feat(boatstack): add goal-driven autonomous runs

labs/12-product-engineering-loop/boatstack-distribution/GENERATED_FILES.md

@@ -34,6 +34,7 @@ Boatstack stores feature artifacts under `.product-loop/features/<feature>/`:
 | `test-plan.md` | Connects promised outcomes to checks |
 | `plan.md` | Holds the human-readable approved plan |
 | `approval.md` | Records who approved which exact plan |
+| `autonomy.md` | Records one explicit run target and its bounded policy decisions without claiming human approval |
 | `compiled/` and `plan.lock.json` | Prove that build activated the approved inputs without drift |
 | `evidence.md` | Records commands, results, review findings, and gate status |
 | `pr.md` | Contains the exact reviewer-ready title and body preview |

labs/12-product-engineering-loop/boatstack-distribution/GETTING_STARTED.md

@@ -18,7 +18,7 @@ Ask Boatstack for the next verified stage without changing anything:
 
 Boatstack reads repository-owned plans, approvals, delivery state, and gate receipts, then returns exactly one next action. Chat, terminal, worktree, and running-process observations may add context but never establish a workflow stage. If no managed work remains, Boatstack reports **Feature complete** and **No action required**.
 
-For a small verified feature, `/boatstack-run` in Cursor or Claude Code and `$boatstack run` in Codex drive every declared delivery slice through PR publication. The command fetches `origin` before mutation and pauses for required plan approval, product decisions, and the exact PR open/update confirmation. Managed side effects use durable attempt receipts, so a lost response or new chat resumes or reconciles the same work instead of repeating it. Merge and deploy remain separate.
+For a tiny, already-specified feature, use `/boatstack-run --to plan|verified|pr` in Cursor or Claude Code or `$boatstack run --to plan|verified|pr` in Codex. If you omit the target, Boatstack asks once. It may choose only non-material, reversible implementation options that remain inside the specification and have repository evidence plus an independent oracle. `plan` stops at the reviewable plan, `verified` stops after build/test/review, and `pr` authorizes one normal open or update action. Merge and deploy remain separate.
 
 ## 1. Install it separately
 

labs/12-product-engineering-loop/boatstack-distribution/README.md

@@ -87,7 +87,7 @@ That is all you need to learn up front. Boatstack shows one next action at a tim
 
 When you return after an interruption, run `/boatstack-next` in Claude Code, Cursor, or Gemini CLI. In Codex, run `$boatstack next`. Boatstack reports the repository-verified stage and one next action. It does not change state. It tells apart a feature that has not started from one that is complete.
 
-`/boatstack-run` (or `$boatstack run` in Codex) starts from one saved plan. It continues through publication and pauses for approvals and product decisions. It checks branch freshness before delivery. It never merges or deploys.
+`/boatstack-run --to plan|verified|pr` (or `$boatstack run --to …` in Codex) starts from one saved plan and stops at the selected goal. An explicit goal-driven run can resolve only low-risk, reversible, evidence-backed implementation choices inside the specification. Any material or uncertain choice still pauses. The `pr` target authorizes one normal PR open or update; it never merges or deploys.
 
 In Claude Code, Cursor, and Gemini CLI, that guidance moves through `/plan-gate` → `/build` → `/test-gate` → `/review-gate` → `/ship-gate`. In Codex, use the same operation names after `$boatstack`.
 

labs/12-product-engineering-loop/boatstack-distribution/release-notes/2026-08-02-goal-driven-autonomous-run.md

@@ -0,0 +1,3 @@
+### Drive small features to an explicit goal
+
+`boatstack run --to plan|verified|pr` can now record a scoped policy receipt for a tiny, already-specified feature. Boatstack chooses only reversible, evidence-backed implementation options with no protected product impact, stops at the selected goal, and fails closed when the plan, repository, branch, evidence, or PR action changes.

labs/12-product-engineering-loop/product-engineering-loop/SKILL.md

