feat: implement GEWU service and local agent workflows

docs/decisions/ADR-001-admin-credential-panel.md

@@ -0,0 +1,34 @@
+# ADR-001: Human administrator credential panel
+
+Status: implemented, 14 October 2026.
+
+The service now exposes a separate `/admin` web page for human administrators to list,
+create and revoke bearer credentials and read recent credential-management activity.
+The research library's knowledge remains read-only in the browser.
+
+The panel reuses the existing human browser session and admin role. Agent identities,
+including identities holding both agent and admin roles, cannot administer credentials.
+Browser writes require the session CSRF token and same-origin requests. Credential
+responses use `Cache-Control: private, no-store`; only creation returns the new secret.
+The panel holds secrets in memory, never browser storage. Revoke confirmation names the
+key, and the service rejects revocation of the key backing the caller's current session.
+
+The strongest alternative was retaining CLI-only provisioning. That avoids a network
+credential-management surface but does not provide the requested operator workflow.
+The first administrator still requires local operator provisioning; the panel cannot
+bootstrap anonymous access. Owner review authentication remains separate.
+
+An additive `admin_events` SQLite table records time, actor, action and credential ID.
+The event and its successful credential mutation commit in one transaction. No raw
+secrets, digests, source bodies or arbitrary application log messages enter this table.
+The initial log covers panel/API creation and revocation only; CLI actions and historical
+credentials are not backfilled. Runtime logs and agent run history remain outside this
+first slice. Credential listing is paged; activity is limited to the latest 50 events.
+
+Existing credentials and sessions require no migration. Reverting the UI and routes
+leaves the additive table harmlessly in place. Credentials issued through the panel
+remain usable by the existing identity store and can be revoked locally.
+
+Validation: API authorization, CSRF, origin, request bounds, conflicts, secret omission,
+durable audit, bearer/session revocation, frontend credential creation and confirmation
+flows. Rendered checks use a disposable data root, separate from operator state.