Change, Concurrency, And Release Workflow
Complete one authorized change, verify its material claims, and preserve a reviewable local checkpoint. Use the delivery guide for the ordinary path. This page covers source-control boundaries and the separate release identity and authority decisions.
Local Checkpoints
After relevant mechanical checks pass, review and commit only task-owned changes. Human product acceptance may still be pending. Report any failed, unavailable, skipped, or inconclusive checks; a required failed or unavailable mechanical check blocks the default verified delivery commit.
Inspect both staged and unstaged state before editing and again before committing. Record enough of pre-existing work to recognize what belongs to the task. Do not use blanket staging, reset, stash, clean, or whole-file replacement to make someone else's changes disappear from view.
When unrelated work is already staged, keep its exact content and staging disposition. An isolated temporary Git index can construct a task-only commit from HEAD, but the real index must then represent the new HEAD for task-owned paths while retaining unrelated entries. Inspect both resulting diffs. Changes mixed in the same file need reviewed hunk-level separation; path names alone do not prove ownership. If the safe boundary is uncertain, deliver the diff and explain why the checkpoint remains pending. Do not risk protected state merely to satisfy the checkpoint default.
Use project commit conventions. STAGE repository commits use Conventional Commits; adopting games choose their own convention. A commit is an engineering checkpoint, not product acceptance or permission to push, merge, tag, or publish. Honor existing authorization for those operations without asking again.
Branches And Worktrees
Choose isolation for an actual need: concurrent mutation, an experiment with material rollback risk, a long-lived incomplete slice, or repository policy. A single bounded change can use the current checkout when those needs are absent and its state is understood. Prefer short-lived branches and small, coherent integration units when branches are useful.
Inspect dirty state before creating or switching worktrees; uncommitted work is not automatically copied. Do not move or discard it by assumption. Each worktree should have an independent tool instance when the tool writes project-wide state. Keep generated caches out of source authority.
Bounded Agent Concurrency
Parallel work earns its cost when useful independent questions or changes can proceed safely. Name one integrator, give each mutator disjoint ownership or an isolated checkout, and state dependency order only where contracts overlap. Shared assets and opaque formats may require serial mutation even across branches. Use the Unity profile for engine-specific ownership and merge rules.
Give shared integration, expensive verification, and release work one owner. Contributors return their diff, focused evidence, and unresolved decisions; they need not remain active to monitor another agent's release. Reuse completion notifications or bounded waits instead of repeatedly fetching unchanged history. Integrate first, then run the affected combined gate once; repeat it for changed inputs or an investigated failure. Delegation and stronger models earn their cost from task complexity, not from a mandatory planner–implementer–reviewer chain.
A work item can carry temporary ownership and coordination notes. There is no required work registry, lease database, or STAGE work-management command. Use a handoff only when work actually crosses a task boundary; a coherent local change does not need a handoff record.
Integration
When merging is authorized, inspect the intended diff and current target branch, resolve conflicts without guessing authored intent, and rerun checks affected by the integrated result. A branch's earlier green result cannot establish a new composition it never exercised. Keep integration serial where shared state makes concurrent writes unsafe.
Clean up only known task-owned branches and worktrees when their work is safely retained and cleanup is authorized. Rejected changes may be reverted within scope without erasing unrelated work. See quality guidance for gate selection and failure handling.
Three Separate Identities
| Identity | What it answers | Who decides |
|---|---|---|
| Product release version | Which player-facing or public contract release is this? | Human under the project's compatibility policy |
| Exact build identity | Which source revision, dirty state, toolchain, and configuration produced these bytes? | Factual build evidence |
| Data contract version | Which save, content, protocol, mod API, or artifact schema can consume this data? | Contract owner under declared compatibility rules |
Do not use one as a proxy for the others. A build can be reproduced without being acceptable to release. A method or plugin update need not migrate a project's artifact schema.
Release Proposal
The agent prepares deterministic version edits, lockfiles, current references, changelog, compatibility notes, and the factual evidence record before asking for a release decision. Make the complete proposal reviewable. Do not require the human to perform clerical edits already authorized by release preparation.
The human decides compatibility judgment, subjective acceptance, release, and publication. Those decisions remain distinct from mechanical preparation and local commits. Existing authorization carries forward to its named scope; automation cannot infer public-source permission from documentation-site approval.
For STAGE, the maintainer workflow uses Release Please for draft proposals only. Current-main eligibility and a successful quality run apply to automatic and manual triggers. Release Please does not tag, create a GitHub Release, refresh the plugin, or publish source. The public documentation mirror remains a separate, scoped downstream consumer.
Failure Handling
Report the failing boundary, preserve evidence and protected state, and repair within scope. Do not retry intermittent failures until green or weaken policy. A stale branch or publication candidate requires fresh relevant evidence. Conflicting authored intent or an unavailable required capability stops only the affected operation. A finished local result can remain ready for human review while release or subjective acceptance is pending.
Measures
Use the existing evaluation context to note human attention, time to a fair inspection, useful acceptance or rejection, rework, escaped defects, and method maintenance. Coordination earns persistence when it reduces these costs. The earlier rationale is preserved in ADR 0057; ADR 0065 supersedes its routine branch/worktree and work-record defaults.