0023: Separate Practitioner Kernel From Maintainer Laboratory

Status: Accepted

Compatibility-laboratory treatment of detached visual export is superseded by ADR 0025. The measured history and kernel/laboratory distinction remain valid. The separate visual capability-manifest contract described below is superseded by ADR 0026. The Solo Unity assessment, milestone, and operational-proof laboratory described below is retired by ADR 0028.

Date: 2026-07-21

Context

STAGE says that infrastructure must earn persistence and that ordinary work should begin with one project-native change. Its own repository had drifted away from that standard. A single portable gate ran the core method contracts, the optional Solo Unity profile simulations, and the historical Evidence Export compatibility stack after every edit.

Measured independently by test module on 2026-07-21, the 42-module suite took about 146 seconds on the owner's machine:

• core method, mapping, native-review, and repository contracts: 7.6 seconds;
• optional Solo Unity profile: 123.2 seconds; and
• Evidence Export compatibility: 15.5 seconds.

The expensive suites are legitimate. They protect profile operations and public compatibility. They are not evidence for every ordinary method or skill change. Running all of them continuously obscures the same distinction STAGE now requires in games: a supporting laboratory is not the production consumer of every claim.

Decision

• Define the Practitioner Kernel as the minimum STAGE method used to deliver one accepted project-native change: human direction, project-native inspection, explicit ownership, consumer-complete verification, human judgment, and reversible checkpointing. It requires no STAGE artifact.
• Define the Maintainer Laboratory as this repository's compatibility, profile, migration, case-study, dogfood, and release machinery. It supports STAGE development but is not part of the default project workflow.
• Keep native Visual Review and product-native Visual Almanac routing in the kernel test suite without requiring a separate capability manifest.
• Preserve detached capture history in Git rather than maintaining unused contact-sheet, baseline, comparison, and receipt compatibility machinery.
• Keep Solo Unity bootstrap, provenance, milestone, and operational-proof simulations in their own laboratory suite. The profile remains optional and non-normative.
• Provide two repository gates:
  • --scope change runs the fast kernel suite plus syntax, maps, studies, native-review declarations, links, and diff hygiene;
  • --scope release runs every test and additional profile and Evidence Export artifact checks.
• Preserve the no-argument check_repository.py behavior as the release gate.
• When a change touches a laboratory capability, run that named suite during development in addition to the change gate. Run the release gate before pushing or publishing STAGE.

Consequences

• Ordinary STAGE iteration gets fast, claim-relevant feedback without deleting or pretending away compatibility obligations.
• A passing change gate supports only kernel and common repository claims. It does not establish that Solo Unity or Evidence Export remains correct after a change to those systems.
• A release remains guarded by all supported contracts.
• New optional systems must declare which suite owns their compatibility cost. They do not enter the kernel merely because they are useful to the owner.
• The split is an internal operating decision, not a new normative requirement for games adopting STAGE.

Research Boundary

Google's SMURF guidance treats speed, maintainability, utilization, reliability, and fidelity as explicit test-portfolio tradeoffs. Its test-hourglass guidance recommends smaller reliable integration boundaries instead of allowing broad tests to dominate feedback. STAGE applies that reasoning to its own repository while retaining the consumer-complete claim rule. This measured local split is not evidence that the same suite boundaries or timing thresholds fit another project.