Stage S3 — Implementation
P Stage correspondence. S3 Implementation. These are the same stage identities used by the product overview and case walkthrough. A checkpoint or nested task conversation stays inside its owning stage.
Purpose
In the customer-specific 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 S3 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 — the stage profile, one bounded instance per declared source the change touches. Its declared-source variants are siblings: backend service nodes, the UI, PL/SQL, and any other source a customer plug-in declares. No source is the default (D184): a case that names none is worked by the generic profile from the approved brief, never routed to the backend by accident |
| 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 | Customer-Specific 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, where it writes, the shared skill common.effect-applier (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 S5.
- 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 No repository is privileged (decision Vladimir, 10.09.2026 — D184). The manifest's stage profile is the generic source.implementer and the four declared sources are profile_variants of it, the same shape Data S2 uses for its investigator domains. A manifest's default profile is a dispatch seam, not a universal specialist: with a concrete variant as the default, a UI-only change whose case named no variant would have been handed to the backend implementer.
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.