gatelisted

# Manual Verification Gate The gate is orchestrator-tracked state, not a task-body checklist. Every verification item lives as a `gate_item` row with a classification and a state machine (`open` → `runnable` → `pass` / `fail` / `deferred`, with `Prod-Mutating` passes parked at `pending-approval` until a human consents). Every attempt is a `gate_item_event` — that log **is** the durable run record. There is no dated run-note to write back into a task body, and nothing here is loaded by fetching and parsing a Notion task's body. This skill is a thin human-driven loop over the gate-state API (`packages/backend/src/routes/gateState.ts`, business logic in `packages/backend/src/gate/gateService.ts`), called through the sanctioned node client `gate-state-client.mjs` (loopback-only, device-authed — never shell out to Notion or hand-fetch a task body for this). ```bash node ~/.claude/scripts/gate-state-client.mjs <command> ... ``` `gate-state-client.mjs` is the vendored sanctioned node client (see `packages/backend/scripts/gate-state-client.mjs`, re-vendored via the `/sync-guidelines` skill), using `$ORCHESTRATOR_DEVICE_TOKEN` (host/port default to `127.0.0.1:3000`, overridable via `$ORCHESTRATOR_BACKEND_HOST` / `$ORCHESTRATOR_BACKEND_PORT`) the same way the other sanctioned session clients (`groom-context-client.mjs`, `staged-intents-client.mjs`) do. If `ORCHESTRATOR_DEVICE_TOKEN` is unset, **stop** — this skill only runs inside an orchestrator-launched session. --- ## Core doc