☰ Contents
AISA v2.0 / Technical documentation / Stages S3 –S4 — Test, corrections and the merge request

Stages S3 –S4 — Test, corrections and the merge request

F verified factP decided planC open challenge

P Stage correspondence. S3 Test; S4 Validation. 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

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 customer-specific development module (id source), two different checks are deliberately separated. S3 is mechanical: does it build, do the tests pass, does the object exist and answer on the environment. S4 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 S5's scripts be approved (DG-7).

What happens

Stage What happens Who
S3 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 S7) F: [release audit]; eval sets where agent behavior changes [F: the CEO answer — agents err, tests gate] test runner (mechanical)
S4 corrections reviewer (isolated, no author reasoning/transcript; relevant requirements and evidence retained) + 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 S5'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.validator for judgement; the human at S4
Isolated sub-agents source.validator — 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 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, taken from real changes

P The reviewer is isolated: no author reasoning or transcript; original objective, requirements, source/environment evidence, dependencies and uncertainties are retained. Its checklist is the diff, the test placement, the internationalisation set, project-file bumps and configuration hunks — the shapes real reviews caught.