Track cross-repo Gateway operator control-surface rollout

[marcusrbrown]

Summary

Track the cross-repo rollout for the Gateway operator control surface across fro-bot/agent, fro-bot/dashboard, marcusrbrown/infra, and this control-plane repo.

Project matrix: Gateway operator control-surface rollout

Current state

The GitHub Project matrix is the structured source of truth. This issue body is the human-readable rollup; comments are the audit log.

Shipped / closed:

• fro-bot/agent#907 is closed. The gateway producer spine is complete on main at operator contract v1.5.0.
• fro-bot/agent#1033 is merged and released as v0.78.0. The release is published; deployed-gateway verification is still owed.
• fro-bot/agent#929 shipped the web operator surface foundation.
• fro-bot/agent#931 shipped the operator listener topology.
• Unit 3 work landed across fro-bot/agent#932, #934, #936, #939, and #944.
• Unit 7 was cut and superseded by GET /operator/repos; raw binding records must not reach the browser.
• marcusrbrown/infra#579, #580, and #581 are closed.
• fro-bot/dashboard#24, #25, #26, #39, #47, #53, #59, and #81 are closed.
• fro-bot/dashboard#48 is closed as superseded. The dashboard already consumes canonical approval settle frames (settled:true) and must not invent deadline-specific copy unless a future gateway contract exposes a deadline reason or timestamp.

Tracker automation:

• fro-bot/.github#3514 installed the scheduled Gateway Rollout Tracker workflow.
• fro-bot/.github#3517 made tracker comments deterministic and idempotent with a Project/issue-state preflight.
• The latest settled tracker snapshot is c112ff2769bfd1abf3d7311fba5686f098a2bed5b7821a7d45c0d4c7c6be58a6.

Still open / not yet complete:

• fro-bot/.github#3512 — this tracker issue. Keep it open until deployed-gateway verification and live dashboard/operator verification are complete.
• Gateway deploy/version verification — v0.78.0 is published, but the auto-release workflow does not itself prove the deployed gateway is running that release.
• Phase-1 monitoring dashboard rollout is code-complete but still code-complete-pending-verification per docs/plans/2026-06-15-001-feat-monitoring-dashboard-phase-1-plan.md.

Cross-repo dependency matrix

Workstream	Item	State	Notes
Agent	fro-bot/agent#907	Done	Producer spine closed at contract v1.5.0.
Agent	fro-bot/agent#1033	Released	v0.78.0 published; deployed-gateway verification still owed.
Dashboard	fro-bot/dashboard#48	Done	Closed as superseded by canonical settled:true approval settle-frame behavior.
Infra	marcusrbrown/infra#579	Done	Operator listener reverse-proxy topology.
Infra	marcusrbrown/infra#580	Done	Operator auth/config secrets.
Infra	marcusrbrown/infra#581	Done	Same-origin hosting path decision.
Control plane	fro-bot/.github#3512	Open	Coordination issue stays open until deploy/live verification and security/R8 checks are done.

Remaining rollout tasks

1. Confirm the deployed gateway is running the v0.78.0 release that includes operator contract v1.5.0.
2. Complete live operator verification before marking the rollout complete:
   • dashboard.fro.bot/operator/health returns healthy.
   • /operator remains auth-gated.
   • gateway-origin operator routes deny as expected when reached from the wrong boundary.
   • launch, run listing, run stream, repo listing, and approval flows work against the deployed gateway.
   • OAuth/session/CSRF/logout behavior is verified end-to-end.
   • redaction/denylist behavior is checked against production-shaped data.
3. Complete the Phase-1 plan's operational/security tail:
   • production-shaped R8 verification: zero private repo names or node_id leaks in SSR, API, logs, or cache; fail closed on metadata failure.
   • infra security posture: App key is file-mounted, container hardening is in place, secrets are absent from logs, and the revocation runbook is documented.
   • post-merge security review for the dashboard and infra surfaces.
