@nomos-arc/arc 0.1.0

package/docs/auth/red_team_report.yaml

@@ -0,0 +1,336 @@
+audit:
+  task_id: "auth-oauth-login"
+  task_title: "Frictionless OAuth 2.0 Google Login for arc CLI"
+  audited_at: "2026-04-06T12:00:00Z"
+
+  verdict: "REVISE"
+  system_integrity_score: 62
+  total_findings: 9
+  findings_by_severity: { critical: 1, high: 3, medium: 4, low: 1 }
+
+  findings:
+    - finding_id: "F-001"
+      domain: "security"
+      severity: "critical"
+      step_id: "3.1"
+      title: "Client secret exposed via CLI flag, shell history, and process list"
+      description: |
+        The plan specifies `--client-secret <secret>` as a Commander.js option for
+        `arc auth login`. Any value passed via CLI flag is:
+        1. Stored in shell history (~/.bash_history, ~/.zsh_history)
+        2. Visible in `ps aux` process list to all users on the system
+        3. Potentially logged by corporate endpoint monitoring tools
+        client_secret is a long-lived credential that cannot be rotated easily.
+      attack_vector: |
+        Any user or process with read access to shell history or /proc can
+        extract the client_secret. On shared servers this is trivial:
+        `grep 'client-secret' ~/.bash_history`
+      evidence: |
+        Step 3.1, lines 397-398: `.option('--client-id <id>', ...)` and
+        `.option('--client-secret <secret>', ...)`. No mention of stdin/prompt
+        fallback or env var alternative for the secret.
+      recommendation: |
+        Remove `--client-secret` CLI flag entirely. Instead:
+        1. Primary: Read from config file (`auth.client_secret` in .nomos-config.json)
+        2. Fallback: Read from env var `NOMOS_GOOGLE_CLIENT_SECRET`
+        3. Last resort: Interactive prompt via `readline` (masked input)
+        Keep `--client-id` as a flag (not sensitive). Update step 3.1 description
+        and the priority resolution logic accordingly.
+
+    - finding_id: "F-002"
+      domain: "security"
+      severity: "high"
+      step_id: "2.2"
+      title: "Loopback server has no CSRF protection on OAuth callback"
+      description: |
+        The loopback server at step 2.2 accepts any GET request with a `code`
+        parameter and exchanges it for tokens. There is no `state` parameter
+        validation. RFC 6749 Section 10.12 requires a `state` parameter to
+        prevent CSRF attacks on the OAuth callback.
+      attack_vector: |
+        An attacker who knows the user is running `arc auth login` can craft a
+        URL like `http://localhost:3000/?code=ATTACKER_CODE` and trick the user
+        into visiting it (e.g., via a malicious page with an img tag). The CLI
+        would exchange the attacker's code, potentially linking the user's CLI
+        to an attacker-controlled Google account.
+      evidence: |
+        Step 2.2, lines 328-330: Callback handler parses `code` from `req.url`
+        but makes no mention of generating, sending, or validating a `state`
+        parameter. The `generateAuthUrl` call (lines 316-320) does not include
+        a `state` field.
+      recommendation: |
+        In step 2.2, add to the auth URL generation:
+        ```
+        const state = crypto.randomBytes(32).toString('hex');
+        oauth2Client.generateAuthUrl({ ..., state });
+        ```
+        In the callback handler, verify `req.url` contains the matching `state`
+        value before exchanging the code. Reject with 403 if mismatched.
+        Add `crypto` to the imports list.
+
+    - finding_id: "F-003"
+      domain: "architecture"
+      severity: "high"
+      step_id: "4.1"
+      title: "OAuth access_token used as API key may not authenticate Gemini API"
+      description: |
+        The plan passes the OAuth access_token directly to `new GoogleGenerativeAI(key)`
+        as if it were an API key. The @google/generative-ai SDK (^0.24.1) uses this
+        value as `x-goog-api-key` header. OAuth access tokens are Bearer tokens and
+        must be sent as `Authorization: Bearer <token>`. These are fundamentally
+        different authentication mechanisms.
+      attack_vector: |
+        Not a security attack — this is a functional failure. The entire OAuth
+        credential chain (steps 4.1, 4.2, 4.3, 4.4, 4.5, 4.6) is non-functional
+        if the SDK rejects bearer tokens passed as API keys.
+      evidence: |
+        Step 4.1, lines 531-533: `return new Embedder(config, logger, token)` where
+        `token` is from `authManager.getAccessToken()`. The Embedder constructor
+        (src/search/embedder.ts:36) passes this to `new GoogleGenerativeAI(key)`.
+        The plan acknowledges this risk in `risk_assessment.failure_scenarios[0]`
+        (lines 1033-1041) but proposes no concrete fallback step — only a vague
+        "fall back to custom Authorization header injection."
+      recommendation: |
+        Add a concrete step between 2.1 and 4.1: a spike/validation step that
+        tests whether `new GoogleGenerativeAI(accessToken)` succeeds with an
+        OAuth token. If it fails, the plan MUST include the alternative path
+        (custom request headers or `GoogleAuth` credential injection) as actual
+        steps, not just a mitigation note. Without this, steps 4.1-4.6 are
+        speculative.
+
+    - finding_id: "F-004"
+      domain: "ai_divergence"
+      severity: "high"
+      step_id: "3.1"
+      title: "Action handlers contain `...` placeholders — executor will improvise"
+      description: |
+        The code blocks for `arc auth login`, `arc auth logout`, and
+        `arc auth status` actions all contain `.action(async (opts) => { ... })`
+        with literal `...` as the implementation body. The detailed flow is
+        described in prose below the code block, but an AI executor seeing
+        `{ ... }` in a code template is likely to either:
+        1. Generate a minimal stub that doesn't match the prose spec
+        2. Invent its own flow that diverges from the described steps
+      evidence: |
+        Step 3.1, line 398: `.action(async (opts) => { ... });`
+        Step 3.1, line 404: `.action(async () => { ... });`
+        Step 3.1, line 410: `.action(async () => { ... });`
+        The actual implementation details are in prose paragraphs starting
+        at lines 414, 426, and 431 — separated from the code template.
+      recommendation: |
+        Replace `{ ... }` with full implementation code in the code block,
+        or at minimum replace with explicit pseudocode comments:
+        ```typescript
+        .action(async (opts) => {
+          // 1. loadConfig()
+          // 2. resolve clientId/clientSecret (flag > config > throw)
+          // 3. new OAuth2Client({ clientId, clientSecret })
+          // 4. new AuthManager(config.auth, logger)
+          // 5. startLoopbackServer(...)
+          // 6. authManager.saveCredentials(tokens)
+          // 7. console.log success
+        });
+        ```
+
+    - finding_id: "F-005"
+      domain: "ai_divergence"
+      severity: "medium"
+      step_id: "4.6"
+      title: "Single step modifies 3 files with 'same pattern' shorthand"
+      description: |
+        Step 4.6 modifies src/commands/index.ts, src/commands/search.ts, and
+        src/commands/map.ts. Only index.ts gets detailed code changes. The other
+        two files get "Same pattern" one-liners. An AI executor may:
+        1. Apply changes only to index.ts and skip the other two
+        2. Apply literally identical code without adapting to each file's
+           specific constructor (QueryEngine vs MapPipeline)
+      evidence: |
+        Step 4.6, lines 816-818: "Also update src/commands/search.ts: Same pattern"
+        Step 4.6, lines 820-822: "Also update src/commands/map.ts: Same pattern"
+        Meanwhile src/commands/search.ts instantiates `QueryEngine` (not SearchIndexer)
+        and src/commands/map.ts instantiates `MapPipeline` with a different constructor
+        signature: `new MapPipeline(config, projectRoot, logger)` (config first,
+        projectRoot second — reversed from SearchIndexer).
+      recommendation: |
+        Split step 4.6 into three separate steps (4.6a, 4.6b, 4.6c) — one per
+        file — each with explicit code showing the exact constructor call change.
+        At minimum, show the MapPipeline change explicitly since its constructor
+        parameter order differs from SearchIndexer.
+
+    - finding_id: "F-006"
+      domain: "ai_divergence"
+      severity: "medium"
+      step_id: "5.1"
+      title: "Ambiguous action — 'No modification expected unless a gap is found'"
+      description: |
+        Step 5.1 says the action is MODIFY but the description concludes with
+        "No modification expected unless a gap is found." This gives the AI
+        executor discretion to either modify or not modify the file based on
+        its own judgment. The executor could:
+        1. Skip the step entirely (interpreting "no change needed")
+        2. Add unnecessary patterns to ALWAYS_DENY
+        3. Misidentify a non-gap as a gap and make harmful changes
+      evidence: |
+        Step 5.1, lines 853-863: "No code change needed if the existing patterns
+        already cover... Action: Read the file, verify coverage, document finding.
+        No modification expected unless a gap is found."
+        Current ALWAYS_DENY (src/utils/sanitize.ts:57-61) already covers
+        `GOOGLE_.*?(KEY|SECRET|TOKEN|PASSWORD|CREDENTIAL)` which matches
+        Google OAuth env vars.
+      recommendation: |
+        Change step 5.1 action from "MODIFY" to "VERIFY". Remove the conditional
+        language. State explicitly: "Verify that the regex
+        `GOOGLE_.*?(KEY|SECRET|TOKEN|...)` in ALWAYS_DENY covers Google OAuth
+        env vars. Expected result: no changes needed. If the regex does NOT
+        match `GOOGLE_CLIENT_SECRET`, add it and report the gap."
+
+    - finding_id: "F-007"
+      domain: "rollback"
+      severity: "medium"
+      step_id: "4.3"
+      title: "Sync-to-async accessor change breaks rollback of downstream steps"
+      description: |
+        Step 4.3 changes `private get embedder(): Embedder` (synchronous accessor)
+        to `private async getEmbedder(): Promise<Embedder>` (async method). This
+        changes every call site from `this.embedder.X()` to
+        `(await this.getEmbedder()).X()`. If step 4.3 is rolled back but step 4.6
+        was already applied, `src/commands/index.ts` will pass `authManager` to a
+        constructor that no longer accepts it.
+        More critically, if 4.3 is partially applied (accessor changed but not all
+        call sites updated), the file won't compile.
+      evidence: |
+        Step 4.3 depends_on: ["4.1"]. Step 4.6 depends_on: ["4.3", "4.4", "4.5"].
+        Rollback of 4.3 says "Revert the lazy accessor and constructor changes"
+        but does not mention that 4.6 must also be reverted first.
+      recommendation: |
+        Add explicit rollback ordering: "Rollback 4.6 BEFORE rolling back 4.3."
+        Add a `rollback_depends_on: ["4.6"]` field or equivalent note to step 4.3.
+        Same applies to steps 4.1, 4.2, 4.4, 4.5.
+
+    - finding_id: "F-008"
+      domain: "architecture"
+      severity: "medium"
+      step_id: "2.1"
+      title: "loadCredentials() uses synchronous fs.readFileSync in async-capable class"
+      description: |
+        Step 2.1 specifies `loadCredentials(): AuthCredentials | null` as a
+        synchronous method using `fs.readFileSync`. This blocks the Node.js event
+        loop during file I/O. While credentials.json is small, this breaks the
+        project's pattern — the codebase consistently uses async fs operations
+        (e.g., indexer.ts writeMeta uses `fs.writeFile` from `node:fs/promises`).
+        The method is called from `isLoggedIn()` (also sync) and
+        `getAuthenticatedClient()` (async), so making it async would only require
+        updating `getAuthenticatedClient`.
+      evidence: |
+        Step 2.1, lines 242-244: "Synchronous read. Return null if file doesn't
+        exist or is invalid JSON."
+        Contrast with src/search/indexer.ts lines 439-444 which uses async
+        `fs.writeFile` + `fs.rename` for atomic writes.
+        `isLoggedIn()` (line 256) calls `loadCredentials()` synchronously.
+      recommendation: |
+        Accept the sync design for `loadCredentials()` and `isLoggedIn()` since
+        they are called in non-hot-path contexts (CLI startup, not per-request).
+        However, add a negative constraint: "DO NOT use readFileSync in any
+        method that could be called in a loop or hot path." This is a MEDIUM
+        concern — not blocking, but worth noting for the planner.
+
+    - finding_id: "F-009"
+      domain: "security"
+      severity: "low"
+      step_id: "2.2"
+      title: "Success HTML response could be used for phishing if server lingers"
+      description: |
+        The loopback server responds with a success HTML page. If the cleanup
+        is delayed or the server is somehow kept alive, a local attacker could
+        serve content on localhost:3000. This is low risk because the server
+        has a 120s timeout and socket tracking.
+      attack_vector: |
+        Theoretical: if socket cleanup fails, server continues to serve the
+        success HTML page, which could be replaced by a MITM on localhost
+        (extremely unlikely on modern systems).
+      evidence: |
+        Step 2.2, lines 331-332: "Respond with success HTML: simple page saying
+        'Login successful! You can close this tab.'"
+        Timeout: 120 seconds (line 334).
+      recommendation: |
+        Ensure the success response includes `Connection: close` header and
+        that `server.close()` is called immediately after sending the response,
+        not just on timeout. The plan describes this at line 343-344 but should
+        make it explicit in the code template.
+
+  hardening_instructions:
+    - step_id: "3.1"
+      instruction: "Remove --client-secret CLI flag. Support config file and env var NOMOS_GOOGLE_CLIENT_SECRET only. Add interactive masked prompt as last-resort fallback."
+      reason: "CLI flags expose secrets in shell history and process lists."
+      priority: "critical"
+
+    - step_id: "2.2"
+      instruction: "Add cryptographic state parameter to OAuth flow. Generate with crypto.randomBytes(32), pass in generateAuthUrl, validate in callback handler before token exchange."
+      reason: "RFC 6749 Section 10.12 requires state parameter to prevent CSRF on OAuth callbacks."
+      priority: "high"
+
+    - step_id: "4.1"
+      instruction: "Add a validation step before 4.1 that tests GoogleGenerativeAI SDK with an OAuth access_token. If it fails, provide concrete alternative steps using Authorization header injection."
+      reason: "The entire credential chain (6 steps) depends on an unverified assumption about SDK behavior."
+      priority: "high"
+
+    - step_id: "3.1"
+      instruction: "Replace `{ ... }` placeholders in code blocks with full implementation or detailed pseudocode comments."
+      reason: "Reduces AI executor improvisation risk."
+      priority: "high"
+
+    - step_id: "4.6"
+      instruction: "Split into 3 separate steps with explicit code for each file, especially showing MapPipeline's different constructor parameter order."
+      reason: "Prevents executor from applying incorrect 'same pattern' changes."
+      priority: "medium"
+
+    - step_id: "5.1"
+      instruction: "Change action from MODIFY to VERIFY. Remove conditional modification language."
+      reason: "Removes ambiguity about whether the executor should change the file."
+      priority: "medium"
+
+  negative_constraints:
+    - "DO NOT pass client_secret via CLI flags — it leaks to shell history and process lists"
+    - "DO NOT exchange OAuth authorization codes without validating the state parameter"
+    - "DO NOT modify src/core/state.ts — it manages task state and is unrelated to auth"
+    - "DO NOT modify src/core/orchestrator.ts — orchestration loop must remain unchanged"
+    - "DO NOT modify src/core/budget.ts — budget tracking is unrelated to auth"
+    - "DO NOT modify src/search/vector-store.ts or src/search/chunk-extractor.ts"
+    - "DO NOT add new dependencies beyond google-auth-library — open is already installed"
+    - "DO NOT store tokens in environment variables — use file-based storage only"
+    - "DO NOT log access_token, refresh_token, or client_secret values at any log level"
+    - "DO NOT use readFileSync in any method that could be called in a loop or hot path"
+
+  rollback_assessment:
+    is_fully_reversible: false
+    weak_points: ["4.3", "4.4", "4.5"]
+    cascade_risks:
+      - "Steps 4.3-4.6 form a tight dependency chain. Rolling back 4.3 (sync-to-async accessor in indexer.ts) without also rolling back 4.6 (command wiring) leaves index.ts passing authManager to a constructor that doesn't accept it. Rollback must proceed in reverse order: 4.6 -> 4.5 -> 4.4 -> 4.3."
+      - "Step 1.1 (npm install) modifies package-lock.json. npm uninstall may not produce a byte-identical package-lock.json, creating noise in git diff."
+      - "If step 6.2 (test suite) discovers failures after steps 4.1-4.6 are applied, selective rollback of individual steps is unsafe — all of Phase 4 must be rolled back together."
+
+  summary:
+    strengths:
+      - "Detailed step-by-step with explicit code blocks, file paths, and line numbers"
+      - "Additive factory method pattern preserves backward compatibility"
+      - "Clear dependency graph with can_parallel flags"
+      - "Comprehensive risk assessment with failure scenarios and mitigations"
+      - "Fragile zone identification correctly protects state.ts, orchestrator.ts, budget.ts"
+      - "Credential chain priority (env var -> OAuth -> error) is well-designed"
+      - "Socket tracking and timeout on loopback server prevents dangling processes"
+    critical_gaps:
+      - "Client secret exposed via CLI flag (F-001) — CRITICAL security issue"
+      - "No OAuth state parameter for CSRF protection (F-002)"
+      - "Unverified assumption that OAuth tokens work as GoogleGenerativeAI API keys (F-003)"
+      - "Placeholder code blocks risk AI executor divergence (F-004)"
+    recommendation: |
+      The plan is well-structured and follows existing codebase conventions closely.
+      However, it must be revised before execution due to one critical and three high
+      findings. The most urgent fix is removing the --client-secret CLI flag (F-001)
+      and replacing it with config/env/prompt-based secret injection. Second, add
+      OAuth state parameter validation to the loopback server (F-002) per RFC 6749.
+      Third, add a concrete validation step for the OAuth-token-as-API-key assumption
+      (F-003) — without this, 6 steps in Phase 4 are built on speculation. Finally,
+      replace the `{ ... }` placeholders in step 3.1 with actual implementation code
+      to prevent executor divergence (F-004). With these four fixes, the plan moves
+      from REVISE to APPROVE_WITH_NOTES.

