Global control integration
Control plane boundary: may propose, may review, and may modify within the Work Item scope of the current user task, and must return to $threejs-game-workflow-control audit and state transition; only A4-A6 operation requests involving external writes, payment, real devices, destructive or external deletion, or release side effects require approval.
This domain may propose, review, and modify within the current user task, Implementation Package, A level, and file scope. All actions first pass through threejs-game-workflow-control preflight, and results return to the master control audit and state transition; changes within the task synchronously update the plan, and A4-A6 operations with external writes, payment, real devices, destructive or external deletion, 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 basic module phase must implement the background pause and resume constraints described below, and verify them in the target container and browser.
- Select strategies based on runtime memory, decoding and loading budgets, and real channel audio specifications; flag assets that are unlicensed, non-loopable, have excessively high decoding or loading peaks, or do not meet channel hard limits.
- Standard and release channels submit one audio scope, evidence, or blocker item to master control, and master control updates the control plane; the fast channel submits only when a pending decision or blocker item 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 playback instances are not separately managed by feedback orchestration.
Background pause and resume constraints
- Establish a unified audio service and platform lifecycle adaptation during the basic module phase, 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 playback during the background period, and do not defer this to specific scene implementation.
- 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, continue playback from the original position, preserve loop, volume, and mute settings, and do not replay from the beginning or recreate playback instances. Instances that were already manually paused, already stopped, already destroyed, or whose owning scene has exited must not be automatically resumed.
- Page visibility, native lifecycle, and audio interruptions may give duplicate or interleaved notifications; 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 a burst of stale feedback after returning to the foreground.
- When the browser or host restricts automatic resumption, 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 re-enters the background before an asynchronous resume completes, background playback must not occur.
- The base 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 erroneous resumption after a manual pause, no revival after stopping/destroying in the background, no deferred playback of new background requests, and retry after restricted resumption. Source code inspection or builds cannot replace actual playback evidence; without runtime evidence, mark as unverified, and real-device acceptance must not be executed automatically.