Milestone 3.5.D.3 — Response Headers and Metadata

Status: Planned
Goal: Track D — Proxy Integration
Phase: 3.5 — Extraction & Context Assembly
Estimated effort: 1 day
Track: Track D — Proxy Integration
Depends on: Milestone 3.5.D.2 (handler wiring)

Why This Milestone Exists

Two integration surfaces are documented and must both be honored: plain HTTP headers (X-IBEX-Memories-Injected, X-IBEX-Context-Tokens, X-IBEX-Context-Fallback) and an embedded ibex block inside the JSON response body for non-streaming responses. The embedded block requires Phase 2.5's ResponsePipeline typed decode and is gated behind a flag since it costs a full response decode.

Orientation (indicative)

Named paths, package layouts, libraries, schemas, env vars, and commands anywhere on this page are rough sketches for orientation — inspiration and a baseline, not a required change list.

During implementation, expect to:

open the live tree and follow existing patterns before inventing new ones
research current constraints (latency, tenancy, deploy shape, libraries) more deeply than this page can
advance the design beyond the sketch where measurement or code reality says so
land work in different filenames, merged packages, deferred docs, or new surfaces when the situation calls for it

Prefer outcomes over matching any particular file tree or command sequence.

Areas that may be involved (situational — not a checklist):

Proxy service (HTTP, bootstrap, config)
Context assembly service
Workers / task runtime

Success signals

Outcome-oriented signals that the milestone is in good shape. Exact filenames, package layouts, and commands may differ from any sketches above.

Header-only surface works without response decode
Embedded ibex JSON block implemented behind IBEX_CONTEXT_EMBED_METADATA flag
IBEXMetadataStage added to the response pipeline
Repo guards / CI checks still pass

Prerequisites

Milestone 3.5.D.2 (handler wiring)
Phase 2.5 Track C (response pipeline)