claw/docs/superpowers/specs/2026-04-18-scene-skill-post-roadmap-execution-design.md

sgClaw Scene Skill Post-Roadmap Execution Design

Status: Draft Date: 2026-04-18 Author: Codex Upstream Plan: 2026-04-17-scene-skill-60-to-90-roadmap-plan.md

Problem Statement

The current 60-to-90 roadmap has already completed the planned mainline scope:

1. G2 is now a code-backed promoted family baseline with no remaining queue item.
2. G1-E is now a code-backed promoted family baseline with no remaining queue item.
3. G3 is now a code-backed promoted family baseline with no remaining queue item.
4. G6/G7/G8 remain established boundary-runtime families.
5. Track E already has frozen snapshot, current overlay, family assets, and roadmap status assets.

This means the next problem is no longer:

How do we finish the current roadmap?

It is now:

How do we convert completed repo-local roadmap assets into a stable execution board, a real-sample validation program, and a bounded next-stage roadmap without reopening old implementation work?

Goal

Define the next-stage execution design after the current roadmap closure, with three explicit goals:

1. unify the current 102-scene execution state into one authoritative board
2. introduce real-sample validation as the next quality gate above repo-local fixture success
3. prepare the next bounded roadmap for boundary families and runtime gaps without silently extending the old roadmap

Success Definition

The next stage is considered successful when:

1. every currently known scene has a stable current-state label in one execution board
2. repo-local baseline success and real-sample success are explicitly separated
3. the next roadmap boundary is written down before new implementation work begins
4. deferred families and runtime gaps have explicit entry criteria instead of ad hoc expansion

Scope

This next-stage design includes:

1. current execution-board unification
2. real-sample validation planning and first-round recording
3. boundary-family and runtime-gap prioritization
4. next-stage roadmap design and plan assets

This design does not include:

1. reopening G1/G2/G3 P0/P1 compiler work already completed
2. unlimited fixture expansion
3. full 102-scene end-to-end runtime rollout
4. direct implementation of unified login recovery
5. direct implementation of all host-runtime and transport gaps

Current Baseline

The current repo already has the following stable assets:

1. roadmap_execution_status_2026-04-18.json
2. scene_ledger_snapshot_2026-04-18.json
3. scene_ledger_status_2026-04-18.json
4. p1_family_manifest.json
5. p1_family_results.json

Together they show that the roadmap mainline is complete at the repo-local level, but they do not yet provide:

1. one unified 102-scene current execution board
2. one authoritative real-sample validation layer
3. one explicit next-stage roadmap boundary

Design Principles

1. Do not extend the old roadmap silently.
2. Keep repo-local promotion and real-world validation as separate stages.
3. Treat family assets as stable inputs, not as temporary scratch data.
4. Keep G4/G5 deferred until a new entry decision is documented.
5. Keep runtime-gap planning separate from archetype-family planning.
6. Keep execution-board work minimal and subordinate to real-sample validation.
7. Move into real-sample validation as soon as G2, G1-E, and G3 each have one mappable real sample.
8. Defer any new asset that does not directly support current validation execution.

Workstream Model

The next stage is divided into four workstreams:

1. WS1 Current Execution Board Unification
2. WS2 Real Sample Validation
3. WS3 Boundary and Runtime Gap Planning
4. WS4 Next Roadmap Definition

WS1: Current Execution Board Unification

Intent

Unify the frozen snapshot, current overlay, family assets, and roadmap status into one authoritative scene-execution board. This board is a support layer for validation, not a new standalone asset program.

Required Outputs

1. current execution board
2. snapshot-vs-current diff table
3. family-to-scene mapping table

Acceptance

1. every scene has one current-state label
2. promoted baseline and promoted expansion states are visible at scene level
3. no manual cross-reading across multiple assets is required to know current status
4. the board stays limited to the minimum structure required by real-sample validation

WS2: Real Sample Validation

Intent

Introduce the next quality layer above fixture success by validating representative real samples for current mainline families. Once one mappable real sample exists for each of G2, G1-E, and G3, this workstream takes priority over further board refinement.

Required Outputs

1. real-sample validation plan
2. first-round validation records
3. mismatch taxonomy
4. execution-board status updates

Acceptance

1. each mainline family has at least one real-sample validation record
2. real-world mismatch reasons are explicit
3. fixture success is no longer treated as the final success state
4. validation execution is not blocked by nonessential board or reporting assets

WS3: Boundary and Runtime Gap Planning

Intent

Prepare the next bounded scope by deciding what should happen with G4/G5 and with runtime gaps that the current roadmap intentionally excluded.

Required Outputs

1. boundary family readiness notes
2. deferred family entry criteria
3. runtime gap matrix
4. prioritization note for next implementation round

Acceptance

1. G4/G5 do not enter by drift
2. runtime gaps have explicit classifications
3. next implementation round has a documented reason for scope choice

WS4: Next Roadmap Definition

Intent

Write the next bounded roadmap instead of continuing indefinitely under the old one.

Required Outputs

1. post-roadmap design
2. post-roadmap plan
3. milestone table
4. new completion criteria

Acceptance

1. the next stage has its own scope guardrails
2. the next stage has its own completion criteria
3. new work no longer depends on stretching the old roadmap beyond closure

Completion Criteria

This design is considered fully executed when:

1. the current roadmap is explicitly marked completed in execution assets
2. the execution board is unified
3. real-sample validation has begun with formal records
4. a new bounded roadmap exists for post-roadmap work