Components — Customer-specific development module
Purpose
For the customer-specific development module (id source), Customer-Specific Development Module says what the module does and Stage Planning says where a change goes. This page says what has to be built: every component, its kind, what it consumes and produces, how it is proved done, and who can build it without waiting for anyone else. It is the phase-1 deliverable for this module and the work breakdown for phase 2 (Delivery § 1, Delivery § 1.4).
The six component kinds are defined once, in Components — Configuration § 0.
What makes this module's breakdown different. Configuration splits by stage and Support by symptom domain. Development splits by source — one implementer agent per repository or per database side, because the repositories differ in language, build system and failure modes, and because the customer's lineage is not the main branch. The module is built against the idea of a source, never against one estate: a source is a configuration row naming its repositories, its database side, its branch model and start flows, its seam catalogue, its build and test gates and its deploy mechanism (D58).
1. The map
flowchart TB C["Brief, branch set
release contract"]:::store A["Planner and
repository profiles"]:::work S["Build, test, port
and release checks"]:::work G["Auditor, gates and grants"]:::decision X["Connector execution"]:::work P["Serving version
and customer proof"]:::proof M["Regression and
lineage knowledge"]:::learn C -->|"validated input"| A A -->|"invoke"| S S -->|"effect proposal"| G G -->|"authorised operation"| X X -->|"recorded result"| P P -.->|"learn after result"| M M -.->|"published revision"| A classDef work fill:#eef4ff,stroke:#6889ba,color:#17365b,stroke-width:1.3px classDef decision fill:#fff4df,stroke:#b78c36,color:#65470d,stroke-width:1.5px classDef proof fill:#e9f5ef,stroke:#689b81,color:#224e39,stroke-width:1.3px classDef learn fill:#f1edf9,stroke:#9580b9,color:#534172,stroke-width:1.3px classDef store fill:#f5f7fa,stroke:#98a6b7,color:#34445a,stroke-width:1.2px classDef owner fill:#24486b,stroke:#24486b,color:#ffffff,stroke-width:1.4px click C href "../contracts.html" "Inputs, selected plan, obligations and signed result contracts are built first." click A href "source-module.html" "planner; repository implementers; test runner, validator and deployer" click S href "../50-agents/agents-memory.html" "Deterministic procedures and assertions; no target permission is inherited from a skill." click G href "../gating.html" "Every applicable requirement is bound to the current proposal." click X href "../contracts/Connectors.Abstractions.cs.html" "Registered read operations and separately granted effects use their own recovery form." click P href "../case-protocol.html" "Verify the complete requested target and any external dependencies." click M href "../50-agents/agents-memory.html" "Record outcome; evaluate proposed knowledge or skill changes before reuse."
Development component responsibilities. The tables below enumerate each profile, skill and connector; this map shows their contracts and handoffs.
2. Contracts
| Component | What it fixes | Done test |
|---|---|---|
| The brief | what the human approves before any code: the reproduction or the evidence standing in for it, the chosen seam with the three rejected alternatives, the blast radius, the branch set across every repository and the database side, the test plan per lineage, the deployment and revert path (Stage Planning § PL-4) | a brief that cannot name the branch set is not ready — it means the case does not yet know which code it is fixing. Draft brief.schema.json (D139) |
| The branch set | which code this case is fixing: a branch per repository plus the database model and stored code on that environment's database, each object with its PLSQL-SIG-1 signature (Stage Planning § 3c) |
the set resolves to real branches, and the divergence is measured on demand, never quoted stale. Draft branch-set.schema.json |
| The cross-repository contract | for a change spanning two repositories: the shape both sides agree on, and the deploy order | named in the brief before either side is written (Customer-Specific Development Module § 1). Draft cross-repo-shape.schema.json |
| The handover packet | request → response → completion for Hd in both directions (Agents § 5, D142) | the receiving root plans from the packet alone. Draft handover-packet.schema.json |
P Core Development is handled by Support classification and communication, with an offer and delivery terms. It adds no implementation profile or Source pipeline. The stage inventory identifies responsible profiles and executable tool functions at every stage, including deterministic source.test_runner at S3 .
3. Agents
P The graph — who spawns whom, which sub-agents are isolated, and where the write path runs. The table under it carries every profile in full; the platform-wide profiles these draw on are Agents § 1.
flowchart TB R["Development root"]:::owner P["Planner and
repository tasks"]:::work K["Own index and
selected domain knowledge"]:::learn T["Change and
release papers"]:::store V["Independent code review"]:::proof G["Required decisions"]:::decision E["Execution coordinator"]:::work R -->|"assign bounded task"| P K -.->|"context"| P P -->|"propose and report"| T T -->|"independent evidence"| V V -.->|"verdict"| R T -->|"reviewable packet"| G G -->|"permit"| E classDef work fill:#eef4ff,stroke:#6889ba,color:#17365b,stroke-width:1.3px classDef decision fill:#fff4df,stroke:#b78c36,color:#65470d,stroke-width:1.5px classDef proof fill:#e9f5ef,stroke:#689b81,color:#224e39,stroke-width:1.3px classDef learn fill:#f1edf9,stroke:#9580b9,color:#534172,stroke-width:1.3px classDef store fill:#f5f7fa,stroke:#98a6b7,color:#34445a,stroke-width:1.2px classDef owner fill:#24486b,stroke:#24486b,color:#ffffff,stroke-width:1.4px click R href "source-module.html" "The root owns the bounded objective and confirms child plans." click P href "source-module.html" "planner; repository implementers; test runner, validator and deployer" click K href "../50-agents/agents-memory.html" "Read compatible knowledge; consult its owner for judgement; write only in owned domains." click T href "../case-protocol.html" "Task text, evidence, scope and completed assertions remain durable." click V href "../50-agents/agents.html" "The validator receives scoped evidence without the author's transcript." click G href "../gating.html" "Root presents unresolved scope and permission decisions; it cannot invent authority." click E href "../50-agents/agent-runtime.html" "The deterministic handler applies only a current permitted packet."
Task ownership and review: a profile is reusable across cases. Each task has its own parent, inputs, evidence and restricted tool catalogue; the root remains responsible for the result.
| Agent reference | Role |
|---|---|
| source.root | Customer-specific development root |
| source.planner | Placement planner |
| source.implementer | Source implementer — one instance per declared source |
| source.implementer.serdica-backend | Backend implementer |
| source.implementer.serdica-ui | Frontend implementer |
| source.implementer.intentgpt | Declared behaviour-source implementer |
| source.implementer.db-plsql | Stored-code implementer |
| source.camunda_developer | Process developer |
| source.validator | Independent source validator — validates the change against the approved brief |
| source.deployer | Source release coordinator |
P Implementer agents are per source, and the set is configuration. For the first customer's estate that is a backend repository with a child node per service, a front-end repository, a separate behaviour repository, and the environment databases' stored code. Another customer declares its own sources and gets its own implementer profiles; the module does not change.
P A missing repository node is never a prerequisite. When an agent needs a node that does not exist, a summarizer sub-agent reads the service — its code, its guidance file, its build and test surface, its recent history — and creates the node before the work continues (Agents § 0.6).
4. Methods and executable helpers
P The module method subpage defines the procedures and their optional source/binary helpers. Runtime and connector operations are implementation mechanisms; they are not separately counted as learned skills or tools.
5. Connector operations
| Connector | Operations | Effect class |
|---|---|---|
gitlab |
read; worktree; commit inside the worktree; push the case branch (never a protected branch) to open the merge request; merge under H4; read the infrastructure repository to enumerate a deploy set | controlled Git write; protected branches are never pushed directly |
oracle |
stored-code snapshot and signature; DDL packet with a signature precondition; the dependency sweep; the caller sweep | the effect applier applies DDL under the HW-ddl gate with the identity of the current D65 stage (D104) |
ssh / host |
read-only commands on an allow-list; a privileged command as a gated write | an operations action such as a restart is a write with its own gate |
kibana |
the runtime verification reads | read |
6. Memory domains
| Domain | Owning profile | Holds |
|---|---|---|
source/ |
source.root; planner reads/proposes | the seam catalogue per source, the placement criteria, the port procedure, the branch and environment map |
source/<repository> |
the repository implementer | the service index, build truths, the path map per layout, the packaging model |
source/<repository>/<service> |
the same | per-service knowledge, created on the first case that works it |
source/db-plsql |
the stored-code implementer | the extract-and-apply workflow, the release audit, the exit seams, the per-environment model |
P Divergence numbers live in memory with their measuring query, never as a quoted figure, because they change (Development Details DG-3).
7. What can be built in parallel
| Wave | Components | Notes |
|---|---|---|
| 1 | the brief contract; the planner with the seam catalogue; the worktree and test runner | the planner is the module's core judgement and its eval set is the past changes |
| 2 — one track per source | each implementer agent with its repository domain | disjoint repositories, disjoint domains |
| 2 — beside them | the reviewer; the snapshot and signature skill | the validator needs only diffs and briefs; the snapshot skill is independent of every agent |
| 3 | the deployer, the port skill, the release audit | they consume what wave 2 produced |
8. What this module does not build
- New modules or new product capability. Its scope is defects and small extensions; module-scale work follows the estate's program process (Non-Goals N-8).
- The deploy itself. The platform prepares the packet; the deployment agent resolves the environment's pipeline job by rule and triggers it after the gate (D130), and the effect applier applies DDL under
HW-ddl(Development DG-8, D104). - Changes to the incumbent system's code. Those remain change requests to the customer (Non-Goals N-1, N-10).
Challenges
- P Attribution for the stored-code side is not solved: the source view carries no author column, and the audit trail returned a complete identity for one actor and none for another on the same schema the same day. Artefacts therefore state what changed and when, and name an actor only where an audit row supports it (Stage Planning § 3b).
- C A source that is not in the workspace has unmapped seams; its node is built on the first case that touches it.