issue-worklisted

# Issue-work — complete the next most important issue, witnessed > **The pick is an admission decision; the completion is a claim; only a > witness closes it.** Importance alone does not pick an issue — importance > × *feasibility* does (an issue whose fix surface the SELF_MODIFY guard > protects is not yours to take, however urgent). And "done" is never your > narration: it is the issue's done-condition made TRUE, pinned by a test, > landed in a commit whose subject `dos commit-audit` witnesses, with > `Fixes #N` left for git ancestry — not you — to close. Worked example: > [#12](https://github.com/anthony-chaudhary/dos-kernel/issues/12) → > commit `8e7f2f5` (the reference run of every step below). **Layering.** Dev tooling that operates ON the repo (the `/release` tier) — it names a vendor (`gh`/GitHub), so it lives in `.claude/skills/`, never `src/dos/skills/`. The closing half is [issue-verify](../issue-verify/SKILL.md); this skill is the completing half. **Public-repo note.** Issue comments and labels are public documents — no dev-machine paths, hostnames, or private-process prose. Leak-scan every drafted body (`python scripts/leak_scan.py --text-file <draft>`) before posting; if the scanner is absent, the hand rule is the floor. ## Step 1: Triage from the deterministic floor (skip if given an issue number) ```bash python scripts/backlog_triage.py --top 12 # the typed, ordered queue (docs/315) ``` The script types every open issue into a closed disposition set a