goalforge-executelisted

# SDD Execute ## Plans root `<wp-path>` points to a WP folder in `<PLANS_ROOT>/<feature>/`. Resolve `<PLANS_ROOT>` per `${CLAUDE_PLUGIN_ROOT}/references/schema.md` §PLANS_ROOT resolution (env `SDD_PLANS_DIR` → project git-root `plans/` → global `~/.claude/plans/`). ## Contract Reads a WP at `status: ready` and drives `ready → executing`; `goalforge-verify` writes `executing → verified` after the WP-level semantic gate. **Tasks reach the interim status `implemented`** here (deterministic eval passed + committed) — *not* `verified`. `verified` is quality-signed-off and is **written only at the WP gate** by `goalforge-verify`, which flips each `implemented` task to `verified` as it finalizes. State-machine invariants (schema.md §state machine): `executing` ⇒ ≥1 task has a `checkpoint` block; a task reaches `implemented` after its deterministic eval (Step 6) passes and it is committed (Step 8); `verified` ⇒ all child tasks `verified` + `findings.md` exists. ## Unattended mode Under `SDD_AUTONOMY=unattended` (the `autopilot` driver), every point that would escalate via `AskUserQuestion` instead PARKs — append the blocker to `findings.md` and stop cleanly; status is never advanced past a blocker. Detail: `references/autonomy.md`. ## Goal layer (the simulated `/goal` loop) Steps 1–10 run inside an **outer goal-completion loop** that simulates native `/goal` (design §4). Split of labour: - **The script (`goalforge-goal-eval`) is pure.** It decides `deterministic`/`numeric`