[CLAUDE-OPUS-5]
Gap
PROJECT_REQUIREMENTS.md names the authentication system as an explicit deliverable. The repo has no implementation and no spec.
Everything currently said about auth:
IMPLEMENTATION_PLAN.md §2 — "Credentials never enter model context, prompts, or action logs."
- §3.4 — "Persistent Playwright storage state supports authenticated sessions after a human logs in."
- §6 — "SSO, roles, retention controls, and audit logs", Phase 2.
README.md:112 — "No live enterprise SSO, auth, or anti-bot handling."
A grep for auth|login|credential|storage_state|cookie across src/ returns nothing.
Evidence this is urgent, not theoretical
During reconnaissance of the eval tasks the browser was already signed in to GitHub and to X under the operator's own personal accounts. Evidence was therefore collectable, but under the wrong identity and with no record of whose session produced it. In an audit context that silently invalidates the artifact.
The audit framing in PROJECT_REQUIREMENTS.md §1 is read-only access granted to an auditor on a client's Workday, GitHub, NetSuite, or Jira tenant. That is delegated third-party access, which is a different problem from logging into your own account.
Scope
Write AUTH_SPEC.md covering:
- Session acquisition: human-in-the-loop login, where it happens, and what is persisted.
- Storage: encryption at rest, per-tenant isolation, retention and revocation.
- Multi-factor prompts and re-auth challenges mid-run.
- Session expiry detected mid-run. Today this would surface as a wrong extraction from a logged-out page, not as a failure.
- Identity provenance: which principal captured each artifact, recorded in the manifest defined in §3.5.
- The boundary that keeps secrets out of model context and out of
trace.jsonl.
Acceptance
AUTH_SPEC.md exists and is linked from IMPLEMENTATION_PLAN.md §3.4.
- The artifact manifest schema in §3.5 gains a capturing-identity field.
- A logged-out or expired session produces
blocked, never a successful extraction.
[CLAUDE-OPUS-5]
Gap
PROJECT_REQUIREMENTS.mdnames the authentication system as an explicit deliverable. The repo has no implementation and no spec.Everything currently said about auth:
IMPLEMENTATION_PLAN.md§2 — "Credentials never enter model context, prompts, or action logs."README.md:112— "No live enterprise SSO, auth, or anti-bot handling."A grep for
auth|login|credential|storage_state|cookieacrosssrc/returns nothing.Evidence this is urgent, not theoretical
During reconnaissance of the eval tasks the browser was already signed in to GitHub and to X under the operator's own personal accounts. Evidence was therefore collectable, but under the wrong identity and with no record of whose session produced it. In an audit context that silently invalidates the artifact.
The audit framing in
PROJECT_REQUIREMENTS.md§1 is read-only access granted to an auditor on a client's Workday, GitHub, NetSuite, or Jira tenant. That is delegated third-party access, which is a different problem from logging into your own account.Scope
Write
AUTH_SPEC.mdcovering:trace.jsonl.Acceptance
AUTH_SPEC.mdexists and is linked fromIMPLEMENTATION_PLAN.md§3.4.blocked, never a successful extraction.