Files
claw/docs/superpowers/plans/2026-04-18-scene-skill-post-roadmap-execution-plan.md

6.4 KiB

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

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