Stage 5 — Weeks 11–14

Rollout

Across every n.tasc module, then the path to the sibling products

Not a Second Pilot

Extend what worked. Do not repeat the discovery.

The fleet, the memory structure, the CI gate and the test harness already exist. What each new module needs is its own context: module docs, glossary entries, patterns, characterization coverage, a named steward. That is a defined intake process, and it gets faster each time because the shared assets are already there.

5.1 — Rollout Order

Sequenced by criticality and readiness, not by who asks loudest

Four waves

WAVE 1 Modules next to the pilot — same team, similar patterns, outside the restricted core Entry: module docs written, glossary entries added, steward named WAVE 2 Remaining modules outside the restricted zone, plus the full API surface Entry: characterization coverage on main paths; endpoint inventory complete WAVE 3 Restricted-zone modules — business-critical calculations and rule engines ⚠ Entry: golden datasets cover the module; domain owner engaged; verification agent proven on a past defect WAVE 4 Sibling products — n.prime, n.image, n.feed Separate scoping. Different stacks mean adapting the fleet, not copying it

Restricted-zone modules come last on purpose

By Wave 3 the team has months of practice, the golden datasets are mature, and the review reflexes are set. Starting here would mean starting at the hardest point with the least experience. One bad outcome in the calculation engine ends the programme regardless of how well everything else is going.

5.2 — Module Onboarding Checklist

Same steps every time. Three to five days per module by the third one.

What onboarding a module means
Steps 1 to 3 are the work. Steps 4 and 5 are the proof.
1
Write the module doc
Purpose, boundaries, known quirks. Drafted by an agent, reviewed by the current owner — they are the source.
2
Extend glossary and patterns
Business terms through to backend service, React component, API and table. Any conventions specific to this module.
3
Backfill characterization
Main paths pinned. Suspicious-behaviour list triaged by the steward.
4
Name the steward
Written remit: keep memory current, review changes, do not be the only author.
5
Ship one real change
Through the full fleet, with the steward reviewing closely. Not onboarded until this is done.
  • Restricted-zone classification confirmed; generation-prohibited status set where the owner wants it
  • Performance-sensitive paths marked in memory
  • Any module-specific lint or static-analysis suppressions reviewed rather than inherited silently
  • The module's own defect history read into the test priority order

5.3 — Enablement and Handover

It has to keep working after we leave

📚

Working sessions, not slides

Every engineer runs a real change through the fleet with someone alongside. Sessions are recorded and become onboarding material for future hires.

🔧

Internal agent maintainers

Two or three of your engineers learn to write and change agent definitions. Agents are software. They need maintainers who are not us.

📋

Runbooks

Onboarding a module. Adding a golden dataset. Diagnosing an agent producing poor output. Disabling one in a hurry. Updating the patterns file when a convention changes.

👥

Steward network

Every module has a named steward. Stewards meet monthly to keep memory honest and share what the agents keep getting wrong.

Stage 5 deliverables

All n.tasc modules onboarded with docs, glossary, patterns and coverage · restricted-zone modules brought in behind golden datasets · every engineer trained on real work · internal agent maintainers established · runbooks handed over · scoping note for the sibling products.