Studio workflow (Creative Engineering OS)

This workflow owns creative stage selection and handoffs: what happens next and what must be true before moving on. It does not replace specialist skills or take over a project's engineering orchestration.

When to use

• Planning a website or web experience that spans multiple stages.
• Unsure which specialist applies; run scripts/ceos-route.py for one deterministic recommendation.
• Reviewing substantial work before calling it done.
• For a local CSS or copy fix, use FAST and verify only the affected behavior plus any checks the change touches.

Inputs

Brief and requested outcome; current project state; framework and dependencies; real assets; time, hosting, and licence constraints; references; existing project instructions and engineering orchestration policy.

Choose a mode

Escalate FAST when behavior, multiple states, dependencies, or brand direction are involved. Escalate STANDARD when a launch/rebrand, shared multi-route system, immersive signature moment, or multi-team handoff needs formal approval. A user or project mode override takes precedence over automatic classification.

The stages

Use only the stages relevant to the selected mode and changed surface. A stage can be merged with another for small work.

FAST work does not require stages 1–7, 10, or a full-page audit by default. It still keeps every relevant safety and quality check. Never bypass input validation, security, data-preserving error handling, accessibility, reduced motion, or an explicit user/project gate to save time.

Decision procedure

1. Select FAST, STANDARD, or FLAGSHIP from the scope. scripts/ceos-route.py can recommend a mode and specialist without running tools or changing project state.
2. Preserve existing project instructions, framework, dependencies, and engineering orchestration. CEOS owns creative orchestration and direction. The existing project engineering orchestrator wins; in gstack-led work, gstack owns engineering orchestration and Superpowers is limited to narrow TDD and verification roles. Do not run two orchestrators.
3. Load only the primary specialist needed for the current stage. Load a second only when its contribution is explicit and needed. Check framework and constraints first; do not add React or another runtime to satisfy a skill route.
4. For substantive new work, select the lightest suitable starter (editorial, motion-heavy, immersive-3d, or experimental-graphics) and record the stack decision. A local fix does not need a template decision.
5. Build semantic content and meaningful fallbacks. Respect approved direction and provide a designed reduced-motion alternative whenever motion changes.

Compact project state and handoff

Keep a current state note only when work spans stages or owners; a FAST change does not need a new document. Use this compact schema in an existing project note or handoff:

Task: <outcome>
Mode: <FAST | STANDARD | FLAGSHIP>
Constraints / stack: <only material constraints and current framework>
Decisions: <decision → reason>
Evidence: <check → artifact or status>
Open questions: <question → owner, or none>
Next: <stage/action → owner>

Keep evidence concrete: screenshot, test output, browser interaction, trace, or explicit “not verified.” Do not write an artifact for a stage that was not needed.

Standards and evidence

• Read standards/STANDARD.md once per project; apply its relevant quality floor at each stage.
• Evidence beats assertion: a visual claim needs a real render, a performance claim needs a measurement, and an accessibility claim needs the applicable automated and manual checks.
• For substantial page work, inspect the documented responsive sizes, interactions, keyboard/focus, console, and accessibility. FAST work checks the affected viewport and interaction rather than inheriting a full-page review.
• Keep references as calibration, never copies. Mark placeholders and do not invent proof.

Failure criteria

• A required gate for the selected mode is only “probably” met.
• Visual, performance, or accessibility claims lack their relevant evidence.
• FAST mode is used even though scope expanded to behavior, multiple states, a new dependency, or brand direction.
• A data, security, accessibility, reduced-motion, or explicit quality check is bypassed.
• “Done” is declared because the build passes.

Output

For FAST, report the change and its focused check. For STANDARD and FLAGSHIP, report the current stage, compact state, decisions, relevant gate status, evidence, open questions, and next owner. Do not emit the full handoff at every step.