build

name	build
description	Build against a signed acceptance contract, under the protocol's write-scope rules. Dispatches into the vendored production-grade pipeline for full engineering depth, or builds directly for small changes. Use after /freeze, or when the ambient router says the next action is "build".

/build — the half that makes the code

export BLACKBOX_ROLE=build

Set this first. It narrows your write scope by hook, which is what makes the independence claim on the certificate true rather than decorative.

Refuse to start without a contract

Run bb next. If the state is not ready-to-build, do not build — follow what it says instead. Building against an unsigned requirement produces work nothing can certify, and the cheapest moment to catch that is now.

Read .blackbox/intent/CONTRACT.md. That is the requirement. Not the user's latest message, not your recollection of the conversation — the signed file.

Which builder

Situation	Use
New system, new subsystem, anything with architecture, security, deployment or a real test surface	${CLAUDE_PLUGIN_ROOT}/build/skills/production-grade/SKILL.md — 15 specialists, 9 protocols, the v5.5 loop engine
A small change or a one-line fix on an existing, already-certified surface	Build directly under the rules below

When in doubt, dispatch to the pipeline. Its overhead on a small change is minutes; the cost of hand-building something that needed architecture is discovered by the certificate, later, in front of the human.

The pipeline is dispatched, never self-triggering. It does not decide when to run; the router does.

The rules, whichever builder runs

Write scope. You may write product source and the harness seams the Access Contract asks for. You may read the contract and your own code. Blocked by hook: .blackbox/runs/, .blackbox/sealed/, .blackbox/certificate/, and the harness drivers.

Not bureaucracy. If you could see the campaign it would stop being an oracle and become a target — you would satisfy the cases instead of the criteria, and the certificate would measure your aim rather than your work.

Two things you must not do to the contract. Do not implement beyond it; anything not in it will not be verified. Do not narrow it; if a criterion is harder than expected, say so and stop so the human can amend and re-sign. Quietly building something easier that passes is the most damaging defect this protocol can produce, because a green certificate hides it completely.

If you think a criterion is wrong, wrong is a thing to raise, not to route around.

Your oracles are advisory. Types, tests, contract checks, lint, adversarial self-review — run all of them. They make the code good. They do not certify it. Your terminal state is "I believe this is done", which is the claim /verify exists to test, and it will sometimes come back and say you were wrong.

The Access Contract obligation

harness/ACCESS.md says, written blind from the criteria alone, what the verifier must be able to control and observe. Implement those seams — you can see the code, so this is cheap for you and impossible for them.

• Behavioural, not structural: they asked to "read the ledger entries", not to read your table.
• Gate test-only routes behind an environment flag so they do not ship enabled.
• If a control genuinely cannot be provided, say so. It lands on the certificate as UNVERIFIED with your reason. Never substitute something weaker in silence.

The harness ships to the user with the product. A system that cannot be driven from outside usually cannot be operated or debugged either.

Rework

A failed verification hands you the violated criterion, the observed-versus-expected behaviour, and a reproduction. You do not get the campaign or the case that caught it — asking for them is asking to overfit.

Each run draws fresh representatives from the same equivalence classes, so fix the criterion, not the reproduction. A patch that satisfies only the values you were shown fails the next draw, which is the mechanism working rather than bad luck.

Fixes

If bb next reports state=needs-witness, the hook blocks your edits until the reproduction has failed against the unmodified build. Deliberate: once you edit, the evidence that anything was broken is gone, and your repair becomes indistinguishable from a no-op.

Register it, watch it fail, then work.

Handing off

When the pipeline is done, do not announce success. Say what you built and that verification has not run yet, then let the router move to /verify. The certificate decides whether this worked, and it does not exist yet.