183 lines
6.4 KiB
Markdown
183 lines
6.4 KiB
Markdown
# 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](D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/plans/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
|