git:20260930.e6aaeed to git:20260930.da9ea73
3 added, 2 removed. Audit A to A.
---
name: blueprint-from-collection-acceptance
description: "Prove each must-have from the spec works end to end inside the Workers runtime, one test per must-have."
---
# Must-haves, proven
The spec numbers the must-haves. For EACH one:
1. Write a test in `test/acceptance.test.ts` named after it (`must-have 1: …`) that walks the real flow through the
Worker (`SELF.fetch`) on the test D1 — create what it needs, do the action, and read back the result the user
would see.
2. If the must-have is limited to some people (signed in, an owner), the same action by someone else is refused.
3. If a must-have does not work yet, make it work — this step is where gaps between the spec and the app close.
- When that means building one of the source's actions (`.blueprint/actions.json`), build it as its entry decides; the
- actions step then finds it done.
+ When that means building one of the source's actions and `.blueprint/actions.json` decides it `feature`, build it as
+ its entry says; the actions step then finds it done. If the entry decides `manual` or `drop`, the spec contradicts
+ itself: ask through the blueprint question tool which one holds, and stop.
4. If a must-have cannot be tested through the API (it is purely visual), test the screen instead and say so in a
comment on the test.
Do not add features that are not must-haves.
Done when the check passes: `test/acceptance.test.ts` exists, `yarn build` and `yarn test` succeed.
## Always
- Read `.blueprint/spec.md` first. It is the agreed specification; do not widen it.
- When you need a decision, ask it through the blueprint question tool and stop. Do not guess.
- Do not run `git init`: a new repository loses the folder's trust and the next unattended step stops at Claude
Code's trust prompt. The user adds git themselves after the build if they want it.
- Say you are done by stopping; the executor runs the check. Do not claim success yourself.