0029: Retire The Solo Unity Slice Charter

Status: Accepted

Date: 2026-07-21

Context

The Solo Unity profile introduced a versioned slice charter between dependency planning and implementation. The charter asked useful questions about the player outcome, scope, authoritative state, mutation entry points, engine boundary, lifecycle, asset ownership, dependency roles, automated checks, and human judgment.

Those questions were not unique to dependency bootstrap or Unity. They already belong to STAGE's ordinary Frame, Inspect, Plan, Rehearse, and Judge loop. The optional feature brief also covers direction, scope, ownership, assumptions, evidence, and rollback. The charter duplicated those decisions, bound them to the byte hash of one bootstrap plan, and required a disposition for every selected dependency whether or not the slice changed dependency state.

The active artifact family occupied two scripts, two tests, two schemas, and two tracked Lanternworks examples: roughly 1,900 lines before documentation. It had one same-owner dogfood consumer. Accepting the charter did not execute its checks or improve the game; it declared that the author had filled in a second planning document.

Decision

• Retire the Solo Unity slice-charter schema, preparer, validator, tests, and active generated examples.
• Use the conversation, an existing project-native plan, or the optional STAGE feature brief to frame a bounded change.
• Keep product outcome, non-goals, preserved behavior, authoritative state, mutation, lifecycle, reset, ownership, evidence, human judgment, and rollback questions when they are material to the change.
• Add concise optional system-boundary prompts to the feature brief instead of introducing another artifact family.
• Keep dependency selection in the bootstrap plan. Mention a dependency in the change plan only when its role, mutation, ownership, or verification is material to that change.
• Do not bind routine feature planning to a dependency-plan hash or require an accepted planning artifact before implementation.

Consequences

• One normal delivery plan can cover Unity and non-Unity changes.
• Agents have fewer stale documents to reconcile before implementation.
• A high-risk systems slice can still record detailed state and lifecycle boundaries, but detail is proportional to the actual risk rather than schema completeness.
• The Lanternworks charter experiment remains recoverable from Git history and summarized in the trial record.
• A future durable planning interface must identify a repeated coordination failure or independent consumer that the ordinary feature brief cannot serve.

Evidence Boundary

This decision rejects a profile-specific artifact, not planning. The Circussy history repeatedly showed that explicit reset, time, lifecycle, ownership, and consumer-complete evidence questions prevent real regressions. The correction is to ask those questions in the plan that drives the change, not to maintain a parallel Unity charter whose acceptance is disconnected from execution.