phaser4-game-artifact-cleanup

Phaser 4 Record and Intermediate Artifact Cleanup

Global Control Integration

Use phaser4-game-workflow-control as the sole task scope, risk gate, and state authority. This Skill proposes cleanup within the current Work Item scope, reviews references and risks, submits the cleanup list, execution results, and verification evidence, then returns to the control plane for audit and state transition; it does not establish a second state machine, and does not directly modify the approval ledger or hand-write state to release references.

When the user requests cleanup, local artifacts confirmed to be regenerable may be inventoried and handled within the specified scope, without repeatedly requesting approval for ordinary local operations. Phase wrap-up only handles temporary files produced by this task; historical records, other tasks, and shared directories are not automatically included due to wrap-up. When out-of-scope candidates are found, only report them. A4-A6 operations with side effects, such as unrecoverable data deletion and external deletion, are approved per object by the control plane, and authorization only covers the approved list and the corresponding content identity.

Determination Boundaries

"Expired" requires a project retention policy, a user-specified period, or the fact of having been replaced by a new version; an earlier modification time does not equal expired. "Unused" requires a complete reference check and clear ownership; zero matches in a text search do not equal no references. Task completion, invalidated evidence, files ignored by Git, untracked files, or duplicate content cannot alone serve as grounds for deletion.

File Category	Default Handling
.workflow-control/work-items/, approval ledger, state transition/rework records	Retain; not automatically deleted even in the terminal state, historical records support tracking and auditing
Implementation package,evidence/<workItemId>/execution-state.json, Result, verification checklist, files bound to paths and business ownership	Retain valid references and the audit chain; invalidation does not equal deletable
V2 decomposition and layout confirmation, V3 formal assets/production records, V4 implementation and runtime evidence	Retain the complete dependency closure, including original images, JSON, review pages, runtime evidence, and host context
Temporary logs, temporary exports, failed candidates, duplicate previews, regenerable builds or caches that clearly belong to this task	After proving no references, no runtime occupancy, and regenerability, include in the cleanup list
Source code, formal assets, source materials/videos, user deliverables, lock files, test fixtures, release artifacts	Retain by default; not general intermediate artifacts

Original videos may be used for re-extracting frames, background-removed original images may support production records and quality review, andreview.html may be the actual artifacts required for manual review. Do not make batch judgments by file extension, directory names containing output/temp, or file size. For existing artifact directory specifications, seeGame Project Directory Specifications, and for evidence semantics, seeControl Model。

Cleanup Process

1. Limit Scope: Read the current task, Work Item, allowed paths, and existing retention policy. Confirm the repository's absolute root path, and record existing Git modifications and staged content; identify parallel tasks and processes currently writing artifacts. When there is no established retention period, do not invent a "delete after N days" policy on your own; first handle files that can be proven useless and regenerable.
2. Establish retention set: From all still-retained Work Items, implementation packages, approval/rework records, evidence lists, resource lists, load entry points, build/test configurations, and delivery lists, trace paths and SHAs; recursively retain their dependencies, and do not only check the current Work Item. Reference resolution covers relative path bases, dynamic loading, directory scanning, embedded references in HTML/CSS/JSON, and symbolic links. When dynamic references cannot be confirmed or reference records cannot be read, retain the corresponding candidates and do not guess at safety.
3. List candidates: Record file by file the project-relative path, resolved absolute path, category, owning task, size, SHA-256, basis for being expired/unused, reference check scope, regeneration command and inputs, recommended action, and retention reason. When usable inputs, tools, or an executable regeneration path are missing, do not mark it as "regenerable". Identical content is only used to identify duplicate candidates, and paths are not automatically merged nor references updated.
4. Pre-execution review: Verify the list and the task-allowed paths, run the control plane check, and execute according to the actual action preflight. First submit objects requiring approval and their impact as precise pending items; ordinary locally regenerable candidates are executed directly within the authorized scope. Before deletion, recheck references and write occupancy, and use internal content digests to prevent mistaken deletion after concurrent writes; this is deletion transaction protection, not acceptance verification, and does not require artifacts to fill in a SHA. If content or dependencies change after the list is generated, skip that object and re-determine, without reusing the old approval.
5. Per-object cleanup: Operate only on the specific files in the reviewed list, do not recursively delete entire record directories, and do not execute git clean、git reset or bulk historical cleanup. Unknown ownership, changes by others, still-active work items, files being written, and inputs required for regeneration are always retained. On failure, record the actual result, stop subsequent actions that depend on that failure, and continue with objects that have no dependencies; do not expand wildcard scope or automatically retry with elevated privileges.
6. Verification and wrap-up: First recommend T0-T3 levels, reasons, coverage, and commands, then automatically execute applicable checks. Recheck that all retained records and referenced files exist and that their actual content meets current requirements, without comparing SHAs, and run the control plane check; when resources or build artifacts are involved, run the affected resource checks/builds, and before starting services reuse a healthy instance of the same project. Successful file deletion does not mean the evidence gate passes; if verification fails, fix first and re-verify, report items that cannot be recovered, and do not hand-write status to bypass the gate.

Paths and recovery

• Before deletion, resolve the final absolute path and confirm it is within the project root and the allowed cleanup directories; reject the root directory itself,.. out-of-bounds, symbolic links/junctions/reparse points pointing outside the scope, and subfiles redirected outside the scope via such directories. On Windows, determine path boundaries according to the actual file system case rules, and do not judge only by string prefixes.
• Use PowerShell 7 and -LiteralPaththroughout Windows file operations; do not concatenate PowerShell enumeration results into cmd /c or another shell for deletion. Prefer per-file Remove-Item -LiteralPath <已复核绝对路径>, and do not treat example placeholder paths as an executable list.
• For recoverable operations, prefer the project's existing recycle/quarantine method; move only within explicitly allowed project directories, and verify that the move target will not overwrite files. Report the space occupied by quarantine, and do not misrepresent moving as freeing space; the quarantine directory remains subject to retention rules and must not grow without bound.
• Before deleting Git-tracked files, confirm they can be recovered from the current commit and contain no uncommitted content; recovery applies only to the exact paths of this task and does not overwrite others' modifications. Untracked records that cannot be regenerated, if no recovery copy exists, are handled as unrecoverable deletions and are not authorized merely by being "untracked".

Result report

Prefer reusing the current Work Item's result/evidence location or report directly in the final reply; do not create long-term independent logs, backups, or report copies for each cleanup. If the report itself is acceptance evidence, add it to the retention set.

• Coverage of cleanup scope, retention policy, and reference checks;
• The exact files actually deleted, quarantined, retained, failed, and skipped, and the reasons;
• The actual number of bytes deleted, bytes quarantined, and recovery/regeneration methods;
• The test levels executed, commands, results, and unverified items;
• Control-plane review results, remaining uncertainties, and out-of-scope items requiring user decisions.

When only taking inventory, explicitly state that no deletion was performed; do not claim freed space without reliable byte statistics. Cleanup does not change the original task's stage or evidence validity; finally hand back to the control plane and submit this task's differences according to the existing wrap-up rules.