SCIO v0.7.0

Added

• check_released_section_frozen in scripts/check_docs.py: the newest released CHANGELOG section must match what its tag shipped, which catches a branch's [Unreleased] entries that a merge across a release cut moved under the new version (I-089).
• M11 coverage floor (issue #54, I-091): SCIO_COVERAGE_FLOOR (default 80) is filled into the profiles' coverage commands; the node-ts profile gains a coverage check (Node's built-in --experimental-test-coverage with --test-coverage-lines). A quality check marked verify: true (coverage in both stacks, typecheck in node-ts) also runs in every product feature's verify once the suite and lint pass; a miss is the failure kind quality, sent to the debugger and never escalated, so a feature meets the bar integrate holds the milestone to.
• M11 release checks (issue #54): integrate adds a secret scan of the product's tracked files (prefixed token formats, private-key headers, and credential-named assignments whose value looks random; a line marked scio: allow-secret is skipped) and a release-files check (README, CHANGELOG, LICENSE, Dockerfile). Both are SCIO's own code (scio/product/release_checks.py), so they always run and a finding fails the milestone. Both scaffolds ship a Dockerfile and .dockerignore: the image runs the same command the acceptance runner starts (python -m <pkg> or node src/main.ts), with the approved dependencies installed; CI's docker-live job builds and runs all four (python and node, cli and http).
• M11 README check (issue #54): the scaffold's README carries its run commands between <!-- scio:run --> and <!-- scio:run-end -->; integrate runs each one ([readme]; only commands that start with one of the profile's command words, no free-form shell) and the product's CI runs the same block in a README run commands step.
• M11 release gate (issue #54): once no milestone remains, scio build runs release_check (every integrate check on main, acceptance included, and the version the product's own --version prints), stops at release_decision for a human (--decision release or stop; the stop is its own node, I-065), then release cuts the product's changelog (chore(release): v<version> [scio:release:v<version>]), tags v<version>, keeps <name>-<version>.tar.gz (a git archive of the tag, Dockerfile included, plus the build check's output when there is any) under .scio/sandbox/release/, and with --gh pushes the tag and publishes a GitHub Release with the artifacts (GitHubClient.find_release, ensure_release). Every step is an effect with a world probe, so a resumed release neither tags nor publishes twice; a failing check ends the build with release_failed; a version already tagged ends it with nothing to do; merge and stop still ends at done. New state ReleaseRecord; scio build prints the release line.
• scio new --spec PRODUCT.md --dir DIR (M11): bootstrap from a given PRODUCT.md as written, with no interview and no planner call (the product graph starts at bootstrap when the spec arrives approved).
• M11 product eval suite (issue #54): python -m evals.runner --suite product. A task (grader: product) carries a fixed PRODUCT.md (stack and interface pinned) and a hidden/ directory; evals/product_solver.py bootstraps it with --spec, builds every milestone to the release gate (answering merge, release and a green gate's proceed as the owner would, stop for anything else, every answer counted), then runs the hidden tests with SCIO's own interpreter from a scratch directory against the released product: APP_CMD and APP_DIR for a CLI, APP_URL for a server started from its ## Runtime. p001 (CLI todo with tags and JSON export) and p002 (REST todo API with a YAML store) pass on the Fake; a stricter hidden test fails the same build. Trial spend includes every feature's child harness (I-095).
• p003 (M11): a todo web app (one HTML page with the list and an add form, http.server, a JSON store) graded in a real headless browser: the hidden tests use Playwright with Chromium (playwright in the dev group; python -m playwright install chromium; CI's checks job installs it, elsewhere the browser tests skip). The runner gains --task ID (repeatable) to run one product eval.

Changed

• The http walking skeletons read HOST (default 127.0.0.1); the Dockerfile sets 0.0.0.0 so the container answers on its published port.
• The coverage floor measures the product's own code, run inside the test process: the python scaffold sets [tool.coverage.run] source and omits __main__.py, the node check excludes tests/**. Both walking skeletons test their app in-process (node's src/cli.ts exports createApp()) and mark the process lifecycle (serve) with the stack's coverage-ignore comment. Products bootstrapped before this change (bookmarks_api, notes_service) counted their tests toward coverage and test through a child process, so their next scio build may stop at the honest floor (I-091).

Fixed

• On the Claude Code backend a structured call whose answer Claude Code's schema check refused within the turn cap is re-asked once with the required keys and length limits spelled out; and a provider failure inside one feature ends that attempt (recorded, with its spend) and the build with feature_failed instead of a traceback, so the next scio build starts the next attempt (I-100).
• A budget stop in the documenter's PR-body call, or at routing, is SCIO's graceful budget exit instead of an exception that ended a whole product build; a scan test keeps every model call in a node inside a BudgetExceeded guard (I-098).
• On the Claude Code backend token caps scale by SCIO_CLAUDE_CODE_TOKEN_FACTOR (default 10), measured from the live product evals at about 380,000 billable tokens per estimated dollar, instead of the dollar factor 4, which made the token cap stop a healthy feature at about half its dollar cap (I-099).
• Verify no longer accepts a feature whose selected tests all skipped: run_tests reports no tests ran: every selected test was skipped (a profile's skipped_only patterns: pytest's summary, TAP's counters), verify fails the feature with a hint that acceptance tests run only at integrate, and the acceptance run and the eval graders fail an all-skipped run too (I-097: the first live p002 build halted on it).
• scio new's crash-resume probe for the bootstrap commit searched git log --grep=[scio:bootstrap] as a regex, a character class that matches nearly any commit message; it uses the fixed-string find_commit now, and a scan test keeps every --grep= in scio/ fixed-string (I-090).
• scio build commits the install phase's manifest and lockfile changes (npm install --save rewrites package.json and writes package-lock.json) on the milestone branch as chore: install approved dependencies [scio:install:<M>:<node>], before the first feature's reset could delete the lockfile; a merged milestone no longer leaves a dirty tree (I-085). load's sync of progress.json with PRODUCT.md is committed the same way ([scio:sync:<M>:plan_milestone]) instead of being reverted by that reset.
• The node scaffold no longer writes a non-registry dependency (file:, github:, a URL or a path) into package.json as a package of that name; the install phase writes it. Such a spec is also its own name on the approved list, so it only matches itself in install_deps (I-088).