Skip to content

llm plane: the OpenAI Responses webhook receiver, ported before the busbar-llm delete (F26/D4, option A) - #966

Draft
MattJackson wants to merge 1 commit into
predevfrom
lane-llm-responses-webhook
Draft

MattJackson wants to merge 1 commit into
predevfrom
lane-llm-responses-webhook

Conversation

@MattJackson

Copy link
Copy Markdown
Collaborator

PARITY-SCOPE item 3. The OpenAI Responses webhook receiver lived only in legacy busbar-llm (webhook-receiver feature, Cargo.toml:56, openai_responses_webhook.rs), so row 155's C delete would have dropped it with no port. Row 155 (af5c074a15290b0f8) has confirmed this lane owns the port and that C waits for it. Spec: F26 + correction (BUSBAR-1.6.0.md l.4642-4643), D4 (l.4664), E table (l.5496); ARCHITECT 2026-10-14, option A.

Design (as ruled)

  • On/off is the plugin's own setting. The llm plane's Statement now owns a top-level webhooks: section, stated with flags 0 (neither declaring nor consumed). webhooks: { openai_responses: true } switches the receiver on, and it is read at open from PlaneOpenIn::owned. The section uses deny_unknown_fields, so a misspelt receiver is refused at boot naming webhooks. There is no kernel or core switch.
  • The kernel learns the key only from the plane's row. config/prepass.rs Dest::for_declared now carries any section a registered plane owns beside its own, other than the endpoint door, RAW to plane_raw, and from there door_sections hands it to the plane's owned. No webhooks literal appears in kernel or root source. The kernel is net -1 line, and only MCP's mcp endpoint door was an owned section before, which is unchanged. Top-level unknown-key refusals keep 1.5.5's list: lifted keys are not serde fields, as with tools/agents.
  • Off by default, so 1.5.5 bytes. Without the key, the plane's claims are exactly today's (the path falls to the fallback claim, as 1.5.5's router answered it). With it, there is one exact POST /v1/llm/webhooks/openai claim wearing the Responses dialect.
  • Verification is the auth kind's (D4). The operator's auth.chain names a busbar-auth-webhook-signature standard-webhooks instance (pinned and linked by busbar-auth-webhook-signature pinned and linked, default-on (Twilio / Standard Webhooks inbound verify) #948). All-PASS is 401, a forged signature is REJECT, and a replayed webhook-id is refused through the claim record. The plane never sees the secret, and its unit requires a principal.
  • The unit is ROUTE_LOCAL. There is no walk and no far end, and the fee unit is never incurred (fee_unit excludes local units), so it bills nothing. On the caller's last piece the plane answers 200 application/json {"received":true,"response_id":…,"type":…}, the ported receiver's acknowledgement. A body that is not a Responses event is Decline::WebhookBody, a 400 invalid_request in the Responses envelope.

REDs (before the port there was no receiver, so none of these builds)

  • busbar-plane-llm/tests/exchange_webhook.rs: off by default with no extra claim; switched on gives one exact POST claim in the Responses dialect; a misspelt or mistyped section is refused naming it; the Statement owns webhooks with flags 0; only a POST on the exact path is a delivery; read and ack bytes; ten malformed bodies are refused.
  • busbar-kernel config::tests::a_section_a_plane_owns_beside_its_own_is_lifted_raw_for_it: before the fix the document was refused at the key as an unknown field.

Register. This is new 1.6.0 surface with no 1.5.5 golden (F26 correction). It carries a CHANGELOG line under 1.6.0 Added. No oracle cell exercises the path. A cell for it belongs to the oracle-new-cells lane, and it records only after #911.

DRAFT. It waits for:

…lm, switched on by the plane's own webhooks: section, verified by the auth kind, answered ROUTE_LOCAL (ARCHITECT 2026-10-14 option A)
@MattJackson

Copy link
Copy Markdown
Collaborator Author

Row 155 $ #991 edits busbar-plane-llm src/plane_door.rs (one compile-time drift assertion beside the billable class list) and src/meta.rs (MeterClassDecl derived from the door's TOKEN_CLASSES). The hunks are disjoint from this PR's, and the merge with predev is clean.

This branch has not been deployed

No deployments
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