The Agent Fleet

Takes a requirement however it arrives — email, call notes, a ticket — and writes a spec with testable acceptance criteria. It works from your own past specs, so the shape matches what your team already builds from. Anything it does not know becomes an open question rather than an assumption.

Reads the approved spec against the real solution and says exactly what is in scope: which services, React components, database logic and config tables. It also raises the restricted-zone flag when a change touches business-critical calculations or rule engines, which routes it through the restricted gate.

Your engines and UI are built on the API, so the contract gets designed and signed before anyone writes code behind it. The agent diffs the proposed shape against the existing surface, classifies it additive or breaking, and drafts the deprecation and notification plan when it breaks something.

Works on a feature branch, reuse first. It has to find the existing service, repository or helper before writing a new one, and follow the conventions already present in that project. It never touches a file the change map did not authorise, and never edits restricted-zone code without routing through agent 11.

Works in the React idiom already in the codebase. Components, hooks, state management, routing and the existing component and state conventions. For dashboard work it follows the display conventions already in place: refresh behaviour, alert prominence, and the fact that an operations user reads that screen under time pressure.

Where real business logic sits in the database, code generation without database awareness is worse than useless. This agent writes forward and rollback migrations, query and database-logic changes, and an index and query-plan note. It reads the live schema, so it never guesses a column name. It never runs DDL anywhere.

This is what makes the rest safe. Point it at an untested part of n.tasc. It runs the existing code and writes tests that pin what it does today — no spec needed first. Anything it captures that looks wrong gets raised as a finding, not frozen into a test.

Unit, integration and Playwright journey tests mapped one to one to acceptance criteria. Plus the cases n.tasc needs and people forget: empty data sets, a missing upstream feed, stale data, expired records, a value sitting exactly on a configured limit. It also generates the synthetic test data.

Takes a defect however it arrives, finds the likely code, drafts a failing test that reproduces it, and writes the ticket in the shape your team already uses. Where the defect sits in a client-specific module rather than the core product, it says so, because the fix path differs.

Your releases stay on request. What changes is that each one arrives in the same shape: what changed and why, the UAT checklist derived from the acceptance criteria, known limitations, the migration scripts to run, and the rollback plan. Assembling that by hand costs half a day per release.

After each completed change it updates .ai-memory/: new patterns, decisions the PO or tech lead made, things reviewers pushed back on, dead ends worth not repeating. Skip this and the fleet is exactly as good in month twelve as it was in week one.