# 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