The Stage Director's Flow

The Stage Director's Flow is STAGE's optional control layer for deciding what work should happen next in a human-directed game project. It is designed for a solo director working with coding agents, where a sticky-note backlog is often more useful than a full production-management system.

It does not replace the per-change Frame -> Inspect -> Plan -> Build -> Rehearse -> Judge -> Checkpoint delivery loop. It places that loop inside a small queue with explicit human decisions:

Cue -> Dialogue -> Ready -> Active -> Rehearsal -> Director's Call -> Checkpointed
         ^                                  |              |
         +---------- revise ----------------+              +-- accept
                                            +----------------- reject/defer

The Flow exists to solve four recurring problems:

1. an agent starts implementing an attractive idea before the intended player experience is agreed;
2. too many partially complete systems accumulate before one complete loop is playable;
3. mechanical success is mistaken for human product acceptance; and
4. useful findings, reversions, and next decisions disappear into chat history.

It is practitioner guidance, not a universal STAGE contract. A conversation, paper notes, a Markdown file, or an issue tracker can all carry the Flow.

Roles

Director

The accountable human who chooses:

• the game's intended experience and identity;
• which work is worth doing now;
• acceptable tradeoffs and scope;
• whether a player-facing result is accepted, revised, rejected, or deferred;
• destructive or irreversible actions; and
• release and publishing decisions.

For a personal game, one person can be director, developer, artist, and playtester. The evidence still keeps those roles distinct. "I want to keep making this" is valid owner acceptance. It is not evidence that a first-time target player understands or enjoys it.

Agent

The agent may:

• recover prior decisions and expose contradictions;
• research, compare alternatives, and identify likely risks;
• turn approved intent into a bounded implementation plan;
• implement through canonical project sources;
• automate mechanical checks and diagnostics;
• prepare the real game for human play;
• preserve observations and propose the next discriminating decision; and
• challenge a weak assumption with evidence.

The agent does not silently choose the game's intended experience, accept its own player-facing work, weaken a gate to obtain green status, or multiply an untested premise through broad content and architecture.

Flow States

Cue

A raw idea, problem, observation, or obligation. Examples:

• "The moon should rearrange the town."
• "The forecast and actual night result disagree."
• "The first five minutes are confusing."
• "We need a Windows build for a showcase."

A Cue is not ready for implementation merely because it sounds concrete.

Minimum record

• one sentence;
• source, if it came from a playtest or defect;
• urgency or external date, if real.

Exit

• promote to Dialogue;
• discard;
• park in the queue without elaboration.

Do not estimate every Cue. The point is to stop memory loss, not build a warehouse of refined tickets.

Dialogue

Resolve the highest-leverage uncertainty. For gameplay, use Human-Led Gameplay Design. For a defect, identify the authoritative owner, production consumer, and symptom before proposing a repair.

Questions

• What outcome is wanted, and for whom?
• What accepted behavior must remain?
• Which assumptions are implementation accidents rather than decisions?
• What alternatives materially change player experience or engineering risk?
• Which decision belongs to the director?
• What would make this idea not worth continuing?

Exit

• a human-approved hypothesis or bounded maintainer outcome;
• explicit non-goals;
• a smallest complete slice;
• stop conditions.

If the director has not approved the player-facing hypothesis, the item does not enter Ready.

Ready

The item can be implemented without inventing its product intent.

Required

• outcome and reason for doing it now;
• approved player/system hypothesis when material;
• protected state and ownership boundary;
• smallest complete production path;
• mechanical acceptance checks;
• human judgment still required;
• selected quality gates;
• stop conditions;
• expected checkpoint or rollback boundary.

Ready does not mean fully specified. It means the remaining unknowns can be answered safely during implementation without changing the intended product.

Active

One item is being delivered through the normal STAGE delivery loop.

The solo default is one active player-facing item. A small maintenance fix may interrupt it when it blocks the same rehearsal, but starting another major feature should move the first item back to Ready or Deferred.

The agent should keep the work item current only when doing so changes a decision. It need not narrate every file edit into the ticket.

The Codex task is not the work item. Continue one task while this outcome remains coherent. If context pressure or a repository switch requires a fresh task, use Task Continuity And Context Recovery and keep the durable work-item state independent of either conversation.

Exit

• Rehearsal when the complete intended slice exists;
• Dialogue when implementation reveals a product decision;
• Blocked when authority, capability, or a material dependency is missing;
• Rejected when the route no longer serves the intended outcome.

Rehearsal

Exercise each claim through the smallest route containing its real production consumer. Use the Quality And CI guide to select mechanical gates.

Rehearsal has two independent outputs:

1. mechanical disposition: passed, failed, unavailable, inconclusive, or not attempted;
2. human-ready state: the real player or author surface is ready for the director to judge.

Compilation, unit tests, synthetic play, screenshots, and agent opinion cannot substitute for a human call about comprehension, control feel, visual quality, audio, pacing, balance, emotion, or fun.

Director's Call

The director plays, inspects, or otherwise judges the result through the real surface.

Use one of four dispositions:

• Accept: keep this result as the current project direction.
• Revise: preserve the hypothesis, change one bounded cause, and rehearse again.
• Reject: stop this route and restore or branch from a known checkpoint.
• Defer: the result may be viable, but it is not worth more attention now.

For a player-facing loop, record four judgments separately:

