# sgClaw Scene Skill Post-Roadmap Execution Plan

> **Status:** Draft
> **Date:** 2026-04-18
> **Author:** Codex
> **Upstream Spec:** [2026-04-18-scene-skill-post-roadmap-execution-design.md](D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/specs/2026-04-18-scene-skill-post-roadmap-execution-design.md)

## Plan Intent

This plan starts after the closure of the current `60-to-90 roadmap`.

Its purpose is not to reopen `G1/G2/G3` implementation, but to:

1. unify current execution state
2. start real-sample validation
3. plan the next bounded roadmap

## Scope Guardrails

1. Do not reopen completed `G1/G2/G3` repo-local baseline implementation.
2. Do not keep expanding fixtures as the primary mode of progress.
3. Do not silently pull `G4/G5` into implementation.
4. Do not directly implement unified login recovery in this plan.
5. Do not treat the old roadmap as still open-ended.
6. Phase 1 execution-board work must stay minimal and exist only to support Phase 2 real-sample validation.
7. Once `G2`, `G1-E`, and `G3` each have at least one mappable real sample, execution must move immediately into Phase 2.
8. Any new asset that does not directly support real-sample validation is deferred to Phase 3 or Phase 4.

## Workstreams

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

## Phase Overview

1. Phase 0: Freeze Handover Boundary
2. Phase 1: Build Current Execution Board
3. Phase 2: Start Real Sample Validation
4. Phase 3: Define Boundary and Runtime Entry Rules
5. Phase 4: Publish the Next Roadmap

Execution order is fixed as:

`Phase 0 -> Phase 1 -> Phase 2 -> Phase 3 -> Phase 4`

## Phase 0: Freeze Handover Boundary

### Objective

Freeze the boundary between the completed roadmap and the next-stage work.

### Tasks

1. Freeze current roadmap completion status.
2. Freeze current mainline family status for `G2`, `G1-E`, and `G3`.
3. Freeze current boundary family status for `G6/G7/G8`.
4. Freeze current deferred status for `G4/G5`.

### Deliverables

1. roadmap handover snapshot
2. next-stage scope statement
3. current family-state matrix

### Acceptance Criteria

1. old and new roadmap boundaries are explicit
2. next-stage work is no longer mixed into the old roadmap

## Phase 1: Build Current Execution Board

### Objective

Create the minimum authoritative execution board required to start real-sample validation for the current `102-scene` status.

### WS1

#### Task 1

Build one `102-scene current execution board`.

#### Task 2

Define the stable scene status vocabulary:

1. `promoted-baseline`
2. `promoted-expansion`
3. `boundary-family`
4. `deferred`
5. `degraded`
6. `unvalidated`

#### Task 3

Map current `G2/G1-E/G3` scene promotions into the board.

#### Task 4

Generate a snapshot-vs-current diff asset.

#### Task 5

Stop Phase 1 immediately after `G2`, `G1-E`, and `G3` each have at least one mappable real sample entry in the board.

### Deliverables

1. `102-scene current execution board`
2. snapshot-vs-current diff report
3. scene-to-family status mapping

### Acceptance Criteria

1. every scene has one current-state label
2. promoted states are visible without reading multiple assets
3. board status matches current family assets
4. the board is limited to the minimum fields needed by Phase 2 validation records
5. no Phase 1 asset is added unless it directly supports real-sample validation

## Phase 2: Start Real Sample Validation

### Objective

Create the next quality layer above fixture success.

### WS2

#### Task 5

Choose the first real-sample validation set for:

1. `G2`
2. `G1-E`
3. `G3`

#### Task 6

Freeze validation criteria:

1. compile success
2. readiness correctness
3. data correctness
4. output correctness
5. fail-closed correctness

#### Task 7

Create a real-sample validation record template.

#### Task 8

Record first-round real-sample results.

#### Task 9

Write mismatches back into the execution board.

#### Task 10

Reject requests for new board-only assets that do not unblock current validation execution.

### Deliverables

1. real-sample validation plan
2. real-sample record template
3. first-round validation records
4. mismatch taxonomy

### Acceptance Criteria

1. each mainline family has at least one real-sample record
2. real-sample status is separated from fixture status
3. mismatch reasons are explicit and reusable
4. Phase 2 begins as soon as `G2`, `G1-E`, and `G3` each have one mappable real sample

## Phase 3: Define Boundary and Runtime Entry Rules

### Objective

Prepare the next bounded execution scope instead of drifting into it.

### WS3

#### Task 11

Assess `G6/G7/G8` boundary-family readiness for future expansion.

#### Task 12

Define formal entry criteria for `G4/G5`.

#### Task 13

Build a runtime-gap matrix for:

1. login recovery
2. host-runtime integration
3. transport/runtime gaps
4. local document and attachment workflows

#### Task 14

Separate:

1. archetype-family gaps
2. runtime-platform gaps

### Deliverables

1. boundary readiness note
2. deferred family entry criteria
3. runtime gap matrix
4. prioritization note

### Acceptance Criteria

1. `G4/G5` do not enter the next build round without documented criteria
2. runtime gaps are tracked separately from family expansion
3. next implementation scope has an explicit reason

## Phase 4: Publish the Next Roadmap

### Objective

Replace open-ended continuation with a new bounded roadmap.

### WS4

#### Task 15

Write the next-stage design.

#### Task 16

Write the next-stage plan.

#### Task 17

Define milestone ordering.

#### Task 18

Define next-stage completion criteria.

### Deliverables

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

### Acceptance Criteria

1. new implementation work has a new roadmap
2. the old roadmap is no longer implicitly extended
3. next-stage completion can be judged independently

## Milestone Order

1. Freeze the handover boundary
2. Unify the execution board
3. Start real-sample validation
4. Freeze boundary/runtime entry rules
5. Publish the next roadmap

No new implementation round should begin before milestones 1 to 4 are complete.
No Phase 1 expansion should continue after the minimum board needed for milestone 3 is available.

## Completion Criteria

This plan is complete when:

1. the current roadmap is explicitly closed
2. the execution board is unified
3. real-sample validation is formally underway
4. a new bounded roadmap exists for post-roadmap work