STAGE Documentation Map
Use this page to find the canonical source for a question. It classifies documents by authority and job; it does not replace them.
Authority
When two documents appear to conflict, use this order:
SPEC.mdowns normative Safety Kernel requirements and explicitly adopted optional contracts.- The glossary owns current STAGE vocabulary.
- The ADR index identifies current decisions and preserved supersession history.
- Packaged skills under
plugin/skills/operationalize the method for agents without adding hidden requirements. - Practitioner and maintainer guides explain how to apply those sources.
- Evaluations, trials, case studies, and release records preserve bounded evidence and history; they do not silently extend the method.
STAGE.md maps this repository itself. It is an orientation
surface, not another normative specification.
Apply STAGE To Game Work
| Read when | Canonical guide | Authority |
|---|---|---|
| Delivering one ordinary project change | Delivery Method | Practitioner guidance |
| Choosing what a solo director and agent should do next | Stage Director's Flow | Optional attention and decision-control guidance |
| Moving work to a fresh task, recovering context, or testing a handoff | Task Continuity And Context Recovery | Practitioner context and task-boundary guidance |
| Installing STAGE in Codex and choosing among delivery, orientation, verification, and mapping | Using STAGE With Codex | Owner-facing plugin operating guide |
| Understanding why humans and agents use different interfaces over the same canonical facts | Documentation Surfaces | Repository documentation policy |
| Reading the public human guide away from the development machine | stage.zoshachi.com | Automatically published derived documentation |
| Isolating branches, coordinating agents and Unity assets, integrating work, or naming builds and releases | Change, Concurrency, And Release Workflow | Practitioner source-control and release guidance |
| Selecting evidence for a claim | Task-Evidence Matrix | Practitioner guidance |
| Selecting source, model, engine, consumer, distribution, and human gates | Quality Gates And CI | Practitioner and repository-automation guidance |
| Defining or materially changing a player-facing premise | Human-Led Gameplay Design | Product-authority guidance |
| Reasoning about systems-heavy decisions, feedback, UI, progression, and playtests | Systems-Heavy Gameplay Evidence | Practitioner guidance; not a fun score |
| Implementing or diagnosing visual, motion, audio-presentation, UI, lighting, or procedural-readability work | Visual Work | Practitioner guidance |
| Deciding whether STAGE artifacts or operations have earned persistence | Adoption | Practitioner guidance |
| Choosing a proportional project-map shape | Map Profiles | Optional contract guidance |
| Comparing a project architecture with one possible systems-heavy shape | Optional Reference Architecture | Non-normative question set |
| Applying engine-specific Unity considerations | Unity Engine Profile and Unity Visual Work | Non-normative engine guidance |
Maintain STAGE
| Read when | Canonical source | Authority |
|---|---|---|
| Changing this repository, plugin, schemas, profiles, or studies | Maintaining STAGE | Maintainer procedure |
| Checking artifact-version support or migration policy | Compatibility | Public compatibility policy |
Deciding whether the personal-use contract is ready for 1.0.0 | 1.0 Readiness Review | Owner decision aid |
| Looking up current and superseded method decisions | ADR Index | Decision history |
| Looking up release-specific evidence and limitations | Release Index | Release history |
| Reviewing all notable changes, including unreleased work | CHANGELOG.md | Change history |
Research And Evidence
| Read when | Canonical source | Claim boundary |
|---|---|---|
| Understanding what STAGE currently claims and does not claim | Evaluation, Readiness, And Transferability | Current evidence boundary |
| Comparing findings across projects and engines | Cross-Project Case-Study Synthesis | Bounded synthesis |
| Inspecting the origin project and its corrections | The Circussy One Case Study | Origin evidence, not a universal architecture |
| Tracing established research and STAGE's proposed contribution | Research Foundations | Research lineage and limits |
| Diagnosing recurring workflow and evidence failures | Failure Atlas | Observed anti-pattern catalog |
| Inspecting source-bounded experiments | trials/ | Historical study records |
Historical Redirects
Visual Review is a preserved historical filename that redirects to current Visual Work guidance. Historical ADRs, trials, and release records remain where they were written so stable links and decision provenance are not rewritten.
Repository Collections
docs/adr/preserves individual architecture decisions.docs/releases/preserves release-specific records.docs/case-studies/preserves named project narratives.profiles/contains optional personal and engine workflows.trials/contains protocols, results, audits, and dogfood evidence.
Adding an active top-level guide, engine profile, case study, ADR, or release record also requires adding it to the corresponding index. The repository gate checks that discoverability contract.