278 lines
6.4 KiB
Markdown
278 lines
6.4 KiB
Markdown
# 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
|