claw/docs/superpowers/specs/2026-04-18-g6-host-bridge-workflow-design.md

G6 Host Bridge Workflow Design

Date: 2026-04-18 Status: Initial implementation slice

Goal

Define G6 宿主桥接多步查询型 as a separate scene family so boundary samples no longer fall back into G1 or G1-E.

The initial implementation goal is classification and fail-closed safety, not runnable generation.

Family Definition

G6 covers scenes where the business workflow is primarily advanced by host-browser bridge actions instead of direct request contracts.

Minimum signals:

1. explicit host bridge action such as BrowserAction(...)
2. explicit browser script bridge such as sgBrowserExcuteJsCode(...)
3. callback-driven request progression
4. business endpoints nested behind the host callback chain
5. optional localhost:* dependency as host runtime evidence

P0 Boundary Sample

电能表现场检验完成率指标报表

Repo-local representative:

tests/fixtures/generated_scene/g6_host_bridge_workflow

Contract Policy

The first slice intentionally does not generate runnable skills for G6.

Instead, it must:

1. classify the scene as host_bridge_workflow
2. preserve host bridge actions as evidence
3. preserve localhost:* dependencies as host-runtime evidence
4. prevent fallback to single_request_table
5. prevent fallback to single_request_enrichment
6. fail closed with a stable blocker

Non-Goals

1. no host transport redesign
2. no callback runtime implementation
3. no full browser bridge orchestration
4. no broad G7/G8 expansion
5. no weakening of G1-E or G3 gates

Readiness Gates

The first slice adds these G6-specific gates:

1. g6_host_bridge_detected
2. g6_fail_closed

g6_fail_closed is expected to fail until a real G6 runtime contract exists.

Acceptance Criteria

1. G6 fixture is classified as host_bridge_workflow
2. generation fails closed instead of writing a pseudo-runnable skill
3. ordinary localhost export noise does not get promoted to G6
4. existing G1-E, G3, G2, and canonical tests remain green