wishcraft_openai: Codex ChatGPT planning conduit — status log and TODOs

[AtlantisPleb]

wishcraft_openai: Codex ChatGPT planning conduit — status log and TODOs

This issue tracks the work to wire the Wishcraft planning conduit to Codex’s ChatGPT backend and what remains to get it production‑ready.

What’s done

• Exact Codex endpoint + headers
  • Requests go to https://chatgpt.com/backend-api/codex/responses (Responses API) using ChatGPT tokens from ~/.codex/auth.json.
  • Sends headers Codex uses: Authorization: Bearer <access_token>, chatgpt-account-id, OpenAI-Beta: responses=experimental, originator, conversation_id, session_id, Codex-Task-Type: standard, Accept: text/event-stream, Referer: https://chatgpt.com/.
  • Token refresh support via https://auth.openai.com/oauth/token (writes back to ~/.codex/auth.json).
• Payload parity (Responses wire)
  • Mirrors codex-rs ResponsesApiRequest: fields include model, instructions, input (ResponseItem array with type: message, content: [{type: input_text, text: ...}]), tool_choice: auto, parallel_tool_calls: false, store: false, stream: true, include: [].
  • Embeds Codex base instructions verbatim by including vendored prompt files:
    • core/prompt.md (default)
    • core/gpt_5_codex_prompt.md (when model starts with gpt-5-codex or codex-).
• SSE parsing (streaming)
  • Aggregates response.delta and response.output_item.done into a single output_text and extracts model + usage from response.completed.
  • Returns a simple JSON that our conduit maps to plan_steps by line‑splitting.
• Chat fallback
  • If the Responses call is rejected for shape reasons, falls back to /codex/chat/completions with messages and a minimal tools array. (Not normally needed now that Responses payload is correct.)
• CLI integration
  • cargo run -p xtask -- wish codex plan --file data/wishes/wishcraft-docs.yaml --live --out /tmp/wish-docs.plan.json
  • Uses ~/.codex/auth.json; no API key required.
• Registry + docs
  • Conduit id: openai.codex.v2025.plan in data/conduits/registry.yaml.
  • Docs overview added: docs/wish.md.
• Warnings fixed
  • Removed the stray mut from SSE parser.

Where the code lives

• Client/headers/SSE: crates/wishcraft_openai/src/client.rs
• Conduit/planning prompt + payload: crates/wishcraft_openai/src/conduit.rs
• Config defaults (base URL, model, CODEX_HOME): crates/wishcraft_openai/src/config.rs
• CLI wiring: xtask/src/main.rs
• Vendored Codex sources (reference only): third_party/openai-codex/codex-rs/

Verified behavior

• Auth: loads access_token + chatgpt-account-id from ~/.codex/auth.json.
• Endpoint: posts to https://chatgpt.com/backend-api/codex/responses.
• Result: produces a non‑empty planning artifact at /tmp/wish-docs.plan.json with plan_steps, model, and tokens_used.

TODO (production‑readiness)

• SSE unit tests: feed canned response.delta, response.output_item.done, and response.completed frames; assert output_text, model, usage are assembled correctly.
• Error hygiene: surface cf-ray and structured JSON error bodies consistently; add Retry-After handling to Responses path (it exists in client; expand coverage).
• Reasoning/text controls: optionally include text.verbosity and/or output schema for specific model families (codex‑rs does this for gpt‑5).
• Tooling parity: if the planner needs a specific function tool shape later, generate tool JSON via a helper rather than hand‑writing (kept empty for now since planning returns text).
• Config ergonomics: allow a small TOML under ~/.codex/config.toml or data/config/wishcraft.toml to override model and tuning safely.
• Apply conduit (separate): safe local apply (write file/patch) and later a high‑risk PR opener with strict gates.
• Telemetry: add tracing spans (wish_id, request_id/cf-ray, token usage) and rate‑limit snapshots to logs.
• Docs: add a short developer note under docs/gdd/11-technical/ for Codex conduit specifics and troubleshooting.

Repro commands

# Lint wish file
cargo xtask wish lint data/wishes/wishcraft-docs.yaml

# Live plan (uses ~/.codex/auth.json)
cargo run -p xtask -- wish codex plan --file data/wishes/wishcraft-docs.yaml --live --out /tmp/wish-docs.plan.json
cat /tmp/wish-docs.plan.json

Notes

• We vendor codex-rs for reference only; no workspace linkage.
• Default model is gpt-5 (env override OPENAI_MODEL).
• Base URL defaults to https://chatgpt.com/backend-api/codex (env override CHATGPT_BASE_URL).

[AtlantisPleb]

Status update:

