stdd-executelisted

# stdd-execute — Forge 鑄造 Fourth phase of the STDD pipeline. Implements each `tasks.md` task with a strict RED → GREEN → REFACTOR loop and a task-boundary spec re-check. Canonical spec: `STDD/specs/stdd-execute.md` (REQ-04); cross-cutting mechanisms (frontmatter status, dual-fingerprint rule, `[wip]`/`[x]` semantics, Lint-STOP, design-ux consistency check) are canonical in `STDD/spec.md` — referenced here, not restated. ## 0. Precondition `stdd-plan`'s own coverage/approval gate (S-08) already blocks tasks.md from existing without an approved spec — do not re-invent an extra triage checkpoint here. Do read `tasks.md` for any `[wip]` task before starting new work (see step 3, interrupt recovery) — a `[wip]` task means the previous `stdd-execute` run was interrupted, and recovery is this skill's job, not `/stdd`'s (`/stdd` only reports "task X appears interrupted", it never touches the file). Only one `stdd-execute` session may run against a given change directory at a time. STDD provides no file lock for this — it is a documented limit, not a mechanism; do not treat the absence of a lock error as permission to run two sessions concurrently. ## 1. Picking a task Take the next `[ ]` task from `tasks.md` in order (or the `[wip]` task if recovering an interruption — see step 3). Route it: - `S-XX` scenario task → full two-dispatch RED/GREEN/REFACTOR loop (steps 2–5 below). - `[INFRA]` task, or an obviously small single-file change → the fast path (step 7). - `[MANUAL]`