--- name: alchemy-formal-milestone-process description: "BINDING (operator 2026-07-29): milestones + request↔milestone linking go through the alchemy shell's formal process, never ad-hoc gh issue ops" metadata: node_type: memory type: feedback originSessionId: a201d152-890f-4c0c-9d52-127120816a5e modified: 2026-08-19T12:48:27.894Z --- # Alchemy formal process for milestones (BINDING, operator-directed 2026-07-29) When creating milestones or linking requests (spt-bs-releases issues) to milestones, use the **alchemy shell's formal process** (`alchemy-0`, the Requests shell bound to spt-bs-releases) — drive it via `spt shell cmd alchemy-0 …`. Do NOT hand-roll the board state with raw `gh issue` label/milestone edits. **Why:** alchemy owns the board workflow (state labels BACKLOG→EVAL→GREENLIT→WIP→ACCEPTANCE→DONE, `kind: SPT-TRACKING` pins, milestone linkage); bypassing it desyncs the tracking layer from the issues. Raw `gh issue create` for a bare backlog idea was tolerated (#16/#17) but milestone structure MUST be alchemy-authored. **How to apply:** at milestone-cut time (e.g. post-grill), create each milestone through alchemy ops, then link every consumed request to its milestone through alchemy. Discover current op vocabulary with `spt shell cmd alchemy-0 help`. This directive is also recorded in doyle's durable /role. **BOARD STATE IS THE GATER'S, AND A LANE-GATE PASS IS NOT FIELD ACCEPTANCE** (doyle, 2026-08-19, asked rather than assumed). After he gated releases#197 PASS at my lane sha, the issue stayed `state: WIP` deliberately: a member moves toward ACCEPTANCE only when the ASSEMBLED head's golden is green, and he sweeps every member's state at milestone close-out through alchemy-0. As the executor I touch NO labels — not even the obviously-implied one — and I do not read my own gate PASS as a board transition. Ask who moves a label before moving it; the answer here was "mine, and not yet". **`alchemy-0` IS NOT MY SHELL — measured 2026-08-19.** `spt shell cmd alchemy-0 help` answers `NO_SHELL:alchemy-0: no such instance for todlando`; my only instance is PACER-0 (alchemy-0 nests under deployah's perch). So the "drive it via `spt shell cmd alchemy-0`" instruction above is DEPLOYAH'S route, not mine, and reading it as universal costs a wasted attempt at the moment a gater is waiting on an issue number. When doyle directs ME to file, the route is `gh issue create` against `BigscreenVR/spt-bs-releases`, copying the form off the named precedent issue rather than inventing one: body + `Requester: ` trailer, evidence in a follow-up comment signed `*\-@*`, and — for a milestone member — a sub-issue attach plus a greenlit-form ADDITION reason comment on the parent BEFORE the next golden. Craft, both paid for at the console: the sub-issue attach is `gh api --method POST repos///issues//sub_issues -F sub_issue_id=` — it takes the issue's **database id, not its number**, and it must be `-F` (typed), because `-f` sends a string and the API 422s with `is not of type integer`. Verify membership by re-reading the `sub_issues` endpoint and counting, never by trusting the POST. Label scope when filing NEW issues: set only the creation labels the gater NAMED, and touch no existing label on any issue — the rule above ("board state is the gater's") governs transitions, not creation, and conflating the two either freezes you or oversteps. ## File through alchemy, never bare `gh` — the mint is what carries the taxonomy `gh issue create` joins the board but SKIPS the alchemy mint, so the issue lands with NO `type:` label and no Requester footer, and reconcile carries it silently forever. Measured 2026-08-21 (flynn, from the #153 label repair): my own #153 filing sat TYPELESS for 17 days. I then measured the population myself — across all 209 issues on spt-bs-releases, exactly ONE lacks both `type:` and `kind:`, and it is that filing. So the hole is not systemic to the board; it is the signature of hand-filing, and the only row carrying it is mine. **Habit (binding for the release lane):** board writes go through `alchemy create`, or get flagged to the gater for a label pass AT FILING TIME. A `gh`-filed issue is not "the same issue with a missing label" — it never entered the taxonomy the workflow is made of. Note the asymmetry that makes it hard to notice: `state:` WAS present on #153 (the gater's transitions applied normally), so the issue looks governed while being untyped. **Presence of one facet of the taxonomy is not evidence of the rest.** Durable fix is flynn's spt-progress-tool#76 (fill-when-absent `type:` arm + loud skip); until it lands, the habit is the control. No action owed on #153 itself. Related: [[access-control-grill-2026-07]] (milestones A–D = first consumers of this process), [[relay-is-not-the-gaters-word]] (a verdict names a SHA — never spread one sha's PASS to a sibling lane; doyle's W3 PASS went to hertz only, and asking was what surfaced it). ## [root-merge 2026-08-23] lines present only in the .claude copy (union-merged at alt-profile migration; placement lost, content verbatim) Related: [[access-control-grill-2026-07]] (milestones A–D = first consumers of this process). **CORRECTION (flynn, measured 2026-09-08 10:40Z):** alchemy DOES mint Requests. `create` (and `comment`) are SEND-payload verbs, not `[shell.capabilities]` ops: `spt shell send alchemy-0 ""` with line 1 = the verb + flags (`create --type bugfix|change|addition|feature|idea`), line 2 = the title, body from line 3 (or the tag form `#< create … #>`). `spt shell cmd alchemy-0 create` answers "unknown op create — the shell's vocabulary is [bags, bind-repo, …]", which names ONLY the cmd set and hides every send verb — that wording is the wart I walked into (filed on spt-bs-releases 2026-09-08). Route for a new Request: shell send create, never bare `gh issue create` + `type` fill (that path works but skips the mint's own labelling).