Files
claw/docs/superpowers/plans/2026-04-18-scene-skill-real-sample-validation-roadmap-plan.md

129 lines
3.8 KiB
Markdown

# sgClaw Scene Skill Real Sample Validation Roadmap Plan
> **Status:** Draft
> **Date:** 2026-04-18
> **Author:** Codex
> **Upstream Spec:** [2026-04-18-scene-skill-real-sample-validation-roadmap-design.md](D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/specs/2026-04-18-scene-skill-real-sample-validation-roadmap-design.md)
## Plan Intent
This plan starts after the post-roadmap execution board and first-round validation layer are in place.
Its purpose is to:
1. execute selected real samples for `G2`, `G1-E`, and `G3`
2. use validation outcomes to decide the next bounded implementation scope
3. avoid drifting back into fixture-first or asset-first work
## Scope Guardrails
1. Do not reopen completed repo-local baseline implementation for `G1/G2/G3`.
2. Do not create new board-only assets unless they unblock current validation execution.
3. Do not open `G4/G5` implementation before formal entry decisions are documented.
4. Do not pull `G6/G7/G8` into the next build round without explicit validation pressure.
## Workstreams
1. `WS1` Mainline Real Sample Execution
2. `WS2` Validation Result Triage
3. `WS3` Boundary Runtime Entry Decision
4. `WS4` Deferred Family Entry Decision
## Phase 0: Execute Mainline Real Samples
### Objective
Convert selected `G2`, `G1-E`, and `G3` anchors into executed real-sample records.
### Tasks
1. Execute `G2` anchor validation updates from the current mismatch baseline.
2. Keep `G1-E` real pass anchor as the current positive baseline.
3. Execute the pending `G3` real sample.
4. Write all outcomes into the validation record layer.
### Deliverables
1. updated real-sample validation records
2. updated mismatch taxonomy usage
3. updated execution-board validation statuses
### Acceptance Criteria
1. `G2`, `G1-E`, and `G3` each have executed real-sample records
2. `selected-not-yet-run` no longer remains for current mainline anchors
## Phase 1: Triage Results Into Scope Decisions
### Objective
Use validation results, not fixture status, to choose the next bounded scope.
### Tasks
1. classify each mainline family result as `stable`, `mismatch-driven`, or `blocked-by-runtime`
2. identify which problems are compiler-family gaps and which are runtime gaps
3. define the next recommended scope from validation evidence
### Deliverables
1. validation triage report
2. next-scope recommendation
### Acceptance Criteria
1. the next scope is justified by executed validation evidence
2. repo-local success no longer acts as the sole decision signal
## Phase 2: Boundary Runtime Entry Decision
### Objective
Decide whether `G6/G7/G8` should stay boundary-only or enter a runtime-focused roadmap.
### Tasks
1. compare boundary-family runtime gaps against executed validation pressure
2. decide whether any boundary family should enter the next roadmap
3. document non-entry decisions explicitly when scope stays closed
### Deliverables
1. boundary runtime decision note
2. next-roadmap inclusion or exclusion list
### Acceptance Criteria
1. `G6/G7/G8` entry decisions are explicit
2. no boundary family enters by drift
## Phase 3: Deferred Family Entry Decision
### Objective
Decide whether `G4/G5` should remain closed or enter a later roadmap.
### Tasks
1. compare deferred-family criteria against current validation pressure
2. confirm whether `G4/G5` remain deferred or degraded
3. record the decision before any new implementation starts
### Deliverables
1. deferred family decision note
2. updated next-roadmap scope boundary
### Acceptance Criteria
1. `G4/G5` entry decisions are explicit
2. deferred families do not enter implementation implicitly
## Completion Criteria
This plan is complete when:
1. all selected mainline anchors have executed real-sample records
2. the next implementation scope is selected from validation outcomes
3. boundary and deferred family entry decisions are documented