Skip to content

docs(superpowers): cc-app-gateway Phase 0 PoC — STUCK at A.1 - #230

Open
imryao wants to merge 2 commits into
mainfrom
spec/cc-app-gateway-phase0
Open

imryao wants to merge 2 commits into
mainfrom
spec/cc-app-gateway-phase0

Conversation

@imryao

@imryao imryao commented Jun 8, 2026

Copy link
Copy Markdown
Member

Builds on PR #229 (PoC-1: v2.1.167 --cloud redirect verified, 2 patches).

Phase 0 was meant to answer two questions before designing a real
cc-app-gateway: (1) does the subscribe-half wire format work
end-to-end against our mock, (2) which backend harness candidate
(patched --cloud vs claude -p stream-json) is the right fit.

Result: STUCK at A.1 (subscribe-half). 6 iterations later the
mock served everything claude --teleport <sid> asked for and the
binary printed "Session resumed" with the chat TUI rendered — but
the gateway saw zero requests for 30 seconds after, telemetry showed
zero tengu_bridge_* events, and the bridge:repl code path was
never entered. --teleport is local-resume; it hydrates history then
hands off to the local REPL.

Per spec §4 A.1 is a hard gate, so A.2/A.3 (backend trials) and A.4
(decision matrix) are NOT attempted. The bridge:repl renderer exists
in the binary but its call site is only reachable from claude assistant, which remains KAIROS-stripped. Memory
cc_binary_internals.md actually said this back in May 2026 (PoC G);
this Phase 0 spec was authored on the incorrect premise that
--teleport exercises bridge:repl.

What did get archived:

  • The full HTTP request sequence the binary uses to reach "Session
    resumed" against a forged backend (9 steps documented in spec §11
    and updated memory).
  • The v2 CCR transport endpoint shapes that are present in the
    binary but unreachable from any CLI mode (/bridge, SSE
    /events/stream, /worker/.../delivery).
  • Three forward options for cc-app-gateway, laid out in spec §11.

Phase 1 cc-app-gateway design is not authored as a follow-up
spec — the structural finding suggests the cheapest viable shape is
not codex-app-gateway-like at all ("reverse direction" option in
§11: extend the existing Dockerfile.claudecode + sandbox topology).
A future spec, if anyone writes one, will start there.

PoC-2 artifacts (extended mock_gateway.py, run_teleport.sh, 7
iteration journals iter-10..iter-16) live under `/tmp/cc-cloud-poc/`
and are deliberately NOT committed.

🤖 Generated with Claude Code

mryao and others added 2 commits June 8, 2026 13:42
PoC-1 (PR #229) proved the submit half of v2.1.167's --cloud thin
client can be redirected to our gateway. Two questions remain before
a real cc-app-gateway (codex-app-gateway shape, per-turn fork) can be
designed:

1. Subscribe-half wire format — the v2 CCR transport (SSE reads + POST
   writes, bootstrapped via POST /v1/code/sessions/{id}/bridge) has
   never been exercised end-to-end against our mock.
2. Backend harness choice — patched `claude --cloud` (PoC-1 binary,
   harvest frames from telemetry/stdout) vs plain `claude -p
   --output-format stream-json` (no backend patches, translate
   stream-json into v2 frames in the gateway).

This Phase 0 spec defines a 2-3 day PoC-2: extend the existing mock
to expose the v2 endpoints, drive `claude --teleport <sid>` against
it to validate the subscribe channel (gate A.1), then drive each
backend candidate into the same SSE stream (A.2, A.3) and write a
5-dimension decision matrix (A.4). All artifacts stay under
/tmp/cc-cloud-poc/; only this spec + outcome + memory updates land
in the repo. Phase 1 (the actual cc-app-gateway) is a separate spec
authored after Phase 0 concludes.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
…be-half unreachable)

PoC-2 ran 6 A.1 iterations against v2.1.167 `claude --teleport <sid>`.
With 4 new mock routes the binary completed every teleport phase
through "Session resumed" and rendered the chat TUI — but never
opened any live transport against the mock. 30s post-resume gateway
idle window; zero tengu_bridge_* / tengu_ccr_* events in telemetry.

Per spec §4 A.1 is a hard gate (no A.1 → no A.2/A.3 → no decision
matrix). Per spec §6 the binding stuck-point is structural: the
subscribe-half data path the spec was designed to exercise doesn't
exist in any v2.1.167 CLI mode. --teleport is local-resume (binary
hydrates history then hands off to the local REPL); --cloud is
fire-and-forget (PoC-1 finding). The bridge:repl renderer code is in
the binary, but its call site is reachable only from `claude
assistant`, which remains KAIROS-stripped — exactly what memory
cc_binary_internals.md recorded from PoC G back in May 2026. This
Phase 0 spec was authored on the incorrect premise that --teleport
exercises bridge:repl; it does not.

What PoC-2 did contribute: the full HTTP request sequence
--teleport actually issues to satisfy a "Session resumed" hydrate
against a mock backend (9-step list now in cc_binary_internals.md),
and the v2 CCR endpoint shapes (bridge handshake, SSE long-poll,
worker delivery ack) that are PRESENT in the binary but UNREACHABLE
from any CLI mode without 3+ further patches.

Phase 1 cc-app-gateway design implications laid out in spec §11;
codex-primary stance reinforced, no agent_integration_strategy.md
update needed.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant