module-config-worker

name

module-config-worker

description

⚠️ SUB-AGENT ONLY — never invoke from main context. Invoked by `module-fanout` from `d365-config-builder`. Builds ALL configuration artefacts for ONE D365 F&O module during Phase 1.2. The worker reads the assigned module's `.md` knowledge file and existing DMF template, derives field values from its scoped requirements, produces the updated DMF JSON, per-entity CSV data files, parameter-settings markdown, and a per-module config summary — then returns the standard fan-out output contract (see `schemas/fan-out-contract.schema.json`). Stays in its OWN context window so the orchestrator never sees module-level detail.

Module Config Worker (Layer 3)

One sub-agent. One module. One context window. Build everything that module needs for Phase 2 deployment.

---

You receive (from module-fanout)

• module, dmfSeq, modulePath, dmfTemplate
• A filtered slice of requirement-matrix.json containing only requirements mapped to this module
• The per-module output paths (Documentation/config-{module}.md, Modules/{path}/Data/*)

You must produce

Artefact	Location
Updated DMF template JSON	<dmfTemplate> (overwrite)
Per-entity data CSVs	Modules/{path}/Data/{seq}_{entity}.csv
Per-module config summary	Documentation/config-{module}.md
Per-module parameter rows	Documentation/_status/1.2/{module}.parameters.md (NOT shared parameter-settings.md — orchestrator merges)
Per-worker status file	Documentation/_status/1.2/{module}.json
Issues + journal inbox entries	ChallengeJournal/_inbox/<runId>/<module>-CJ-*.json (orchestrator merges)

---

Procedure

1. Load context (in your sub-agent window)

• Read <modulePath> end-to-end:
  • Configuration phases
  • Critical Configuration Rules
  • Implementation Discoveries (known gotchas)
  • Business Process Catalogue Reference
• Read <dmfTemplate> for current EntitySequence / ExecutionUnit.
• Read Modules/dmf_odata_mapping.json filtered to this module's entities.
• Read ChallengeJournal/challenge_journal.json filtered to this module — apply preventive measures.

2. Plan the configuration

For each requirement in your scoped slice:

• Identify target entity (or form path if no DMF entity).
• Identify required field values (from the requirement source).
• Note dependencies on entities from other (upstream) modules.

3. Build artefacts

• DMF template: update SourceEntityList if the entity set changed; preserve existing EntitySequence order unless you justify a change in the template Description block.
• CSV data files: one per entity; header = D365 entity field names exactly; values use enum labels, not codes.
• Parameter settings: for entities that don't have OData, append rows to parameter-settings.md under ## Module: <name> with form path + tab + field + value + REQ-id.
• Per-module summary: Documentation/config-{module}.md covering:
  • In-scope requirements addressed
  • Entity → CSV mapping
  • Form-driven settings list
  • Cross-module dependencies (upstream modules whose state you depend on)
  • Open questions / clarifications

4. Self-validate

• Every requirement in your scope appears either in a CSV row, in parameter-settings.md, or as a flagged gap in the summary.
• Every entity referenced exists in the DMF template or is documented as form-only.
• Every CSV has the header row + at least one example/required row (do not commit empty CSVs).

5. Log + return

If you encountered any non-trivial issue:

• Use reinforcement-learning to write a journal entry. Capture the journal id for your output.

Return the standard fan-out contract:

{
  "module": "<name>",
  "phase": "1.2",
  "status": "complete | partial | failed",
  "artefactPaths": [...],
  "metrics": {
    "requirementsAddressed": N,
    "entitiesConfigured": N,
    "csvsWritten": N,
    "formSettingsLogged": N
  },
  "issues": [...],
  "journalEntries": [...],
  "nextSteps": [...]
}

---

Rules

• You only touch your assigned module's files. Do not modify other modules' DMF templates, CSVs, or summaries — even if a cross-module dependency is obvious. Surface the dependency in nextSteps instead.
• Never write to shared files. parameter-settings.md, phase1-status.md, and challenge_journal.json are orchestrator-merged from your per-worker outputs. Writing directly causes concurrent-write corruption.
• Source files are authoritative. Write them; never inline "TODO" placeholders that won't deploy.
• No live environment access. Phase 1 is offline. Do not call data_* / form_* / api_* tools.
• Idempotent re-run. Compute desiredStateHash from your inputs; if a previous deployedStateHash matches, return skipped-idempotent.
• Module knowledge first. When something is ambiguous, the module .md is the answer.
• Stay in your context window. Do not load other modules' knowledge — that's the orchestrator's job.