Break the multi-upstream implementation into milestones, building on the three ratified design RFCs (#49 config shape + routing, #50 policy/audit/annotation partitioning, #51 migration plan):
- M1 — partitioning substrate (dark, zero behavior change): singular-
upstream normalization layer, upstream label plumbing, audit upstream column (additive-only auto-migration), upstream-qualified limit buckets, evidence session-key qualification + sideband/SDK upstream parameter (security fix).
- M2 — config + router (feature light-up):
upstreams map schema and match.upstreams matcher + validation, mount table and per-mount forwarder/governed stacks, routing-error contract, degraded-mount recovery, two-upstream end-to-end isolation test.
- M3 — UX / docs / release: dashboard upstream filters, health strip, per-upstream limit gauges and approval labels; configuration reference and upgrade example; removal of the "exactly one upstream" notes; ships as v0.4.0.
Acceptance criteria:
- Milestones and sequencing are documented.
- Dependencies/risks are called out per milestone.
- Implementation tickets are derived from the milestone plan, not ad hoc.
(The M1/M2/M3 split is the original draft's; whether that's actually the right cut is exactly what drafting RFC 4.4 will determine — the issue just needs to capture the intent, and the plan document can refine it.)
Break the multi-upstream implementation into milestones, building on the three ratified design RFCs (#49 config shape + routing, #50 policy/audit/annotation partitioning, #51 migration plan):
upstreamnormalization layer, upstream label plumbing, auditupstreamcolumn (additive-only auto-migration), upstream-qualified limit buckets, evidence session-key qualification + sideband/SDKupstreamparameter (security fix).upstreamsmap schema andmatch.upstreamsmatcher + validation, mount table and per-mount forwarder/governed stacks, routing-error contract, degraded-mount recovery, two-upstream end-to-end isolation test.Acceptance criteria:
(The M1/M2/M3 split is the original draft's; whether that's actually the right cut is exactly what drafting RFC 4.4 will determine — the issue just needs to capture the intent, and the plan document can refine it.)