---
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-07-29T08:52:42.969Z
---

# 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 <op> …`. 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.

Related: [[access-control-grill-2026-07]] (milestones A–D = first consumers of this process).