ops-console is the post-login workbench where the Tier 0 family's internal operations run. Agents execute orders, refunds, content and listings upstream; the console is where a human sees the holds, approves or rejects them, and reads the business. One environment password and an HMAC-signed cookie, two roles, no user table, no registration, zero keys in the browser. It is not merchant-facing, not a SaaS, and not open to sign-up.
D2/D3 held 423 → approve / reject → result flows backworkbench polls the queue every 20s while openbrowser holds only an HMAC cookie — zero upstream keysconsole stopped zeus & commerce APIs keep runningEverything the console writes goes through the upstream services; everything it reads is reused from existing dashboards. The workbench is a lens and a decision seat, never a second copy of business state.
One environment password plus an HMAC-signed cookie. Two roles — owner and operator. There is no account table, no registration, no password-reset flow, and no upstream key ever reaches the browser.
D1–D3 holds queue as cards: approve or reject. Results flow back consistently through the zeus /approval endpoint — the same channel agents wait on — and the workbench refreshes on a 20s poll while the queue is open.
A read-only view reusing the commerce dashboard: orders, refunds, content and net amount. It shows no cost data — the console reads; upstream services decide and write.
Every hold arrives as a webhook card in the IM client carrying an approval deep link. The IM client only notifies — approve and reject never happen inside IM; the link opens the workbench on the held item.
D3 listing changes are owner-only; D2 refunds are open to both roles; manual stock adjustments are available where the flow allows. Every write executes through commerce endpoints — the console never mutates storage directly.
Machine readouts are fixed identifiers: owner / operator roles, D1–D3 grades, the zeus /approval endpoint, the 20s poll interval. The console itself stores no business records; all state lives in zeus and commerce.
A single-process Astro 7 SSR (node standalone) with React 19 interactive islands. One process is one deployment unit: one config, one restart, one thing to reason about.
Upstream bearer tokens live on the server only. The browser holds nothing but an HMAC cookie; there is no path for the client to call zeus or commerce directly.
Shutting the console down does not affect the underlying zeus and commerce APIs. The workbench is a lens on upstream services, not a dependency of them.
The console exists to put a human in the loop — never to become another system the loop depends on.
The workbench is feature-complete and fully verified on the local build. What remains is external acceptance — days of live operation, real notification endpoints, production authentication and a real deployment. No gate is claimed early.
Local development complete. Every local verification is green: Vitest 40/40, astro check 0 errors, verify-batch1 29/0, the notify path OK, verify-batch2 21/0. The workbench runs end to end locally.
Not passed. The items below are external — they cannot be settled inside this repository, and none of them is claimed as done.
Never claimed as live: no real shop connection, no production webhooks, no production authentication. The planned URL https://ops-console.bayjf.com is a placeholder until GATE-M8 passes.