@@ -34,11 +34,11 @@ Run the project-local helper's read-only `next-status --repo . --json` inspectio
 
 To see every feature at once, run the read-only `.product-loop/bin/boatstack-helper flow frontier --repo .`. It lists each delivery, its observed position, and who owes the next step. To wait for a published PR to move (checks finish, a review lands, a merge happens), run the read-only `.product-loop/bin/boatstack-helper flow watch --repo .`. The watch observes on an interval and exits when the frontier changes, when nothing can move, or at its timeout. It never acts on what it sees. When it exits, run `next-status` again and continue from the fresh state.
 
-## Run through ship
+## Run to an explicit goal
 
-For `$boatstack run`, `/boatstack-run`, or natural language such as “run Boatstack through ship,” first run the read-only `next-status --repo . --json` and `operation-status --repo . --json`. Wait for an executing operation and reconcile unknown completion before retrying. When the host supplies the plan path, enter `auto-plan` with `--plan <path>`; when no plan path is supplied, stop and ask the user for the plan to build. Return **Feature complete** only for a verified completed feature, and stop on unverified, ambiguous, stale, or invalid state. Schema-v3 `check-plan` runs the Git freshness preflight before it displays the approval fingerprint, and activation repeats it immediately before writing the immutable lock. A failed fetch, missing remote/base, stale base, upstream drift, wrong worktree, constrained branch mismatch, or incomplete journey decision blocks without creating authority or consuming repair budget. Never repair freshness by merging, rebasing, switching or creating a constrained delivery branch, discarding changes, force-pushing, or broadening permissions.
+For `$boatstack run --to plan|verified|pr`, `/boatstack-run`, or a natural-language run request, resolve the target from the request. When it is absent, ask once for `plan`, `verified`, or `pr`. First run the read-only `next-status --repo . --json` and `operation-status --repo . --json`. Wait for an executing operation and reconcile unknown completion before retrying. When the host supplies the plan path, enter `auto-plan` with `--plan <path>`; when no plan path is supplied, stop and ask the user for the plan to build. Return **Feature complete** only for a verified completed feature, and stop on unverified, ambiguous, stale, or invalid state. Schema-v3 `check-plan` runs the Git freshness preflight before it displays the plan fingerprint. Record the selected target with `record-autonomy --plan <plan.md> --target <target>` after all material questions are answered or every remaining question has a valid `RESOLVED_BY_POLICY` autonomy decision. Target `plan` stops after the valid reviewable plan. Targets `verified` and `pr` activate with `--autonomy <autonomy.md>` and stop if that receipt becomes stale. A failed fetch, missing remote/base, stale base, upstream drift, wrong worktree, constrained branch mismatch, incomplete journey decision, or ineligible policy decision blocks without creating authority or consuming repair budget. Never repair freshness by merging, rebasing, switching or creating a constrained delivery branch, discarding changes, force-pushing, or broadening permissions.
 
