decision-brieflisted

<!-- decision-brief-version: 1 --> # Decision brief A ticket stalls waiting on a human, and the human is handed the ticket as it was written. That is the worst moment to read it: the premise may have drifted since, the options are rarely costed, and the obvious answer often turns on practice outside this repo that nobody has looked up. This skill produces the artifact that unsticks it. The pattern is not invented here. Four tickets in one session (#94, #102, #103, #120) each ended as a hand-written version of it, and #94 had sat through five nudges as "the maintainer must decide" when one verify-then-research pass answered it. ## What this is not **It is not a second ticket-gate, and it does not quote one either.** The gate asks *is this ready to implement* and answers PASS, NEEDS-WORK or BLOCKED. This asks *which option should the maintainer choose*. Reach for `/gate-ticket` before implementation; reach for a brief when implementation is not the question. The way to get the gate's analysis is to **run the gate**, never to cite a previous run and never to restate its bars. Carrying a copy of the gate's rules here is the restatement drift this repo keeps finding, and it is a different thing from re-running the analysis. It does not decide product or architecture direction, does not implement, and does not merge. ## Host access, and what this skill depends on **Depends on `forge-kit-devops`, for `forge-host`'s `forge-lib.sh`.** The dependency runs one way: nothing in d