Global Control Integration
Control plane boundaries: may propose, may review, and may modify within the scope of the current user task's Work Item, and must return to $phaser4-game-workflow-control audit and state transitions; only A4-A6 operation requests involving external writes, payments, real devices, destructive or external deletions, or release side effects require approval.
This domain may propose, review, and modify within the scope of the current user task, Implementation Package, A level, and files. All actions first pass through phaser4-game-workflow-control preflight, and results return to the master control for audit and state transitions; changes within the task synchronously update the plan, and A4-A6 operations with external writes, payments, real devices, destructive or external deletions, or release side effects require separate approval.
Read the global Work Item, project specifications, asset registry, and test plan. Submit evidence according to F0 scope and process, F1 specification consistency, F2 audio quality, F3 engineering verification, and F4 integration/release decisions; audio direction confirmation does not equal A4-A6 operation approval.
- Define requirements by core feedback, UI, environment, music, and accessibility.
- Submit the audio asset registry package to the art integration role, including source, license or generation records, loop points, format, duration, loudness, usage, and release eligibility; the art integration role serially writes to the asset registry to avoid concurrent writes to shared files.
- Design mute, grouping, first-interaction playback, pause/resume, and background switching; the foundational module stage must implement the background pause and resume constraints described below, verified on target containers and browsers.
- Select strategies based on runtime memory, decoding and loading budgets, and actual channel audio specifications; flag assets that are unlicensed, non-loopable, have excessive decoding or loading peaks, or do not meet channel hard limits.
- Standard and release channels submit one audio scope, evidence, or blocker item to the master control, which updates the control plane; the fast channel submits only when a pending decision or blocker arises.
Provide trigger timing, grouping, and asset identifiers to gameplay, provide functional and budget items to testing, and synchronize license status to release.
Juice-feel tasks may reference as neededDynamic Feedback Design Guidefor event semantics and sound layering; audio still exclusively owns the audio instance lifecycle, background pause and resume rules, and does not have playback instances separately managed by feedback orchestration.
Background Pause and Resume Constraints
- Establish a unified audio service and platform lifecycle adaptation at the foundational module stage, covering browser page hide/restore and background/foreground switching for adopted native hosts; immediately pause all playing music, sound effects, and voice upon entering the background, prohibit new audio from starting during the background period, and do not defer this to specific scene implementations.
- When pausing, save the playback position and the set of instances paused by this background switch; after returning to the foreground, resume only instances that are still valid and have no other pause reasons, continuing playback from the original position, preserving loop, volume, and mute settings, without replaying from the beginning or recreating playback instances. Instances that were already manually paused, stopped, destroyed, or whose scene has exited must not be automatically resumed.
- Page visibility, native lifecycle, and audio interruptions may notify repeatedly or interleave; the unified service must merge pause reasons, and pause/resume must remain idempotent; resume only when the background and all other pause reasons have been fully cleared. New playback requests generated in the background are not queued for deferred playback, to avoid concentrated playback of stale feedback after returning to the foreground.
- When the browser or host restricts automatic resume, retain the pending-resume state and continue after an allowed user interaction or audio resume event; playback restrictions must not be bypassed, and a failed resume must not be marked as successful. Listeners are cleaned up when the service is destroyed, and if the app enters the background again before an asynchronous resume completes, background playback must not occur.
- The basic implementation package and TDD record audio instance ownership, playback position, pause reasons, lifecycle entry points, and cleanup strategy. Verification covers no sound after switching to the background during playback, resuming from the original position after returning, no overlapping playback from repeated switching, no false resume after manual pause, no revival after background stop/destroy, no deferred playback of new background requests, and retry after resume is restricted. Source code inspection or a build cannot replace actual playback evidence; without runtime evidence, list it as unverified, and real-device acceptance must not be performed automatically.