[Maximo-Guk]

Builds on #1040, now merged. Lets a deployment admin list users and workspaces and inspect any workspace read-only, with every call recorded in the audit log, and shows those calls in the Audit tab with their sensitivity. Supersedes #861.

Kernel (first commit)

• AdminApi.listUsers / listWorkspaces, read from the user directory
• AdminApi.inspectWorkspace(id, reason, { access, lifetimeSeconds }) mints a read-only AdminWorkspaceView (describe, listChats, getChat, listActions, listFiles, readFile, listGatekeepers, getDiagnostics) through OverseerDurableObject.openForAdmin, which is reachable only over the DO binding. The view:
  • skips collaborator and observer checks by explicit policy (docs/observers.md); the audit is the compensating control
  • re-checks admin status on every call, and expires
• Access levels off / metadata / full. A view runs at the lower of the level asked for (metadata by default) and the deployment's, which is capped by ADMIN_WORKSPACE_ACCESS_MAX (default metadata; anything unrecognised means off).
• Every view call is recorded as an AdminAccessRecord after the server-side read and before anything leaves the server. The record says what the answer exposed (metadata or content) and who owns the workspace (workspaceOwner, resolved when the view opens)

UI (second commit)

• The log's row is Time · Admin · Action · Sensitivity · Target user. The expanded row shows the workspace, reason, level, arguments and Via.
  • Sensitivity is Content read (the answer held content), Workspace metadata or Setting change.
  • Refused marks a call the access level blocked, so it read nothing. It's either Content withheld (a Metadata-only view asked for chat messages, file contents or descriptions) or Access off (the deployment's level is Off). Refused calls are still logged.
  • Target user is the owner of the workspace the call reached. Setting changes have none.
