phaser4-game-orchestrator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Phaser 4 游戏编排

Phaser 4 Game Orchestration

控制面边界：可提议、可审查、可在 Work Item 任务授权或显式批准范围内修改，且必须回到

$phaser4-game-workflow-control

风险门。

以

phaser4-game-workflow-control

为唯一全局状态与审批权威。本 Skill 只编排领域提议、审查、实施包和证据，不能批准、推断授权、扩展范围或改变全局状态。

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

先读取全局 Work Item、任务授权、当前基线与状态；只有显式批准门才读取 Approval Ledger。任何写入前运行全局
```
preflight
```
。
缺项目文档时，先受限 bootstrap，再在任务授权的 A1 路径内运行
```
node scripts/initialize_project_docs.mjs --project-root . --work-item <file> --object <authorized-object>
```
；仅 A4-A6 具体操作批准需要传
```
--ledger
```
，默认拒绝覆盖。视觉或效果图任务随后必须第二次运行同一初始化器并追加
```
--include assets,qa
```
；第二次只生成 optional 文档，不覆盖第一次生成的 core 文档。
按领域读取模块划分、游戏实现、视觉质量门、服务复用、交付物、依赖与服务边界。
在 G0 冻结完整场景、功能、模块、正式资源和证据追踪；按 G0-G3 阶段门将首个可玩切片作为 G1 中间里程碑，而非出口。

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

将 G0-G3、V0-V5 和产品/架构/生产/测试/发布阶段写入
```
stageId
```
，按全局状态映射汇总；不得建立第二套状态机。
在 G1 内强制执行公共基础、全部 gameplay 场景、全部 supporting 场景、跨场景功能关闭的顺序；每个场景必须完成功能、V3、V4
```
accepted
```
、V5、占位清理和联合证据后才能关闭。持续实施到全部授权场景和功能完成。
F0-F4 只采用唯一语义：F0 授权与流程合规、F1 规格一致性、F2 领域质量、F3 工程验证、F4 集成/发布决策。
需求变化只停止直接受影响范围。首次模块或边界变化先从事实确定；仅有会改变产品行为、架构/data 边界或成本的实质取舍才进入 grilling。
进入 A3
```
IMPLEMENTING
```
前冻结绑定任务授权的 Implementation Package。拆分模块和场景时按
```
executionUnits
```
数组记录计划制定者预设的实施顺序，逐实施单元标注并行模式/并行组、负责人、互斥文件与状态所有权、验收和串行原因；控制面只按数组位置校验当前候选完成证据并执行 READY，不从依赖图推导顺序。串行单元等待其前面全部单元，并行单元等待其并行组首项之前全部单元；同一并行组必须连续出现且同组 peer 不互相等待。每个子代理委派绑定实施单元与并行组，含 authorizationId、所有权、allowed/forbidden、验收命令和不得覆盖他人；串行单元通过
```
delegate-check
```
，同组并行单元必须组成完整原子批次并通过
```
parallel-check
```
。
进入 A3
```
IMPLEMENTING
```
后，控制面必须维护与当前 Work Item、Implementation Package、baseline 和
```
executionUnits
```
数组顺序绑定的
```
execution-state.json
```
。每次
```
unit-check
```
通过都必须把当前单元更新为
```
COMPLETE
```
，并把下一串行单元或下一并行组更新为
```
IN_PROGRESS
```
；并行组未齐不得推进后续数组位置，所有单元完成且无下一任务时必须明确
```
WORKFLOW_COMPLETE
```
。
```
delegate-check
```
、
```
parallel-check
```
、
```
unit-check
```
、
```
evidence-check
```
和进入
```
VALIDATING
```
的迁移不得绕过缺失或过期状态。
实施后用真实 Git diff 执行
```
diff-audit
```
；领域验证生成 Evidence Manifest 并执行
```
evidence-check
```
。越界只报告并停止，不自动回滚共享工作区。
启动服务前检查同项目健康实例并复用。本项目本地验证、非特权且无外部写入时直接执行；不得终止归属不明进程。
发布使用独立 Work Item；A5 外部准备与 A6 真机/商店/正式发布分别逐对象精确审批。本地构建、测试、G3 候选或旧批准都不授权发布。
总控只编排
```
phaser-*
```
生命周期动作。Git、GitHub、消息、包管理和普通云/API 操作不进入本工作流；Git diff 仅作为 Phaser 候选证据。

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.

