0032: Make The Artifact-Free Practitioner Kernel Normative

Status: Accepted

Date: 2026-07-21

Context

STAGE 0.3 made project maps, machine-readable manifests, and proportionate evidence part of its public contract. Later dogfood established a simpler and more useful default: one real change can be controlled, verified through its production consumer, judged by the human, and checkpointed without creating a STAGE-specific file.

The explanatory method, primary delivery skill, plugin prompt, and adoption guide already use that artifact-free path. The 0.3 specification still says that every conforming project must maintain STAGE.md and .stage/project.yaml, recommends evidence receipts for risky changes, and describes visual evidence primarily through captures. That makes the normative contract disagree with the workflow that survived dogfood.

The mismatch has practical consequences. An agent following the specification can stop useful work to manufacture a map, receipt, gallery, or export package. The project then pays maintenance cost for an artifact with no downstream consumer. The rejected detached Circussy visual workflow and the retired Solo Unity attestation, slice-charter, normalized-test, and post-commit-provenance pipelines are repeated examples of this inversion.

Decision

• Define the Practitioner Kernel as the normative minimum for one material change: human authority, protected ownership, project-native inspection, consumer-complete verification, honest uncertainty, and a reversible checkpoint.
• Permit a project or change to use STAGE without creating STAGE.md, a manifest, a receipt, a custom operation, a gallery, or another STAGE-specific artifact.
• Apply project-map requirements only when a project deliberately claims mapped-project conformance.
• Require a persistent operation, tool, evidence artifact, or product surface to have an observed recurring cost, ownership risk, or named consumer. Direct project-native work remains the default.
• Make consumer-complete verification normative for material claims. The smallest truthful route must include the production consumer and material integration or environmental boundaries; this does not require a universal full-game test.
• Keep direct engine or player observation authoritative for visual runtime truth and identified human judgment authoritative for taste. Capture and export remain optional transport for named consumers.
• Separate the STAGE method release version from project-map and case-study schema versions. STAGE 0.4 continues to validate map/study artifacts declared as 0.1 or 0.3; no migration is required solely because the method release changes.
• Retain the Maintainer Laboratory for compatibility, external studies, the optional Solo Unity profile, and release verification without making it a game-project adoption checklist.

Consequences

• The specification, primary skill, plugin prompt, method, and adoption guide describe the same default workflow.
• Existing 0.1 and 0.3 project maps remain valid and supported.
• A project can truthfully say that a change used the STAGE Practitioner Kernel without claiming that the whole repository is mapped or operationally conformant.
• Durable guidance and tooling remain available when they lower repeated coordination or correction cost, but artifact count no longer signals maturity.
• Historical trials and ADRs remain useful evidence of why the stricter artifact-first contract was revised.

Evidence Boundary

This decision is supported by same-owner dogfood and repeated retirement of unconsumed infrastructure. It does not establish independent adoption or prove that artifact-free delivery is optimal for every team. Teams with audit, compliance, CI, handoff, or external-review consumers may legitimately retain more durable artifacts than the personal owner workflow.