Module Research Notes
This guide is grounded in the live module package, not a wish-list. Below is the evidence gathered by reading the Compliance module's own files — the manifest, config sidecars, controllers, models, migrations, seeder, helpers, and tests — and the capabilities they confirm.
Provenance
The suite began by relocating ERPat's core Disciplinary feature into a self-contained module under the Feature Modularization Runbook (specs/modular-architecture-documentation/20-FEATURE-MODULARIZATION-RUNBOOK.md) and the module-file contract (.claude/rules/module-files.md). The disciplinary behavior was preserved 1:1 — only the identity (slug, setting, URLs, menu) was renamed to compliance. The ten additional areas were then built natively on the same ERPat architecture, following the roadmap in specs/implementation-compliance-module/.
Files inspected
Manifest & config sidecars
module.json— slugcompliance, version 1.2.0, category Human Resource.config/module_config,routes,permissions,menu,default_menu.config/settings,settings_lists,system_logs,user_guides,control_tokens.config/api_routes,euapi_routes.
Code & data
- 14 web controllers +
Compliance_api/Compliance_euapi. - Models per area (disciplinary trio plus the ten newer areas' models).
- Module migrations (tracked in
migrations_compliance). ComplianceDemoSeeder, helper functions, and the module test suite.
Capability evidence
- Twelve independently-gated areas — Overview, Disciplinary, Investigations, Corrective Actions, Disclosures, Speak-up & Grievances, Training & Certifications, Policies & Attestations, Compliance Calendar, Reports & Analytics, Audit Log, and Configuration — each with its own menu item, route, controller, and permission key.
- 19 tables across the areas (see the Data & Screen Reference for the per-area breakdown); the disciplinary trio predates the module, the rest are created by module migrations.
- Workflow evidence read from the controllers/models: disciplinary New/Open/On Hold/Closed; investigation phases Planning → Interviews → Evidence review → Findings review → Closed; disclosure review → manager input → legal review → mitigation → closed; obligation statuses on track / at risk / overdue / approval pending / done.
- 46 system-log event keys registered in
config/system_logsunder the Compliance category — every create/update/delete across the areas leaves an audit entry. - Two REST surfaces (integration + employee self-service) with unchanged disciplinary URLs and operation names.
- 5 module tests in the module's own
tests/suite (run withphp erpat module:test Compliance), covering the module's structural contract and behavior.
Documented boundaries
- Industry category presets (Settings → Initial Data) intentionally stay in core — a module's
config/is not reachable by CI'sconfig->load(); the core flow consumes this module's globally-loadable model. - Notification event definitions remain in the shared core notifications subsystem; the module only emits into it.
- Permission keys and disciplinary table names were preserved (not renamed) to avoid grant and data migrations.
- The Overview dashboard owns no table — it aggregates the other areas read-only, which is why there are 12 areas but 19 tables.