• New filters: sensitivity, target user (click one in the log, or type it), and workspace (picked from a record's details, shown as a removable chip). The Action filter lists the workspace calls.
• Most active admins shows each admin's content reads

More workspace reads (last nine commits)

• Chats: getChatState (the recorded turn, queued agent calls, pending actions), listChatAttachments, readChatAttachment
• Code: getCommitLog, listFilesAtCommit, readFileAtCommit, listChangedPaths, listPendingChanges, readPendingFile, at any commit the workspace stores
• Sharing: listObservers, listObserverRequirements, listShareLinks, listAutoApprovals, listBlueprints
• listGatekeepers adds who created each connection (recorded from now on, so older ones have none), and getDiagnostics the storage size and who is present
• Same rules as the first eight: recorded before answering, exposed set from the answer, and only stored objects are read, never a connection. Below full the three read* calls are refused, and commit messages, queued-call argument summaries and blueprint ids are withheld.
• No UI change beyond the Audit tab's "Metadata only" help sentence; the Action filter lists the new calls.

Screenshots (three admins, real inspections at full)

Before (main): settings changes only.

After: content reads per admin; the log with a content read opened; carol's getChat calls, a refused read opened; page 2.

[ask-bonk]

LGTM!

github run

[ask-bonk]

LGTM!

github run

[github-actions]

Preview: pr1026-maximo-admin-api

https://pr1026-maximo-admin-api-router.cloudflare-os-previews.workers.dev

Dashboard · deleted when this PR closes

[ask-bonk]

LGTM!

github run

[ask-bonk]

[P1] Prevent stale KV retention from pruning the audit log

#call() builds this policy from readAdminConfig()'s eventually consistent KV mirror, but append() immediately calls #prune() with the supplied retention. After an admin raises retention from 90 to 365 days, a workspace still seeing 90 can permanently delete records that cross the 90-day boundary during propagation, even though they are now within the committed retention. I reproduced this with the actual audit-store class and in-memory SQLite: a record retained when the setting changed was deleted by an inspection append 20 seconds later. Keep destructive pruning on the existing authoritative-config paths (listAdminAudit() / getAdminAuditStats()), or otherwise prevent inspection appends from pruning with stale retention. The package guide identifies the source of truth: “The AdminSettings durable object owns the authoritative AdminConfig” (packages/workshop-backend/AGENTS.md).

[ask-bonk]

Review: 1 finding.

Submitted one actionable inline comment, verified with an in-memory reproduction.

github run

[ask-bonk]

LGTM!

github run

[ask-bonk]

LGTM!

github run

[ask-bonk]

LGTM!

github run

[clanky-the-clanker]

✅ Approved — No findings. The one INFO from the last review (an incomplete restricted-data list in docs/observers.md) is fixed, and nothing changed since then has a defect.

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

---

✅ All checks passed

🔒 Security: ✅ LGTM

• Access cap: the cap fails closed. An unrecognised ADMIN_WORKSPACE_ACCESS_MAX becomes off, and setAdminWorkspaceAccess refuses a level above the cap. Every call runs at the lower of the level asked for and the current policy.
• Content refusal: below full, the five content reads are refused, and commit messages, queued-call argument summaries, the descriptions of actions, observations and hooks, and blueprint ids are withheld.
• Recording order: the audit record is written before the answer leaves the server.
• SQL: audit and directory queries bind every value as a parameter, and filter lengths are capped.

---

📖 AGENTS.md: ✅ LGTM

The AGENTS.md updates match the change.

---

📋 Code Quality: ✅ LGTM

• View calls: AdminWorkspaceViewImpl.#call checks expiry and admin status before the read and again before it records the call, with no await between the last check and the audit append. A refused call is recorded and then refused. A failed read is recorded as metadata and rethrown. A call whose record cannot be written fails and returns nothing.
• Local-only reads: the new git-cache readers use only stored objects and never pull. readCommitLog({ stopAtMissing }) marks a parent as reached before skipping it, so the walk never visits it twice.
• Directory and paging: sync steps run one at a time and re-check the removed flag at each step. Pages fetch limit + 1 rows in id order, so no row is skipped between pages.
• vitest.config.ts: ADMINS is now an array binding, which matches string[] | string in env.d.ts.

---

⚡ Performance: ✅ LGTM

Each admin view call does one config read and one audit append. Indexes cover the new filters, and the retry loop in listPendingChanges is bounded.

---

📝 Documentation: ✅ LGTM

The list of restricted data at docs/observers.md:118-120 now names the argument summaries of queued agent calls and blueprint ids, so it matches docs/admin-access.md.

---

_{Reviewed commit: 27434f04}

[ask-bonk]

LGTM!

github run

[github-actions]

Eval results

Verdict: ⚪ Unchanged. No task moved beyond what these runs can tell apart from noise.

Task	Score	Δ score	Fisher test	Cache hits	Avg min	Avg steps
change-calendar (gpt-6-luna)	100% → 10 run errors	candidate run errors	—	95% → —	2.8 → 0.3	24.9 → 1.7
chat-views (gpt-6-luna)	100% → 10 run errors	candidate run errors	—	94% → —	1.7 → 0.3	12.0 → 1.7
chess (gpt-6-luna)	50% → 10 run errors	candidate run errors	—	97% → —	3.6 → 0.4	27.2 → 1.8
compaction (claude-sonnet-5-5)	100%	0 pp	p = 1.00	90% 0 pp	1.7 → 2.0	43.0
compaction (gpt-6-luna)	100% → 1 run error	candidate run errors	—	92% → —	1.8 → 0.1	43.0 → 0.0
incident-desk (gpt-6-luna)	90% → 10 run errors	candidate run errors	—	96% → —	3.0 → 0.4	28.1 → 2.2
ticket-triage-agent (gpt-6-luna)	100% → 100% (5 run errors)	candidate run errors	—	97% → —	0.2 → 0.1	2.2 → 1.5
worker-logs (gpt-6-luna)	90% → 10 run errors	candidate run errors	—	95% → —	3.1 → 0.3	21.9 → 1.3

Failed checks

Task	Check	Failed
chess (gpt-6-luna)	t1 agrees-with-the-oracle-through-random-games	5/10 → —
chess (gpt-6-luna)	t1 agrees-with-the-oracle-on-the-hard-positions	4/10 → —
chess (gpt-6-luna)	t1 agrees-with-the-oracle-on-perft-positions	4/10 → —
chess (gpt-6-luna)	t1 the-game-is-shared-across-connections	3/10 → —
chess (gpt-6-luna)	t1 starts-from-the-standard-position	2/10 → —
incident-desk (gpt-6-luna)	t1 opens-acknowledges-and-resolves-in-order	1/10 → —
incident-desk (gpt-6-luna)	t1 simultaneous-acknowledges-yield-exactly-one-owner	1/10 → —
incident-desk (gpt-6-luna)	t1 simultaneous-opens-of-one-id-admit-exactly-one	1/10 → —
incident-desk (gpt-6-luna)	t1 board-lists-by-severity-then-age	1/10 → —
worker-logs (gpt-6-luna)	t1 ingests-resets-and-summarises-per-worker	1/10 → —
worker-logs (gpt-6-luna)	t1 hourly-buckets-cover-every-hour-including-empty-ones	1/10 → —
worker-logs (gpt-6-luna)	t1 ranges-are-half-open-and-filter-by-worker	1/10 → —

Run · trajectories and raw results

[ask-bonk]

🔬 Eval runs review

Performance

comparison.json reports unchanged, but GPT-6-Luna is non-comparable: ticket-triage-agent passed all five completed candidate runs versus main’s 10/10, while every candidate run of its other tasks aborted. The only clean comparison, Sonnet compaction, stayed at 100% with 43 model steps and 21 tool calls; cost was $1.4572 → $1.4584, time 1.7 → 2.0 minutes, cache hits 89.76% → 89.76%, and cache breaks 2.06% → 2.07% (both cache p-values 1). Infrastructure aborts account for the lost runs and apparent GPT cost/step savings, not more efficient completion.

🟡 VERDICT: INCONCLUSIVE

The diff’s audited admin views and directory feeds do not explain the opaque candidate-only GPT failures, while the single comparable Sonnet run provides too little evidence to clear or implicate this PR.

• Agent execution aborts · caused by this PR: unclear — the agent prompt and tool definitions are unchanged, and the transcripts expose no underlying exception linking the failures to changed code.

Triage

Failure modes

• Agent execution aborts · change-calendar 10/10, chat-views 10/10, chess 10/10, incident-desk 10/10, worker-logs 10/10, ticket-triage-agent 5/10, compaction (gpt-6-luna) 1/1 · harness bug · this PR: unclear — every aborted run reports only Sorry, something went wrong. GPT compaction stops on turn 1 before replying “Ready”; change-calendar trial 3 stops after a successful listBlueprints; chat-views trial 1 passes turns 1–4, then aborts on turn 5 after successful expense-gadget file writes. These are infrastructure interruptions, not rejected task results; main has no infrastructure errors.

Tool errors

• editFile: validation failed · change-calendar 2 → 0, chess 1 → 0, incident-desk 6 → 0, worker-logs 3 → 0 · model error — main’s agents omitted filename, supplied text or .replace instead of required fields, or passed a batch wrapper directly to editFile; corrected calls succeeded.
• editFile: no matching text · change-calendar 1 → 0, chess 3 → 0, incident-desk 1 → 0, worker-logs 3 → 1 · model error — replacement anchors did not match the written source. Candidate worker-logs trial 6, turn 1 double-escaped the regex in its anchor; main change-calendar trial 2 recovered by rereading and quoting the actual text.
• editFile: multiple matches · chess 2 → 1, incident-desk 2 → 0 · model error — anchors were not unique despite the parameter’s explicit requirement. Candidate chess trial 5, turn 1 matched both knight and king logic, then successfully retried with the surrounding blocks.
• editFile: file not found · change-calendar 1 → 0, chess 1 → 0 · model error — main change-calendar trial 3, turn 4 used CHANGE_CALENDAR/README.md instead of README.md; chess trial 6, turn 3 supplied CHESS as the filename instead of a source file.
• grep: invalid regex, unmatched ) · chess 1 → 0 · model error — main chess trial 9, turn 1 searched for castling).*test; retrying with castling succeeded.

What to do

• Rerun the GPT evaluations with sanitized underlying error diagnostics, then refresh artifacts/candidate/trajectories.md and artifacts/comparison/comparison.json before attributing the aborts to this PR.
• No changes to packages/workshop-backend/src/agent.ts are warranted for the existing editFile and grep model mistakes.

github run