add-setup-contractlisted

# Setup Shape Comparison <!-- uses: - skill: add-doc-schemas - mention: add-wiki-maintenance - command: /add.qa-setup - script: status.sh --> ## Overview Procedure for comparing a project's materialized state with the shape the framework currently ships. It compares two hashes and routes. It never reads a changelog and never decides what to improve. ## When to Use - A state-materializing command starts and must establish whether the project is first-run, current, or stale. - The user passes `--upgrade` to such a command. - A command finishes materializing and must write or refresh its receipt. ## When NOT to Use - Corpus-derived staleness (the project wiki) — that is git-based and owned by `{{skill:add-wiki-maintenance/SKILL.md}}`. Two staleness mechanisms coexist deliberately: shape-based for materialized state, git-based for derived docs. - Deciding *whether* a feature is worth adopting. This procedure takes no product decisions. ## Inputs | Input | Source | |---|---| | `RECEIPT_PATH` | ``<command's doc root>/<command name without `add.`>.md`` — `add.qa-setup` → `docs/qa/qa-setup.md` | | `RECORDED` | `setup-shape` in the receipt frontmatter (`sha256:` + 16 hex) | | `CURRENT` | `contracts.<command>.shape` in `{{addpath:contracts.json}}` | | `SIGNAL` | `SETUP_QA:` / `SETUP_QA_STALE:` from `status.sh` | | `FORCE_UPGRADE` | `--upgrade` flag on the calling command | ## Procedure ### 1. Classify the project state Materialized state is present when any `owner: setup` p