Dimension	Question
Comprehension	Could the player infer goal, state, controls, and consequence?
Usability	Could the player act without fighting the interface or controls?
Engagement	Did the loop produce the intended interest, tension, care, mastery, or other approved quality?
Desire to continue	Did the player want another decision, attempt, or cycle?

Use categorical findings such as passed, concern, failed, and not tested. Do not average them into a fun score.

Checkpointed

The accepted result and its actual evidence have a recoverable boundary:

• a coherent commit;
• a branch or tag;
• a shelved experiment;
• a playable build;
• a retained scenario or regression test; or
• another project-native checkpoint.

A checkpoint records what is now true. It does not imply every proposed follow-up is approved.

Rejected and deferred items can also receive a checkpoint when preserving the experiment or lesson is useful. Mark the disposition plainly.

Work Item Shape

Use templates/director-work-item.md when a durable item is useful. The minimum information is:

Outcome
Why now
Human-owned decision
Smallest complete slice
Protected state
Mechanical checks
Human judgment
Stop conditions
Disposition
Next decision

For unfinished work crossing a task boundary, use the separate Task Handoff template. The work item owns the durable outcome; the handoff owns only revision-bound resume state.

Work Types

Type	Useful when	Completion boundary
Design question	Intended experience or tradeoff is unresolved	Human-approved hypothesis or explicit rejection
Player slice	A complete repeated interaction must be judged	Mechanical preflight plus Director's Call
Defect	Current behavior violates an accepted expectation	Reproduction no longer occurs through the production route
Technical debt	Repeated change cost or risk has a concrete owner	Named operation becomes safer or simpler without behavior drift
Experiment	Two hypotheses need bounded comparison	Comparable result and a human decision
Content batch	An accepted grammar is being populated	Validation plus representative in-game review
Release	A named build must be distributable	Clean build, release smoke, retained coordinates, human publish call

Do not classify speculative infrastructure as technical debt merely because the future might need it. Name the repeated cost it removes.

Priority Without Story-Point Theater

For one director and one agent, use a small priority lens:

1. Broken show: crash, data loss, main-path blocker, unplayable build.
2. Next decision blocker: prevents the director from fairly judging the current slice.
3. Accepted-loop improvement: strengthens an already accepted product direction.
4. Speculative option: may be useful later but does not unlock a current decision.

Within a level, prefer work that:

• produces a complete player-visible consequence;
• reduces irreversible risk;
• answers the most expensive uncertainty;
• shortens the next human rehearsal; or
• removes a repeatedly observed failure.

Story points, velocity targets, sprint commitments, and detailed estimates are usually noise for this workflow. Use a date only when an actual external date exists. If an item is too large to reason about, split it by player-visible or author-visible outcome, not by arbitrary file layers.

Suggested Solo Board

NOW
  One active item and its current blocking decision.

NEXT
  At most three Ready items, ordered by the next useful human decision.

LATER
  Unrefined Cues. Keep them cheap.

WAITING FOR DIRECTOR
  Rehearsed items needing play, taste, or product judgment.

DONE / REJECTED
  Checkpoint and one-sentence disposition.

This can be five headings in a Markdown file, GitHub issue labels, a physical board, or sticky notes. Tooling is earned only when the current surface loses state, obscures ownership, or is too expensive to maintain.

Agent Operating Rules

When an agent picks up an item:

1. confirm its state and newest human decision;
2. do not promote a Cue to Ready by inference;
3. do not start a second player-facing Active item while the first awaits a fair rehearsal;
4. keep quality configuration, suppressions, baselines, and release authority human-owned;
5. stop and return to Dialogue when implementation reveals a product decision;
6. prepare the actual game or authoring surface for the Director's Call;
7. report exactly what evidence supports and what still requires a human; and
8. checkpoint only the coherent accepted or explicitly preserved result.

From Ready To Checkpointed

The Flow owns attention and decisions, not Git mechanics. Once an item becomes Ready, use the Change, Concurrency, And Release Workflow for:

• a stable work-item ID;
• short-lived branch and isolated worktree;
• owned and exclusive paths;
• bounded parallel agents;
• Unity Editor and serialized-asset ownership;
• serial integration and the integrated main smoke; and
• separate checkpoint, build-identity, and release states.

One player-facing Active item may have independent implementation lanes, but parallel lanes do not authorize competing product directions. If ownership or integration order is unclear, the item returns to Dialogue rather than creating overlapping branches.

Useful Measures

Measures are for finding process friction, not grading the agent:

• time from Ready to first fair human rehearsal;
• number of revisions before acceptance;
• reason for rejection or reopen;
• defects escaping the selected gate;
• human time spent diagnosing avoidable mechanical failures;
• items abandoned after broad implementation but before first play;
• recurring operations still performed manually; and
• stale Ready items whose product reason disappeared.

Do not optimize task count, lines changed, story points, test count, agent activity, or average "quality score." A small rejected prototype that answers the right question can be more valuable than a large green implementation.

Relationship To STAGE

flowchart LR
    C["Director's Flow<br/>chooses the next bounded item"] --> D["Delivery loop<br/>implements one item"]
    D --> Q["Quality gates<br/>support mechanical claims"]
    Q --> H["Director's Call<br/>accepts product experience"]
    H --> K["Checkpoint<br/>preserves the decision"]
    H -->|revise| D
    H -->|reject| C

• The Safety Kernel protects authority, state, truth, and reversibility.
• The Director's Flow controls attention and product decisions.
• The delivery loop changes the project.
• Quality gates provide claim-matched mechanical evidence.
• The Director's Call supplies human product acceptance.

None replaces another.