• Planning conduit: live and streaming via ChatGPT Codex Responses. Endpoint, headers, and payload now mirror codex-rs. SSE aggregator returns output_text + model + usage; verified with your auth.
• Warning fixed: removed unused mut in SSE parser; CI clean.
• Hands-off loop: added xtask wish run orchestration (no clarifying questions). It:
  • Branches wish/<wish_id>, writes audit schema, plans via Codex (ShadowRun)
  • Generates unified diff patches via Responses, applies/commits, builds/tests, and auto-fixes until green
  • Enforces budgets (time/iters), stall, breaker; requires 2× consecutive greens; writes ledger + events
  • Tracks WISHES.md; marks completed on success
• Docs: added docs/wish.md overview.

How to run

• cargo run -p xtask -- wish codex plan --file data/wishes/wishcraft-docs.yaml --live --out /tmp/wish-docs.plan.json
• cargo run -p xtask -- wish run --wish "<wish>" --timeout-mins 180 --max-iters 50

Next steps (TODOs)

• SSE unit tests for aggregator
• Patch scope enforcement (reject hunks outside allowed paths)
• Better error surfacing (cf-ray, Retry-After)
• Optional reasoning/text controls for gpt-5
• Apply conduit (safe local write; later PR opener), telemetry docs

If you want, I can prioritize SSE tests + scope enforcement next.

[AtlantisPleb]

Sweeper + WISHES.md integration (phase 1) landed.

• WISHES.md is now canonical: parser reads Pending/Completed lines, supports HTML comment wish: metadata (id, scope[], accept).
• Runner (xtask wish run) updates WISHES.md on success (checks the item) and writes ledger/events.
• Patch scope enforcement: minimal glob gate on unified diff paths; rejects hunks outside scope.
• Acceptance override: if accept="..." is present, runner uses it instead of cargo test for success checks (still requires 2× passes).
• Seeded two initial wishes in WISHES.md: SRD conversion and Wishcraft Lab recursive improvement.

Next (as spec’d):

• Add xtask wish sweep|status|tail commands to pick first pending, show state, and stream events.
• Add docs-only apply policy for SRD wish (hard reject non-docs changes) and optional xtask docs srd import helper.
• Implement event bridge + Wishcraft Lab UI (scene, HUD panels, Petition Board, Ledger viewer).
• SSE unit tests + better error surfacing (cf-ray, Retry-After).

You can run now:

• Plan only: cargo run -p xtask -- wish codex plan --file data/wishes/wishcraft-docs.yaml --live --out /tmp/plan.json
• Orchestrate: cargo run -p xtask -- wish run --wish "<pending wish string>"

I’ll tackle wish sweep/status/tail and the SRD docs-only apply gate next unless you prefer I start on the Wishcraft Lab bridge/scene first.

[AtlantisPleb]

Bridge + Lab skeleton landed.

Phase 1 — Bridge

• Added xtask wish bridge --addr 127.0.0.1:7069
  • GET /last → { wish_id } (based on most recent events file)
  • GET /wishes → { pending: [...], completed: [...] } (parsed from WISHES.md)
  • GET /events/:id → SSE stream that tails ~/.roa/wish_runner/.events.jsonl
  • GET /ledger/:id → returns .wish-ledger/.json

Phase 2 — Zone skeleton

• Added data/zones/wishcraft_lab/manifest.json (schema-compliant) and scene.json
• Zone validator passes in CI; scene is a flat plane w/ placeholder obelisk

Phase 3 — HUD scaffold

• crates/ux_hud/src/wish_ui.rs with WishUiState + apply_event (Dock/Motes/Terminal fields)
• Rendering + input wiring TBD (next increment).

How to try the bridge now

1. Start bridge: cargo run -p xtask -- wish bridge --addr 127.0.0.1:7069
2. Kick off a wish: cargo run -p xtask -- wish run --wish "Convert the SRD PDF fully to Markdown..."
3. Stream events: curl -N http://127.0.0.1:7069/events/<wish_id>
4. Inspect last: curl http://127.0.0.1:7069/last

Next (as outlined):

• Wire HUD panel render + toggle, and add the SSE client thread (channel→state.apply_event).
• Petition Board panel: GET/POST /wishes; Ledger viewer via GET /ledger/:id.
• Optional: xtask wish sweep, status, tail.
• SRD docs-only apply gate + importer cmd.

If you want, I’ll proceed wiring the HUD into the client next (default toggle key per policy) and add the small SSE client adapter.

[AtlantisPleb]

Status update on Codex runner integration

• Added detailed request logging for patch generation:
  • Per-step preview in xtask: [wish-run] step=N preview="..." (first 120 chars)
  • Client logs: [wishcraft_openai] model=<slug> instr_len=<bytes> user_len=<bytes> prompt_hash=<sha256>
• Aligned system instructions for codegen with Codex CLI:
  • instructions now use vendored Codex base prompts (core/prompt.md or core/gpt_5_codex_prompt.md), and our directives moved into the user message.
