What this plan assumes, and what would change if we are wrong
Why This Section Exists
So you can see exactly what we guessed at
This plan was built from a scoping conversation plus public information about n.tasc. Several things we would normally pin down before writing a schedule are still open. Each one is listed with what we assumed and what changes if the answer is different.
None of these blocks anything. The sequence holds under any answer. What they affect is duration, the order agents get built, and in a couple of cases whether a workstream is in scope.
Confirmed vs open
Codebase and Architecture
Where does the cycle time actually go today?
Split across spec, working out what to touch, coding, testing, review, regression and deploy.
Assumed: coding and manual regression are the two biggest bands, with review a close third. If different: this changes which agents get built first in Stage 2. If, say, spec-writing turns out to be your biggest band, the Spec Agent moves to the front and the coding agents move back. Stage 0 measures this before we commit to an order.
Which React and backend versions are in play?
One current React version across the app, or older code alongside newer? Same question for the backend services.
Assumed: mixed, older patterns in the core and newer versions at the edges. If different: a uniform, current stack makes the test tooling simpler and the characterization backfill faster. An older stack constrains the test tooling slightly but changes nothing structural.
How many projects, and how big is the codebase?
A project or repository count is enough. We do not need line counts.
Assumed: a moderate codebase, in the tens of projects. If different: drives the Stage 0 audit effort and the size of the backfill. A bigger codebase stretches Stages 1 and 2 rather than changing their content.
Which database, and how much logic lives in the database layer?
Where the business logic sits matters more than which engine it is.
Assumed: some business logic in the database layer. If different: if logic is mostly in the backend services, the Data & Migration Agent shrinks a lot and integration testing gets simpler. If the database carries more than we assume, that agent becomes one of the most valuable in the fleet.
Are there hard latency or throughput constraints in the real-time paths?
For n.tasc, correct but slower is still a regression.
Assumed: real-time paths with meaningful latency expectations, but no formal performance suite today. If different: hard SLAs move performance regression checks from Stage 5 into Stage 2, as a gate rather than an addition.
Are there coding standards written down anywhere?
A style guide, ESLint or static-analysis rule set, or PR checklist.
Assumed: conventions exist in practice but are not written down or enforced by tooling. If different: an existing rule set is a head start — the patterns file starts from it rather than being derived from the code, which saves a week.
Process and Organisation
What is the headcount on n.tasc, and the role split?
Developers, QA, BA, DBA, release. How many are shared with the sibling products?
Assumed: one squad of roughly six on n.tasc, some roles shared. If different: this is what the 14 weeks is built on. Smaller stretches every stage and justifies a leaner fleet in a different order. Larger parallelises Stage 5 and compresses rollout.
“Dedicated people for every task — we would want to change”: change to what?
The brief stopped mid-sentence. Two readings, two different sections of this plan.
Assumed: today one person owns each module or task, and you want any engineer to be able to work anywhere. That is what Role Transformation addresses. If different: if you meant you do not want to staff the transformation itself with dedicated people, that is a resourcing constraint and it changes the staffing model in the timeline, not the role model.
How does a requirement become a spec today, and who writes it?
This is what the Spec Agent has to fit into.
Assumed: written by a BA or the tech lead, in a format that varies. If different: a consistent existing template gets encoded directly and the agent's output slots into your current process with no change to how anyone works.
Source control and CI platform, and where does the pipeline stop?
Azure DevOps, GitHub, Jenkins, TFS. And how much of the path to UAT is manual.
Assumed: a working build pipeline that does not enforce tests, with some manual deployment steps. If different: affects Stage 2 effort only. We would not recommend migrating platforms mid-programme under any answer.
Who runs UAT and who signs off?
You said UAT is yours. We want to confirm the boundary.
Assumed: UAT runs in your environment with your sign-off, and client acceptance happens separately after. If different: if clients test in your UAT, the UAT Pack becomes a client-facing document and its format needs their input.
What does code review look like today?
Every PR, or only some? How long does a review typically wait?
Assumed: reviews happen but are not mandatory on every change, and waiting for a reviewer is a real part of the cycle. If different: if review is already rigorous and fast, the Code Review Agent contributes less and moves down the build order.
Governance and Scope
Do any client agreements constrain AI-assisted development?
Disclosure obligations, or restrictions on where code may be processed.
Assumed: no explicit constraint. If different: a disclosure obligation is easy to meet through commit tagging. A restriction on processing location needs resolving before Stage 2, because it affects tool choice.
Are there modules that should be off-limits to generation entirely?
Your call, not ours, and revisable at any time.
Assumed: none prohibited outright, with the restricted zone gated by golden datasets and a named owner. If different: prohibited modules are excluded in memory and every agent respects it automatically. This costs almost nothing, so use it freely wherever it gives your domain owners confidence.
Are the sibling products in scope?
n.prime, n.image and n.feed run on different stacks.
Assumed: out of scope for these 14 weeks, entering as Wave 4 with separate scoping. If different: bringing one forward extends the programme rather than fitting inside it. The fleet needs adapting for a different stack, not pointing at a new repo.
Is there an existing defect classification we should match?
Severity definitions, SLAs to clients, escalation paths.
Assumed: an informal severity scheme. If different: the Bug Triage Agent adopts your scheme directly, which makes its output immediately usable in your current workflow.
How to use this section
The fastest way to sharpen the plan is to correct the assumptions above. Two matter most: where the cycle time actually goes (shapes the fleet build order) and headcount (shapes the schedule). Everything else is refinement. We are happy to revise and reissue on your answers before any commitment is discussed.