Phaser 4 Global Workflow Control
Use this Skill as the authoritative state machine and risk gate for the Phaser project lifecycle. It is not a general-purpose operation controller; non-Phaser operations are completely excluded from this process and handled by upper-layer system security rules and user tasks.
Execution Sequence
- First resolve to the directory where this is located, then read the control model, state and gates, and Schema.
- Create an independent Work Item for each piece of work; create a Change Request for requirement changes, and an independent Work Item for releases.
- Freeze the user's current explicit request as , binding the original text, objectives, and scope. A0, A1, A2, and security A3 use this as task authorization, do not generate Approval Ledger records, and must not be referred to as "auto-approved".
- Run before any write operations, command side effects, or external actions. Request a decision only when it cannot be determined from the user's request, code, configuration, authoritative artifacts, or deterministic evidence, and will change the product scope, user-visible behavior, visual direction, budget, compliance, or data boundaries; the first module or boundary itself is not a trigger.
- Freeze the Implementation Package before A3 enters , including task authorization ID, baseline, scope, implementation units and their array order, parallel groups, file/state ownership, outputs, verification and exit conditions; the array order is preset by the planner and serves as the only execution sequence, the control plane only validates and executes, and does not derive the sequence from dependency graphs. Modules and scenarios must be marked unit by unit, A2 does not require an A3 package.
- Proactively identify safe parallelism. READY only validates the current effective PASS Execution Unit Result according to the position of the array: serial units wait for all preceding units; parallel units wait for all units before the first item of their parallel group, and peers in the same group do not wait for each other. The same non-empty parallel group must appear consecutively in the array, and READY module/scenario units must form a complete Parallel Delegation Batch, and run once, instead of delegating and releasing one by one. The batch must freeze the sorted delegation path and file-by-file hash, and record the sorted unique implementation units and agent array derived from the content; any delegation changes after the batch or damage to historical batches will be blocked. A0-A2 delegations do not carry implementation unit fields, A3 delegations must be bound to implementation units; A4-A6 operation approvals cannot be converted into delegation authorizations. When entering ,
evidence/<workItemId>/execution-state.json
- First run to automatically derive the channel, missing artifacts, and next command. Run after implementation: A1/A2 or external-only receipts can use real hashes, A3/A4 must have real Git diffs; generate an Evidence Manifest after verification.
- Use to advance at most one state at a time. A1/A2 are closed after audit and evidence requirements are met; security A3 is directly marked by after F0-F3 are passed, and A4/F4 is not mandatory. Formal entry replacement, migration, deletion of old implementations, and cross-module high-impact integrations enter A4.
Task state hard gates:
,
,
,
, and migrations entering
must read and review the current Execution State; fail closed if it is missing, expired, tampered with, or inconsistent with the Work Item/Package/baseline/
order. After the V2 unit sequence is completed, the next task
must be provided in the machine output; only when the unique
is bound with
,
,
in evidenceRoot, and
with consistent recalculation can it be marked
, otherwise it remains
. Contract completion must be refreshed in an exclusive lock via the official
command, after the V2 contract passes, the current work item is allowed to enter
VALIDATING → PASSED → COMPLETE
, and V3 planning is executed by subsequent work items.
Hard Constraints
- Output for unresolved trade-offs in product, visual, architecture, budget, compliance, or data boundaries; update task authorization, authoritative artifacts, or decision records after clarification, do not write to the Approval Ledger.
- Only specific operations of A4, A5, A6 create pending, and freeze impacts with a non-empty . Short replies only explain the unique operation and impact shown in the most recent , and cannot approve subsequent operations or expand the scope.
- A4 requires precise F4 approval by default; A5 must be bound to the specific external target and impact of this time; A6 includes destructive operations, production migration, real-device testing, store/official release, and online rollback, and is never automated.
- Only accept fixed whitelist actionType. Git, Shell, file management, package management, browser, messaging, GitHub, general cloud configuration, third-party APIs, and general process management all return , do not read Work Item/Ledger, do not enter F0-F4, and do not create approvals.
- Prohibit automatic rollback of shared workspaces, prohibit overwriting others' modifications. The workflow explicitly supports controlled parallel implementation with mutually exclusive file/state ownership; do not automatically create worktree.
- Check the same project, type, mode, port, PID, and health status before starting a process and reuse it. Execute directly when local verification, non-privileged, and no external writes are required for this project; do not terminate processes with unknown ownership.
- Old approvals and old evidence become invalid after baseline, code/diff fingerprint, or scope changes.
Machine Hard Gates for Visual Stages
The visual sequence is fixed as
V0 → V1 → V2 → V3 → V4 → V5
.
global-static-baseline-frozen
only indicates that the static visual baseline is frozen, and is never equivalent to
; V3, V4, V5 use
v3-production-planning-complete
,
v4-formal-acceptance-complete
,
v5-runtime-integration-candidate
respectively. Bare
, unknown stages, missing semantics, and conflicting fields fail closed.
Formal Scene/UI entry replacement, Boot entry modification, visible asset runtime consumption, old visual deletion, and "completed/releasable" declarations all belong to visible visual production integration.
,
,
,
,
,
,
,
,
,
uniformly call
scripts/visual-stage-prerequisites.mjs
. The validator only reads immutable V2/V3/V4/V5 evidence files with path+sha256 and recalculates the Work Item, Unit Result, candidate and dependency hashes; handwritten PASS, root boolean values, stage names, and user approvals cannot replace evidence. Dependency changes will mark pending as stale, and the recovery action is to return to V2. Gray-box/diagnostic text can only be isolated in A2 or security A3, and accessing the official Boot/Scene chain must go through V2→V5 again.
Visual production contract hard gates:
of V3 must explicitly declare
,
,
,
image_generation_required
,
generation_record_required
,
, and
for each annotation/region, and cannot infer ImageGen from
,
, or visual similarity. The PNG, atomic components, states, and asset requirement list from renderings decomposition analysis must be confirmed by manual
,
of
visual-decomposition-confirmation/1.0
before entering the Implementation Package; the confirmation set must cover all numbered current generation, reused existing resources, and non-image logic, freeze production_label, component/state/asset requirements, and proposal/annotation/decision SHA; missing, AUTO, pending, old fields, old SHA, or missing numbers are rejected. Fixed visual images only allow
,
PNG/JPG, or
with evidence;
, Graphics, CanvasTexture, runtime drawing,
can only be used for non-image logic, and cannot become image components, expected_assets, actual_assets, or runtime consumption.
image_generation_required=true
can only be satisfied by ImageGen + independent raster-image, complete generation/prompt records, and actual runtime consumption. V4 requires
production_contract_audit
, F2 only accepts deterministic machine facts with
(no second reviewer required), V5 also requires F3 runtime replay, non-empty freshness-bound fidelity cases, runtime consumption, and no unapproved substitutions. Method changes only accept
Change Requests bound with complete context.
Additional requirements for rendering reconstruction:
scene_reconstruction_contract
: it freezes the full-screen composition, visual facts per region, runtime fidelity obligations, target-bound layout, responsive invariants, project tolerances, and complete implementation plan. Return
when V2→V3 only produces independent resources, reuses old layouts, or lacks runtime visual facts; the same-screen combination pre-acceptance of V4 and structured fidelity/F2/official Scene consumption evidence of V5 cannot be replaced by resource engineering sub-gates.
of the implementation package only accepts V3/V4/V5, unknown stages must explicitly fail, and V5 cannot fall back to V3.
Visual manual confirmation is an additional constraint for the above scenario hard gates, and does not change the general A0-A6/F0-F4: the entire V0→V5 chain only requires a unique structured
when the V2 visual direction is frozen. This record does not collect
,
, or reviewer strings, and only expresses a manual approval event with
,
,
,
,
, and frozen target, V2 candidate, diff, and baseline hashes. The representative screens, dynamic samples, and structured machine verification of V2, as well as the asset, combination, full-screen, overlay, diff, per-region, and component checks of V4/V5/F2, only use deterministic machine evidence bound to the current identity, and no longer require repeated human_review or a second reviewer; AI reviewer fields cannot replace this unique human approval. The approval becomes invalid if the target, candidate, diff, baseline, or approval evidence hash bound to it changes; root PASS, bare approval text, auto boolean values, or
all_visual_artifacts_human_reviewed
cannot bypass the validation.
Commands
Run
node <skill-dir>/scripts/workflow-control.mjs init ...
for the first use, it only creates an empty ledger, standard directories, and the first Work Item when the control directory does not exist.
must be resolved to the actual root directory of this Skill, and cannot be guessed based on the current working directory of the game project. Then run
node <skill-dir>/scripts/workflow-control.mjs <route|advance|prepare-approval|handoff|preflight|approve|delegate-check|parallel-check|unit-check|diff-audit|evidence-check|transition|status|lint> --help
.
approve --approval-id <id> --user-text "批准"
will automatically generate a complete record from the currently displayed pending; negative or irrelevant text is rejected. The commands only use the Node.js standard library, and never automatically roll back, release, or execute external actions.