视觉与 UI

Visuals & UI

V0 分流，V1 契约/低保真，V2 方向/高保真，V3 生产规划，V4 正式资源，V5 运行态集成。普通资产在 schema 1.5 声明还原

not-applicable

。效果图还原冻结后、V3 前完成合同回对与 coverage，生命周期为

v3-ready

；拆解顺序固定为“先状态分析，再按可复用部件拆分”：每个 region 的

state_analysis

必须覆盖 default、selected、active、disabled、pressed、hover、victory、defeat、paused，并逐项写

required

或

not-applicable+reason

；

annotation_number

不是资产数量，② 6 个顶部按钮、⑧ 3 个底部表面、⑨ 3 个动作图标必须逐部件登记。

expected_assets

默认逐部件独立交付；ImageGen 无条件要求独立位图、

delivery_mode=individual

、

atlas_allowed=false

，禁止横向组图和图集；固定视觉图片只允许 imagegen/authored-raster PNG/JPG 或有证据的 reuse，authored-svg、Phaser Graphics、Canvas/CanvasTexture、runtime-program 和 runtime drawing 只能用于非图片逻辑，不能替代游戏图片。之后再依据 ownership/F2 事实在冻结效果图上生成编号 PNG（左原图、右侧说明栏）并展示用户，明确本次生成、复用既有资源和程序实现。所有带

annotation_number

的区域（本次生成、复用既有资源、非图片逻辑）必须先进入同一提案/标注/决定确认集合，冻结 production_label、component/state/asset requirement、场景状态及区域定义 SHA；在

visual-decomposition-confirmation/1.0

中绑定 proposal/annotation/decision SHA、用户原文、accepted_at、work item 和 candidate identity。只有

status=accepted

、

confirmation_mode=manual

的人工确认才能进入 Implementation Package，AUTO、pending、旧 SHA 或漏编号均拒绝。正式流程不生成或接受 SVG 标注。

reuse-existing

必须使用不可变

asset-reuse-snapshot/1.0

，额外精确绑定

source_file

、

source_manifest_sha256

、

source_sha256

、

compatibility_evidence_sha256

，并由文件检查确认快照资源为

accepted

；冻结原图须为与目标画布同尺寸的完整合法 PNG。开始任何拆解生产前必须运行带

--check-files --project-root .

的校验且结构和文件证据均通过，确认前不得裁切、抠图、分层、AI 分割/补全或生产派生位图；确认只授权拆解范围，不改变玩法、布局或视觉事实。V3/V4 可暂无 fidelity case，只有 V5 验证完成才标记

v5-complete

并要求全部通过。owner_type 是合同/F2 专业事实，验证器不从像素推断。

其中⑧若三个表面视觉相同，登记为 1 个 component + 3 个 placements；编号和 placement 数量都不能被解释为组合图资产数量。

视觉阶段使用全局控制面的唯一机器枚举

V0→V1→V2→V3→V4→V5

。

global-static-baseline-frozen

只冻结静态基线，不等于

v2-direction-frozen

；生产规划、正式资产验收和运行集成分别使用

v3-production-planning-complete

、

v4-formal-acceptance-complete

、

v5-runtime-integration-candidate

。正式 Scene/UI 入口、Boot 接入、可见资产消费和旧视觉删除必须由共享跨阶段校验器从带 path+sha256 的 V2/V3/V4/V5 证据派生，不能使用根摘要、手写 PASS 或用户批准文字。灰盒仅可留在隔离 A2/安全 A3，进入正式链后必须重新通过完整视觉阶段门。

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

只报告状态包、交付物、实际 diff、可复现证据、未覆盖项和下一门。仍有未完成场景、功能、正式视觉接入或占位资源时不得报告 G1 完成；仅全局控制面可迁移到

PASSED

、

INTEGRATING

、

RELEASING

或

COMPLETE

。

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