Phaser 4 Game Orchestration

Control Plane Boundary: Can propose, review, and modify within the scope of Work Item task authorization or explicit approval, and must return to the

$phaser4-game-workflow-control

risk gate.

Treat

phaser4-game-workflow-control

as the sole global state and approval authority. This Skill only orchestrates domain proposals, reviews, implementation packages, and evidence; it cannot approve, infer authorization, expand scope, or change global state.

Startup

First read the global Work Item, task authorization, current baseline and state; only read the Approval Ledger at explicit approval gates. Run the global
```
preflight
```
before any write operation.
When project documentation is missing, first perform restricted bootstrap, then run
```
node scripts/initialize_project_docs.mjs --project-root . --work-item <file> --object <authorized-object>
```
within the A1 path of task authorization; only A4-A6 specific operation approvals require passing
```
--ledger
```
, and overwriting is denied by default. Visual or render task must then run the same initializer a second time and append
```
--include assets,qa
```
; the second run only generates optional documentation and does not overwrite the core documentation generated in the first run.
Read Module Decomposition, Game Implementation, Visual Quality Gate, Service Reuse, Delivery Artifacts, Dependency & Service Boundaries by domain.
Freeze complete scenes, features, modules, formal resources, and evidence tracking at G0; treat the first playable slice as the G1 intermediate milestone instead of an exit, in accordance with G0-G3 Stage Gates.

Orchestration Rules

Write G0-G3, V0-V5, and product/architecture/production/test/release stages into
```
stageId
```
, and summarize according to Global State Mapping; do not establish a second set of state machines.
Enforce the order of common foundation, all gameplay scenes, all supporting scenes, and cross-scene feature closure within G1; each scene can only be closed after completing features, V3, V4
```
accepted
```
, V5, placeholder cleanup, and joint evidence. Continue implementation until all authorized scenes and features are completed.
F0-F4 only adopt the Unique Semantics: F0 Authorization & Process Compliance, F1 Specification Consistency, F2 Domain Quality, F3 Engineering Validation, F4 Integration/Release Decision.
Requirement changes only halt the directly affected scope. First determine facts for the first module or boundary change; only substantive trade-offs that will change product behavior, architecture/data boundaries, or costs enter grilling.
Freeze the Implementation Package bound to task authorization before entering A3
```
IMPLEMENTING
```
. When splitting modules and scenes, record the implementation sequence preset by the planner in the
```
executionUnits
```
array, and mark each execution unit with parallel mode/parallel group, owner, mutually exclusive files and state ownership, acceptance, and reasons for serial execution; the control plane only verifies the current candidate completion evidence according to the array position and executes READY, and does not deduce the sequence from the dependency graph. Serial units wait for all preceding units; parallel units wait for all units before the first item in their parallel group; the same parallel group must appear consecutively and peers in the same group do not wait for each other. Each sub-agent delegates binding execution units and parallel groups, including authorizationId, ownership, allowed/forbidden, acceptance commands, and must not overwrite others; serial units pass
```
delegate-check
```
, and parallel units in the same group must form a complete atomic batch and pass
```
parallel-check
```
.
After entering A3
```
IMPLEMENTING
```
, the control plane must maintain
```
execution-state.json
```
bound to the current Work Item, Implementation Package, baseline, and the order of the
```
executionUnits
```
array. Each time
```
unit-check
```
passes, the current unit must be updated to
```
COMPLETE
```
, and the next serial unit or next parallel group must be updated to
```
IN_PROGRESS
```
; subsequent array positions cannot be advanced until the parallel group is complete, and
```
WORKFLOW_COMPLETE
```
must be explicitly marked when all units are completed and there is no next task. Migrations for
```
delegate-check
```
,
```
parallel-check
```
,
```
unit-check
```
,
```
evidence-check
```
, and entering
```
VALIDATING
```
cannot bypass missing or expired states.
After implementation, perform
```
diff-audit
```
using real Git diff; domain validation generates Evidence Manifest and executes
```
evidence-check
```
. Out-of-bounds operations only report and stop, and do not automatically roll back the shared workspace.
Check for healthy instances of the same project and reuse them before starting services. Execute directly for local validation, non-privileged, and no external writes in this project; do not terminate processes with unknown ownership.
Use an independent Work Item for release; A5 external preparation and A6 real-device/store/official release require precise approval per object respectively. Local builds, tests, G3 candidates, or old approvals do not authorize release.
The master controller only orchestrates
```
phaser-*
```
lifecycle actions. Git, GitHub, messaging, package management, and general cloud/API operations do not enter this workflow; Git diff is only used as Phaser candidate evidence.