• Fixed bridge routes to axum 0.8 style {id} and stabilized SSE tailing.
• Improved robustness:
  • Skip empty/invalid diffs (log patch.skipped), don’t crash on git apply with no hunks.
  • Accept header honors stream flag: JSON for non-stream; SSE for stream.

Open issue reproduced & mitigations

• Previously saw network: error decoding response body on codegen calls — likely due to SSE + decompression + body read semantics. Switched to raw bytes read and split JSON vs SSE parse paths. If needed, can fallback to Chat wire (/codex/chat/completions) for codegen-specific calls.
• Also saw Instructions are not valid: addressed by using Codex’s base instructions as required.

Current behavior

• Planning conduit runs; patch-gen shows previews and request stats. With short budgets (--timeout-mins 1 --max-iters 1) we hit budget exceeded after trying 3 plan steps and skipping invalid diffs.

Next steps

• Add re-plan-with-context when all steps produce invalid/empty diffs (feed a concise progress/error summary back to Codex and retry).
• Optionally switch codegen to Chat wire for this SRD wish to increase text→diff reliability; keep Responses wire for planning.
• Wire HUD to bridge for in-scene monitoring; add Petition Board read/write.

Repro commands

# Start bridge
cargo run -p xtask -- wish bridge --addr 127.0.0.1:7069

# Run SRD wish (allow dirty if you have local changes)
cargo run -p xtask -- wish run --wish "Convert the SRD PDF fully to Markdown…" --allow-dirty

# Observe
curl -N http://127.0.0.1:7069/events/<wish_id>

[AtlantisPleb]

Update: Codex core loop vs our orchestration

What we’re using today

• Codex code (vendored under third_party/openai-codex/codex-rs/) is used as a reference source of truth for:
  • Base system instructions (core/prompt.md, core/gpt_5_codex_prompt.md) — we now feed these verbatim via the Responses instructions field, and put our constraints in the user message.
  • Provider shape and headers (mirroring core/src/model_provider_info.rs + default_client behavior): /backend-api/codex/responses, auth via ~/.codex/auth.json, chatgpt-account-id, OpenAI-Beta, conversation_id/session_id, originator.
• Our glue built around that (current state):
  • Planning: thin client → ChatGPT Codex Responses API; logs model/instr_len/user_len/prompt_hash.
  • Patch-gen: same thin client using Codex base instructions; output expected to be unified diff.
  • Apply: currently via git apply --index (we added scope gating + invalid/empty diff skip + detailed logging).
  • Orchestration: xtask wish run (WISHES.md queue + events/ledger + budgets), and xtask wish bridge for in‑scene streaming.

What we will switch to (your intent)

• Use Codex’s own core loop for planning/patching/apply, and keep our side focused on orchestration only:
  • Let Codex handle: tool lifecycle (esp. apply_patch), plan ↔ tool ↔ review steps, diff generation/apply/retry,
    and streaming/aggregation. We do not re‑implement patch parsing or apply semantics.
  • Keep our responsibilities: WISHES.md backlog; budgets/stop conditions; events/ledger; SSE bridge; in‑scene HUD; acceptance gates (2× green or custom accept=).

Concrete plan to adopt Codex loop

• Mode A — Subprocess orchestration (least invasive):

  1. Add xtask wish codex-run that spawns the codex exec binary with ChatGPT auth (~/.codex/auth.json), working dir = repo root, and model from our config.
  2. Pass the initial instructions (Codex prompt) + our wish text and scope constraints via a small profile/CLI flags.
  3. Stream Codex’s event output (SSE/log lines) into our ledger + ~/.roa/wish_runner/<id>.events.jsonl and forward via /events/:id.
  4. Remove our custom patch apply path when --engine=codex is selected.
  5. Keep xtask wish run as an orchestrator that invokes codex-run under the hood instead of calling the Responses API directly.

• Mode B — In‑process (optional later):

  • Add a small adapter crate that links to selected codex-rs crates (core, exec, apply-patch) as path deps. This requires relaxing our third_party guard or vendoring specific subcrates into a tools/ workspace. Benefit: richer telemetry and programmatic control. Cost: repo policy change.

What we’ll reuse from Codex

• codex_apply_patch tool (tool spec + in‑process application flow, not plain git apply).
• The Responses/Chat aggregation and event handling in core/src/client.rs.
• The default client headers/tuning (originator, user‑agent) and provider URL logic.
• Tool sets and the apply_patch instructions block for models that require it.

What we keep on our side

• WISHES.md backlog + id/scope parsing and enforcement (we’ll still enforce scope globs before we allow Codex to apply).
• Budgets and stop conditions (2× consecutive greens, stall/budget checks, acceptance via accept=).
• Ledger/events/SSE bridge; Wishcraft Lab HUD reading the same stream.

Short-term changes I’ll make next

