What Happens Here
Two tracks in parallel: build the net, build the fleet
Stage 2 has no demo. It produces a suite that runs, a pipeline that goes red when it should, and agent definitions in a folder. That is why it gets compressed in most programmes. It is also what makes Stage 3 safe.
If this stage slips, the pilot slips
We would rather move Stage 3 back two weeks than start generating code at volume into an unenforced suite. On a platform whose clients depend on its calculations and alerts being right, that is the difference between a programme that improves quality and one that quietly degrades it while reporting velocity gains.
2.1 — Turn On the Gate
The cheapest big win. Available in week five.
Tests exist. Nothing gates on them. The first move is not writing more tests. It is making the ones you have matter, and adding the analyzer and standards checks alongside them so the gate covers all eight of the production-ready checks.
- Find the true state: what passes, what has been failing for months, what is quarantined
- Fix or explicitly quarantine every failing test. No ambiguous middle
- Wire in the analyzer rule set agreed in Stage 0 — ESLint on the React side plus the backend’s linters and static analysis
- Turn on the gate: red build blocks the merge, with no override that leaves no record
- Hold the line for two weeks. This is social more than technical
- Publish the pass rate where the team sees it daily
Expect friction in week one
Builds will break for reasons unrelated to the change in hand. That is the accumulated cost of the tests having been optional, paid at once. It settles quickly, and after that the suite becomes something the team defends instead of routes around.
2.2 — Characterization Backfill
Where agent-generated tests are worth more than agent-generated features
Most of n.tasc has no test and no written spec. Writing specs first takes months. Characterization inverts it: run the code, capture what it does, assert it keeps doing it. Current behaviour becomes the reference. That is exactly what you need to spot a regression, as distinct from a pre-existing bug.
The suspicious-behaviour list
Characterization pins current behaviour, including behaviour that is wrong. Every case where the captured output looks incorrect gets raised as a finding, not frozen into a test. This list is usually uncomfortable and one of the more valuable things the stage produces — it is where long-standing defects nobody had a reason to look at come out. Each item goes to the module steward: fix it, or record why it is intentional.
2.3 — Golden Datasets
The biggest ask in the programme, and it cannot be delegated
Detail in QA & Test Readiness. In Stage 2 the work is: build the scenario families with your Domain Owners, agree the reference outputs, freeze them, and wire the Critical-Logic Verification Agent to run automatically when the change map raises the restricted-zone flag.
The scheduling risk, named now
Golden datasets need your most experienced domain people. Those are the same people busy with client work. Two to three days per scenario family. It cannot be substituted with agent-generated data, because the datasets exist to check the agents. If this time is not protected in weeks five to eight, Stage 2 slips and the pilot goes with it.
2.4 — Integration and UI Harness
Real database, real database logic, real journeys
2.5 — Building the Fleet
One at a time, in the order the pipeline consumes them
Spec and Architecture come first. Every downstream agent inherits their output quality. A weak change map produces confidently wrong code no matter how good the coding agent is.
| Week | Built | Proven against |
|---|---|---|
| 5–6 | Spec, Architecture & Impact | Replayed on 10 past changes. Does the change map match what was actually touched? |
| 6–7 | API Contract, Bug Triage, Regulatory Watch | Replayed on past breaking changes, past bugs, and the circulars gathered in Stage 1 |
| 7–8 | Characterization Test, Test & QA | Coverage produced. Defects caught when a known past regression is put back deliberately |
| 7–8 | Code Review Agent | Replayed on 20 past pull requests. Does it find what the reviewers found? |
| 8–9 | Backend, Web UI — React, Data & Migration | Small real changes, read line by line by the module steward |
| 9 | Critical-Logic Verification, Release Pack, Knowledge Update | Verification agent replayed on a known past defect in critical business logic |
Replay validation — how an agent earns its place
- Read-only credentials confirmed. No deploy, DDL or protected-branch merge rights anywhere
- Agent workspaces scoped so an agent cannot reach outside the repositories it needs
- Audit logging of every agent run, at the agreed retention
- AI-assisted commits tagged
- Kill-switch drill run and documented. Not assumed to work
Stage 2 deliverables
Enforced CI gate with a green suite and analyzer rules · characterization coverage on the priority list · suspicious-behaviour findings with steward decisions · golden datasets frozen and wired in · integration and UI harness running · all fourteen agents built and replay-validated · audit and kill switch verified in practice.