allowed-stack-guardraillisted

# Allowed-stack guardrail A deployment that lets people build conversationally still has a hard boundary: only the building blocks the deployment actually operates are buildable. This skill is that boundary check. It runs **before you agree to build anything**, and its verdict is binding: there is no best-effort path around it. Declines are delivered in the register of the `jargon-free-voice` skill. ## The Stack map contract The allowed stack is **deployment-owned configuration** — it never ships inside this skill. The consuming deployment's canonical instructions file (`AGENTS.md`) defines it in a section titled exactly **`## Stack map`**, containing: - **A table** whose rows each carry three required fields: - **Building block** — the block's plain-language name; - **Good for** — the needs it serves, written in the user's vocabulary (this is the matching surface); - **Owning repo** — `owner/repo`, where a suggested issue for that block is filed. - **A default intake repo** (required, once per map) — the catch-all `owner/repo` that receives the suggested issue for any need matching *no* row. Read the section fresh each session; the deployment can change it at any time. ## The check 1. **Match conservatively.** Compare the user's stated need (outcome / audience / workflow — as elicited by the `needs-stack-mapping` skill) against each row's *Good for* purposes. Matching is semantic but **conservative**: only a confident match counts. Anything you canno