• Add xtask wish codex-run [--wish-id ...] that:
  • Spawns the Codex exec from our vendored tree (build-if-needed) or an installed binary, in repo root.
  • Pipes events → our ledger and event JSONL.
  • Uses our accept gate and WISHES.md scope as a guard (we’ll still reject patches outside the declared scope if Codex attempts them).
• Update xtask wish run to default to --engine=codex so we’re orchestrating Codex’s loop, not re‑implementing it.
• Remove (or gate) the current Responses-based patch‑gen/apply when engine=codex is used.

Outcome

• You get the Codex behavior you expect (its tool loops and patch handling), while we still own orchestration, queueing, and visualization. No more hand‑rolled patch apply or fragile diff parsing on our side.

If you prefer in‑process integration (Mode B), say the word and I’ll put together a minimal wishcraft_codex_adapter crate with the needed symbols and a well-bounded exception to the third_party workspace guard.

[AtlantisPleb]

Pivot complete: Orchestrate Codex CLI, don’t re‑implement it

Short version: we now spawn the vendored Codex CLI and stream its JSONL events into our existing pipeline (WISHES.md backlog, budgets, ledger/SSE, Wishcraft Lab HUD). Codex owns planning, tool orchestration, and apply_patch. Our value stays in orchestration, scope gating, acceptance, and UI.

What we keep (ours)

• WISHES.md backlog + id/scope parsing and acceptance gates (2× green or accept=)
• Budgets/stop conditions (time/iters)
• Wish Ledger + JSONL events + SSE bridge (and the Wishcraft Lab HUD)
• Scope enforcement (glob allow‑list from WISHES.md)

What we replace (stop reinventing)

• Direct Responses/Chat calls for plan/patch generation
• Hand‑rolled patch apply and diff parsing
• Prompt assembly rules that try to emulate Codex

What we use from Codex (as‑is)

• Core loop (plan → tool calls → apply_patch → retry)
• Responses payload shaping and tool orchestration
• apply_patch semantics and error handling

Implementation status (on main)

• xtask adds Codex helpers:
  • wish codex-build — builds vendored Codex CLI (third_party/openai-codex/codex-rs, bin: codex)
  • wish codex-run --wish "…" [--id …] [--scope '["docs/**"]'] [--model …] [--timeout-mins N] — runs Codex Exec in JSONL mode and streams/records events
  • wish run --wish "…" defaults to engine=codex (legacy path still available via --engine legacy)
• Event translation: Codex Exec ThreadEvents → our Wisp events
  • TodoList → plan.started/plan.updated/plan.completed
  • FileChange (patch apply) → patch.applied/patch.failed
  • TurnCompleted/TurnFailed → wish.success/wish.failed
  • Writes to ~/.roa/wish_runner/<id>.events.jsonl for the bridge/HUD
• Scope enforcement (Guard B):
  • Record base SHA; after Codex exits, git diff --name-only base..HEAD vs glob allow‑list
  • On violation: git reset --hard base and emit scope.audit.error
• Acceptance & ledger:
  • Run cargo build + tests (or accept= command) after Codex
  • On pass: flip checkbox in WISHES.md, write .wish-ledger/<id>.json
• SSE bridge fixes:
  • Axum 0.8 path params (/events/{id}, /ledger/{id}); streaming unchanged

Why earlier failures stop happening

• “Instructions are not valid” / decode errors: we no longer call Responses directly in the default path. Codex CLI handles prompts/tools and outputs machine events we consume.
• “No valid patches in input”: Codex owns apply_patch; our path doesn’t try to parse/apply diffs.

How to run it

1. Build Codex once

cargo run -p xtask -- wish codex-build

2. Start the bridge (for HUD/SSE)

cargo run -p xtask -- wish bridge --addr 127.0.0.1:7069

3. Run a wish (Codex engine by default)

cargo run -p xtask -- wish run --wish "Convert the SRD PDF fully to Markdown …" --allow-dirty

4. Tail events

curl http://127.0.0.1:7069/last
curl -N http://127.0.0.1:7069/events/<wish_id>

File references

• Routes: xtask/src/main.rs:426, 861
• Codex build/run: xtask/src/main.rs:981, 1003, 1023, 1043, 1325, 1350
• Event translation: xtask/src/main.rs:1251
• Scope audit: xtask/src/main.rs:1112

Next steps (optional)

• Pre‑apply Guard A by wrapping apply_patch tool through Codex’ tool registry (strict scoping before touching index)
• Translator unit tests (Codex JSONL → Wisp events)
• POST /wishes on the bridge to enqueue from HUD
• Wire HUD toggle (documented key, not F‑keys) and SSE client in client_core

Net: default wish runs now orchestrate Codex “as is”, while our runtime enforces scope, runs acceptance, emits ledger/SSE, and powers the Wishcraft Lab UI.