Stage S3 — Implementation
Purpose
In the Development module (id source), the brief is approved and names the seam. This stage writes the change inside that seam and nowhere else. A widened diff is not diligence; it is a blast radius nobody approved.
Inputs → Outputs
In: the approved brief — the seam, the branch set, the test plan, the contract paper where two repositories are involved. Out: commits in isolated worktrees per repository, a failing test first where the change is a defect fix, and the pipeline run that S4 reads as evidence.
What happens
| Stage | What happens | Who |
|---|---|---|
| S3 implementation | isolated git worktrees per repo; repo-profiled implementers booted from their source/<repo> domain; camunda developer / db extractor sub-agents as needed |
implementers |
What runs this stage
| Agents | source.implementer.<repository> — backend service nodes, the UI, PL/SQL, and any other declared source |
| Isolated sub-agents | the Camunda developer and the database extractor, spawned when the change reaches those surfaces |
| Memory domain it owns | source/serdica-backend/<service> · source/serdica-ui · source/db-plsql · source/intentgpt (Agents Memory) |
| Skills it runs | worktree + build + test runner · PL/SQL snapshot + signature · PL/SQL apply with precondition (Agents Memory and Skills) |
| Its branch of the graph | Development Module § 0 — the module's agent tree, its memory branch and its skills · the component list is Components — Development |
Every stage also uses source.root — the only profile that reaches the human — and the platform's write_executor and write_auditor (Gating).
Rules this stage carries
- A change spanning two repositories carries a contract paper (G5): the DTO / route / message shape both sides agree on, and the deploy order (backend before UI, or the reverse) in S6.
- Worktree files pass the secret scrubber before a model reads them (D116): customer branches carry real database passwords in
appsettings.json, so connection strings, passwords and tokens are handle-substituted before implementers see file content.
P An implementer is repository-profiled: it boots from its own source/<repo> domain and knows that repository's build truths, its layout and its conventions. It does not learn another repository's; a change that needs one recruits that repository's agent, and the two-failed-attempts rule sends an unknown contract to its owner rather than to a third attempt.
P Worktrees are isolated per repository so that two implementers on one case never share a working tree. What crosses between them is the contract paper, never a file.