-After preflight, repeatedly run `next-status --repo . --json`, execute only its verified next operation using the canonical semantics below, verify the resulting repository state, and resolve again. Continue across all declared slices. Pause for explicit `a` plan approval, material product questions, and the exact `o` or `u` PR confirmation; a valid answer resumes the foreground run in the current host session. The run invocation itself is never approval or publication authority. Same-intent test/review failures may be recorded and repaired for at most three complete repair-and-gate cycles per active slice; the durable delivery attempt count does not reset across turns or hosts. Stop on amendments, ambiguity, safety failures, stale evidence, unsupported recovery, branch mismatch, or an exhausted budget. Persist execution facts and retry identity, never autonomous workflow intent; conversation is not workflow evidence. Completion means every slice PR is published for review, never merged or deployed — unless `delivery.terminal` is `merged`, in which case the flow continues past publication with prescribed read-only steps until the PR is observed merged (see the post-publish rules below).
+After preflight, repeatedly run `next-status --repo . --json`, execute only its verified next operation, verify the resulting repository state, and resolve again. Continue across all declared slices until the selected target is reached. A policy receipt may resolve only a non-material, within-spec, reversible choice with one recommendation, repository evidence, no protected impact, and a runnable oracle. Record it as `RESOLVED_BY_POLICY`, never `ANSWERED`. Any failed or unknown condition pauses for the human. Target `verified` stops after current test and review evidence passes. Target `pr` supplies scoped authority for one normal open or update action recorded in `autonomy.md`; after the exact preview is revalidated, call `publish-pr --autonomy <autonomy.md>` without asking for `o` or `u`. A changed plan, repository, branch, PR action, preview, evidence, or target invalidates that path. Same-intent test/review failures may be repaired for at most three complete cycles per active slice. Stop on amendments, ambiguity, safety failures, stale evidence, unsupported recovery, branch mismatch, or exhausted repairs. Never force-push, merge, deploy, or execute a foreign program.
 
 When `delivery.terminal` is `merged`, follow the post-publish prescriptions exactly. After publication, run `flow next` (or `next-status`). When it prescribes `flow watch`, run the watch and re-resolve when it exits. When checks fail, it prescribes `record-change --source-stage ci`; derive the exact message, classification, evidence, and changed repair mechanism from the failing check logs, never from memory, then repair, re-gate, and republish with `publish-pr --action update`. When the PR is observed merge-eligible, it prescribes the exact `gh pr merge` command; run it only as rendered, under the host's own permissions — Boatstack never merges, and you never merge without the prescription. A required review approval, a changes-requested verdict, a closed PR, or an unverifiable PR position always ends your turn at the operator frontier.
 

labs/12-product-engineering-loop/product-engineering-loop/assets/templates/plan.md

@@ -18,6 +18,7 @@
   "source_plan_path": "source-plan.md",
   "spec_path": "feature-spec.md",
   "blocking_questions": [],
+  "autonomy_decisions": [],
   "acceptance_criteria": [
     {
       "id": "AC-1",
@@ -84,6 +85,13 @@
 ```
 <!-- /boatstack-plan -->
 
+Keep `autonomy_decisions` empty for the normal human-driven flow. An explicit
+goal-driven run may add a decision only with `resolution: RESOLVED_BY_POLICY`,
+one selected recommended option, `material: false`, `within_spec: true`,
+`reversible: true`, every protected `impact` flag false, repository
+`evidence_ids`, a rationale, and a runnable `verification` with an independent
+oracle.
+
 For an external write, replace the empty `side_effects` list with entries such as:
 
 ```json

labs/12-product-engineering-loop/product-engineering-loop/assets/templates/questions.md

@@ -3,6 +3,6 @@
 | ID | Question | Why it matters | Options | Recommendation | Answer | Source | Status/expiry |
 |---|---|---|---|---|---|---|---|
 
-Use `ANSWERED` only for an explicit human answer or an authoritative existing contract. Repository inference is `PROPOSED` until the human accepts it. Material unanswered questions remain `OPEN`, appear in `plan.md` as `blocking_questions`, and block approval.
+Use `ANSWERED` only for an explicit human answer or an authoritative existing contract. In an explicit goal-driven run, use `RESOLVED_BY_POLICY` only when the structured autonomy envelope proves the choice non-material, within-spec, reversible, free of protected impacts, evidence-backed, and independently verifiable. Repository inference is otherwise `PROPOSED`. Material unanswered questions remain `OPEN`, appear in `plan.md` as `blocking_questions`, and block activation.
 
 When presenting finite questions, give every choice a compact inline-code key (`1a`, `1b`, `1c`, then `2a`, `2b`, and so on) and suffix exactly one choice per question with `(Recommended)`. End with one reply hint: name the keys for explicit selection, or use `r` to accept all displayed recommendations. A standalone `r` is `ANSWERED` human provenance only after the selected question-to-answer mapping is echoed; it is never an agent-selected default.