sb-gap-analysislisted

# Analyze the distance between the need and what exists ## Apply project language style Before authoring any artifact or user-facing prose, read: ```sh specbind rule read language-style --for consume ``` Apply returned policy only to natural-language prose. `NO_CHANGE RULE_ABSENT` means no additional project preference; any `ERROR` line stops the workflow. Establish what the repository already provides, name precisely what is missing, and hand the next phase material it can decide from. **You inform. You do not decide.** Read the protocol before you start. It owns how evidence is gathered, how gaps are named, and how uncertainty is handled: ```sh specbind protocol read gap-analysis ``` ## 1. Read ```sh specbind spec status <spec> specbind artifact list <spec> specbind steering list ``` Then: - the Spec's brief — always - **every** steering document the listing named - the Requirements, when the Spec has them - the existing research, when one exists - the contract, and the contracts across a seam this work touches, when boundaries are in scope An `ERROR` line from `steering list` or `steering read` stops you. An analysis built against a knowingly partial view of the project's constraints is worse than none, because it is persuasive. Read the project's own preferences through its rule surface: ```text specbind rule read design-principles --for consume specbind rule read contract-principles --for consume ``` The second read is required when boundaries are in sco