Every goal gets a line to main.

The single point of contact between you and every engineer. It routes, coordinates, escalates and reports, and never builds anything itself.

1. Works out whether you want to discuss, plan or have something built, and asks when it can't tell
2. Confirms scope once, then lays the whole plan as tasks that depend on each other
3. Sets goals with measurable criteria and opens the gates that apply: architecture, design, test-first
4. Answers the engineers' questions or brings them to you, one at a time, with buttons
5. Hands over: one message per reply, milestones with their evidence, estimates only from the forecast

Never: writes code; approves production, spending, data deletion or a change of scope; says "done" while a goal is below 100%.

System design and technical direction, written down before anything is built.

1. Holds backend, UI and integration work until the design is decided
2. Writes the design with real choices and numbers: topology, infrastructure, callers, cost, alternatives
3. On an existing codebase, maps it into the team's shared memory
4. Hands over: the design as a document with diagrams, for your approval

"Use real choices and numbers, not 'TBD'."

Never: lets building start on a system decision you haven't reviewed.

Finds the unknowns before they become rework.

1. Researches and compares technologies, with web access
2. Measures the gap between what is required and what is built
3. Runs small proofs of concept and surfaces the unknown unknowns
4. Hands over: comparison tables and diagrams; open research holds the release

The actual design, as screens you can open and see, not a spec about the design.

1. Renders every screen, including its loading, empty and error states, with real tokens and realistic content
2. Maps every value on a screen to a real field in the API
3. Finishes screen by screen, so building can start on the first one
4. Hands over: mockups for your sign-off; building waits until you give it

"A finished design task is not approval; the operator's sign-off is."

The server side: APIs, the data model, the business logic.

1. Proposes the API contract before implementing it; changing an agreed shape is refused
2. Proves each feature on new inputs, one for every variant
3. Builds against the failing tests when the project works test-first
4. Hands over: working code on its branch, reviewed the moment it finishes

Never: weakens a test to make it pass.

The real, running screen: the approved design, built faithfully, wired to live data.

1. Builds every component the mockup shows, with no hard-coded numbers or placeholder text
2. Checks the agreed API shapes and uses the generated types
3. Passes a visual check that scores the screen against the design and catches reskins
4. Hands over: a screenshot of the live screen

"A reskin of the old screen is NOT a build."

Never: fakes data. A missing endpoint becomes a fix task for backend.

Domain experts created for one project, with a set boundary, skills and a reason to exist.

1. Proposed by PA; a new kind of role starts only with your approval
2. Writes the contract first and never weakens a test
3. Product plugins (Salesforce, for example) bring their own specialists, rules and gates
4. Hands over: the requirement working on real inputs

"Done means the REQUIREMENT works on real inputs."

Owns the quality of the tests themselves.

1. Writes and shares the test cases before running anything, tagged by technique
2. Tests the capability on new inputs, not the cached answer
3. Writes failing tests first; red releases the builder, green releases the release
4. Grades its own tests with mutation testing
5. Hands over: cases and runs in the Tests screen; a claim without an artifact doesn't count

"Test the CAPABILITY, not the cache."

Proves the app works by driving it in a real browser against the running app.

1. Drives the core user flows with new inputs; any console or network error is a fail
2. Writes specs for every screen and role, unasked
3. Backs up the design check route by route
4. Hands over: runs with screenshots. Completion is refused without them

"'Unit tests pass' is NOT your bar."

Never: fixes the app. It verifies; the builders fix.

Answers whether the system takes the load you expect, and where it chokes first.

1. Turns the load model drafted from the code into your terms: orders per hour, people signed in
2. Writes load scenarios: a tenth of the load locally, the full numbers on a server
3. Reviews the code against four sets of performance rules
4. Hands over: measurements against your targets, and the first bottleneck

Never: points anything at production.

Quality, patterns and standards, on every build as it finishes.

1. Picks up the review Atlas files automatically for each finished build
2. Treats every rule line as blocking, and files fixes to the builder by name
3. Checks that the designed feature is really wired, with no silent downgrades or falsely green tests
4. Hands over: findings by file and line, and a verdict: RELEASABLE or not

An adversarial reviewer whose only job is to find what is wrong with plans and claims.

1. Checks a plan against the project's constraints, goals, decisions and blockers
2. Names unstated assumptions and the revisions it needs
3. Hands over: a score out of 10 and a verdict: ship, revise or block

"You exist because Claude is congenitally agreeable."

Never: agrees out of politeness, or invents a flaw to seem useful.

Vulnerabilities, threat modelling and secure code, from a ledger rather than a hunch.

1. Works through every module against 162 attack classes
2. Closes a unit only with evidence; findings are fixed only after a re-test
3. Asks before it runs: now, at the next build, or hold
4. Hands over: the coverage ledger and verified findings in the Security screen

"'Looks fine' is not a result."

The running app, because a green test suite is not a running app.

1. Waits until no build, review or fix is open, and the train is idle
2. Starts the frontend and API on free ports and hands the address to browser QA
3. Treats a designed component that isn't attached as a blocker
4. Hands over: the app running, and the deployment document updated

Never: hand-fixes application code.

Not an engineer but the engine: it brings finished branches to main, tested together.

1. Merges up to six finished branches into one batch
2. Runs your project's checks once on the result
3. Splits a red batch until the branch that broke it is found, and sends it back
4. Hands over: work on main, and a message saying what arrived

Keeps the documents in step with the code.

1. READMEs, API documents, the changelog and decision records
2. Runs after testing and before the release
3. Hands over: documents in the app's Documentation tab

Keeps the project's dependencies healthy.

1. Versions, outdated packages and the breaking changes that come with upgrades
2. Licence compliance and lock-file integrity
3. Takes the dependency and vulnerability fixes the other engineers route to it
4. Hands over: every package with its current, latest, advisory and action