Visuals & UI

V0 Diversion, V1 Contract/Low-Fidelity, V2 Direction/High-Fidelity, V3 Production Planning, V4 Formal Resources, V5 Runtime Integration. Declare

not-applicable

for ordinary assets in schema 1.5. After render restoration is frozen and before V3, complete contract reconciliation and coverage, with the lifecycle

v3-ready

; the disassembly sequence is fixed as "first state analysis, then split by reusable components": the

state_analysis

of each region must cover default, selected, active, disabled, pressed, hover, victory, defeat, paused, and write

required

not-applicable+reason

for each item;

annotation_number

is not the number of assets, ② 6 top buttons, ⑧ 3 bottom surfaces, ⑨ 3 action icons must be registered component by component.

expected_assets

are delivered independently component by component by default; ImageGen unconditionally requires independent bitmaps,

delivery_mode=individual

atlas_allowed=false

, and prohibits horizontal group images and atlases; fixed visual images only allow imagegen/authored-raster PNG/JPG or reused assets with evidence; authored-svg, Phaser Graphics, Canvas/CanvasTexture, runtime-program, and runtime drawing can only be used for non-image logic and cannot replace game images. Then generate numbered PNGs (original image on left, description column on right) on the frozen render based on ownership/F2 facts and display to users, clearly indicating current generation, reused existing resources, and program implementation. All regions with

annotation_number

(current generation, reused existing resources, non-image logic) must first enter the same proposal/annotation/decision confirmation set, freeze production_label, component/state/asset requirement, scene state, and region definition SHA; bind proposal/annotation/decision SHA, user original text, accepted_at, work item, and candidate identity in

visual-decomposition-confirmation/1.0

. Only manual confirmation with

status=accepted

and

confirmation_mode=manual

can enter the Implementation Package; AUTO, pending, old SHA, or missing numbers are rejected. The formal process does not generate or accept SVG annotations.

reuse-existing

must use immutable

asset-reuse-snapshot/1.0

, additionally precisely bind

source_file

source_manifest_sha256

source_sha256

compatibility_evidence_sha256

, and confirm that the snapshot resource is

accepted

via file check; the frozen original image must be a complete legal PNG of the same size as the target canvas. Before starting any disassembly production, run the verification with

--check-files --project-root .

and pass both structure and file evidence; do not crop, matting, layer, AI segment/complete, or produce derived bitmaps before confirmation; confirmation only authorizes the disassembly scope and does not change gameplay, layout, or visual facts. V3/V4 may have no fidelity case temporarily, and only after V5 verification is completed can

v5-complete

be marked and all requirements must be met. owner_type is a contract/F2 professional fact, and the validator does not infer from pixels.

If the three surfaces in ⑧ are visually identical, register as 1 component + 3 placements; neither the number nor the number of placements can be interpreted as the number of combined image assets.

Visual stages use the global control plane's unique machine enumeration

V0→V1→V2→V3→V4→V5

global-static-baseline-frozen

only freezes the static baseline and does not equal

v2-direction-frozen

; production planning, formal asset acceptance, and runtime integration use

v3-production-planning-complete

v4-formal-acceptance-complete

v5-runtime-integration-candidate

respectively. Formal Scene/UI entry, Boot access, visible asset consumption, and old visual deletion must be derived by the shared cross-stage validator from V2/V3/V4/V5 evidence with path+sha256, and cannot use root summaries, handwritten PASS, or user approval text. Gray boxes can only stay in isolated A2/secure A3, and must re-pass the complete visual stage gate after entering the formal chain.

Completion

Only report status packages, delivery artifacts, actual diffs, reproducible evidence, uncovered items, and the next gate. Do not report G1 completion if there are still unfinished scenes, features, formal visual access, or placeholder resources; only the global control plane can migrate to

PASSED

INTEGRATING

RELEASING

, or

COMPLETE

phaser4-game-orchestrator

NPX Install

Tags

SKILL.md Content (Chinese)

Phaser 4 Game Orchestration

Startup

Orchestration Rules

Visuals & UI

Completion