fix(product): worker python is the product's env; advisor-cap text; skip defers (I-114 to I-118)

CHANGELOG.md

@@ -13,6 +13,9 @@ Format: [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). Versioning: [S
 - CLAUDE.md and CONTRIBUTING protocols 4 and 5: Always/Never rules each backed by a guard, and a bottleneck audit after every pass (issue #61).
 
 ### Fixed
+- On the Claude Code worker backend a feature's `python` is the product's environment, with its approved dependencies, not SCIO's own: the worker turn's PATH starts with the product interpreter's directory (I-114).
+- The advisor-cap halt names the cap that fired: the feature's total, or the one call per step (I-115).
+- `skip` at a halted feature defers it to the next milestone instead of dropping it, and the release refuses while a feature in `PRODUCT.md` is not done; removing a feature from `PRODUCT.md` drops it (I-116, the owner's decision).
 - `scio report` on a thread whose run is still going no longer dies on the cost ledger's half-written last line: `CostLedger.load_entries` reads only complete lines (a complete line that does not parse still raises), and a worker transcript caught mid-write is read with its broken character replaced (I-127).
 - `scio build --gh` no longer fails at its first issue on a repository without the `product-mode` label: the GitHub client creates a missing label before it names it (an existing one is left as it is), and a GitHub refusal stops `scio build` with the error and how to resume instead of a traceback (I-113).
 - A hand edit of `PRODUCT.md` is no longer lost: the milestone's sync commit records it, a fresh feature attempt commits one made while the build waited, SCIO's own checkouts and resets carry it, and the next milestone of the same thread re-reads it (I-109).

README.md

@@ -2,7 +2,7 @@
 
 A model-agnostic, multi-agent framework built on LangGraph that turns a prompt into product-ready software. Today it takes one software task, from a spec or a GitHub Issue, to a merged, tested and documented pull request, reliably and live. Product Mode (M6 to M11) extends that to whole products, from a prompt or a `PRODUCT.md`, in Python or TypeScript, one approved milestone at a time, through a release gate to a tagged release.
 
-> Status: **v0.8.0 released; Product Mode M6 to M11 and the post-M11 follow-ups done.** The product eval suite passes live on one commit: a CLI todo app (p001), a REST API (p002) and a web app graded in a real browser (p003), each built from a fixed `PRODUCT.md` to a released v0.1.0 whose hidden black-box tests pass ($11.63 estimated for all three, nothing billed). `scio new` and `scio build` have also bootstrapped and built live products on the Claude Code backend: `todo_tags` (M8), `bookmarks_api` (M9: a Python HTTP service with a third-party dependency, black-box acceptance against the started server, $5.38 estimated, nothing billed) and `notes_service` (M10: a TypeScript HTTP service with zod, eslint, tsc, npm audit and black-box acceptance all green, $4.61 estimated, nothing billed). Post-M11 follow-ups ([issue #58](https://github.com/NewMe505/SCIO/issues/58), [PR #59](https://github.com/NewMe505/SCIO/pull/59), [ADR 0016](docs/adr/0016-post-m11-follow-ups.md)) are done and released in 0.8.0: squash-safe `--gh` merges and a release PR, `scio upgrade` (live: `bookmarks_api` upgraded and its M2 built, $4.56 estimated), Node in the Docker sandbox, `run_app` in a container, parallel CI tests. Merged since: Always/Never guardrails enforced by a docs check and a push-gate hook (#61). In progress: a live product test, `graphcalc` (a TI-Nspire-style graphing calculator built by v0.8.0), and the fixes it finds (#64, merged: the quality bar follows the stack, hand edits of PRODUCT.md survive, `scio new` threads report, spend spans invocations; [issue #66](https://github.com/NewMe505/SCIO/issues/66): GitHub labels are created before use). Also in progress: `scio dashboard`, a live read-only web view of every thread's step, pending stop and cost across workspaces ([issue #68](https://github.com/NewMe505/SCIO/issues/68), [ADR 0017](docs/adr/0017-dashboard.md)). Task mode is proven live: ten regression tasks at pass^5 = 1.00 offline, nightly live suites green. Roadmap: [docs/PRODUCT_MODE.md](docs/PRODUCT_MODE.md); decision records: [docs/adr/](docs/adr/); board: [SCIO Product Mode](https://github.com/users/NewMe505/projects/1); milestones: [M6 to M11](https://github.com/NewMe505/SCIO/milestones).
+> Status: **v0.8.0 released; Product Mode M6 to M11 and the post-M11 follow-ups done.** The product eval suite passes live on one commit: a CLI todo app (p001), a REST API (p002) and a web app graded in a real browser (p003), each built from a fixed `PRODUCT.md` to a released v0.1.0 whose hidden black-box tests pass ($11.63 estimated for all three, nothing billed). `scio new` and `scio build` have also bootstrapped and built live products on the Claude Code backend: `todo_tags` (M8), `bookmarks_api` (M9: a Python HTTP service with a third-party dependency, black-box acceptance against the started server, $5.38 estimated, nothing billed) and `notes_service` (M10: a TypeScript HTTP service with zod, eslint, tsc, npm audit and black-box acceptance all green, $4.61 estimated, nothing billed). Post-M11 follow-ups ([issue #58](https://github.com/NewMe505/SCIO/issues/58), [PR #59](https://github.com/NewMe505/SCIO/pull/59), [ADR 0016](docs/adr/0016-post-m11-follow-ups.md)) are done and released in 0.8.0: squash-safe `--gh` merges and a release PR, `scio upgrade` (live: `bookmarks_api` upgraded and its M2 built, $4.56 estimated), Node in the Docker sandbox, `run_app` in a container, parallel CI tests. Merged since: Always/Never guardrails enforced by a docs check and a push-gate hook (#61), and `scio dashboard`, a live read-only web view of every thread's step, pending stop and cost across workspaces (#70, [ADR 0017](docs/adr/0017-dashboard.md)). In progress: a live product test, `graphcalc` (a TI-Nspire-style graphing calculator built by v0.8.0), and the fixes it finds (#64, merged: the quality bar follows the stack, hand edits of PRODUCT.md survive, `scio new` threads report, spend spans invocations; #66, merged: GitHub labels are created before use; [issue #69](https://github.com/NewMe505/SCIO/issues/69): the worker's `python` is the product's environment, `skip` defers a feature). Task mode is proven live: ten regression tasks at pass^5 = 1.00 offline, nightly live suites green. Roadmap: [docs/PRODUCT_MODE.md](docs/PRODUCT_MODE.md); decision records: [docs/adr/](docs/adr/); board: [SCIO Product Mode](https://github.com/users/NewMe505/projects/1); milestones: [M6 to M11](https://github.com/NewMe505/SCIO/milestones).
 
 ## Product Mode in one paragraph
 A product orchestrator sits above the proven task graph. It interviews you (two to four Opus questions), writes a normalised `PRODUCT.md`, picks a toolchain profile, and bootstraps a repository with CI and a walking skeleton. Then, milestone by milestone, it decomposes work into GitHub issues, runs each feature through the task graph with the tier pinned, verifies the integrated result against a fixed quality bar (tests with a coverage floor, lint, types, build, smoke and e2e against the running app, dependency audit, secret scan, working README instructions), and opens one milestone PR for a human to merge. Any failing check overrides any model verdict. There is one writer, so a product builds serially; there is no product-level dollar cap by default, but per-feature tier caps, stall caps and iteration caps remain as runaway guards, and cost is reported at every approval stop.
@@ -77,6 +77,8 @@ the task graph on its own checkpoint thread on branch `milestone/<n>`. After the
 profile's full suite and lint run on the branch, an Opus milestone gate gives a verdict that any failing
 check overrides, and one milestone PR waits for you. A crash at any point resumes without a duplicated
 issue, commit or PR; a feature that halts stops for one decision (`retry`, `skip`, or stop).
+`skip` defers the feature to the next milestone; the release waits until every feature in `PRODUCT.md`
+is done, so a feature leaves the product only when you remove it from `PRODUCT.md`.
 Every feature's verify also holds it to the product's coverage floor (`SCIO_COVERAGE_FLOOR`, 80% of
 the product's own code by default). When no milestone remains, the release gate (M11) runs the whole
 bar on `main` (coverage, secret scan, release files, the README's run commands, black-box acceptance)
@@ -89,7 +91,7 @@ uv run scio build --product ./todo [--gh you/todo]        # runs the next milest
 uv run scio build --product ./todo --decision merged      # after you merged the PR (offline: "merge")
 uv run scio build --product ./todo --decision release     # at the release gate (or "stop")
 uv run scio build --product ./todo --decision "merge and stop"   # record the milestone, end the thread
-uv run scio build --product ./todo --decision skip        # or retry / stop, when a feature halted
+uv run scio build --product ./todo --decision skip        # defer it; or retry / stop, when a feature halted
 uv run scio status --product ./todo                       # progress.json as text
 uv run scio report --thread build-todo_cli                # feature runs, cost, escalations
 uv run scio upgrade --product ./todo                      # bring an older product to today's bar

docs/ARCHITECTURE.md

@@ -898,7 +898,7 @@ Assumptions are numbered F‑n and referenced above. Change one by PR; record th
 - The real end-to-end run (`NewMe505/scio-eval-sandbox`, issue #1 → PR #2) found that `git add -A` committed bytecode caches; `prepare_repo` now writes repo-local excludes (I-028).
 
 ### Product mode graphs (M7, M8)
-Two graphs sit above the task graph (ADR 0007, ADR 0010, ADR 0011). `scio new` runs `product_new`: interview, normalised `PRODUCT.md`, bootstrap, optional publish, with an interrupt at every human stop. `scio build` runs `product_build`, the milestone loop: the orchestrator picks the first open feature, the milestone planner groups up to four, issues are created idempotently, each feature runs through the task graph as a subgraph on its own checkpoint thread (the `feature` node loops until the milestone's features have passed or been skipped), the integration checks and the milestone gate run on the branch, one PR waits for the human merge, and `update_progress` loops back to plan the next milestone. Both diagrams below are generated from the compiled graphs.
+Two graphs sit above the task graph (ADR 0007, ADR 0010, ADR 0011). `scio new` runs `product_new`: interview, normalised `PRODUCT.md`, bootstrap, optional publish, with an interrupt at every human stop. `scio build` runs `product_build`, the milestone loop: the orchestrator picks the first open feature, the milestone planner groups up to four, issues are created idempotently, each feature runs through the task graph as a subgraph on its own checkpoint thread (the `feature` node loops until the milestone's features have passed or been skipped; a skipped feature is deferred, so it stays open and the next milestone plans it again, I-116), the integration checks and the milestone gate run on the branch, one PR waits for the human merge, and `update_progress` loops back to plan the next milestone. Both diagrams below are generated from the compiled graphs.
 
 <!-- scio:graph:product_new:begin -->
 ```mermaid