Settings
Connection diagnostics and the state of this console (09 §3.14).
Connections
Staff API
ok · roofkarma-admin-api · production
Read at Source GET /v1/health
settings:administerOPS-02: a connection is reported as working only once a controlled check proves it. admin-api publishes no diagnostics endpoint in this deployment, so nothing is claimed about them.settings:administer · audited on useThe environment is part of the authorisation decision and is bound to the verified principal, not chosen in the browser (ADM-42).About this console
What is running here
Every staff route family in the sitemap is served, on a console shell authored in this repository rather than the canonical fleet package. Sign-in does not exist: fleet SSO is an unverified seam, and admin-api refuses a staff request rather than inventing a session for it. Each screen therefore renders the refusal it actually received.
What this console will own
Route families and their capability boundary. Each one is served; admin-api decides what each may read.
- /, /reports, /reports/[reportId]
- Report read access, with revealing homeowner detail held as a separate permission
- /quality, /quality/[issueId]
- Quality review only: automated diagnostics and offline evaluation, never customer fulfilment
- /leads, /leads/[leadId]
- Marketplace and support scope: matching history, consent, acceptance and disputes
- /homeowners, /homeowners/[homeownerId]
- Contact detail masked by default; every reveal is audited against a stated purpose
- /contractors, /contractors/[organisationId]
- Verification and public-profile publication are deliberately distinct permissions
- /marketplace, /marketplace/markets/[marketId]
- Marketplace operations: coverage, ranking inputs, supply and fairness
- /billing, /billing/disputes, /billing/ledger
- Finance reconciliation; ledger history is read, never edited
- /inbox
- The canonical fleet Emails, Requests and Chats surface, scoped to RoofKarma; no replacement mail interface
- /providers, /providers/[providerId]
- Operational read is separate from publishing a provider policy or a kill switch
- /content, /configuration/[key]
- Draft, preview and publish are separated so approval cannot be self-granted
- /analytics, /accuracy
- Analyst read; exports use authorised projections rather than raw records
- /staff, /settings, /audit
- Staff administration, or the specific read permission for audit history
Showing a route is not granting it. admin-api authorises every staff request against a named capability and the selected sandbox or live environment, and a console that hid a control would still be denied by the API.
Why the shell is missing: BK-02
The blocker register entry this application is waiting on.
ARC-10 makes @melvynkim/admin-ui mandatory for every staff surface in this console. It supplies:
- Shell, PageHeader and PageBody
- DataTable and FilterBar
- Form controls, Tabs and overlays
- Status components and toast
- The fleet workspace rail and the sandbox/live switch
That package is not published to any registry this workspace can reach. BK-02 records portable distribution and fleet project registration as an open blocker, and ARC-12 forbids depending on a developer’s absolute path, so it cannot be wired in from a local checkout either.
Rebuilding the shell here is not the workaround. ARC-10 and DEV-06 both forbid a second staff design system, so no local table, filter bar or toast has been written in its place.
What closing BK-02 requires
- Registry access to the published package, or an approved unchanged snapshot distributed with its revision, licence and file hashes recorded.
- RoofKarma registered in the canonical fleet project registry, with its approved origins and console route.
- A supported forced-light integration of the upstream theme provider, proved during the first integration stage rather than assumed from a default-light prop.
- A clean build on a fresh machine and in CI that depends on no developer absolute path (ARC-12).