controlled-ticket-deliverylisted

# controlled-ticket-delivery `coder` assumes a normal environment. This skill is for when it isn't — when the constraint, not the code, decides how the work ships. ## Step 1 — Name the constraints explicitly Write them down before starting. An unnamed constraint gets violated. | Constraint | Questions to answer now | |---|---| | **Budget** | Token/spend cap? What's already burned? What happens at the cap — stop, or degrade? | | **Spend authority** | Does this run call paid providers, deploy, or purchase? Spend is **always separately authorized.** | | **Migration** | Does this touch live data? Is it reversible? Is there a backup? Expand-then-contract available? | | **Git authority** | Commit allowed? Push allowed? Direct to branch, or PR only? Protected branches? | | **Tracker access** | Can you write the GitHub Project? Does `gh auth` have the `project` scope? If not, where does the handoff live? | | **Time** | Hard deadline that changes the acceptable path? | State the resolved set back to the user in one block before implementing. ## Step 2 — Choose the delivery path | Situation | Path | |---|---| | Full authority, normal ticket | Standard `coder` | | No push authority | Implement + commit locally, write handoff, report. **Do not push.** | | No commit authority | Implement, verify, leave the tree dirty, write a handoff describing exactly what to stage | | No project write | **Local handoff file** (template below). Never substitute labels or issue closure for a missin