4. Keep the Project matrix current; use this issue for audit comments only when state actually changes.

Risks to keep visible

• Same-origin cookie boundary: do not rely on cross-site browser cookies between dashboard and Gateway origins.
• Auth/session duplication: dashboard's existing session is not Gateway operator auth.
• SSE proxy buffering: reverse proxy must support long-lived streams without buffering.
• Approval settlement: the UI must dismiss settled prompts without inventing settlement reasons the gateway does not send.
• Binding enumeration: dashboard repo selection must not expose raw binding records or private-repo identity.
• Announce ingress separation: existing /v1/announce HMAC route must remain distinct from browser operator control.

Acceptance criteria

• The Project matrix is current and reflects all shipped/closed rollout items.
• fro-bot/dashboard#48 is closed as superseded by canonical settle-frame behavior.
• Gateway contract v1.5.0 is released and verified on the deployed gateway before live rollout claims are made.
• Production operator flows are verified live, including auth, CSRF, repo/run surfaces, SSE, approvals, and privacy boundaries.
• R8/privacy verification, infra security posture, revocation runbook, and post-merge security review are complete.
• This issue links the cross-repo issues and records state transitions without performing implementation directly from the tracker.

[fro-bot]

This isn't a bug to reproduce—it's a cross-repo coordination spine. Triage here means verifying the dependency graph is wired correctly and the state claims hold. They do.

State verification

• Gateway foundation PR fro-bot/agent#929 — MERGED 2026-06-17T00:52Z, ~30 min before this issue opened. Title confirms scope: "prepare web operator surface spine." The Phase B foundation slice you describe (runtime accepts surface: 'web', stable GitHub numeric IDs + login/session correlation, approval spine ready for a future web transport, no live routes yet) matches a merged foundation, not a claim. Good.
• Tracking issue fro-bot/agent#907 — OPEN. Still the canonical agent-side home for the inbound control surface + operator web auth. Correct parent.
• Phase B plan — docs/plans/2026-06-15-002-feat-gateway-web-operator-control-surface-plan.md present (~59KB). The dependency matrix (Units 2–8) traces to a real artifact, not a sketch.

Cross-repo links — all six exist, confirmed

The "related issues to track" in the body are live. Resolving them so this issue actually links the surface instead of describing it:

Dashboard (fro-bot/dashboard):

• #24 — Plan same-origin Gateway operator control-surface integration
• #25 — Add typed Gateway operator API client contract behind mocks
• #26 — Mock operator workflow UI skeleton

Infra (marcusrbrown/infra):

• #579 — Prepare Gateway operator listener reverse-proxy topology
• #580 — Wire Gateway operator auth/config secrets into deploy
• #581 — Decide same-origin hosting path for dashboard operator UI

Dependency matrix — current gating reality

The matrix is a chain rooted at agent units. Mapping the unlock edges to the downstream issues so the critical path is visible:

Agent unit	Unlocks	Downstream blocked on it
Unit 2 — operator listener/topology	infra proxy/topology	marcusrbrown/infra#579
Unit 3 — OAuth/session/CSRF/allowlist	infra secrets + dashboard auth validation	marcusrbrown/infra#580, fro-bot/dashboard#24
Unit 4 — run snapshot/SSE	live dashboard run observation	fro-bot/dashboard#25→live
Unit 5 — web launch	live launch form	fro-bot/dashboard#26→live
Unit 6 — web approvals	live approval cards	fro-bot/dashboard#26→live
Unit 7 — binding reads	Gateway-backed repo selector	dashboard repo selector
Unit 8 — smoke/operational readiness	production rollout claim	acceptance criterion #3

Critical-path read: Unit 2 and Unit 3 are the true gate. marcusrbrown/infra#579 (topology) needs Unit 2's listener shape; marcusrbrown/infra#580 + fro-bot/dashboard#24 both need Unit 3's auth/config contract. Until those land, fro-bot/dashboard#25/fro-bot/dashboard#26 stay behind mocks—which is exactly where they're scoped right now. Nothing downstream is prematurely unblocked. The graph is honest.

