sb-contract-reviewlisted

# Review the contract graph ## 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. One review per milestone, between design approval and any task plan, or between reverse Design approval and adoption finalization. The question is **not** "do the Specs in this milestone agree with each other." It is: > Does this milestone leave **every** persistent seam in the project coherent — > including seams owned by Specs it never touched? A Spec outside the milestone is the consumer most likely to break, precisely because nobody is looking at it. You accept one artifact. You author no Spec artifact and change no Spec's state. ## 1. Check that the review can run ```sh specbind milestone review status specbind milestone status specbind milestone scope ``` Stop and report, rather than fixing, in these cases: - **`Status: not_applicable`** — a Direct-only milestone has no persistent seams to review. Say that the review is not required and stop. - **A participant is not ready** — use the reported `Milestone kind`. Delivery acceptance needs every Spec-backed item to hold a fresh Design gate and sit in `tasks`; reverse acceptance needs the same fresh gate and `adoption_ready`, with no Tasks. Route any other state to its phase. Nev