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. Agent releases have since advanced to v0.85.0. The deployed gateway is pinned to v0.83.0 and runs operator contract v1.6.0 live (dashboard.fro.bot/operator/health returns {"ok":true,"contractVersion":"1.6.0"}). The v1.5.0 → v1.6.0 cutover is complete: main, the latest release (v0.85.0), and the deployed gateway (v0.83.0) all carry contract v1.6.0.
• fro-bot/agent#1111 is merged. Operator-initiated run cancellation is code-complete on main: POST /operator/runs/:runId/cancel cancels a queued or executing run, auto-rejects any pending tool approval through the single settlement gate, posts a cancellation notice to the run's origin Discord thread, and reconciles a per-repo lock stranded by a crash mid-cancel on startup recovery. This closes the one functional gap in the operator surface (previously launch/list/stream/approve but no stop). It bumped the operator contract to v1.6.0 (additive route + response type, MINOR), and is now released in v0.83.0 (2026-07-04) and deployed — the running gateway carries the cancellation route and contract v1.6.0.
• fro-bot/agent#1109 is merged. Fixes a latent bug where run-state thread_id was written empty at admission and never persisted, which broke discord approval-scope resolution (scopeIdFor) and startup recovery thread-notes. Repaired at the root by persisting the live thread_id at run adoption; web/GitHub surfaces (scoped on run_id) were unaffected.
• fro-bot/agent operator push notifications shipped across six PRs (#1152, #1157, #1160, #1162, #1163, #1165) and released in v0.85.0 (2026-07-11). The gateway is now the authoritative owner of operator push subscriptions, VAPID dispatch, and the notification lifecycle (pending approvals, failed runs, logout deactivation), with a durable subscription store, a connect-time SSRF guard on the relay path, and coarse lifecycle audit events. Push is disabled-by-default (active only when VAPID config is present) and adds only /operator/push/* REST routes — it deliberately does not bump OPERATOR_CONTRACT_VERSION, since additive REST is invisible to the dashboard's SSE ready-frame drift gate, so v0.85.0 carries contract v1.6.0 unchanged. Not yet deployed (the deployed pin is v0.83.0); production enablement additionally requires VAPID secret provisioning.
• fro-bot/dashboard#108 is closed (COMPLETED). It scoped the browser half of operator push (consent UI, PushManager handoff, service-worker notification rendering/click handling); the gateway server half is the v0.85.0 push feature above. Any remaining browser-side push consumption is dashboard-repo work.
• 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.
• fro-bot/dashboard#122 is merged. The PWA is now operator-first: / renders the operator shell, the user-facing monitoring UI is suspended from the active frontend, and /api/monitoring survives behind operator auth as a server-side snapshot endpoint.

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 live dashboard/operator verification (browser-session flows) and the push deploy/enablement tail are complete. The gateway-side deployed-version and contract-match gates are now satisfied.
• Gateway live capability verification — the deployed gateway (v0.83.0) now runs contract v1.6.0 and carries run cancellation (#1111) and the thread_id persistence fix (#1109), both released in v0.83.0 and live. What remains is end-to-end verification of the live operator capability flows (launch, run listing, run stream, repo listing, approvals, run cancellation) and OAuth/session/CSRF/logout behavior against the deployed gateway — this is browser-session operator verification (dashboard-repo work), not gateway-side.
• Operator push deploy + enablement (v0.85.0) — the push feature is released in v0.85.0 but not yet deployed (the deployed pin is v0.83.0). Production enablement additionally requires VAPID secret provisioning (marcusrbrown/infra) and the dashboard browser half (consent UI, PushManager, service worker). Push is disabled-by-default, so deploying v0.85.0 without VAPID config is inert on the push surface.
• Dashboard consumption of the v1.6.0 contract — the dashboard already pins OPERATOR_CONTRACT_VERSION at v1.6.0 (the cutover landed with the deployed gateway; the exact-match drift gate is satisfied on both sides). The remaining dashboard-side UI work — the Cancel button consuming POST /operator/runs/:runId/cancel and per-kind failureKind failure copy — is tracked at fro-bot/dashboard#179.
• Phase-1 monitoring tail — the user-facing monitoring UI is intentionally suspended by fro-bot/dashboard#122, not relocated or fallback. The remaining verification is to ratify that suspension as a deliberate decision and to verify R8 against the surviving /api/monitoring server-side endpoint and the monitoring-v1 cache-purge path, 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; releases since advanced to v0.85.0; deployed gateway pinned at v0.83.0, running contract v1.6.0 live.
Agent	fro-bot/agent#1111	Deployed	Operator run cancellation; bumped operator contract v1.5.0 → v1.6.0; released in v0.83.0 and live.
Agent	fro-bot/agent#1109	Deployed	Persists run-state thread_id at adoption; repairs discord approval-scope resolution + recovery thread-notes; released in v0.83.0.
Agent	Operator push (#1152/#1157/#1160/#1162/#1163/#1165)	Released	Gateway-owned push subscriptions, VAPID dispatch, connect-time SSRF guard, lifecycle audit; released in v0.85.0 (contract unchanged at v1.6.0). Not yet deployed; needs VAPID secrets + dashboard browser half for enablement.
Dashboard	Cancel UI (fro-bot/dashboard#179)	Open	Cancel button consuming POST /operator/runs/:runId/cancel + per-kind failureKind copy. The v1.6.0 pin cutover is already complete (dashboard and deployed gateway both at v1.6.0).
Dashboard	Push browser half (fro-bot/dashboard#108)	Done	Closed COMPLETED; scoped consent UI / PushManager / service-worker rendering. Gateway server half shipped in v0.85.0.
Dashboard	fro-bot/dashboard#48	Done	Closed as superseded by canonical settled:true approval settle-frame behavior.
Dashboard	fro-bot/dashboard#122	Done	PWA operator-first; monitoring UI suspended, /api/monitoring endpoint survives behind operator auth.
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 a release that includes the current operator contract. Done (re-verified 2026-07-11 at v0.83.0 / contract v1.6.0). The contractVersion health-body field (shipped since #1096) now makes this a one-line probe:
   • dashboard.fro.bot/operator/health returns {"ok":true,"contractVersion":"1.6.0"} — the running gateway reports contract v1.6.0 directly.
   • marcusrbrown/infra pins the gateway to fro-bot/agent v0.83.0 (apps/gateway/upstream.json, pin bump 7b9bffd7b, 2026-07-04); version.ts at tag v0.83.0 declares OPERATOR_CONTRACT_VERSION = '1.6.0' and the tag carries the #1111 cancellation route and #1109 thread_id fix.
   • The deploy asserts the running droplet image digest equals the CI-built digest and fails closed on mismatch.
   • Not yet advanced to v0.85.0 (operator push); that deploy is gated on VAPID secret provisioning and is inert on the push surface without it.
2. Complete live operator verification before marking the rollout complete:
   • dashboard.fro.bot/operator/health returns healthy.
   • / and /operator remain auth-gated.
   • gateway-origin operator routes deny as expected when reached from the wrong boundary.
   • launch, run listing, run stream, repo listing, approval, and run cancellation 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. Phase-1 plan's operational/security tail:
   • ratify the monitoring-UI suspension from fro-bot/dashboard#122 as a deliberate decision, not a missing or fallback surface.
   • R8 verification against the surviving /api/monitoring endpoint and the monitoring-v1 cache-purge path: zero private repo names or node_id leaks in SSR, API, logs, or cache; fail closed on metadata failure. Verified in code (2026-06-28). All four leak surfaces pass with pinned tests: SSR renders no repo identity pre-auth; /api/monitoring is auth-gated with a strict DTO whitelist (internal identity fields never emitted) and Cache-Control: no-store; every aggregator logger call routes through safeRepoLogIdentity/safeRepoErrorContext; /api/* is service-worker NetworkOnly (never cached) and monitoring-v1 is purged on logout; metadata failure fails closed (no fresh query, no partial identity). One low-severity nit filed: /api/status lacks no-store (fro-bot/dashboard#125). The residual node_id-format gap is tracked at fro-bot/.github#3525. Production-shaped runtime confirmation against a live snapshot with both public and denylisted repos is still owed.
   • infra security posture: App key is file-mounted, container hardening is in place, secrets are absent from logs. Verified in code (2026-06-28). App private key is file-mounted (container receives a path via *_FILE, never key material in env; O_NOFOLLOW read); secrets are delivered via SSH stdin (never argv) with redaction on failure; the deploy asserts the running image digest fails closed on mismatch. Two gaps filed: gateway container hardening (fro-bot/agent#1053, closed 2026-06-28 — cap_drop: ALL + no-new-privileges shipped on main; read-only rootfs + non-root user deferred pending a tmpfs-mount audit), and there is no dedicated GitHub App key revocation runbook (marcusrbrown/infra#711).
   • 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.
• Operator contract drift (exact-match, fail-closed): the dashboard's drift gate breaks every operator run stream at the ready frame on any OPERATOR_CONTRACT_VERSION skew. The v1.5.0 → v1.6.0 cutover is complete and matched on both sides, so this is currently satisfied. It stays a live risk for any FUTURE contract bump — a gateway release/deploy carrying a new contract version and the dashboard's pin bump must land in the same deploy window. v0.85.0 (push) is deliberately contract-neutral (v1.6.0 unchanged), so deploying it carries no drift risk.
• Suspended-surface drift: with the monitoring UI gone, the surviving /api/monitoring endpoint and its cache-purge path must stay watched so a removed thing does not become an unwatched thing.

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.
• The deployed gateway's operator contract version is verified and matched by the dashboard pin before live rollout claims are made. Satisfied: the deployed gateway (v0.83.0) runs contract v1.6.0 live and the dashboard pin is at v1.6.0 — the exact-match drift gate holds on both sides.
• 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.