wiki-vault/Sources/Dev/2026-06-04-2026-06-04-petal-dispatch-v3-phase-minus-1-deltas.md

35 lines
2.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
created: '2026-06-04'
path: Sources/Dev
project: petal-dispatch-v3
tags:
- petal-dispatch
- v3
- phase-minus-1
- oauth
- journal
- lovebug
- claude-code
- errata
type: session-notes
---
Phase 1 of the v3 build ran the OAuth viability spike on 2026-06-04 and surfaced findings that materially patch the v3 spec. v3 is immutable; this note is the consumption layer for future readers.
Full results live in trellis thread `petal-dispatch-v3-build` (id 588), checkpoint event 1084. Raw artifacts in repo `petal-power/petal-dispatch` (currently `petal-dispatch-demo`) under `phase-minus-1/`.
## Corrections to v3
**D-11 (OS exit code mapping): drop the SIGINT/130 row.** Measurement: claude under stream-json treats SIGINT-when-busy as a clean exit; rc=130 is unreachable. The orchestrator's cancel path is SIGTERM (rc=143 → `cancelled`), the crash path is SIGKILL (rc=137 → `crashed`). SIGINT plays no role in v1. The rest of the v3 mapping (0 → success, nonzero → failed, 143 → cancelled, 137 → crashed) holds; the SIGINT row was conjectural.
## Additions to internalize when reading v3
**Init event exposes `mcp_servers[*].status` (per-spawn).** D-21 plumbing: the harness can detect `needs-auth` MCPs at spawn time and route around them instead of crashing on an interactive prompt. The Phase 0 event taxonomy should treat MCP-status as a first-class signal in init events.
**`system init` fires per user_message in long-lived stream-json mode.** Not a one-time event. The orchestrator state machine and the journal's event-type reference table must accept >1 `init` event per process lifetime. Relevant to Phase 0 and any forward-compat planning for long-lived workers (v4 lifecycle).
**`rate_limit_event` is a status-only signal.** Payload reports `status` (allowed / not) with no remaining-quota gauge. Phase 2's not-clean-return policy for `rate_limited` (FR-009 / D-18 / Phase 2) must back off on `status != allowed` rather than on a quota threshold. Forecasting headroom from this signal is not possible; the orchestrator only sees the binary circuit-breaker state.
## What did NOT change
D-21 (extractor as Claude Code spawn), D-13 (two-service split), Phase 1's OAuth decision, and the harness-as-sole-substrate-touching-layer containment argument all hold under measurement. Six of seven Phase 1 tests passed cleanly; the one PARTIAL was the SIGINT row above.