STAGE 1.0 Readiness Review
Status: owner accepted the 1.x contract and authorized the 1.0.0 release on 2026-09-27
Last reviewed: 2026-09-27
Accepted Decision
Release plugin 1.0.0 / method 1.0 as a compatibility commitment for the owner's working method. The release record owns the exact changes, verification evidence, and publication receipts. It includes the previously unreleased 0.7 redesign; publishing an intermediate 0.7 is not required.
On September 27 the owner described Salvageist as a successful pilot and asked to carry its learnings into 1.0. After reviewing the completed candidate, the owner directed: “proceed to create 1.0 and published, everything updated.” This accepts the presented 1.x commitment and authorizes integration, release, documentation publication, and plugin refresh. The September 25 study remains a dated retrospective with its original checkpoint and formal playtest status.
The 1.0 decision accepts a small stable surface and its maintenance cost. It does not establish independent adoption, causal productivity gains, universal engine/model support, or autonomous game design. Those are separate claims, not prerequisites for a personal compatibility-stable release.
What Salvageist Changes
The pilot records nine real-change groups covering architecture, iteration, performance, telemetry, UI, defect repair, and release. Repeated owner play supplied useful corrections and positive product feedback. The workflow-cost follow-up shows where the method's intended proportionality was defeated by local policy and tooling.
| Learning | Applied response |
|---|---|
| Broad suites missed real input, clearance, and cold-start defects | Keep production-consumer checks and early human play; distinguish cold events from steady-state performance |
| A cleaner shared architecture initially performed worse | Measure comparable target workloads and actual backend execution; preserve rejected candidates |
| Documentation-only edits paid for engine checks | Select gates over the complete task delta; unknown inputs remain conservative; preserve the full release route |
| Failure and waiting consumed unnecessary work | Stop expensive dependent stages after failed prerequisites; let the runner report compact completion evidence |
| Large recovery docs still described stale state | Reconcile current claims with source and route to dated history and machine-local evidence only when needed |
| Shared delivery can duplicate builds, review, and coordination | Give shared integration/release one owner when delegation is authorized; keep simple work in one task |
These are conditional guidance improvements. They add no Safety Kernel rule, schema, dashboard, mandatory task chain, or model requirement. Stronger reasoning and independent review are options when complexity earns their cost.
The pilot does not supply consistent human active time, time to fair inspection,
or STAGE maintenance minutes. Its informal positive feedback is not a retroactive
four-dimension playtest pass. Owner readiness remains operational; the separate
repeatable and durable categories need their own cost and resumption evidence.
None of those missing measurements blocks this bounded compatibility release.
Accepted Contract
The canonical 1.x compatibility inventory freezes the obligations and interfaces people can depend on: S1–S8, the four skill routes, supported project-map versions, named installed read-only helpers, orientation/verification inventory, and repository-backed migration. Compatibility lasts throughout the 1.x line. Preserve older supported schemas and make migrations explicit; breaking stable interfaces requires a major release and migration notes.
Instructional prose, templates, reference layout, optional board labels, engine profiles, and model choices remain maintainable. Historical case-study schemas remain valid without turning all laboratory tooling into a public research API. Optional mapping, Unity bootstrap, and research capabilities receive correctness, compatibility, and maintenance support; expansion needs a present consumer.
Support follows the exercised macOS/Codex/Git/Python workflow and declared packaged dependencies. No calendar support term is promised. Installing 1.0 does not create or rewrite game-project artifacts. See ADR 0066.
Release Path
The release incorporates the 0.7 correctness repairs, paired Astra evidence, and Salvageist-informed guidance. Dated checks and publication receipts belong in the release record; earlier passes are not relabeled as current. The agent completed deterministic metadata, both lockfiles, compatibility notes, release evidence, and a local checkpoint before the owner decision.
The authorized release path is complete: the proposal was integrated through
repository checks, current-main hosted quality passed, the annotated tag and
GitHub Release were published, the guarded public documentation deployed, and
the installed plugin passed a fresh-task probe. The release record owns those
receipts. Release Please stays draft-only; its tag policy follows STAGE's
existing v<version> convention.
Continue using real project work to improve the guidance. Record a short cost, rework, or escaped-defect observation when it can inform a decision. A fresh-agent takeover and a bounded lighter-model comparison are useful future opportunities, not additional release ceremonies or reasons to defer ordinary work.