spec-gaplisted

The question at hand: **$ARGUMENTS** The blueprint was written to be complete enough to implement from without inventing product decisions — that is the level-2 cold-start bar it passed. It was not written by anyone who had run the code. So gaps are expected, and this exists because the expensive failure is never the gap itself: it is **deciding quietly and building on it**. Work the steps in order. Do not skip step 1 — most reported gaps are answered elsewhere in the set. ## 1. Is it really absent? Search before concluding, roughly in order of hit rate: 1. `blueprint/amendment-log.md` — may already answer it, and overrides the locked files 2. the feature spec's `bp:edge-cases`, `bp:states`, `bp:fields`, `bp:open-decisions` 3. `blueprint/blueprint-overview.md` → `bp:decisions` — the `DR-n` register. **If the question is there, the decision is the implementer's to make** within the recorded constraint. Not a gap; make it, record it in the PR, stop. 4. `blueprint/interaction-map.md` — cross-feature rules, invariants, job semantics 5. `blueprint/data-schema.md`, `nfr-spec.md`, `api-contract.md`, `integration-specs.md` 6. `mvp-pack/mvp-spec.md` — it may be out of scope rather than unspecified ```bash node "${CLAUDE_SKILL_DIR}/../../scripts/spec-lookup.js" --grep <keyword> ``` State what was searched. "Not specified" is a claim that should be checkable. ## 2. Product question or technical one? **Product** if the answer changes what a user sees, what they are promise