Stages S4–S5 — Test, corrections and the merge request
Purpose
P Review boundary from the typical cases: the module enforces its reviewed-MR path as a target practice even where the historical estate used direct environment-branch commits. Review the entire intended change series. Generated GraphQL/schema output, lockfiles and agent/tooling instructions remain reviewable because they can change runtime or build behaviour; deterministic regeneration and focused diffs make them reviewable, not exempt. The same person may hold the necessary roles, but each scoped decision remains recorded. Case journeys supplies the per-case falsifying variants.
In the Development module (id source), two different checks are deliberately separated. S4 is mechanical: does it build, do the tests pass, does the object exist and answer on the environment. S5 is judgement: an isolated reviewer who never saw the author's reasoning reads the diff, and the human iterates with them until both are satisfied. The stage ends at the merge request, reviewed under the estate's own development process — a gate record, not a transcript line.
Inputs → Outputs
In: the commits, the pipeline result, the test plan the brief named. Out: green gates per repository, the reviewer's verdict, the merge request with its id — and only then may S6's scripts be approved (DG-7).
What happens
| Stage | What happens | Who |
|---|---|---|
| S4 test on env | per-repo gates: dotnet build (authoritative F: [LSP rule]) + unit tests; nx build/test + UI runs; PL/SQL source-signature proof and one real call (G11; the apply is S8) F: [release audit]; eval sets where agent behavior changes [F: the CEO answer — agents err, tests gate] |
test runner (mechanical) |
| S5 corrections | reviewer (isolated, no author context) + the human iterate until satisfied; failed checks loop to S3. The stage ends at the merge request: every case publishes one, reviewed under the estate's own development process, before S6's scripts may be approved (DG-7). The review is a gate record, not a transcript line | reviewer, human, the estate's reviewer |
What runs this stage
| Agents / handlers | deterministic source.test_runner handler; source.reviewer for judgement; the human at S5 |
| Isolated sub-agents | source.reviewer — given the diff and neither the author's transcript nor the case's reasoning |
| Memory domains it reads / proposes to | source/<repository> build truths; the reviewer boots from the review checklist (Agents Memory) |
| Skills it runs | worktree + build + test runner · release audit where a promotion is being proved (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, taken from real changes
- S5 ends in a merge request; the pipeline result is S4 evidence; the deployer merges under H4 (G7, DG-7). The MR link, the reviewer's verdict and the pipeline id are gate records.
- S4 is not vacuous for a promotion: for a PL/SQL or config promotion the test is the signature proof on the source environment plus one real call; S8 repeats the call on the target (G11).
- Browser evidence from a customer-facing environment is handle-substituted at the browser connector before it reaches a model or a paper (D116).
P The reviewer is isolated: no author context or transcript; source/environment evidence is retained. Its checklist is the diff, the test placement, the internationalisation set, project-file bumps and configuration hunks — the shapes real reviews caught.