Risk that needs a guardrail, not just visibility

Two of your listed risks are the ones most likely to silently rot the rollout:

• Same-origin cookie boundary + auth/session duplication. Decide same-origin hosting path for dashboard operator UI marcusrbrown/infra#581 (hosting path) and Plan same-origin Gateway operator control-surface integration dashboard#24 (auth integration) are coupled by a single decision: same-origin vs. cross-origin. If that decision drifts between the two issues, you get a cookie boundary that works in dev and fails closed in prod. Pin the decision in one place—Decide same-origin hosting path for dashboard operator UI marcusrbrown/infra#581—and have Plan same-origin Gateway operator control-surface integration dashboard#24 reference it rather than re-derive it. Don't let two issues independently decide the same trust boundary.
• SSE proxy buffering. This is an Prepare Gateway operator listener reverse-proxy topology marcusrbrown/infra#579 acceptance criterion, not a Unit 4 problem. Long-lived streams that get buffered by a reverse proxy fail in a way that looks like "the dashboard is slow," not "the proxy is wrong." Make "no buffering on the SSE path" an explicit checkbox on Prepare Gateway operator listener reverse-proxy topology marcusrbrown/infra#579 before Unit 4 ships, or you'll debug it live.
• Announce ingress separation. The existing /v1/announce HMAC route (#671 lineage) must stay a distinct trust boundary from browser operator control. This is the single most important invariant in Gateway inbound control surface + operator web auth (the web-command spine) agent#907's hard constraints: web launch must route through the same fail-closed approval gate and must not become a higher-privilege bypass. Keep that assertion attached to Unit 5/Unit 6, not buried here.

Proposed next steps

1. Label this as a tracking epic. No tracking/epic label exists in this repo yet—agent: working is the only workflow label. Recommend adding a tracking label so this and future cross-repo coordination issues are queryable. I won't create labels unprompted.
2. Make the matrix self-updating, not manual. Acceptance criterion feat: set default settings #1 says "keep the dependency matrix updated as units land." Manual matrix maintenance is where tracking issues go to die. Add the six cross-repo issues to a GitHub Project (or task-list with - [ ] items referencing each issue number) so closure state renders automatically instead of requiring a human to re-edit prose.
3. Gate Unit 3 first. It's the widest unlock (Wire Gateway operator auth/config secrets into deploy marcusrbrown/infra#580 + Plan same-origin Gateway operator control-surface integration dashboard#24 both wait on it) and it's the security-critical auth boundary Gateway inbound control surface + operator web auth (the web-command spine) agent#907 flagged as "the genuinely hard part." Sequence it ahead of Units 4–7.
4. Do not mark rollout complete until Unit 8 smoke + live dashboard/infra integration verify. This is acceptance criterion feat: sync template changes #3 and it's correct—hold the line. Foundation merged is not rollout shipped.

No implementation happens from this issue, per its own acceptance criteria. This is a map. The map currently matches the territory.

---

Run Summary

Field	Value
Event	issues
Repository	fro-bot/.github
Run ID	27659325442
Cache	miss
Session	ses_12cd45e5affeplNhOtkycKGwLo

[marcusrbrown]

@fro-bot tracker bootstrap complete.

Project:

• Gateway operator control-surface rollout

Tracked items added:

• Track cross-repo Gateway operator control-surface rollout #3512
• Gateway inbound control surface + operator web auth (the web-command spine) agent#907
• feat(gateway): prepare web operator surface spine agent#929
• Plan same-origin Gateway operator control-surface integration dashboard#24
• Add typed Gateway operator API client contract behind mocks dashboard#25
• Mock operator workflow UI skeleton dashboard#26
• Prepare Gateway operator listener reverse-proxy topology marcusrbrown/infra#579
• Wire Gateway operator auth/config secrets into deploy marcusrbrown/infra#580
• Decide same-origin hosting path for dashboard operator UI marcusrbrown/infra#581

Current automation direction:

• scheduled/manual Gateway rollout tracker workflow will call the reusable Fro Bot workflow
• daily Fro Bot prompt will check the tracker during org oversight but stays awareness-only
• tracker updates should update project item state/fields and post comments only when meaningful readiness evidence changes

[fro-bot]

Tracker spine confirmed. Project users/fro-bot/projects/1 now holds all nine items, and I just re-verified the territory the map points at:

Item	State	Role
fro-bot/agent#929	MERGED 2026-06-17T00:52Z	Phase B foundation slice (spine only)
fro-bot/agent#907	OPEN	canonical agent-side parent
fro-bot/dashboard#24 / #25 / #26	OPEN	downstream, behind mocks
marcusrbrown/infra#579 / #580 / #581	OPEN	topology + secrets + hosting decision

Nothing has moved since the foundation merged. No Phase B unit beyond the spine has landed (the only other gateway-operator PR, #915, was a closed brainstorm doc). So the current readiness state is exactly: foundation merged, zero live routes, eight downstream issues all blocked. That's the honest baseline the tracker should start from.

On the automation direction

The three rules you set are the right shape. One sharpening on each:

1. Scheduled/manual tracker → reusable workflow. Fine. But give the scheduled run a no-op exit when nothing changed. A daily tracker that posts "still blocked on Unit 2/3" every 24h is noise that trains people to ignore it. Which leads directly to —

2. "Post comments only when meaningful readiness evidence changes." This is the load-bearing rule, and "meaningful" needs a definition or it'll rot into either spam or silence. Pin it to state transitions on the gating edges, not prose drift:

• an Agent unit (2–8) merges → recompute the matrix, post
• a downstream issue closes or flips to a live (non-mock) state → post
• the same-origin hosting decision lands in infra#581 → post (this one unblocks two issues at once)
• nothing in that set changed → update project fields silently, no comment

Field updates are free; comments cost attention. Spend comments only on edge transitions.

3. Daily org-oversight prompt checks the tracker. Good, but have it read project item state, not this issue's comment history. The project is now the source of truth for closure; the comment thread is the narrative. Don't let the daily prompt re-derive status by parsing prose — that's the manual-matrix failure mode wearing a cron disguise.

The gate hasn't changed

Unit 3 (OAuth/session/CSRF/allowlist) is still the widest unlock and the security-critical boundary fro-bot/agent#907 flagged as the genuinely hard part — infra#580 and dashboard#24 both wait on it. Sequence it ahead of 4–7. And the single decision most likely to silently break prod is still the same-origin trust boundary: keep it pinned in infra#581 and let dashboard#24 reference it, not re-decide it.

Hold acceptance criterion #3 — rollout is not complete until Unit 8 smoke + live dashboard/infra integration verify. Foundation merged is not rollout shipped. The tracker's job now is to keep that distinction from blurring as units land.

Map's wired. The daemon can watch the edges from here.

---

Run Summary

Field	Value
Event	issue_comment
Repository	fro-bot/.github
Run ID	27663826532
Cache	hit
Session	ses_12c5eb63cffe1s03VrFTn0FuXS

[fro-bot]

@fro-bot tracker sweep — no drift. Edges held since the last status.

Item	State	Readiness	Gate	Δ
fro-bot/agent#929	MERGED	foundation shipped	foundation	—
fro-bot/agent#907	OPEN	tracking	Units 2–8	—
fro-bot/dashboard#24	OPEN	ready now	Unit 3	—
fro-bot/dashboard#25	OPEN	ready now	Units 4–6	—
fro-bot/dashboard#26	OPEN	ready now	Units 5–6	—
marcusrbrown/infra#579	OPEN	blocked	Unit 2	—
marcusrbrown/infra#580	OPEN	blocked	Unit 3	—
marcusrbrown/infra#581	OPEN	ready now	Unit 3	—

What I checked for, what moved: No Agent unit (2–8) merged — the only Phase B merge remains the #929 spine, already acknowledged. Activity in the three repos since last sweep is dependency bumps, CI/release tuning, and branding chores (agent#926/#928, dashboard#6/#7/#18/#19/#21/#22/#23/#27, infra#572–#578). None touch a gateway-operator route, none close a downstream issue, none land the infra#581 same-origin hosting decision.

No tracked issue closed. No live (non-mock) route shipped. The hosting decision still sits unmade in infra#581 — still the widest single unlock.

Project fields on users/fro-bot/projects/1 already match this matrix; nothing to re-write. No tracked-issue comments posted — no issue-specific transition evidence to report.

Baseline stands: foundation merged, zero live routes, eight downstream issues blocked. The daemon's still watching the edges. Nothing crossed.

---

Run Summary

Field	Value
Event	workflow_dispatch
Repository	fro-bot/.github
Run ID	27666598120
Cache	hit
Session	dispatch-27666598120

[fro-bot]

@fro-bot tracker sweep — one edge crossed. A gate transitioned since the last status.

Transition

fro-bot/dashboard#24 → CLOSED (COMPLETED) 2026-06-17T06:15:30Z, via dashboard PR #29.

This is the same-origin Gateway operator control-surface plan landing — not a live route. The merged plan (docs/plans/2026-06-17-001-feat-gateway-operator-control-surface-plan.md) pins:

• the dashboard-side same-origin /operator/* contract
• the dashboard-vs-Gateway auth boundary (dashboard session ≠ Gateway operator auth — the duplication risk, settled on paper)
• disabled/default behavior and Phase B readiness dependencies
• handoff criteria for chore(deps): update bfra-me/renovate-config action to v1.5.9 #25 and feat: add schedule trigger to Renovate workflow #26

No production Gateway calls were introduced. This closes the planning obligation, not an integration. The work it unblocks — the typed API client (#25) and mock UI skeleton (#26) — is contract/mock scoped and still gated behind Agent Units 4–6 for anything live.

What this does and does not move

The plan also documents the same-origin trust boundary that infra#581 owns the decision for. Worth being precise: dashboard#24 references and consumes that boundary from the dashboard side; it does not make the hosting decision. infra#581 stays open and stays the widest single unlock. The map says: dashboard now knows what shape it's building toward, but infra still has to choose where it lives.

Current matrix

Item	State	Readiness	Gate	Δ
fro-bot/agent#929	MERGED	foundation shipped	foundation	—
fro-bot/agent#907	OPEN	tracking	Units 2–8	—
fro-bot/dashboard#24	CLOSED	ready now → done	Unit 3	closed (plan landed)
fro-bot/dashboard#25	OPEN	ready now	Units 4–6	—
fro-bot/dashboard#26	OPEN	ready now	Units 5–6	—
marcusrbrown/infra#579	OPEN	blocked	Unit 2	—
marcusrbrown/infra#580	OPEN	blocked	Unit 3	—
marcusrbrown/infra#581	OPEN	ready now	Unit 3	—

Project users/fro-bot/projects/1 already carries #24 as Done; fields match this matrix, nothing to re-write. No Agent unit (2–8) merged — the #929 spine is still the only Phase B merge. No live route shipped.

Baseline shifts by exactly one: foundation merged, zero live routes, dashboard planning closed, seven downstream issues still open. Acceptance criterion #3 holds — a closed plan is not a shipped rollout. The daemon logged the edge and went back to watching.

---

Run Summary

Field	Value
Event	workflow_dispatch
Repository	fro-bot/.github
Run ID	27669761833
Cache	hit
Session	dispatch-27669761833

[marcusrbrown]

@fro-bot tracker sweep — Agent Unit 2 crossed.

Transition

fro-bot/agent#931 → MERGED (COMPLETED) 2026-06-17T06:20:38Z, merge commit 198905b57545902d82fe0668fc7daa3cf3d339d4.

This is the Gateway operator listener/topology slice landing. It adds the opt-in operator listener skeleton, keeps it disabled by default, binds it only to explicit gateway-net IPv4 config, rejects hostnames/all-interface/loopback/sandbox-net/IPv6 binds, keeps the announce and operator surfaces pinned separately, and exposes no privileged browser routes yet.

Readiness evidence:

• PR head 3fccb2e1b29f9d5b6226332771972481af3e8bae
• fresh Fro Bot review: APPROVED, verdict PASS
• all checks green: CI, Test GitHub Action, Gateway Image Smoke Test, Workspace Image Smoke Test, Release preview, CodeQL
• Unit 2 non-blockers were patched before merge: IPv6 binds rejected, prefix-check assumptions documented, and future route rate-limit contract documented

What this moves

Unit 2 was the gate for the infra topology work. That edge is now crossed: marcusrbrown/infra#579 is no longer blocked on agent code shape and can proceed against the listener contract from fro-bot/agent#931.

Unit 3 is now the next agent-side gate and the right next implementation target. The operator listener exists, but it has only GET /operator/health; auth/session/CSRF/allowlist are not present yet. That means anything needing real browser operator auth remains Unit-3-gated.

Current matrix

Item	State	Readiness	Gate	Δ
fro-bot/agent#929	MERGED	foundation shipped	foundation	—
fro-bot/agent#931	MERGED	listener/topology shipped	Unit 2	crossed
fro-bot/agent#907	OPEN	tracking	Units 3–8	Unit 2 complete
fro-bot/dashboard#24	CLOSED	planning done	Unit 3	—
fro-bot/dashboard#25	OPEN	mock/client work can continue; live calls wait	Units 4–6	—
fro-bot/dashboard#26	OPEN	mock UI can continue; live launch/approval waits	Units 5–6	—
marcusrbrown/infra#579	OPEN	ready now	Unit 2	unblocked by fro-bot/agent#931
marcusrbrown/infra#580	OPEN	blocked	Unit 3	—
marcusrbrown/infra#581	OPEN	ready now	Unit 3 / hosting decision	—

Unit 3 readiness

Agent is ready to start Unit 3: OAuth/session/CSRF/allowlist/audit seam.

The plan dependency is satisfied because fro-bot/agent#931 delivered:

• separate operator listener lifecycle
• fail-closed operator config and deploy validation
• no-oracle response helpers
• pre-auth body/rate-limit/forwarded-header guards
• ingress-pin coverage keeping announce and operator trust boundaries distinct
• explicit rate-limit contract for future authenticated routes

Unit 3 should keep the same trust-boundary posture: GitHub human auth only, opaque server-side sessions, __Host- cookie invariants, origin + CSRF checks before mutating JSON routes, file-backed operator allowlist, stable GitHub numeric IDs for audit, and no bearer/API callers in v1.

Dependent-project status

• infra#579 should now be treated as ready to proceed with reverse-proxy topology against the feat(gateway): add operator listener topology agent#931 listener contract. It still must preserve no-buffering for future SSE and must not route /v1/announce through the browser operator trust boundary.
• infra#580 remains blocked until Unit 3 defines and lands the auth/config secret contract.
• infra#581 remains ready and should stay the source of truth for same-origin hosting; dashboard#24 has already consumed that boundary on paper but does not replace the infra decision.
• dashboard#25/feat: add schedule trigger to Renovate workflow #26 can continue mock/contract UI work, but live Gateway calls stay blocked until Units 4–6 expose run observation, launch, and approvals.

Baseline is now: foundation merged, Unit 2 listener/topology merged, zero privileged live routes, dashboard planning closed, infra topology unblocked, Unit 3 is the next agent gate.