Change an SPF behavior
Treat code and tests as implementation truth. Read the behavior, composition site, state/context slots, helpers, and tests, then load only the relevant file from internal/design/spf/conventions/.
Before acting, read the one detailed workflow that matches the requested change:
- Purpose expands or changes:
references/update.md
- Purpose stays fixed while implementation improves:
references/refactor.md
- One responsibility splits by type or concern:
references/split.md
- Two responsibilities may become one:
references/merge.md
- State the current purpose, intended delta, and observable business rules.
- Map inputs, writes, lifecycle gates, cleanup, ordering, and source-reset rules.
- Choose the smallest destination shape that preserves those constraints.
- Pin observable behavior with tests before changing implementation.
- Re-read the final behavior without the diff and verify ownership, cleanup, composition, naming, and coverage.
For a split, name the ownership axis and cross-boundary invariants. For a merge, confirm the result owns one coherent purpose; extract a helper when only an algorithm is shared. Ask for direction when alternatives materially change ownership or public contracts.
Run the narrow affected tests, then as applicable:
pnpm -F @videojs/spf test
pnpm -F @videojs/spf build
pnpm -F @videojs/spf size
Example
Input: “Split source cleanup out of the playback lifecycle behavior.”
Output: A documented ownership boundary, pinned invariants, focused implementation changes, and proportional SPF checks.
1---2name: change-spf-behavior3description: Change SPF playback-engine behaviors. Use when updating, refactoring, splitting, or merging responsibilities, signals, lifecycle, cleanup, or composition.4---56# Change an SPF behavior78Treat code and tests as implementation truth. Read the behavior, composition site, state/context slots, helpers, and tests, then load only the relevant file from `internal/design/spf/conventions/`.910Before acting, read the one detailed workflow that matches the requested change:1112- Purpose expands or changes: `references/update.md`13- Purpose stays fixed while implementation improves: `references/refactor.md`14- One responsibility splits by type or concern: `references/split.md`15- Two responsibilities may become one: `references/merge.md`16171. State the current purpose, intended delta, and observable business rules.182. Map inputs, writes, lifecycle gates, cleanup, ordering, and source-reset rules.193. Choose the smallest destination shape that preserves those constraints.204. Pin observable behavior with tests before changing implementation.215. Re-read the final behavior without the diff and verify ownership, cleanup, composition, naming, and coverage.2223For a split, name the ownership axis and cross-boundary invariants. For a merge, confirm the result owns one coherent purpose; extract a helper when only an algorithm is shared. Ask for direction when alternatives materially change ownership or public contracts.2425Run the narrow affected tests, then as applicable:2627```bash28pnpm -F @videojs/spf test29pnpm -F @videojs/spf build30pnpm -F @videojs/spf size31```3233## Example3435Input: “Split source cleanup out of the playback lifecycle behavior.”3637Output: A documented ownership boundary, pinned invariants, focused implementation changes, and proportional SPF checks.
videojs