# Post-G7 Boundary Decision Roadmap Design

> Date: 2026-04-19
> Status: Draft
> Upstream Validation Layer: [real_sample_validation_records_2026-04-18.json](D:/data/ideaSpace/rust/sgClaw/claw-new/tests/fixtures/generated_scene/real_sample_validation_records_2026-04-18.json)
> Upstream Entry Rules: [boundary_runtime_entry_rules_2026-04-18.json](D:/data/ideaSpace/rust/sgClaw/claw-new/tests/fixtures/generated_scene/boundary_runtime_entry_rules_2026-04-18.json)
> Upstream Closure: [2026-04-19-g7-real-sample-entry-closure-report.md](D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/reports/2026-04-19-g7-real-sample-entry-closure-report.md)

## 1. Intent

This design defines the next bounded roadmap after `G7` has closed as the first executed boundary-family real sample.

The current validated state is now:

1. `G1-E = executed-pass`
2. `G2 = executed-pass`
3. `G3 = executed-pass`
4. `G7 = executed-pass`

So the next roadmap must not reopen any closed mainline slice and must not continue extending the finished `G7` plan.

The only question under this roadmap is:

`After G7, should another boundary family enter real-sample scope next, or should boundary work stop and defer to prerequisites?`

## 2. Problem Statement

The prior boundary-entry roadmap solved the first ambiguity by selecting `G7`.

That ambiguity is now closed.

The remaining ambiguity is narrower:

1. whether `G6` is now the next justified boundary-family entry candidate
2. whether `G8` is now the next justified boundary-family entry candidate
3. or whether both should remain held and a bounded prerequisites roadmap should be opened first

Without a new roadmap, the next step would drift into one of three bad outcomes:

1. reopening `G7` after closure
2. opening both `G6` and `G8` at once
3. starting runtime-platform implementation without a bounded decision slice

## 3. Scope Boundary

This roadmap is limited to a post-`G7` boundary-family decision.

It may include:

1. restating the now-closed `G7` result
2. comparing only `G6` and `G8` as remaining boundary candidates
3. determining whether one of them is admitted next
4. or determining that both remain held and a prerequisites slice is needed
5. publishing one bounded follow-up `design + plan`

It must not include:

1. reopening `G7` implementation or expansion
2. reopening `G1-E / G2 / G3`
3. opening `G4 / G5`
4. implementing host-runtime, transport, or local-doc prerequisites
5. executing real samples for more than one boundary family

## 4. Current Decision Inputs

The current repo state already provides the relevant admission constraints:

1. `G6` still needs stronger host-bridge real execution semantics than current repo-local coverage
2. `G8` still needs stronger local document pipeline and attachment/runtime handling than current repo-local coverage
3. `G7` is no longer a candidate because it has already closed as an executed pass

These are decision inputs only.

They are not yet implementation tasks.

## 5. Roadmap Goal

The goal of this roadmap is to reduce the post-`G7` boundary question to one bounded next step:

1. select exactly one next bounded direction
2. either `G6`
3. or `G8`
4. or a prerequisites-only slice with both held

## 6. Preferred Outcome

The preferred outcome is:

1. either one selected next boundary family
2. or one bounded prerequisites roadmap
3. with the non-selected direction explicitly held

## 7. Acceptance Logic

This roadmap is successful when:

1. `G6` and `G8` no longer compete ambiguously
2. `G7` is not reopened
3. only one bounded next direction is emitted
4. no runtime-platform implementation is started under roadmap scope

## 8. Out of Scope

The following are explicitly out of scope:

1. new scene-generator family work
2. new canonical answers
3. new mainline contract correction
4. direct host-runtime implementation
5. direct local-doc runtime implementation
6. `G4 / G5`