package/docs/auth/session_state.yaml

@@ -0,0 +1,162 @@
+execution_report:
+  task_id: "auth-oauth-login"
+  task_title: "Frictionless OAuth 2.0 Google Login for arc CLI"
+  phase_executed: 6
+  session_id: "2026-04-06T10:27:00Z"
+  status: "SUCCESS"
+
+  pre_execution_gates:
+    blueprint_integrity: "PASSED"
+    phase_exists: "PASSED"
+    dependencies_satisfied: "PASSED"
+    idempotency_check: "PASSED (no phase 6 steps in prior state)"
+    gate_result: "ALL_PASSED"
+    abort_reason: ""
+
+  steps_log:
+    - step_id: "6.1"
+      status: "SUCCESS"
+      pre_condition: "PASSED"
+      constraints_checked: true
+      execution_note: |
+        ROLLBACK INVOKED then RE-EXECUTED.
+        Initial run: `npm run lint` (tsc --noEmit) produced 2 TypeScript errors:
+          - src/search/__tests__/indexer.test.ts(22,16): error TS2339: Property 'create'
+            does not exist on type 'Mock<Procedure>'
+          - src/search/__tests__/query-engine.test.ts(26,16): same error
+        Root cause: both test files assigned `EmbedderMock.create = vi.fn()...` after
+        constructing with `vi.fn()`, which TypeScript does not recognize as a valid
+        property assignment on `Mock<Procedure>`.
+        Fix: replaced assignment pattern with `Object.assign(vi.fn()..., { create: vi.fn()... })`
+        in both test files. Re-run: `npm run lint` exits 0.
+      validation_result: "PASSED — tsc --noEmit exits 0"
+      rollback_executed: true
+      rollback_result: "Fixed TS2339 errors in indexer.test.ts and query-engine.test.ts"
+      duration_ms: 0
+
+    - step_id: "6.2"
+      status: "SUCCESS"
+      pre_condition: "PASSED"
+      constraints_checked: true
+      execution_note: |
+        `npm test` (vitest run) completed: 29 test files, 345 tests passed, 6 skipped.
+        No unexpected failures. All existing tests remain green after auth changes.
+      validation_result: "PASSED — npm test exits 0"
+      rollback_executed: false
+      rollback_result: ""
+      duration_ms: 0
+
+    - step_id: "6.3"
+      status: "SUCCESS"
+      pre_condition: "PASSED — AuthManager (step 2.1) exists at src/core/auth/manager.ts"
+      constraints_checked: true
+      execution_note: |
+        Created src/core/auth/__tests__/manager.test.ts with 13 unit tests covering:
+        - saveCredentials: writes JSON, creates parent dirs, sets 0600 permissions
+        - loadCredentials: returns parsed data, null on missing file, null on invalid JSON,
+          null on missing required fields
+        - isLoggedIn: true with refresh_token, false without file, false on empty token
+        - clearCredentials: deletes file, no-throw when missing
+        - getAccessToken: throws auth_not_logged_in when no credentials
+        Uses real temp directory (os.tmpdir()) with afterEach cleanup — no fs mocking.
+      validation_result: "PASSED — npx vitest run src/core/auth/__tests__/manager.test.ts exits 0 (13/13)"
+      rollback_executed: false
+      rollback_result: ""
+      duration_ms: 0
+
+    - step_id: "6.4"
+      status: "SUCCESS"
+      pre_condition: "PASSED — startLoopbackServer (step 2.2) exists at src/core/auth/server.ts"
+      constraints_checked: true
+      execution_note: |
+        Created src/core/auth/__tests__/server.test.ts with 5 unit tests covering:
+        - Port binding: server starts and resolves with credentials
+        - Timeout: server rejects after 120s (fake timers via vi.useFakeTimers + vi.advanceTimersByTimeAsync)
+        - Callback: resolves with credentials for valid code + state
+        - CSRF state validation (F-002): 403 returned for wrong state, getToken NOT called
+        - Cleanup: server is closed after successful callback
+        Mocked node:crypto randomBytes to yield deterministic FIXED_STATE for tests.
+        Mocked `open` to prevent browser launch.
+        Fixed unhandled-rejection warning in timeout test by attaching .catch() before timer advance.
+      validation_result: "PASSED — npx vitest run src/core/auth/__tests__/server.test.ts exits 0 (5/5)"
+      rollback_executed: false
+      rollback_result: ""
+      duration_ms: 0
+
+    - step_id: "6.5"
+      status: "SUCCESS"
+      pre_condition: "PASSED — Embedder.create() (step 4.1) exists at src/search/embedder.ts"
+      constraints_checked: true
+      execution_note: |
+        Created src/search/__tests__/embedder-auth.test.ts with 4 integration tests covering:
+        - API key priority: GEMINI_API_KEY set → authManager not consulted
+        - OAuth fallback: env key unset, isLoggedIn=true → getAccessToken called
+        - Neither available: env key unset, isLoggedIn=false → throws search_api_key_missing
+          with message mentioning both GEMINI_API_KEY and arc auth login
+        - No authManager: passes null → throws search_api_key_missing
+        Fixed @google/generative-ai mock to use regular function (not arrow) as constructor.
+      validation_result: "PASSED — npx vitest run src/search/__tests__/embedder-auth.test.ts exits 0 (4/4)"
+      rollback_executed: false
+      rollback_result: ""
+      duration_ms: 0
+
+  session_state:
+    blueprint_version: "2.0-HARDENED"
+    last_executed_phase: 6
+    completed_steps:
+      - "1.1"
+      - "1.2"
+      - "1.3"
+      - "1.4"
+      - "2.1"
+      - "2.2"
+      - "3.1"
+      - "3.2"
+      - "3.5"
+      - "4.1"
+      - "4.2"
+      - "4.3"
+      - "4.4"
+      - "4.5"
+      - "4.6a"
+      - "4.6b"
+      - "4.6c"
+      - "5.1"
+      - "6.1"
+      - "6.2"
+      - "6.3"
+      - "6.4"
+      - "6.5"
+    failed_step: ""
+    is_phase_complete: true
+    next_phase: null
+
+  state_delta:
+    files_created:
+      - "src/core/auth/__tests__/manager.test.ts"
+      - "src/core/auth/__tests__/server.test.ts"
+      - "src/search/__tests__/embedder-auth.test.ts"
+    files_modified:
+      - "src/search/__tests__/indexer.test.ts"
+      - "src/search/__tests__/query-engine.test.ts"
+    files_deleted: []
+    configs_changed: []
+    other_changes: []
+
+  post_mortem: {}
+
+  phase_summary:
+    total_steps_in_phase: 5
+    executed: 5
+    skipped: 0
+    succeeded: 5
+    failed: 0
+    system_stable: true
+    ready_for_next_phase: false
+    next_phase_number: null
+    handoff_message: |
+      Phase 6 complete — all validation and testing steps succeeded.
+      TypeScript compiles clean (0 errors). Full suite: 32 files, 367 tests pass.
+      New test coverage: AuthManager (13 tests), loopback server (5 tests, CSRF F-002 covered),
+      Embedder credential chain (4 tests). Blueprint task auth-oauth-login is fully complete.
+      No further phases remain.