gstack/test/fixtures/eng-fb10-count-public.json

{
  "source": "fb10b21c2a01365d82c1ac44d6fd53f67b9db644",
  "originalOutcome": "TIMEOUT",
  "qualification": "Original first attempt timed out; retry 2 was cancelled by the root owner. This captured public input has no paid passing verdict.",
  "windowStart": "2026-09-17T00:43:15.000Z",
  "windowEnd": "2026-09-17T01:06:55.409606+00:00",
  "plan": "Proceed directly to the requested engineering review; skip the optional /office-hours prerequisite.\nPlease review this plan thoroughly. Write the full reviewed implementation plan, including its final ## GSTACK REVIEW REPORT section, to /tmp/g-vlxin2hi/gstack-paid-shard-rOxzCt/tmp/gstack-e2e-plan-eng-uyBqKt/gstack-test-plan-eng.md (use Edit/Write to that exact path).\nThe separate QA Test Plan artifact belongs at the skill-prescribed test-plan path; keep this requested deliverable as the full reviewed implementation plan.\n\n# Plan: Multi-tenant Auth Refactor\n\n## Context supplied by the plan author\nThe goal is to reorganize existing tenant-auth orchestration without changing\nits product behavior. RequestPolicy groups the existing per-request access\ndecision: given already-fetched claims and tenant/request context, it returns\nallow or deny under the existing access policy. AuthBroker.validateAndDispatch()\ncalls it after validation and before dispatch. It adds no policy, network call,\ncache mutation or state. Its separate class boundary remains a proposal to review.\n\n## Existing contracts retained\nThe existing cache adapter keys entries by tenant ID, issuer, audience,\nand policy version. It evicts expired tokens and invalidates entries on\nlogout, token revocation, or tenant suspension. AuthCache retains these\nunchanged validity and tenant-key rules; they do not serialize mutations.\nAuthCache is a service-facing facade over that same existing adapter,\nwith one backing cache. The adapter, its invalidation hooks, and their\nexisting tests remain in use unchanged.\nUnit and integration coverage is planned for the new components and their\nsuccess/error paths. That coverage does not exercise legacyAuthFlow() or\nassert compatibility with its prior behavior.\n\n## Architecture\nTwo new services (`AuthBroker` and `SessionMint`) share a global mutable\n`AuthCache` instance via module-level export. Both services mutate it.\n\n## Code quality\nThe `validateAndDispatch()` function is 60 lines with three nested\ntry/catch blocks; each catch swallows a different error class.\n\n## Tests\nThe existing `legacyAuthFlow()` will get rewritten as part of this work;\nno regression test for the prior behavior is planned.\n\n## Performance\nToken validation issues 5 sequential API calls to the IDP; they could be\nparallelized via Promise.all trivially (calls are independent).\n\n## Architecture (scope smell)\nThis touches 12 files and introduces 5 new classes (AuthBroker, TokenStore,\nSessionMint, AuthCache, RequestPolicy). Worth flagging the complexity check.",
  "calls": [
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_011bWtb3sZRACVmR16iJKApo",
      "questions": [
        {
          "question": "D1 — Should the Promise.all IDP parallelization ship in this refactor PR, or as its own follow-up?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Scope Challenge complexity gate.\nELI10: The plan promises \"no product behavior change\" (PLAN.md:8-9), then also proposes turning 5 sequential calls to the identity provider into 5 parallel ones (PLAN.md:39-41). Parallel calls change which error the user sees when one fails, stop waiting for the others on first failure, and hit the IDP 5x harder at once. That is real behavior, not reorganization. If something breaks after the merge, you will not know whether the refactor or the parallelization did it.\nStakes if we pick wrong: bundle them and a regression in login is un-bisectable; cut it and users keep waiting ~5x longer on token validation than they need to.\nRecommendation: A because the speedup is real and cheap, but it deserves its own PR with its own error-semantics tests so the refactor stays a pure structural change.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Defer to an immediate follow-up PR (recommended)\n  ✅ Refactor PR stays honest to \"no behavior change\"; any login regression bisects cleanly to one PR\n  ✅ Follow-up PR can carry its own tests for fail-fast ordering, partial-failure and IDP rate limits\n  ❌ Users wait one more release cycle for the latency win (human: ~1 day / CC: ~10 min of extra PR overhead)\nB) Include in this PR as planned\n  ✅ One review, one merge, latency win lands with the refactor\n  ✅ AuthBroker is written parallel-first instead of retrofitted later\n  ❌ Refactor is no longer behavior-preserving; a 3am login incident has two suspects instead of one\nC) Cut parallelization entirely\n  ✅ Zero new risk surface in the auth path\n  ✅ Nothing to test beyond the refactor itself\n  ❌ Leaves a known, trivially fixable ~5x latency on every token validation on the table indefinitely\nNet: you are trading one release cycle of latency for a refactor you can actually trust and bisect.",
          "header": "D1 Promise.all",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Defer to follow-up PR (recommended)",
              "description": "Keep this PR structural only. Parallelization ships next as its own PR with fail-fast/partial-failure tests. Recorded as NOT in scope for this plan."
            },
            {
              "label": "B) Include in this PR",
              "description": "Ship Promise.all inside the refactor. Plan's \"no behavior change\" claim gets amended to name this exception. Performance section will still review the fail-fast semantics."
            },
            {
              "label": "C) Cut parallelization",
              "description": "Drop it from the plan and do not schedule a follow-up. Sequential IDP calls stay as they are."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D1 — Should the Promise.all IDP parallelization ship in this refactor PR, or as its own follow-up?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Scope Challenge complexity gate.\nELI10: The plan promises \"no product behavior change\" (PLAN.md:8-9), then also proposes turning 5 sequential calls to the identity provider into 5 parallel ones (PLAN.md:39-41). Parallel calls change which error the user sees when one fails, stop waiting for the others on first failure, and hit the IDP 5x harder at once. That is real behavior, not reorganization. If something breaks after the merge, you will not know whether the refactor or the parallelization did it.\nStakes if we pick wrong: bundle them and a regression in login is un-bisectable; cut it and users keep waiting ~5x longer on token validation than they need to.\nRecommendation: A because the speedup is real and cheap, but it deserves its own PR with its own error-semantics tests so the refactor stays a pure structural change.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Defer to an immediate follow-up PR (recommended)\n  ✅ Refactor PR stays honest to \"no behavior change\"; any login regression bisects cleanly to one PR\n  ✅ Follow-up PR can carry its own tests for fail-fast ordering, partial-failure and IDP rate limits\n  ❌ Users wait one more release cycle for the latency win (human: ~1 day / CC: ~10 min of extra PR overhead)\nB) Include in this PR as planned\n  ✅ One review, one merge, latency win lands with the refactor\n  ✅ AuthBroker is written parallel-first instead of retrofitted later\n  ❌ Refactor is no longer behavior-preserving; a 3am login incident has two suspects instead of one\nC) Cut parallelization entirely\n  ✅ Zero new risk surface in the auth path\n  ✅ Nothing to test beyond the refactor itself\n  ❌ Leaves a known, trivially fixable ~5x latency on every token validation on the table indefinitely\nNet: you are trading one release cycle of latency for a refactor you can actually trust and bisect.": "A) Defer to follow-up PR (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:46:28.200Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_01DbdvyGe8tLQMaThag4yxvK",
      "questions": [
        {
          "question": "D2 — Should legacyAuthFlow() be deleted in this PR, or kept alive behind a flag until the new path proves parity?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Scope Challenge complexity gate (D1 answered: parallelization deferred).\nELI10: The plan rewrites legacyAuthFlow() and removes the old code in the same change (PLAN.md:36-37). If the new AuthBroker path gets one tenant edge case wrong, the only way back is a revert of a 12-file PR. A strangler approach lands AuthBroker next to the old flow, routes traffic with a flag (per tenant or percentage), and deletes legacyAuthFlow() in a small follow-up once nobody has been paged. This question is about sequencing only. Whether and how the old behavior gets regression tests is a separate mandatory question in the Tests section; it stays pending here regardless of your answer.\nStakes if we pick wrong: big-bang and a bad tenant edge case means a full revert under incident pressure; strangler and you carry two auth paths for a short window and must remember to delete the old one.\nRecommendation: A because auth is the wrong place to make a wrong choice expensive to undo, and the flag costs minutes.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Strangler: flag-routed, legacy deleted in follow-up (recommended)\n  ✅ One-line rollback (flip the flag) instead of a 12-file revert during an incident\n  ✅ Can canary one internal tenant first and compare allow/deny decisions side by side\n  ❌ Two live auth paths for a sprint or so; someone must own the deletion follow-up (human: ~2h / CC: ~10 min)\nB) Rewrite and delete legacyAuthFlow() in this PR as planned\n  ✅ No dual-path window, no flag to clean up, smaller total diff\n  ✅ Forces the team to fully understand the legacy behavior now rather than later\n  ❌ Rollback is a full revert; any missed tenant-specific quirk hits production with no soft landing\nNet: a flag and a follow-up deletion buy you a cheap undo on the one code path where undo matters most.",
          "header": "D2 Legacy path",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Strangler behind a flag (recommended)",
              "description": "AuthBroker lands beside legacyAuthFlow(). Flag routes traffic (default off, then per-tenant canary). legacyAuthFlow() deletion becomes a named follow-up task. Regression-test coverage stays a separate pending decision."
            },
            {
              "label": "B) Rewrite and delete in this PR",
              "description": "Keep the plan as written: legacyAuthFlow() is rewritten and removed in this change. Regression-test coverage stays a separate pending decision."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D2 — Should legacyAuthFlow() be deleted in this PR, or kept alive behind a flag until the new path proves parity?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Scope Challenge complexity gate (D1 answered: parallelization deferred).\nELI10: The plan rewrites legacyAuthFlow() and removes the old code in the same change (PLAN.md:36-37). If the new AuthBroker path gets one tenant edge case wrong, the only way back is a revert of a 12-file PR. A strangler approach lands AuthBroker next to the old flow, routes traffic with a flag (per tenant or percentage), and deletes legacyAuthFlow() in a small follow-up once nobody has been paged. This question is about sequencing only. Whether and how the old behavior gets regression tests is a separate mandatory question in the Tests section; it stays pending here regardless of your answer.\nStakes if we pick wrong: big-bang and a bad tenant edge case means a full revert under incident pressure; strangler and you carry two auth paths for a short window and must remember to delete the old one.\nRecommendation: A because auth is the wrong place to make a wrong choice expensive to undo, and the flag costs minutes.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Strangler: flag-routed, legacy deleted in follow-up (recommended)\n  ✅ One-line rollback (flip the flag) instead of a 12-file revert during an incident\n  ✅ Can canary one internal tenant first and compare allow/deny decisions side by side\n  ❌ Two live auth paths for a sprint or so; someone must own the deletion follow-up (human: ~2h / CC: ~10 min)\nB) Rewrite and delete legacyAuthFlow() in this PR as planned\n  ✅ No dual-path window, no flag to clean up, smaller total diff\n  ✅ Forces the team to fully understand the legacy behavior now rather than later\n  ❌ Rollback is a full revert; any missed tenant-specific quirk hits production with no soft landing\nNet: a flag and a follow-up deletion buy you a cheap undo on the one code path where undo matters most.": "A) Strangler behind a flag (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:46:48.769Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_012Q2o11tyfihFA79sscWbbo",
      "questions": [
        {
          "question": "D3 — Five new classes, or fewer moving parts for the same behavior?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Scope Challenge complexity gate (D1: parallelization deferred; D2: strangler behind flag — both fixed across all options here).\nELI10: The plan adds AuthBroker, TokenStore, SessionMint, AuthCache and RequestPolicy across 12 files (PLAN.md:44-45). Two of those look like ceremony. RequestPolicy is described as stateless with one job: take claims plus tenant context, return allow or deny (PLAN.md:9-13). That is a function, not a class; the author already flagged the boundary as open. TokenStore is never described anywhere, while AuthCache is already \"a facade over that same existing adapter, with one backing cache\" (PLAN.md:20-21). Two cache-shaped classes over one cache is a duplication smell, but I cannot see TokenStore's code, so that one is medium confidence. Every option keeps the same features, contracts and the D1/D2 answers; this is structure only. The shared-mutable-cache problem (PLAN.md:28-29) is a separate Architecture question and stays pending here.\nStakes if we pick wrong: too many classes and every future auth change touches five files and five test suites; too few and you cram unrelated responsibilities together and get a god-object AuthBroker.\nRecommendation: B because RequestPolicy-as-function is a clear win with no downside, while folding TokenStore needs the author to confirm it has no responsibility distinct from AuthCache.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Keep all 5 classes as planned\n  ✅ Every responsibility has a named home; matches the plan the team already discussed\n  ✅ RequestPolicy as a class can grow strategies later without a signature change\n  ❌ A one-method stateless class is premature abstraction; five suites for what is one orchestration path\nB) 4 parts: RequestPolicy becomes a pure exported function; keep TokenStore (recommended)\n  ✅ evaluateRequestPolicy(claims, ctx) is trivially unit-testable with no constructor or mocks\n  ✅ Removes one class and its test scaffolding while touching nothing whose role is unclear\n  ❌ TokenStore's overlap with AuthCache stays unresolved; plan must define TokenStore's distinct job or this becomes a follow-up\nC) 3 parts: RequestPolicy as function AND TokenStore folded into AuthCache\n  ✅ One cache facade, one truth about tenant keys and invalidation; least surface for a shared-state bug\n  ✅ Fewest files and suites to maintain for a change that claims no behavior difference\n  ❌ If TokenStore actually owns something AuthCache does not (e.g. refresh-token persistence), you merge two responsibilities and have to split them again later\nNet: B takes the free simplification now and makes the plan author write down what TokenStore is for before deciding its fate.",
          "header": "D3 Class count",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Keep all 5 classes",
              "description": "AuthBroker, TokenStore, SessionMint, AuthCache, RequestPolicy as planned. Same contracts, D1/D2 unchanged. Shared-cache remedy stays pending for Architecture."
            },
            {
              "label": "B) 4 parts: RequestPolicy as function (recommended)",
              "description": "RequestPolicy becomes a pure exported function module (no class). AuthBroker, TokenStore, SessionMint, AuthCache stay. Plan must add a one-paragraph TokenStore responsibility statement. Shared-cache remedy stays pending."
            },
            {
              "label": "C) 3 parts: also fold TokenStore into AuthCache",
              "description": "RequestPolicy as function; TokenStore's duties absorbed by the AuthCache facade. AuthBroker, SessionMint, AuthCache remain. Shared-cache remedy stays pending."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D3 — Five new classes, or fewer moving parts for the same behavior?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Scope Challenge complexity gate (D1: parallelization deferred; D2: strangler behind flag — both fixed across all options here).\nELI10: The plan adds AuthBroker, TokenStore, SessionMint, AuthCache and RequestPolicy across 12 files (PLAN.md:44-45). Two of those look like ceremony. RequestPolicy is described as stateless with one job: take claims plus tenant context, return allow or deny (PLAN.md:9-13). That is a function, not a class; the author already flagged the boundary as open. TokenStore is never described anywhere, while AuthCache is already \"a facade over that same existing adapter, with one backing cache\" (PLAN.md:20-21). Two cache-shaped classes over one cache is a duplication smell, but I cannot see TokenStore's code, so that one is medium confidence. Every option keeps the same features, contracts and the D1/D2 answers; this is structure only. The shared-mutable-cache problem (PLAN.md:28-29) is a separate Architecture question and stays pending here.\nStakes if we pick wrong: too many classes and every future auth change touches five files and five test suites; too few and you cram unrelated responsibilities together and get a god-object AuthBroker.\nRecommendation: B because RequestPolicy-as-function is a clear win with no downside, while folding TokenStore needs the author to confirm it has no responsibility distinct from AuthCache.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Keep all 5 classes as planned\n  ✅ Every responsibility has a named home; matches the plan the team already discussed\n  ✅ RequestPolicy as a class can grow strategies later without a signature change\n  ❌ A one-method stateless class is premature abstraction; five suites for what is one orchestration path\nB) 4 parts: RequestPolicy becomes a pure exported function; keep TokenStore (recommended)\n  ✅ evaluateRequestPolicy(claims, ctx) is trivially unit-testable with no constructor or mocks\n  ✅ Removes one class and its test scaffolding while touching nothing whose role is unclear\n  ❌ TokenStore's overlap with AuthCache stays unresolved; plan must define TokenStore's distinct job or this becomes a follow-up\nC) 3 parts: RequestPolicy as function AND TokenStore folded into AuthCache\n  ✅ One cache facade, one truth about tenant keys and invalidation; least surface for a shared-state bug\n  ✅ Fewest files and suites to maintain for a change that claims no behavior difference\n  ❌ If TokenStore actually owns something AuthCache does not (e.g. refresh-token persistence), you merge two responsibilities and have to split them again later\nNet: B takes the free simplification now and makes the plan author write down what TokenStore is for before deciding its fate.": "A) Keep all 5 classes"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:47:12.849Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_01WVkmUmFQzEqmiDzAqXVwuQ",
      "questions": [
        {
          "question": "D4 — How should AuthBroker and SessionMint get their shared AuthCache?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Architecture review (D1–D3 fixed).\nELI10: The plan has both new services import one mutable AuthCache object from a module (PLAN.md:28-29). Anything that imports it can change it, tests share it unless someone remembers to reset it, and you cannot hand a service a fake cache without monkey-patching the module. Passing the cache into each service's constructor from one place at startup keeps a single shared cache in production but makes every dependency visible and every test isolated. The cache itself, its tenant keys and invalidation rules do not change under any option.\nStakes if we pick wrong: with the module export, a test that leaks a cached token into the next test passes locally and hides a tenant-isolation bug; in production, any stray importer can mutate auth state with no owner.\nRecommendation: A because it is the Layer 1 answer, costs a constructor parameter per service, and makes the R2 write-ordering fix far easier to place.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Constructor injection from one composition root (recommended)\n  ✅ Every test gets a fresh cache or a fake by passing an argument; no shared state between tests\n  ✅ Dependency is explicit in the type signature; grep shows exactly who can mutate the cache\n  ❌ One more wiring line at startup and a constructor param per service (human: ~1h / CC: ~5 min)\nB) Module export behind a getter with resetForTests()\n  ✅ Minimal change from the plan; import sites stay the same\n  ✅ Tests can reset state between cases\n  ❌ Hidden dependency stays hidden; resetForTests() in production code is a smell and easy to forget to call\nC) Keep module-level mutable export as proposed\n  ✅ Zero extra wiring; shortest path to a working diff\n  ✅ No cons beyond those already named in the plan\n  ❌ Two writers on an unowned global in the auth path; test isolation depends on discipline, not structure\nNet: one constructor parameter buys explicit ownership of auth state and isolated tests.",
          "header": "D4 Cache wiring",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Constructor injection (recommended)",
              "description": "AuthBroker and SessionMint take `cache: AuthCache` in their constructors. One AuthCache instance is built at the composition root and passed to both. The module exports the class/factory, not an instance. Same single backing cache in production."
            },
            {
              "label": "B) Getter + resetForTests()",
              "description": "Keep the module-level instance but access it via `getAuthCache()` and add `resetAuthCacheForTests()`. Services keep importing from the module."
            },
            {
              "label": "C) Keep as proposed",
              "description": "Module-level mutable export, imported and mutated directly by both services."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D4 — How should AuthBroker and SessionMint get their shared AuthCache?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Architecture review (D1–D3 fixed).\nELI10: The plan has both new services import one mutable AuthCache object from a module (PLAN.md:28-29). Anything that imports it can change it, tests share it unless someone remembers to reset it, and you cannot hand a service a fake cache without monkey-patching the module. Passing the cache into each service's constructor from one place at startup keeps a single shared cache in production but makes every dependency visible and every test isolated. The cache itself, its tenant keys and invalidation rules do not change under any option.\nStakes if we pick wrong: with the module export, a test that leaks a cached token into the next test passes locally and hides a tenant-isolation bug; in production, any stray importer can mutate auth state with no owner.\nRecommendation: A because it is the Layer 1 answer, costs a constructor parameter per service, and makes the R2 write-ordering fix far easier to place.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Constructor injection from one composition root (recommended)\n  ✅ Every test gets a fresh cache or a fake by passing an argument; no shared state between tests\n  ✅ Dependency is explicit in the type signature; grep shows exactly who can mutate the cache\n  ❌ One more wiring line at startup and a constructor param per service (human: ~1h / CC: ~5 min)\nB) Module export behind a getter with resetForTests()\n  ✅ Minimal change from the plan; import sites stay the same\n  ✅ Tests can reset state between cases\n  ❌ Hidden dependency stays hidden; resetForTests() in production code is a smell and easy to forget to call\nC) Keep module-level mutable export as proposed\n  ✅ Zero extra wiring; shortest path to a working diff\n  ✅ No cons beyond those already named in the plan\n  ❌ Two writers on an unowned global in the auth path; test isolation depends on discipline, not structure\nNet: one constructor parameter buys explicit ownership of auth state and isolated tests.": "A) Constructor injection (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:49:05.231Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_01CEdCTHbBPHmTwCgexifafv",
      "questions": [
        {
          "question": "D5 — Can a SessionMint write re-cache a token that was just revoked?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Architecture review (D1–D4 fixed).\nELI10: The plan says the cache does not serialize mutations and that two services both write to it (PLAN.md:19, :29). Picture this: a tenant gets suspended and the invalidation hook clears its entries. A millisecond earlier, SessionMint had finished minting a session for that tenant and is about to write it. Its write lands after the clear. Now a suspended tenant has a valid cached token until it expires. I cannot see the adapter, so this is medium confidence: if invalidation bumps the policy-version part of the key, stale writes are already unreachable and this is a non-issue. The fix, if needed, is small and lives entirely in the new AuthCache facade: track an invalidation epoch per tenant and drop writes that carry an old one.\nStakes if we pick wrong: ignore a real race and a revoked or suspended tenant keeps access for one token lifetime; build the guard when the adapter already covers it and you carry ~40 unnecessary lines plus a test.\nRecommendation: A because the guard is cheap, adapter-independent, and makes the facade's safety not depend on an adapter detail nobody has verified; the interleaving test documents the invariant either way.\nCompleteness: A=10/10, B=3/10, C=n/a (investigation approves no implementation)\nPros / cons:\nA) Epoch-guarded writes in the AuthCache facade (recommended)\n  ✅ Revocation/suspension always wins over an in-flight mint write, regardless of adapter internals\n  ✅ Adapter and its tests stay untouched; guard and interleaving test are ~40 lines in new code (human: ~half day / CC: ~10 min)\n  ❌ Slight extra bookkeeping per tenant in the facade; redundant if the adapter already keys invalidations by version\nB) Accept as proposed, document the risk\n  ✅ Zero extra code in this PR\n  ✅ Keeps the facade a pure pass-through as the plan describes\n  ❌ A suspended tenant may retain a cached token for one lifetime; nobody will find this in a unit test\nC) Investigate the adapter first, remedy stays pending\n  ✅ Avoids building a guard the adapter may already provide\n  ✅ Bounded: one read of the adapter's invalidation and key code, then this question returns\n  ❌ Blocks the plan on a probe; if the race is real you end up doing A anyway, later\nNet: ~40 lines in new code versus trusting an unverified adapter detail on the path that decides whether a suspended tenant stays logged in.",
          "header": "D5 Write race",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Epoch-guarded facade writes (recommended)",
              "description": "AuthCache keeps a per-tenant invalidation epoch, bumps it on every invalidation hook, and `put()` drops writes carrying a stale epoch. Add an interleaving test: mint-read → invalidate → mint-write must not re-cache. Adapter unchanged."
            },
            {
              "label": "B) Accept as proposed",
              "description": "No guard. Record \"post-invalidation write race\" as an accepted known risk in the plan."
            },
            {
              "label": "C) Investigate adapter first",
              "description": "Read the adapter's invalidation/key code in the real repo before choosing. R2 remedy stays pending; nothing else changes."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D5 — Can a SessionMint write re-cache a token that was just revoked?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Architecture review (D1–D4 fixed).\nELI10: The plan says the cache does not serialize mutations and that two services both write to it (PLAN.md:19, :29). Picture this: a tenant gets suspended and the invalidation hook clears its entries. A millisecond earlier, SessionMint had finished minting a session for that tenant and is about to write it. Its write lands after the clear. Now a suspended tenant has a valid cached token until it expires. I cannot see the adapter, so this is medium confidence: if invalidation bumps the policy-version part of the key, stale writes are already unreachable and this is a non-issue. The fix, if needed, is small and lives entirely in the new AuthCache facade: track an invalidation epoch per tenant and drop writes that carry an old one.\nStakes if we pick wrong: ignore a real race and a revoked or suspended tenant keeps access for one token lifetime; build the guard when the adapter already covers it and you carry ~40 unnecessary lines plus a test.\nRecommendation: A because the guard is cheap, adapter-independent, and makes the facade's safety not depend on an adapter detail nobody has verified; the interleaving test documents the invariant either way.\nCompleteness: A=10/10, B=3/10, C=n/a (investigation approves no implementation)\nPros / cons:\nA) Epoch-guarded writes in the AuthCache facade (recommended)\n  ✅ Revocation/suspension always wins over an in-flight mint write, regardless of adapter internals\n  ✅ Adapter and its tests stay untouched; guard and interleaving test are ~40 lines in new code (human: ~half day / CC: ~10 min)\n  ❌ Slight extra bookkeeping per tenant in the facade; redundant if the adapter already keys invalidations by version\nB) Accept as proposed, document the risk\n  ✅ Zero extra code in this PR\n  ✅ Keeps the facade a pure pass-through as the plan describes\n  ❌ A suspended tenant may retain a cached token for one lifetime; nobody will find this in a unit test\nC) Investigate the adapter first, remedy stays pending\n  ✅ Avoids building a guard the adapter may already provide\n  ✅ Bounded: one read of the adapter's invalidation and key code, then this question returns\n  ❌ Blocks the plan on a probe; if the race is real you end up doing A anyway, later\nNet: ~40 lines in new code versus trusting an unverified adapter detail on the path that decides whether a suspended tenant stays logged in.": "A) Epoch-guarded facade writes (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:50:41.100Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_01Y2Vo6KveEgcQPR2PE9jRRn",
      "questions": [
        {
          "question": "D6 — How should validateAndDispatch() handle the errors it currently swallows?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Code Quality review (D1–D5 fixed).\nELI10: The plan's new orchestration function is 60 lines with three try/catch blocks nested inside each other, and each one quietly eats a different kind of error (PLAN.md:32-33). At 3am, \"quietly eats\" means the IDP timed out, the user got denied or half-dispatched, and the log says nothing. The user-facing result must stay what it is today; this question is only about making the path explicit: three small steps, one shared error mapper, every failure named in the return type and logged. Anything the code did not anticipate fails closed to a deny instead of vanishing.\nStakes if we pick wrong: a swallowed IDP failure looks identical to a policy deny in production; you cannot tell an outage from a permissions bug, and a partial dispatch after a swallowed error is a security question you cannot answer from logs.\nRecommendation: A because three nested catches doing similar work is a DRY violation with a silent-failure bonus, and the split costs minutes with AI while keeping the user outcome identical.\nCompleteness: A=10/10, B=7/10, C=3/10\nPros / cons:\nA) Three steps + discriminated AuthOutcome + one error mapper (recommended)\n  ✅ Every error class has one named outcome; unknown errors are logged and fail closed, never silent\n  ✅ Each step is unit-testable alone; the DRY mapper replaces three near-identical catch bodies (human: ~1 day / CC: ~20 min)\n  ❌ More small units to read; the return type is a new concept for the team to learn\nB) Keep 3 try/catch, log and rethrow typed AuthError\n  ✅ Minimal restructuring; errors stop being silent\n  ✅ Caller decides the mapping, so behavior stays centralized\n  ❌ Still three nested blocks in one 60-line function; still three copies of near-identical catch logic\nC) Keep as proposed\n  ✅ No extra work in this PR\n  ✅ Matches whatever legacy did, if legacy also swallowed\n  ❌ Silent failures on the auth path; the plan itself lists this as a code-quality problem\nNet: same user result, but you can tell an outage from a deny in the logs and test each step alone.",
          "header": "D6 Error paths",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Split + AuthOutcome + mapper (recommended)",
              "description": "`validate()` → `RequestPolicy.evaluate()` → `dispatch()`, each returning a discriminated `AuthOutcome`. One `mapAuthError()` for all known error classes; unknown → `error{unknown}`, logged with tenant and request id, fails closed to today's deny response."
            },
            {
              "label": "B) Log + rethrow typed AuthError",
              "description": "Keep the three try/catch blocks; each catch logs and rethrows a typed `AuthError`. Caller maps to the same deny."
            },
            {
              "label": "C) Keep as proposed",
              "description": "60 lines, three nested swallowing catches."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D6 — How should validateAndDispatch() handle the errors it currently swallows?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Code Quality review (D1–D5 fixed).\nELI10: The plan's new orchestration function is 60 lines with three try/catch blocks nested inside each other, and each one quietly eats a different kind of error (PLAN.md:32-33). At 3am, \"quietly eats\" means the IDP timed out, the user got denied or half-dispatched, and the log says nothing. The user-facing result must stay what it is today; this question is only about making the path explicit: three small steps, one shared error mapper, every failure named in the return type and logged. Anything the code did not anticipate fails closed to a deny instead of vanishing.\nStakes if we pick wrong: a swallowed IDP failure looks identical to a policy deny in production; you cannot tell an outage from a permissions bug, and a partial dispatch after a swallowed error is a security question you cannot answer from logs.\nRecommendation: A because three nested catches doing similar work is a DRY violation with a silent-failure bonus, and the split costs minutes with AI while keeping the user outcome identical.\nCompleteness: A=10/10, B=7/10, C=3/10\nPros / cons:\nA) Three steps + discriminated AuthOutcome + one error mapper (recommended)\n  ✅ Every error class has one named outcome; unknown errors are logged and fail closed, never silent\n  ✅ Each step is unit-testable alone; the DRY mapper replaces three near-identical catch bodies (human: ~1 day / CC: ~20 min)\n  ❌ More small units to read; the return type is a new concept for the team to learn\nB) Keep 3 try/catch, log and rethrow typed AuthError\n  ✅ Minimal restructuring; errors stop being silent\n  ✅ Caller decides the mapping, so behavior stays centralized\n  ❌ Still three nested blocks in one 60-line function; still three copies of near-identical catch logic\nC) Keep as proposed\n  ✅ No extra work in this PR\n  ✅ Matches whatever legacy did, if legacy also swallowed\n  ❌ Silent failures on the auth path; the plan itself lists this as a code-quality problem\nNet: same user result, but you can tell an outage from a deny in the logs and test each step alone.": "A) Split + AuthOutcome + mapper (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:52:03.460Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_01RpuS5SBB8PgUo8miNXq4mH",
      "questions": [
        {
          "question": "D7 — How do we prove AuthBroker behaves exactly like legacyAuthFlow() before traffic moves?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Test review (D1–D6 fixed). This is the mandatory regression contract: the question is how to cover, not whether.\nELI10: The plan rewrites the login decision path and says outright that the new tests will not check the old behavior (PLAN.md:23-25, :36-37). The stated goal is \"no behavior change\", but nothing would tell you if that were false. Because D2 keeps the old flow alive behind a flag, you can run the old and new code on the same inputs and demand identical answers: same allow/deny, same error response, same cache state. That table of inputs is the contract. Option B pins the old behavior in tests and checks the new code against the same table separately; it catches most drift but not side effects you forgot to list.\nStakes if we pick wrong: a tenant edge case the fixture table misses flips from deny to allow after the flag goes on, and the first signal is a customer.\nRecommendation: A because running both paths on one fixture table is the strongest possible parity check, costs minutes with AI, and self-deletes with the legacy code.\nCompleteness: A=10/10, B=7/10\nPros / cons:\nA) Differential parity suite + characterization anchor (recommended)\n  ✅ Catches any decision, response or cache-state difference on every fixture, including ones nobody thought to assert individually\n  ✅ Doubles as the canary gate: flag flips only when the suite is green (human: ~2 days / CC: ~30 min)\n  ❌ Needs a shared fake IDP harness both paths can run against; one more suite to keep green during the window\nB) Characterization tests on legacy + independent AuthBroker tests on the same table\n  ✅ Simpler harness; each path tested on its own terms\n  ✅ Legacy behavior gets pinned before anyone touches it\n  ❌ Only asserts what you remembered to list; cache side-effect drift between paths can slip through\nNet: the same fixture table either way; A also runs both paths on it and refuses to let them disagree.",
          "header": "D7 Regression",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Differential parity suite (recommended)",
              "description": "Shared fixture table (12+ cases listed in the grid). Each case runs `legacyAuthFlow()` and `AuthBroker.validateAndDispatch()` against the same fake IDP and a fresh `AuthCache`; assert equal decision, response shape and post-call cache state. Characterization tests pin legacy outputs. Suite gates the flag flip and is deleted with legacy."
            },
            {
              "label": "B) Characterization + independent tests",
              "description": "Pin `legacyAuthFlow()` outputs on the fixture table; test `AuthBroker` against the same table separately. No side-by-side execution."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D7 — How do we prove AuthBroker behaves exactly like legacyAuthFlow() before traffic moves?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Test review (D1–D6 fixed). This is the mandatory regression contract: the question is how to cover, not whether.\nELI10: The plan rewrites the login decision path and says outright that the new tests will not check the old behavior (PLAN.md:23-25, :36-37). The stated goal is \"no behavior change\", but nothing would tell you if that were false. Because D2 keeps the old flow alive behind a flag, you can run the old and new code on the same inputs and demand identical answers: same allow/deny, same error response, same cache state. That table of inputs is the contract. Option B pins the old behavior in tests and checks the new code against the same table separately; it catches most drift but not side effects you forgot to list.\nStakes if we pick wrong: a tenant edge case the fixture table misses flips from deny to allow after the flag goes on, and the first signal is a customer.\nRecommendation: A because running both paths on one fixture table is the strongest possible parity check, costs minutes with AI, and self-deletes with the legacy code.\nCompleteness: A=10/10, B=7/10\nPros / cons:\nA) Differential parity suite + characterization anchor (recommended)\n  ✅ Catches any decision, response or cache-state difference on every fixture, including ones nobody thought to assert individually\n  ✅ Doubles as the canary gate: flag flips only when the suite is green (human: ~2 days / CC: ~30 min)\n  ❌ Needs a shared fake IDP harness both paths can run against; one more suite to keep green during the window\nB) Characterization tests on legacy + independent AuthBroker tests on the same table\n  ✅ Simpler harness; each path tested on its own terms\n  ✅ Legacy behavior gets pinned before anyone touches it\n  ❌ Only asserts what you remembered to list; cache side-effect drift between paths can slip through\nNet: the same fixture table either way; A also runs both paths on it and refuses to let them disagree.": "A) Differential parity suite (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:53:23.343Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_018wCvMk3g1AyHpKmVxL5is8",
      "questions": [
        {
          "question": "D8 — Should the flag-routed login flow get end-to-end tests, or stop at integration level?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Test review (D1–D7 fixed).\nELI10: D2 put a switch in front of the login path and D7 proves the two paths agree at the function level. What nothing checks yet is the whole journey a user actually takes: HTTP request comes in, the flag is read, the right path runs, the response goes out. Auth is one of the flows where mocking hides real failures (wrong middleware order, header not forwarded, flag read from the wrong config). Option A adds three end-to-end journeys with a fake identity provider; option B trusts the integration tests at the routing point.\nStakes if we pick wrong: skip E2E and a middleware-order bug lets the flag flip to a path that never sees the tenant header; every test is green and every login fails.\nRecommendation: A because auth flows are the textbook case for E2E, three journeys is a small fixed cost, and they become the canary rehearsal.\nCompleteness: A=10/10, B=7/10\nPros / cons:\nA) Three E2E journeys with fake IDP (recommended)\n  ✅ Exercises the real entrypoint, middleware, flag read and response shape for both paths and the flag-failure fallback\n  ✅ The same journeys are what you run against the canary tenant before widening the flag (human: ~1 day / CC: ~20 min)\n  ❌ Needs an E2E harness with a fake IDP; slower than unit tests, one more thing in CI\nB) Integration tests at the routing point only\n  ✅ Fast, already carried by D2; no new harness\n  ✅ Covers the routing decision itself\n  ❌ Blind to anything between the HTTP edge and the routing function; auth flows are exactly where that gap bites\nNet: three slow tests versus discovering a middleware-order bug from the canary tenant.",
          "header": "D8 E2E depth",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Three E2E journeys (recommended)",
              "description": "Through the real HTTP entrypoint with a fake IDP: flag off → legacy (allow + deny); flag on for tenant T → AuthBroker (allow + deny); flag-read failure → legacy. Marked [→E2E] in the coverage diagram."
            },
            {
              "label": "B) Integration only",
              "description": "Keep the routing-point integration tests from D2. No HTTP-level journeys."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D8 — Should the flag-routed login flow get end-to-end tests, or stop at integration level?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Test review (D1–D7 fixed).\nELI10: D2 put a switch in front of the login path and D7 proves the two paths agree at the function level. What nothing checks yet is the whole journey a user actually takes: HTTP request comes in, the flag is read, the right path runs, the response goes out. Auth is one of the flows where mocking hides real failures (wrong middleware order, header not forwarded, flag read from the wrong config). Option A adds three end-to-end journeys with a fake identity provider; option B trusts the integration tests at the routing point.\nStakes if we pick wrong: skip E2E and a middleware-order bug lets the flag flip to a path that never sees the tenant header; every test is green and every login fails.\nRecommendation: A because auth flows are the textbook case for E2E, three journeys is a small fixed cost, and they become the canary rehearsal.\nCompleteness: A=10/10, B=7/10\nPros / cons:\nA) Three E2E journeys with fake IDP (recommended)\n  ✅ Exercises the real entrypoint, middleware, flag read and response shape for both paths and the flag-failure fallback\n  ✅ The same journeys are what you run against the canary tenant before widening the flag (human: ~1 day / CC: ~20 min)\n  ❌ Needs an E2E harness with a fake IDP; slower than unit tests, one more thing in CI\nB) Integration tests at the routing point only\n  ✅ Fast, already carried by D2; no new harness\n  ✅ Covers the routing decision itself\n  ❌ Blind to anything between the HTTP edge and the routing function; auth flows are exactly where that gap bites\nNet: three slow tests versus discovering a middleware-order bug from the canary tenant.": "A) Three E2E journeys (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:54:45.281Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_0195tWsGC5oW2JSZTgqRnDix",
      "questions": [
        {
          "question": "D9 — Track the deferred IDP parallelization in TODOS.md?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), final planning (D1–D8 fixed).\nELI10: D1 pushed the 5x latency fix to its own PR. Deferred work that is not written down tends to never happen. This question is only about where the reminder lives. Choosing C would reopen D1 and pull the change back into this PR.\nStakes if we pick wrong: the follow-up quietly evaporates and users keep the sequential latency for a year.\nRecommendation: A because it is a real, cheap win that should not depend on someone's memory.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md (recommended)\n  ✅ Durable, visible to the whole team, with the context above attached\n  ✅ Zero engineering cost now; keeps D1 intact\n  ❌ TODOS.md cannot be written in plan mode; content is presented not persisted until you leave plan mode\nB) Skip\n  ✅ Nothing to maintain\n  ✅ Team may already track this elsewhere\n  ❌ Deferred work with no owner and no record\nC) Build it now in this PR\n  ✅ Latency win ships immediately\n  ✅ No follow-up to track\n  ❌ Reopens D1 and makes the refactor PR behavior-changing again\nNet: a paragraph in a file versus an unowned deferral.",
          "header": "D9 TODO perf",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Add to TODOS.md (recommended)",
              "description": "Record the TODO content above in TODOS.md (presented not persisted in plan mode). D1 unchanged."
            },
            {
              "label": "B) Skip",
              "description": "Do not track. D1 unchanged."
            },
            {
              "label": "C) Build now in this PR",
              "description": "Reopen D1 and include parallelization in this PR."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D9 — Track the deferred IDP parallelization in TODOS.md?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), final planning (D1–D8 fixed).\nELI10: D1 pushed the 5x latency fix to its own PR. Deferred work that is not written down tends to never happen. This question is only about where the reminder lives. Choosing C would reopen D1 and pull the change back into this PR.\nStakes if we pick wrong: the follow-up quietly evaporates and users keep the sequential latency for a year.\nRecommendation: A because it is a real, cheap win that should not depend on someone's memory.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md (recommended)\n  ✅ Durable, visible to the whole team, with the context above attached\n  ✅ Zero engineering cost now; keeps D1 intact\n  ❌ TODOS.md cannot be written in plan mode; content is presented not persisted until you leave plan mode\nB) Skip\n  ✅ Nothing to maintain\n  ✅ Team may already track this elsewhere\n  ❌ Deferred work with no owner and no record\nC) Build it now in this PR\n  ✅ Latency win ships immediately\n  ✅ No follow-up to track\n  ❌ Reopens D1 and makes the refactor PR behavior-changing again\nNet: a paragraph in a file versus an unowned deferral.": "A) Add to TODOS.md (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:57:12.689Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_01ShA1DmNGhZypaxGM8Z5yWP",
      "questions": [
        {
          "question": "D10 — Track the legacyAuthFlow() deletion follow-up in TODOS.md?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), final planning (D1–D9 fixed).\nELI10: D2 keeps the old login path alive behind a flag so you can roll back cheaply. The cost is that someone has to remember to delete it afterward, plus the flag and the parity suite. Strangler migrations that nobody finishes are how codebases end up with three auth paths. This question is only about where that reminder lives; C would reopen D2.\nStakes if we pick wrong: the old path lives forever, on-call has to reason about two code paths, and the parity suite keeps burning CI minutes.\nRecommendation: A because the exit criteria are worth writing down now while everyone agrees on them.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md (recommended)\n  ✅ Exit criteria captured while fresh; the deletion has a home\n  ✅ Zero engineering cost; D2 intact\n  ❌ Not persisted in plan mode; presented until you leave plan mode\nB) Skip\n  ✅ Nothing to maintain\n  ✅ Team may track flag cleanup elsewhere\n  ❌ Strangler with no end date is just two code paths\nC) Delete legacy in this PR\n  ✅ No dual-path window at all\n  ✅ No cleanup follow-up\n  ❌ Reopens D2 and removes the cheap rollback on the auth path\nNet: writing down the exit criteria versus trusting that a flag cleanup happens on its own.",
          "header": "D10 TODO legacy",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Add to TODOS.md (recommended)",
              "description": "Record the TODO content above with exit criteria (presented not persisted in plan mode). D2 unchanged."
            },
            {
              "label": "B) Skip",
              "description": "Do not track. D2 unchanged."
            },
            {
              "label": "C) Delete legacy in this PR",
              "description": "Reopen D2 and remove legacyAuthFlow() in this PR."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D10 — Track the legacyAuthFlow() deletion follow-up in TODOS.md?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), final planning (D1–D9 fixed).\nELI10: D2 keeps the old login path alive behind a flag so you can roll back cheaply. The cost is that someone has to remember to delete it afterward, plus the flag and the parity suite. Strangler migrations that nobody finishes are how codebases end up with three auth paths. This question is only about where that reminder lives; C would reopen D2.\nStakes if we pick wrong: the old path lives forever, on-call has to reason about two code paths, and the parity suite keeps burning CI minutes.\nRecommendation: A because the exit criteria are worth writing down now while everyone agrees on them.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md (recommended)\n  ✅ Exit criteria captured while fresh; the deletion has a home\n  ✅ Zero engineering cost; D2 intact\n  ❌ Not persisted in plan mode; presented until you leave plan mode\nB) Skip\n  ✅ Nothing to maintain\n  ✅ Team may track flag cleanup elsewhere\n  ❌ Strangler with no end date is just two code paths\nC) Delete legacy in this PR\n  ✅ No dual-path window at all\n  ✅ No cleanup follow-up\n  ❌ Reopens D2 and removes the cheap rollback on the auth path\nNet: writing down the exit criteria versus trusting that a flag cleanup happens on its own.": "A) Add to TODOS.md (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:57:34.310Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_01MUYRKyK1y2sWGgmEzNhnEN",
      "questions": [
        {
          "question": "D11 — Where does the missing TokenStore definition get written?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), final planning (D1–D10 fixed).\nELI10: The plan lists TokenStore as a new class but never says what it does, while AuthCache already fronts the only cache (PLAN.md:44 vs :20-21). D3 kept the class. Before anyone writes it, someone has to say in one paragraph what it owns, how it relates to AuthCache, and how it is tested. Otherwise the person implementing it guesses, and the likely guess duplicates AuthCache. This is about whether that paragraph is a TODO for later or a gate before implementation.\nStakes if we pick wrong: TokenStore ships as a second cache facade with its own key-building code, and the next invalidation bug has two places to hide.\nRecommendation: C because the definition is a 15-minute writing task that blocks correct implementation and tests; it belongs in this plan, not a backlog.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md\n  ✅ Tracked somewhere durable\n  ✅ Does not block starting the other four classes\n  ❌ TokenStore could be implemented before the TODO is picked up, which defeats the point\nB) Skip\n  ✅ No extra work\n  ✅ Implementer may already know the intent\n  ❌ The one class nobody described gets built from a guess, on the auth path\nC) P1 pre-implementation task in this plan (recommended)\n  ✅ Definition exists before TokenStore code starts; T4 tests become specifiable\n  ✅ Surfaces early whether TokenStore is pure overlap with AuthCache (human: ~15 min / CC: n/a, author knowledge)\n  ❌ Adds a small gate before one of the five classes can begin\nNet: fifteen minutes of writing before code versus a second cache facade nobody asked for.",
          "header": "D11 TokenStore",
          "multiSelect": false,
          "options": [
            {
              "label": "C) P1 task in this plan (recommended)",
              "description": "Plan author writes TokenStore's responsibility, AuthCache relationship and test surface into the working plan before TokenStore implementation starts. Other classes not blocked."
            },
            {
              "label": "A) Add to TODOS.md",
              "description": "Track the definition as a TODO (presented not persisted in plan mode). Implementation not gated."
            },
            {
              "label": "B) Skip",
              "description": "No written definition; implement from intent."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D11 — Where does the missing TokenStore definition get written?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), final planning (D1–D10 fixed).\nELI10: The plan lists TokenStore as a new class but never says what it does, while AuthCache already fronts the only cache (PLAN.md:44 vs :20-21). D3 kept the class. Before anyone writes it, someone has to say in one paragraph what it owns, how it relates to AuthCache, and how it is tested. Otherwise the person implementing it guesses, and the likely guess duplicates AuthCache. This is about whether that paragraph is a TODO for later or a gate before implementation.\nStakes if we pick wrong: TokenStore ships as a second cache facade with its own key-building code, and the next invalidation bug has two places to hide.\nRecommendation: C because the definition is a 15-minute writing task that blocks correct implementation and tests; it belongs in this plan, not a backlog.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md\n  ✅ Tracked somewhere durable\n  ✅ Does not block starting the other four classes\n  ❌ TokenStore could be implemented before the TODO is picked up, which defeats the point\nB) Skip\n  ✅ No extra work\n  ✅ Implementer may already know the intent\n  ❌ The one class nobody described gets built from a guess, on the auth path\nC) P1 pre-implementation task in this plan (recommended)\n  ✅ Definition exists before TokenStore code starts; T4 tests become specifiable\n  ✅ Surfaces early whether TokenStore is pure overlap with AuthCache (human: ~15 min / CC: n/a, author knowledge)\n  ❌ Adds a small gate before one of the five classes can begin\nNet: fifteen minutes of writing before code versus a second cache facade nobody asked for.": "C) P1 task in this plan (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T00:58:02.004Z"
    },
    {
      "sessionId": "4489eb59-47eb-4023-b8a1-abc3adc8969d",
      "toolUseId": "toolu_01CgqbZ4mcMS9ekWteDVmDHv",
      "questions": [
        {
          "question": "D12 — Where next?\nProject/branch/task: gstack-plan-count-cf9goi on `main`; Multi-tenant Auth Refactor plan just cleared eng review.\nELI10: The engineering review is done and clean — every open question has an answer written into the plan, and the implementation tasks T1–T10 are listed with their gates. The only choice left is what you do next: start building, or run another kind of review first. Nothing here changes the plan itself.\nStakes if we pick wrong: Low — this is navigation only; picking a review you don't need costs time, skipping one you did need costs a later rework round.\nRecommendation: A because the plan is a behavior-preserving refactor with no product-scope or UI questions left; T1 (TokenStore definition) is the only thing to write before coding.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Ready to implement — write T1, then start T3/T4/T8/T5 in parallel lanes; run /ship when done (recommended)\n  ✅ All 11 decisions are recorded and every P1 task has a verify step; nothing blocks coding except the T1 paragraph\n  ✅ Leaving plan mode also lets you persist the two accepted TODOS.md items right away\n  ❌ No outside voice reviewed this plan (codex disabled), so the only second read so far is yours\nB) Run /plan-ceo-review first — challenge whether the refactor is worth its 12 files and canary window at all\n  ✅ Catches a scope question this review deliberately did not ask: is the reorganization itself justified\n  ✅ Cheap relative to the ~10 engineering days the task list implies\n  ❌ The plan author already framed this as pure reorganization with no product change, so a CEO pass may just confirm what is written\nC) Enable codex and re-run the outside review — `gstack-config set codex_reviews enabled`, then /plan-eng-review again for the outside pass only\n  ✅ Fills the one empty row in the report: an independent model reading the same plan and ledger\n  ✅ The auth path is security-sensitive; a second read on the fail-closed and epoch-guard logic is cheap insurance\n  ❌ Requires codex to be installed and configured in this environment, which is unverified here\nNet: Build now versus buy a second opinion first — the plan is clean either way, the trade is time against an extra reader on a security-sensitive path.",
          "header": "Next step",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Ready to implement (recommended)",
              "description": "Exit plan mode; write T1; start lanes A–E; persist TODOS.md; /ship when done"
            },
            {
              "label": "B) /plan-ceo-review first",
              "description": "Challenge whether the refactor's scope and canary window are justified before coding"
            },
            {
              "label": "C) Enable codex, outside review",
              "description": "Turn on codex_reviews and get an independent read of the plan and ledger"
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D12 — Where next?\nProject/branch/task: gstack-plan-count-cf9goi on `main`; Multi-tenant Auth Refactor plan just cleared eng review.\nELI10: The engineering review is done and clean — every open question has an answer written into the plan, and the implementation tasks T1–T10 are listed with their gates. The only choice left is what you do next: start building, or run another kind of review first. Nothing here changes the plan itself.\nStakes if we pick wrong: Low — this is navigation only; picking a review you don't need costs time, skipping one you did need costs a later rework round.\nRecommendation: A because the plan is a behavior-preserving refactor with no product-scope or UI questions left; T1 (TokenStore definition) is the only thing to write before coding.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Ready to implement — write T1, then start T3/T4/T8/T5 in parallel lanes; run /ship when done (recommended)\n  ✅ All 11 decisions are recorded and every P1 task has a verify step; nothing blocks coding except the T1 paragraph\n  ✅ Leaving plan mode also lets you persist the two accepted TODOS.md items right away\n  ❌ No outside voice reviewed this plan (codex disabled), so the only second read so far is yours\nB) Run /plan-ceo-review first — challenge whether the refactor is worth its 12 files and canary window at all\n  ✅ Catches a scope question this review deliberately did not ask: is the reorganization itself justified\n  ✅ Cheap relative to the ~10 engineering days the task list implies\n  ❌ The plan author already framed this as pure reorganization with no product change, so a CEO pass may just confirm what is written\nC) Enable codex and re-run the outside review — `gstack-config set codex_reviews enabled`, then /plan-eng-review again for the outside pass only\n  ✅ Fills the one empty row in the report: an independent model reading the same plan and ledger\n  ✅ The auth path is security-sensitive; a second read on the fail-closed and epoch-guard logic is cheap insurance\n  ❌ Requires codex to be installed and configured in this environment, which is unverified here\nNet: Build now versus buy a second opinion first — the plan is clean either way, the trade is time against an extra reader on a security-sensitive path.": "A) Ready to implement (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-17T01:04:57.056Z"
    }
  ],
  "report": "# Plan: Multi-tenant Auth Refactor — Reviewed Implementation Plan\n\nReviewed by `/plan-eng-review` on 2026-09-17. Target: `PLAN.md` (\"Plan: Multi-tenant Auth Refactor\") on branch `main`, commit `7d4af5b`.\nReport file: this document (user-requested destination).\n\n**Evidence note.** The review target repository contains only `CLAUDE.md` and `PLAN.md`. None of the code the plan describes (`validateAndDispatch()`, `legacyAuthFlow()`, the cache adapter, the IDP calls) is present, and no test framework is detected. Every finding is calibrated against the plan text (`PLAN.md:line`). Every \"Runtime evidence\" field below is **unknown**; nothing here was verified against running code.\n\n---\n\n## Working plan (original plan, amended only by accepted decisions)\n\n### Context supplied by the plan author (PLAN.md:7-13, unchanged)\nThe goal is to reorganize existing tenant-auth orchestration without changing its product behavior. RequestPolicy groups the existing per-request access decision: given already-fetched claims and tenant/request context, it returns allow or deny under the existing access policy. `AuthBroker.validateAndDispatch()` calls it after validation and before dispatch. It adds no policy, network call, cache mutation or state. Its separate class boundary was flagged for review; **D3 kept it as a class.**\n\n### Existing contracts retained (PLAN.md:15-25, unchanged)\nThe existing cache adapter keys entries by tenant ID, issuer, audience, and policy version. It evicts expired tokens and invalidates entries on logout, token revocation, or tenant suspension. AuthCache retains these unchanged validity and tenant-key rules; they do not serialize mutations. AuthCache is a service-facing facade over that same existing adapter, with one backing cache. The adapter, its invalidation hooks, and their existing tests remain in use unchanged.\nUnit and integration coverage is planned for the new components and their success/error paths. As originally written, that coverage does not exercise `legacyAuthFlow()` or assert compatibility with its prior behavior — superseded by the regression contract in Tests below (D7=A).\n\n### Scope decisions accepted at the complexity gate\n- **D1 = A (accepted):** Promise.all parallelization of the 5 IDP calls is **deferred to an immediate follow-up PR**. This PR stays structural only. Recorded under NOT in scope.\n- **D2 = A (accepted):** `legacyAuthFlow()` is **not deleted in this PR**. `AuthBroker` lands beside it; a feature flag routes traffic (default off, then per-tenant canary). Deleting `legacyAuthFlow()` is a named follow-up task. Necessary common work carried with this answer: flag definition, the single routing point, and tests that the flag routes to each path.\n- **D3 = A (accepted):** All five new classes stay: `AuthBroker`, `TokenStore`, `SessionMint`, `AuthCache`, `RequestPolicy`. Structure is fixed; remedies below vary behavior/mechanics only.\n\n### Architecture (PLAN.md:27-29, amended by D4, D5 and D11)\nOriginal: two new services (`AuthBroker` and `SessionMint`) share a global mutable `AuthCache` instance via module-level export. Both services mutate it.\n**Amended (D4=A):** `AuthBroker` and `SessionMint` receive `cache: AuthCache` through their constructors. One `AuthCache` is built at the composition root and passed to both; the module exports the class/factory, not an instance. Both services still write to the one backing cache.\n**Amended (D5=A):** `AuthCache.put()` is epoch-guarded. The facade keeps a per-tenant invalidation epoch, bumps it whenever an existing invalidation hook fires (logout, revocation, suspension), and drops any write that carries an older epoch. `SessionMint` reads the epoch at mint start and passes it with its write. The adapter itself is untouched; an interleaving test (mint-read → invalidate → mint-write is not re-cached) is part of this work.\n**Pre-implementation task (D11=C, P1):** before any `TokenStore` code is written, the plan author adds a paragraph here defining `TokenStore`'s responsibility, its relationship to `AuthCache` (what it holds that the cache does not, who writes through whom), and its test surface. `TokenStore` and its tests are blocked on that paragraph; `AuthBroker`, `SessionMint`, `AuthCache` and `RequestPolicy` are not. If the definition turns out to be a second wrapper over the same adapter, reopen D3.\n\n### Code quality (PLAN.md:31-33, amended by D6)\nOriginal: the `validateAndDispatch()` function is 60 lines with three nested try/catch blocks; each catch swallows a different error class.\n**Amended (D6=A):** `validateAndDispatch()` orchestrates `validate()` → `RequestPolicy.evaluate()` → `dispatch()`. Each step returns a discriminated `AuthOutcome` (`allowed` | `denied{reason}` | `error{kind}`). A single `mapAuthError()` maps known error classes; unknown errors become `error{unknown}`, logged with tenant and request id, and fail closed to today's deny response. No swallowing, no nested try/catch.\n\n```\nvalidateAndDispatch(req)\n  │\n  ├─ validate(req) ──────────────► AuthOutcome\n  │     ├─ cache hit  → claims               │ error{expired|revoked|idp_timeout|idp_5xx|malformed}\n  │     └─ cache miss → IDP (5 calls, seq.)  │        └─► mapAuthError() → log(tenant, reqId) → deny\n  │           └─ AuthCache.put(claims, epoch)  (dropped if epoch stale, D5)\n  ├─ RequestPolicy.evaluate(claims, ctx) ─► allowed | denied{reason}\n  └─ dispatch(outcome) ───────────────────► response (same shape as legacy)\n```\n\n### Tests (PLAN.md:35-37, amended by D2, D7 and D8)\n`legacyAuthFlow()` stays callable behind the flag during the strangler window (D2=A).\n**Regression contract (D7=A, CRITICAL):** differential parity suite on a shared fixture table (happy allow; policy deny; expired token; revoked token; suspended tenant; unknown issuer; audience mismatch; policy-version bump; cache hit vs miss; IDP timeout; IDP 5xx; malformed claims). Each case runs both `legacyAuthFlow()` and `AuthBroker.validateAndDispatch()` against the same fake IDP and a fresh `AuthCache`; asserts equal decision, response shape and post-call cache state. Characterization tests pin legacy outputs. Suite gates the flag flip and is deleted with legacy.\nPlanned unit/integration coverage for new components (PLAN.md:23-24) stands, extended by the common work of D4 (fresh/fake cache per test), D5 (interleaving test), D6 (per-step and mapper tests), D2 (flag routing tests).\n**E2E (D8=A):** three HTTP-level journeys against the real entrypoint with the fake IDP: (1) flag off → `legacyAuthFlow()` allow and deny; (2) flag on for tenant T → `AuthBroker` allow and deny; (3) flag read failure → legacy path still serves login. Everything else stays at unit/integration level.\nTest framework: unknown in this repo (no manifests or test files present); use whatever the real repo already runs.\n\n### Performance (PLAN.md:39-41, amended by D1)\nToken validation issues 5 sequential API calls to the IDP. Parallelization is deferred to a follow-up PR (D1).\n\n### Scale (PLAN.md:43-45, resolved by D3)\n12 files, 5 new classes. Complexity gate resolved: structure kept as planned.\n\n---\n\n## Step 0: Scope Challenge\n\n**Reuse check.** The plan reuses the existing cache adapter, its 4-tuple keying, invalidation hooks and tests (PLAN.md:16-22). `legacyAuthFlow()` was the one existing thing slated for removal; D2 converts that to a strangler.\n\n**Minimum change.** `AuthBroker` + `AuthCache` facade + `SessionMint` achieve the stated goal. `RequestPolicy` class and `TokenStore` are optional structure (kept per D3). Promise.all was a behavior change riding along (deferred per D1).\n\n**Search check** (Aside unavailable; host WebSearch used):\n- **[Layer 1]** Module-level mutable singletons with multiple writers are the documented anti-pattern: state leaks between tests, hard to replace, request-scoped data can persist across requests. Standard remedy: build the instance once at a composition root and pass it in (no DI framework needed). Sources: https://thelazyweb.dev/modules , https://blog.openreplay.com/singletons-javascript-tool-trap/ , https://www.patterns.dev/vanilla/singleton-pattern/\n- **[Layer 1]** `Promise.all` is fail-fast: first rejection wins, remaining results are discarded, error ordering differs from sequential. Relevant to the deferred follow-up PR. Sources: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all , https://andrewusher.dev/blog/promise-all-vs-promise-allsettled\n\n**Complexity check:** 12 files, 5 new classes → gate tripped; resolved via D1–D3 above.\n**TODOS cross-reference:** no `TODOS.md` exists in the target repo.\n**Completeness check:** applied per finding below.\n**Distribution check:** N/A (internal services, no new distributable artifact).\n\n### Scope Challenge findings\n\n| # | Sev | Conf | Where | Finding | Disposition |\n|---|---|---|---|---|---|\n| S1 | P1 | 8/10 | PLAN.md:39-41 vs :8-9 | Promise.all parallelization is a behavior change (error ordering, fail-fast, IDP load shape) bundled into a \"no behavior change\" refactor. | **accepted → deferred to follow-up PR (D1=A)** |\n| S2 | P1 | 8/10 | PLAN.md:36-37 | Big-bang rewrite/delete of `legacyAuthFlow()` with no soft rollback. | **accepted → strangler behind flag (D2=A)** |\n| S3 | P2 | 7/10 | PLAN.md:9-13, :44 | `RequestPolicy` is stateless with one decision; class boundary is ceremony. | **rejected → class kept (D3=A)** |\n| S4 | P2 | 5/10 | PLAN.md:44 vs :20-21 | `TokenStore` undescribed; overlaps `AuthCache` facade over one backing cache. Medium confidence. | **rejected as structure (D3=A)**; plan should still document TokenStore's responsibility (TODO candidate) |\n| S5 | info | 9/10 | repo | No source in target; runtime evidence unknown throughout. | recorded |\n\nScope Challenge result: **scope reduced per recommendation** (D1 deferral, D2 strangler); structure accepted as planned (D3).\n\n---\n\n## Decision ledger\n\n### R1: AuthCache wiring — module-level mutable export vs constructor injection\nFinding: A1, P1, confidence 8/10, PLAN.md:28-29 (\"share a global mutable `AuthCache` instance via module-level export. Both services mutate it.\"), reviewer: Claude (native, plan-eng-review)\nPlan baseline: original proposal — module-level exported mutable `AuthCache` singleton, mutated by both `AuthBroker` and `SessionMint`. No prior approval.\nRuntime evidence: unknown — no source in target repo; the wiring is stated by the plan text only.\nComparison grid:\n\n| Choice | Current | A | B | C |\n|---|---|---|---|---|\n| R1 AuthCache wiring | module-level mutable export (proposed) | constructor injection: `new AuthBroker({ cache })`, `new SessionMint({ cache })`; one instance built at the composition root; module exports the class/factory only | keep module export but expose it through a getter plus `resetForTests()`; services still import it | keep module-level mutable export as proposed |\n| One backing cache (PLAN.md:20-21) | fixed | fixed | fixed | fixed |\n| Adapter keying/invalidation (PLAN.md:16-19) | fixed | fixed | fixed | fixed |\n| R2 concurrent-write ordering | pending | pending | pending | pending |\n| D1/D2/D3 | approved | fixed | fixed | fixed |\n\nQuestion D4:\nD4 — How should AuthBroker and SessionMint get their shared AuthCache?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Architecture review (D1–D3 fixed).\nELI10: The plan has both new services import one mutable AuthCache object from a module (PLAN.md:28-29). Anything that imports it can change it, tests share it unless someone remembers to reset it, and you cannot hand a service a fake cache without monkey-patching the module. Passing the cache into each service's constructor from one place at startup keeps a single shared cache in production but makes every dependency visible and every test isolated. The cache itself, its tenant keys and invalidation rules do not change under any option.\nStakes if we pick wrong: with the module export, a test that leaks a cached token into the next test passes locally and hides a tenant-isolation bug; in production, any stray importer can mutate auth state with no owner.\nRecommendation: A because it is the Layer 1 answer, costs a constructor parameter per service, and makes the R2 write-ordering fix far easier to place.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Constructor injection from one composition root (recommended)\n  ✅ Every test gets a fresh cache or a fake by passing an argument; no shared state between tests\n  ✅ Dependency is explicit in the type signature; grep shows exactly who can mutate the cache\n  ❌ One more wiring line at startup and a constructor param per service (human: ~1h / CC: ~5 min)\nB) Module export behind a getter with resetForTests()\n  ✅ Minimal change from the plan; import sites stay the same\n  ✅ Tests can reset state between cases\n  ❌ Hidden dependency stays hidden; resetForTests() in production code is a smell and easy to forget to call\nC) Keep module-level mutable export as proposed\n  ✅ Zero extra wiring; shortest path to a working diff\n  ✅ No cons beyond those already named in the plan\n  ❌ Two writers on an unowned global in the auth path; test isolation depends on discipline, not structure\nNet: one constructor parameter buys explicit ownership of auth state and isolated tests.\nHeader: D4 Cache wiring\nOptions:\nA) Constructor injection (recommended)\nAuthBroker and SessionMint take `cache: AuthCache` in their constructors. One AuthCache instance is built at the composition root and passed to both. The module exports the class/factory, not an instance. Same single backing cache in production.\nB) Getter + resetForTests()\nKeep the module-level instance but access it via `getAuthCache()` and add `resetAuthCacheForTests()`. Services keep importing from the module.\nC) Keep as proposed\nModule-level mutable export, imported and mutated directly by both services.\n\nState: approved\nActual answer: A) Constructor injection — answered at D4\nAccepted scope: `AuthBroker` and `SessionMint` take `cache: AuthCache` as a constructor dependency. Exactly one `AuthCache` instance is constructed at the composition root and passed to both. The `AuthCache` module exports the class (or a factory), never an instance. Production keeps one backing cache (PLAN.md:20-21). Common work carried: constructor signatures, composition-root wiring, and unit tests that construct each service with a fresh/fake cache.\nHistory: none\n\n### R2: Concurrent cache writes — mint write racing an invalidation\nFinding: A2, P1, confidence 6/10 (medium — verify this is actually an issue), PLAN.md:19 (\"they do not serialize mutations\") + PLAN.md:29 (\"Both services mutate it\") + PLAN.md:17-18 (invalidation on logout, token revocation, tenant suspension), reviewer: Claude (native, plan-eng-review)\nPlan baseline: original proposal — two writers (`AuthBroker`, `SessionMint`) on one unserialized cache, with adapter-level invalidation hooks firing independently. No prior approval. R1 (D4=A) fixes wiring only; it does not order writes.\nRuntime evidence: unknown — adapter source not in target repo. The interleaving is inferred from the plan's own statements; whether the adapter's invalidation bumps the policy-version key component (which would make stale writes unreachable) is unverified.\nComparison grid:\n\n| Choice | Current | A | B | C |\n|---|---|---|---|---|\n| R2 write-after-invalidate protection | none specified (proposed) | `AuthCache.put()` is epoch-guarded: the facade records a per-tenant invalidation epoch, bumps it on every invalidation hook (logout/revocation/suspension), and a write carrying an older epoch is a no-op. Plus an interleaving test. | keep as proposed; document the race as an accepted risk in the plan | bounded investigation in the real repo: read the adapter's invalidation and key code to confirm whether a post-invalidation write is reachable; R2 remedy stays pending; proposal unchanged |\n| R1 wiring (D4=A) | approved | fixed | fixed | fixed |\n| Adapter keying/invalidation hooks unchanged (PLAN.md:16-22) | fixed | fixed (guard lives in the facade, adapter untouched) | fixed | fixed |\n| D1/D2/D3 | approved | fixed | fixed | fixed |\n\nQuestion D5:\nD5 — Can a SessionMint write re-cache a token that was just revoked?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Architecture review (D1–D4 fixed).\nELI10: The plan says the cache does not serialize mutations and that two services both write to it (PLAN.md:19, :29). Picture this: a tenant gets suspended and the invalidation hook clears its entries. A millisecond earlier, SessionMint had finished minting a session for that tenant and is about to write it. Its write lands after the clear. Now a suspended tenant has a valid cached token until it expires. I cannot see the adapter, so this is medium confidence: if invalidation bumps the policy-version part of the key, stale writes are already unreachable and this is a non-issue. The fix, if needed, is small and lives entirely in the new AuthCache facade: track an invalidation epoch per tenant and drop writes that carry an old one.\nStakes if we pick wrong: ignore a real race and a revoked or suspended tenant keeps access for one token lifetime; build the guard when the adapter already covers it and you carry ~40 unnecessary lines plus a test.\nRecommendation: A because the guard is cheap, adapter-independent, and makes the facade's safety not depend on an adapter detail nobody has verified; the interleaving test documents the invariant either way.\nCompleteness: A=10/10, B=3/10, C=n/a (investigation approves no implementation)\nPros / cons:\nA) Epoch-guarded writes in the AuthCache facade (recommended)\n  ✅ Revocation/suspension always wins over an in-flight mint write, regardless of adapter internals\n  ✅ Adapter and its tests stay untouched; guard and interleaving test are ~40 lines in new code (human: ~half day / CC: ~10 min)\n  ❌ Slight extra bookkeeping per tenant in the facade; redundant if the adapter already keys invalidations by version\nB) Accept as proposed, document the risk\n  ✅ Zero extra code in this PR\n  ✅ Keeps the facade a pure pass-through as the plan describes\n  ❌ A suspended tenant may retain a cached token for one lifetime; nobody will find this in a unit test\nC) Investigate the adapter first, remedy stays pending\n  ✅ Avoids building a guard the adapter may already provide\n  ✅ Bounded: one read of the adapter's invalidation and key code, then this question returns\n  ❌ Blocks the plan on a probe; if the race is real you end up doing A anyway, later\nNet: ~40 lines in new code versus trusting an unverified adapter detail on the path that decides whether a suspended tenant stays logged in.\nHeader: D5 Write race\nOptions:\nA) Epoch-guarded facade writes (recommended)\nAuthCache keeps a per-tenant invalidation epoch, bumps it on every invalidation hook, and `put()` drops writes carrying a stale epoch. Add an interleaving test: mint-read → invalidate → mint-write must not re-cache. Adapter unchanged.\nB) Accept as proposed\nNo guard. Record \"post-invalidation write race\" as an accepted known risk in the plan.\nC) Investigate adapter first\nRead the adapter's invalidation/key code in the real repo before choosing. R2 remedy stays pending; nothing else changes.\n\nState: approved\nActual answer: A) Epoch-guarded facade writes — answered at D5\nAccepted scope: `AuthCache` keeps a per-tenant invalidation epoch, bumps it on every invalidation hook (logout, token revocation, tenant suspension), and `put()` drops a write whose epoch is older than the tenant's current epoch. Adapter and its tests unchanged. Common work carried: the epoch bookkeeping in the facade, wiring the existing invalidation hooks to bump it, and an interleaving test (mint-read → invalidate → mint-write must not re-cache).\nHistory: none\n\n### R3: validateAndDispatch() error handling — three nested swallowing catches\nFinding: C1, P1, confidence 8/10, PLAN.md:32-33 (\"60 lines with three nested try/catch blocks; each catch swallows a different error class\"), reviewer: Claude (native, plan-eng-review)\nPlan baseline: original proposal — one 60-line function, three nested try/catch, each catch absorbs a different error class. No prior approval. Goal constraint fixed: same observable allow/deny result as today (PLAN.md:8-9).\nRuntime evidence: unknown — function not in target repo; structure is stated by the plan text. What each swallowed error currently turns into (deny? continue? partial dispatch?) is unverified.\nComparison grid:\n\n| Choice | Current | A | B | C |\n|---|---|---|---|---|\n| R3 error handling shape | 3 nested try/catch, each swallows one error class (proposed) | split into `validate()` → `RequestPolicy.evaluate()` → `dispatch()`; each step returns a discriminated `AuthOutcome` (`allowed` / `denied{reason}` / `error{kind}`); one `mapAuthError()` maps every known error class to an explicit outcome; unknown errors become `error{unknown}`, logged with tenant+request id; `error` outcomes fail closed to the same user-facing deny legacy produces | keep the 3 try/catch blocks; each catch logs and rethrows a typed `AuthError`; caller maps to deny | keep as proposed |\n| Observable allow/deny result (PLAN.md:8-9) | fixed | fixed (fail closed = deny) | fixed | fixed |\n| RequestPolicy called after validation, before dispatch (PLAN.md:11-12) | fixed | fixed | fixed | fixed |\n| D1–D5 | approved | fixed | fixed | fixed |\n\nQuestion D6:\nD6 — How should validateAndDispatch() handle the errors it currently swallows?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Code Quality review (D1–D5 fixed).\nELI10: The plan's new orchestration function is 60 lines with three try/catch blocks nested inside each other, and each one quietly eats a different kind of error (PLAN.md:32-33). At 3am, \"quietly eats\" means the IDP timed out, the user got denied or half-dispatched, and the log says nothing. The user-facing result must stay what it is today; this question is only about making the path explicit: three small steps, one shared error mapper, every failure named in the return type and logged. Anything the code did not anticipate fails closed to a deny instead of vanishing.\nStakes if we pick wrong: a swallowed IDP failure looks identical to a policy deny in production; you cannot tell an outage from a permissions bug, and a partial dispatch after a swallowed error is a security question you cannot answer from logs.\nRecommendation: A because three nested catches doing similar work is a DRY violation with a silent-failure bonus, and the split costs minutes with AI while keeping the user outcome identical.\nCompleteness: A=10/10, B=7/10, C=3/10\nPros / cons:\nA) Three steps + discriminated AuthOutcome + one error mapper (recommended)\n  ✅ Every error class has one named outcome; unknown errors are logged and fail closed, never silent\n  ✅ Each step is unit-testable alone; the DRY mapper replaces three near-identical catch bodies (human: ~1 day / CC: ~20 min)\n  ❌ More small units to read; the return type is a new concept for the team to learn\nB) Keep 3 try/catch, log and rethrow typed AuthError\n  ✅ Minimal restructuring; errors stop being silent\n  ✅ Caller decides the mapping, so behavior stays centralized\n  ❌ Still three nested blocks in one 60-line function; still three copies of near-identical catch logic\nC) Keep as proposed\n  ✅ No extra work in this PR\n  ✅ Matches whatever legacy did, if legacy also swallowed\n  ❌ Silent failures on the auth path; the plan itself lists this as a code-quality problem\nNet: same user result, but you can tell an outage from a deny in the logs and test each step alone.\nHeader: D6 Error paths\nOptions:\nA) Split + AuthOutcome + mapper (recommended)\n`validate()` → `RequestPolicy.evaluate()` → `dispatch()`, each returning a discriminated `AuthOutcome`. One `mapAuthError()` for all known error classes; unknown → `error{unknown}`, logged with tenant and request id, fails closed to today's deny response.\nB) Log + rethrow typed AuthError\nKeep the three try/catch blocks; each catch logs and rethrows a typed `AuthError`. Caller maps to the same deny.\nC) Keep as proposed\n60 lines, three nested swallowing catches.\n\nState: approved\nActual answer: A) Split + AuthOutcome + mapper — answered at D6\nAccepted scope: `validateAndDispatch()` becomes an orchestrator over three steps: `validate()` → `RequestPolicy.evaluate()` → `dispatch()`. Each step returns a discriminated `AuthOutcome` (`allowed` | `denied{reason}` | `error{kind}`). One `mapAuthError()` maps every known error class to an explicit outcome; unknown errors become `error{unknown}`, logged with tenant id and request id. `error` outcomes fail closed to the same user-facing deny response legacy produces today; no user-visible behavior change. Common work carried: the three step functions, the `AuthOutcome` type, the mapper, and unit tests for each step's success/deny/error branches and for the mapper's per-class mapping.\nHistory: none\n\n### R4: Regression contract for legacyAuthFlow() (REGRESSION RULE — mandatory)\nFinding: T1, P1 (CRITICAL), confidence 9/10, PLAN.md:23-25 (\"That coverage does not exercise legacyAuthFlow() or assert compatibility with its prior behavior\") + PLAN.md:36-37 (\"no regression test for the prior behavior is planned\"), reviewer: Claude (native, plan-eng-review)\nPlan baseline: original proposal — no regression coverage. D2=A keeps `legacyAuthFlow()` callable behind a flag during the strangler window, which makes side-by-side verification possible; it did not approve any test contract.\nRuntime evidence: unknown — `legacyAuthFlow()` and its callers are not in the target repo. Callers at risk (from plan text): every request entering tenant auth; the flag's routing point (D2) becomes the single caller of both paths.\nBehavior to preserve: allow/deny decision for each (tenant, issuer, audience, policy version, claims, request context); cache hit/miss/write/invalidation side effects; user-facing responses for expired token, revoked token, suspended tenant, unknown issuer/audience, IDP failure/timeout.\nIntentional differences in this PR: none user-visible. Internal only: structured logging of error outcomes (D6), epoch guard on writes (D5), constructor wiring (D4).\nComparison grid:\n\n| Choice | Current | A | B |\n|---|---|---|---|\n| R4 regression coverage form | none (proposed) | differential parity suite: one shared fixture table of auth cases; for each case run `legacyAuthFlow()` and `AuthBroker.validateAndDispatch()` against identical fake IDP + fresh `AuthCache`; assert equal decision, equal response shape, equal cache state after. Plus characterization tests pinning legacy's outputs so the fixture table itself is anchored. Runs in CI for the whole strangler window; deleted with legacy. | characterization tests pinning `legacyAuthFlow()` outputs on the same fixture table; `AuthBroker` tests assert against that table independently; no side-by-side run |\n| Fixture cases (both options) | — | happy allow; policy deny; expired token; revoked token; suspended tenant; unknown issuer; audience mismatch; policy-version bump; cache hit vs miss; IDP timeout; IDP 5xx; malformed claims | same |\n| D1–D6 | approved | fixed | fixed |\n\nQuestion D7:\nD7 — How do we prove AuthBroker behaves exactly like legacyAuthFlow() before traffic moves?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Test review (D1–D6 fixed). This is the mandatory regression contract: the question is how to cover, not whether.\nELI10: The plan rewrites the login decision path and says outright that the new tests will not check the old behavior (PLAN.md:23-25, :36-37). The stated goal is \"no behavior change\", but nothing would tell you if that were false. Because D2 keeps the old flow alive behind a flag, you can run the old and new code on the same inputs and demand identical answers: same allow/deny, same error response, same cache state. That table of inputs is the contract. Option B pins the old behavior in tests and checks the new code against the same table separately; it catches most drift but not side effects you forgot to list.\nStakes if we pick wrong: a tenant edge case the fixture table misses flips from deny to allow after the flag goes on, and the first signal is a customer.\nRecommendation: A because running both paths on one fixture table is the strongest possible parity check, costs minutes with AI, and self-deletes with the legacy code.\nCompleteness: A=10/10, B=7/10\nPros / cons:\nA) Differential parity suite + characterization anchor (recommended)\n  ✅ Catches any decision, response or cache-state difference on every fixture, including ones nobody thought to assert individually\n  ✅ Doubles as the canary gate: flag flips only when the suite is green (human: ~2 days / CC: ~30 min)\n  ❌ Needs a shared fake IDP harness both paths can run against; one more suite to keep green during the window\nB) Characterization tests on legacy + independent AuthBroker tests on the same table\n  ✅ Simpler harness; each path tested on its own terms\n  ✅ Legacy behavior gets pinned before anyone touches it\n  ❌ Only asserts what you remembered to list; cache side-effect drift between paths can slip through\nNet: the same fixture table either way; A also runs both paths on it and refuses to let them disagree.\nHeader: D7 Regression\nOptions:\nA) Differential parity suite (recommended)\nShared fixture table (12+ cases listed in the grid). Each case runs `legacyAuthFlow()` and `AuthBroker.validateAndDispatch()` against the same fake IDP and a fresh `AuthCache`; assert equal decision, response shape and post-call cache state. Characterization tests pin legacy outputs. Suite gates the flag flip and is deleted with legacy.\nB) Characterization + independent tests\nPin `legacyAuthFlow()` outputs on the fixture table; test `AuthBroker` against the same table separately. No side-by-side execution.\n\nState: approved\nActual answer: A) Differential parity suite — answered at D7\nAccepted scope: **CRITICAL regression contract.** A shared fixture table (minimum: happy allow; policy deny; expired token; revoked token; suspended tenant; unknown issuer; audience mismatch; policy-version bump; cache hit vs miss; IDP timeout; IDP 5xx; malformed claims). For each case, run `legacyAuthFlow()` and `AuthBroker.validateAndDispatch()` against the same fake IDP and a fresh `AuthCache`; assert equal decision, equal response shape, equal post-call cache state. Characterization tests pin `legacyAuthFlow()` outputs on the same table. The suite runs in CI for the whole strangler window, gates the flag flip, and is deleted together with `legacyAuthFlow()`. Common work carried: the fake IDP harness, fixture table, parity runner, characterization tests.\nHistory: none\n\n### R5: E2E depth for the flag-routed login flow\nFinding: T2, P2, confidence 7/10, D2=A routing flag + PLAN.md:8 (tenant-auth orchestration is the login path), reviewer: Claude (native, plan-eng-review)\nPlan baseline: D2=A approved unit/integration tests that the flag routes to each path. No E2E depth approved. R4 (D7=A) covers decision parity at the function level, not the HTTP entrypoint.\nRuntime evidence: unknown — no HTTP layer visible in the target repo; whether an E2E harness already exists is unverified.\nComparison grid:\n\n| Choice | Current | A | B |\n|---|---|---|---|\n| R5 E2E depth for flag-routed login | none (integration only, per D2) | two E2E journeys through the real HTTP entrypoint with a fake IDP: (1) flag off → legacy path → allow and deny cases; (2) flag on for tenant T → AuthBroker path → same allow and deny cases; plus one journey for flag-read failure → legacy | integration tests only at the routing point; no HTTP-level journey |\n| D1–D7 | approved | fixed | fixed |\n\nQuestion D8:\nD8 — Should the flag-routed login flow get end-to-end tests, or stop at integration level?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), Test review (D1–D7 fixed).\nELI10: D2 put a switch in front of the login path and D7 proves the two paths agree at the function level. What nothing checks yet is the whole journey a user actually takes: HTTP request comes in, the flag is read, the right path runs, the response goes out. Auth is one of the flows where mocking hides real failures (wrong middleware order, header not forwarded, flag read from the wrong config). Option A adds three end-to-end journeys with a fake identity provider; option B trusts the integration tests at the routing point.\nStakes if we pick wrong: skip E2E and a middleware-order bug lets the flag flip to a path that never sees the tenant header; every test is green and every login fails.\nRecommendation: A because auth flows are the textbook case for E2E, three journeys is a small fixed cost, and they become the canary rehearsal.\nCompleteness: A=10/10, B=7/10\nPros / cons:\nA) Three E2E journeys with fake IDP (recommended)\n  ✅ Exercises the real entrypoint, middleware, flag read and response shape for both paths and the flag-failure fallback\n  ✅ The same journeys are what you run against the canary tenant before widening the flag (human: ~1 day / CC: ~20 min)\n  ❌ Needs an E2E harness with a fake IDP; slower than unit tests, one more thing in CI\nB) Integration tests at the routing point only\n  ✅ Fast, already carried by D2; no new harness\n  ✅ Covers the routing decision itself\n  ❌ Blind to anything between the HTTP edge and the routing function; auth flows are exactly where that gap bites\nNet: three slow tests versus discovering a middleware-order bug from the canary tenant.\nHeader: D8 E2E depth\nOptions:\nA) Three E2E journeys (recommended)\nThrough the real HTTP entrypoint with a fake IDP: flag off → legacy (allow + deny); flag on for tenant T → AuthBroker (allow + deny); flag-read failure → legacy. Marked [→E2E] in the coverage diagram.\nB) Integration only\nKeep the routing-point integration tests from D2. No HTTP-level journeys.\n\nState: approved\nActual answer: A) Three E2E journeys — answered at D8\nAccepted scope: Three end-to-end journeys through the real HTTP entrypoint against a fake IDP: (1) flag off → `legacyAuthFlow()` → allow and deny cases; (2) flag on for tenant T → `AuthBroker` → allow and deny cases; (3) flag read/parse failure → `legacyAuthFlow()`. These are the canary rehearsal before widening the flag. Common work carried: E2E harness with fake IDP (shared with the D7 parity suite where possible).\nHistory: none\n\n### R6: TODO — Promise.all IDP parallelization follow-up PR\nFinding: S1/PF1, P2, confidence 8/10, PLAN.md:39-41, reviewer: Claude (native, plan-eng-review)\nPlan baseline: D1=A deferred parallelization to an immediate follow-up PR. Tracking mechanism not yet decided.\nRuntime evidence: unknown — IDP call independence unverified.\nTODO content:\n- What: Parallelize the 5 IDP calls in `validate()` behind `AuthBroker`, in a dedicated PR.\n- Why: ~5x avoidable latency on every cache-miss validation.\n- Pros: Real user-visible latency win; isolated PR bisects cleanly.\n- Cons: Fail-fast semantics and IDP burst load need their own tests; calls may not all be independent.\n- Context: Deferred by D1 in the 2026-09-17 eng review so the refactor PR stays behavior-preserving. Start in `AuthBroker.validate()`; map per-call errors via `mapAuthError()` (D6); decide `Promise.all` vs `allSettled` per call; check IDP rate limits.\n- Depends on / blocked by: refactor PR merged and flag on for at least one canary tenant.\nComparison grid:\n\n| Choice | Current | A | B | C |\n|---|---|---|---|---|\n| R6 tracking of the deferred parallelization | deferred, untracked | add to TODOS.md (not persisted in plan mode; content shown) | skip — no tracking | build now — contradicts D1=A; would reopen D1 |\n| D1–D8 | approved | fixed | fixed | D1 reopened |\n\nQuestion D9:\nD9 — Track the deferred IDP parallelization in TODOS.md?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), final planning (D1–D8 fixed).\nELI10: D1 pushed the 5x latency fix to its own PR. Deferred work that is not written down tends to never happen. This question is only about where the reminder lives. Choosing C would reopen D1 and pull the change back into this PR.\nStakes if we pick wrong: the follow-up quietly evaporates and users keep the sequential latency for a year.\nRecommendation: A because it is a real, cheap win that should not depend on someone's memory.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md (recommended)\n  ✅ Durable, visible to the whole team, with the context above attached\n  ✅ Zero engineering cost now; keeps D1 intact\n  ❌ TODOS.md cannot be written in plan mode; content is presented not persisted until you leave plan mode\nB) Skip\n  ✅ Nothing to maintain\n  ✅ Team may already track this elsewhere\n  ❌ Deferred work with no owner and no record\nC) Build it now in this PR\n  ✅ Latency win ships immediately\n  ✅ No follow-up to track\n  ❌ Reopens D1 and makes the refactor PR behavior-changing again\nNet: a paragraph in a file versus an unowned deferral.\nHeader: D9 TODO perf\nOptions:\nA) Add to TODOS.md (recommended)\nRecord the TODO content above in TODOS.md (presented not persisted in plan mode). D1 unchanged.\nB) Skip\nDo not track. D1 unchanged.\nC) Build now in this PR\nReopen D1 and include parallelization in this PR.\n\nState: approved\nActual answer: A) Add to TODOS.md — answered at D9\nAccepted scope: TODO \"Parallelize the 5 IDP calls in a dedicated follow-up PR\" with the content above is accepted for TODOS.md. TODOS.md is not writable in plan mode; content is presented as **not persisted** (see TODOS.md updates section). D1 unchanged.\nHistory: none\n\n### R7: TODO — delete legacyAuthFlow(), flag and parity suite after the canary window\nFinding: S2, P2, confidence 9/10, PLAN.md:36-37 + D2=A, reviewer: Claude (native, plan-eng-review)\nPlan baseline: D2=A named legacy deletion as a follow-up task. Tracking mechanism not yet decided.\nRuntime evidence: unknown.\nTODO content:\n- What: Remove `legacyAuthFlow()`, the routing flag, the routing branch, and the D7 parity suite once all tenants run on `AuthBroker`.\n- Why: Two live auth paths is a temporary state; leaving it doubles maintenance and confuses on-call.\n- Pros: Single auth path; smaller codebase; parity suite CI time goes away.\n- Cons: Must wait for canary evidence; removing the flag is a one-way door.\n- Context: Strangler approved at D2 in the 2026-09-17 eng review. Exit criteria: parity suite green for the window, flag on for 100% of tenants for an agreed period (suggest 2 weeks), no auth incidents attributed to AuthBroker.\n- Depends on / blocked by: refactor PR merged; flag fully rolled out; parity suite green.\nComparison grid:\n\n| Choice | Current | A | B | C |\n|---|---|---|---|---|\n| R7 tracking of legacy deletion | follow-up named, untracked | add to TODOS.md (not persisted in plan mode) | skip — no tracking | build now — contradicts D2=A; would reopen D2 |\n| D1–D8 | approved | fixed | fixed | D2 reopened |\n\nQuestion D10:\nD10 — Track the legacyAuthFlow() deletion follow-up in TODOS.md?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), final planning (D1–D9 fixed).\nELI10: D2 keeps the old login path alive behind a flag so you can roll back cheaply. The cost is that someone has to remember to delete it afterward, plus the flag and the parity suite. Strangler migrations that nobody finishes are how codebases end up with three auth paths. This question is only about where that reminder lives; C would reopen D2.\nStakes if we pick wrong: the old path lives forever, on-call has to reason about two code paths, and the parity suite keeps burning CI minutes.\nRecommendation: A because the exit criteria are worth writing down now while everyone agrees on them.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md (recommended)\n  ✅ Exit criteria captured while fresh; the deletion has a home\n  ✅ Zero engineering cost; D2 intact\n  ❌ Not persisted in plan mode; presented until you leave plan mode\nB) Skip\n  ✅ Nothing to maintain\n  ✅ Team may track flag cleanup elsewhere\n  ❌ Strangler with no end date is just two code paths\nC) Delete legacy in this PR\n  ✅ No dual-path window at all\n  ✅ No cleanup follow-up\n  ❌ Reopens D2 and removes the cheap rollback on the auth path\nNet: writing down the exit criteria versus trusting that a flag cleanup happens on its own.\nHeader: D10 TODO legacy\nOptions:\nA) Add to TODOS.md (recommended)\nRecord the TODO content above with exit criteria (presented not persisted in plan mode). D2 unchanged.\nB) Skip\nDo not track. D2 unchanged.\nC) Delete legacy in this PR\nReopen D2 and remove legacyAuthFlow() in this PR.\n\nState: approved\nActual answer: A) Add to TODOS.md — answered at D10\nAccepted scope: TODO \"Remove legacyAuthFlow(), routing flag and parity suite after canary window\" with the content and exit criteria above is accepted for TODOS.md. Presented as **not persisted** in plan mode. D2 unchanged.\nHistory: none\n\n### R8: TokenStore responsibility statement\nFinding: S4/A6/C2/T4, P2, confidence 6/10 (medium — verify), PLAN.md:44 vs :20-21, reviewer: Claude (native, plan-eng-review)\nPlan baseline: D3=A kept `TokenStore` as a class. The plan never states what it owns relative to `AuthCache` (facade over the one backing cache). No prior approval of a definition.\nRuntime evidence: unknown — TokenStore does not exist in the target repo.\nTODO content:\n- What: Add a paragraph to the plan defining `TokenStore`'s responsibility, its relationship to `AuthCache` (does it write through the facade? own refresh tokens? persist anything the cache does not?), and its test surface.\n- Why: Without it, two cache-shaped classes over one adapter will duplicate key-building and invalidation logic, and TokenStore cannot be tested (T4).\n- Pros: Unblocks TokenStore tests; prevents the DRY violation before it is written.\n- Cons: Requires the plan author's knowledge; ~15 minutes of writing.\n- Context: Raised at S4 in the 2026-09-17 eng review; structure kept at D3. If the answer is \"it wraps the same adapter\", D3 should be revisited later and TokenStore folded into AuthCache.\n- Depends on / blocked by: nothing; should happen before implementation of TokenStore starts.\nComparison grid:\n\n| Choice | Current | A | B | C |\n|---|---|---|---|---|\n| R8 where the TokenStore definition lands | undefined | TODOS.md entry (not persisted in plan mode) | skip — implement TokenStore without a written responsibility | P1 pre-implementation task in this plan: author writes the definition into the working plan before TokenStore code starts |\n| D3 (structure) | approved | fixed | fixed | fixed (revisit only if definition shows pure overlap) |\n\nQuestion D11:\nD11 — Where does the missing TokenStore definition get written?\nProject/branch/task: main — Multi-tenant Auth Refactor (PLAN.md), final planning (D1–D10 fixed).\nELI10: The plan lists TokenStore as a new class but never says what it does, while AuthCache already fronts the only cache (PLAN.md:44 vs :20-21). D3 kept the class. Before anyone writes it, someone has to say in one paragraph what it owns, how it relates to AuthCache, and how it is tested. Otherwise the person implementing it guesses, and the likely guess duplicates AuthCache. This is about whether that paragraph is a TODO for later or a gate before implementation.\nStakes if we pick wrong: TokenStore ships as a second cache facade with its own key-building code, and the next invalidation bug has two places to hide.\nRecommendation: C because the definition is a 15-minute writing task that blocks correct implementation and tests; it belongs in this plan, not a backlog.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md\n  ✅ Tracked somewhere durable\n  ✅ Does not block starting the other four classes\n  ❌ TokenStore could be implemented before the TODO is picked up, which defeats the point\nB) Skip\n  ✅ No extra work\n  ✅ Implementer may already know the intent\n  ❌ The one class nobody described gets built from a guess, on the auth path\nC) P1 pre-implementation task in this plan (recommended)\n  ✅ Definition exists before TokenStore code starts; T4 tests become specifiable\n  ✅ Surfaces early whether TokenStore is pure overlap with AuthCache (human: ~15 min / CC: n/a, author knowledge)\n  ❌ Adds a small gate before one of the five classes can begin\nNet: fifteen minutes of writing before code versus a second cache facade nobody asked for.\nHeader: D11 TokenStore\nOptions:\nA) Add to TODOS.md\nTrack the definition as a TODO (presented not persisted in plan mode). Implementation not gated.\nB) Skip\nNo written definition; implement from intent.\nC) P1 task in this plan (recommended)\nPlan author writes TokenStore's responsibility, AuthCache relationship and test surface into the working plan before TokenStore implementation starts. Other classes not blocked.\n\nState: approved\nActual answer: C) P1 task in this plan — answered at D11\nAccepted scope: P1 pre-implementation task (T1 below): the plan author writes a paragraph into this working plan defining `TokenStore`'s responsibility, its relationship to `AuthCache` (write-through? owns refresh tokens? persists anything the cache does not?), and its test surface. `TokenStore` implementation (T10) and its tests wait on T1; the other four classes are not blocked. D3 structure unchanged; if the definition shows pure overlap with `AuthCache`, reopen D3 in a later review.\nHistory: none\n\n### Approval readiness\n\nApproval readiness: **PASS** — checked R1 (D4=A), R2 (D5=A), R3 (D6=A), R4 (D7=A, regression contract), R5 (D8=A), R6 (D9=A), R7 (D10=A), R8 (D11=C). Scope selectors D1=A, D2=A, D3=A recorded under Scope Challenge. Every accepted remedy cites its own actual answer. No deferrals left pending. No auto-decisions (QUESTION_TUNING off, interactive session).\n\n---\n\n## Section findings\n\n### 1. Architecture review — 6 issues\n\n| # | Sev | Conf | Where | Finding | Disposition |\n|---|---|---|---|---|---|\n| A1 | P1 | 8/10 | PLAN.md:28-29 | Module-level mutable `AuthCache` singleton with two writers; hidden dependency, test-state leaks. | accepted → constructor injection (D4=A) |\n| A2 | P1 | 6/10 | PLAN.md:19, :29, :17-18 | Unserialized writes: a `SessionMint` write can land after a revocation/suspension invalidation and re-cache a dead token. Medium confidence. | accepted → epoch-guarded facade writes + interleaving test (D5=A) |\n| A3 | P2 | 8/10 | D2 flag | Routing flag is a new single point of misroute; must default to legacy and fail closed to legacy on read/parse failure, with a warning log. | carried as common work of D2=A |\n| A4 | P2 | 7/10 | PLAN.md:32-33 | Production failure: IDP timeout mid-`validateAndDispatch()` lands in a swallowing catch; user outcome unspecified. | resolved via C1/D6 |\n| A5 | P3 | 7/10 | plan | No data-flow diagram for validate → policy → dispatch or invalidation paths. | documentation task T9 |\n| A6 | P2 | 6/10 | PLAN.md:44 vs :20-21 | `TokenStore` → `AuthCache` dependency edge undefined. | accepted → P1 definition task (D11=C) |\n\nSecurity architecture note: all auth decisions stay inside `AuthBroker`/`RequestPolicy`; no new API boundary is introduced. The flag is an internal config read, not a user-controllable input; it must not be derivable from request headers.\nDistribution architecture: N/A, no new artifact.\n\n### 2. Code Quality review — 4 issues\n\n| # | Sev | Conf | Where | Finding | Disposition |\n|---|---|---|---|---|---|\n| C1 | P1 | 8/10 | PLAN.md:32-33 | 60-line function, three nested swallowing catches; DRY violation plus silent failure on the auth path. | accepted → split + `AuthOutcome` + one mapper (D6=A) |\n| C2 | P2 | 7/10 | PLAN.md:20-21, :44 | `AuthCache` and `TokenStore` both over one adapter; key-building/invalidation duplication risk without a written split. | accepted → definition task (D11=C) |\n| C3 | P3 | 8/10 | plan | `AuthBroker` header comment should carry the pipeline diagram. | documentation task T9 |\n| C4 | P2 | 6/10 | D2 flag | Flag check must live at exactly one routing point. Medium confidence. | carried as common work of D2=A |\n\n### 3. Test review — 5 findings, 31 gaps in diagram\n\nTest framework: unknown in target repo (no manifests, zero test files). File names below are placeholders; match the real repo's convention.\n\n| # | Sev | Conf | Finding | Disposition |\n|---|---|---|---|---|\n| T1 | P1 CRITICAL | 9/10 | No regression coverage for `legacyAuthFlow()` while it is replaced (PLAN.md:23-25, :36-37). | accepted → differential parity suite (D7=A) |\n| T2 | P2 | 7/10 | No HTTP-level journey for the flag-routed login. | accepted → three E2E journeys (D8=A) |\n| T3 | P2 | 8/10 | Planned coverage named only \"success/error paths\"; approved remedies add concrete branches (D2, D4, D5, D6). | carried as common work |\n| T4 | P3 | 7/10 | `TokenStore` tests unspecifiable until its responsibility exists. | waits on T1 (D11=C) |\n| T5 | info | 9/10 | Test framework unknown. | recorded |\n\nCoverage diagram (existing tests: none visible in target; **[APPROVED]** = required by a decision):\n\n```\nCODE PATHS                                                    USER FLOWS\n[+] auth/AuthBroker (validateAndDispatch → 3 steps)           [+] Login (flag off → legacy)\n  ├── validate()                                                ├── [GAP][APPROVED D7] allow/deny parity per fixture\n  │   ├── [GAP][APPROVED D6] cache hit → claims                 └── [GAP][→E2E][APPROVED D8] HTTP journey\n  │   ├── [GAP][APPROVED D6] cache miss → IDP → put(epoch)    [+] Login (flag on, tenant T → AuthBroker)\n  │   ├── [GAP][APPROVED D6] expired / revoked / malformed       ├── [GAP][APPROVED D7] allow/deny parity per fixture\n  │   └── [GAP][APPROVED D6] IDP timeout / 5xx → error{}         └── [GAP][→E2E][APPROVED D8] HTTP journey\n  ├── RequestPolicy.evaluate()                                [+] Flag misconfig / read failure\n  │   ├── [GAP][APPROVED PLAN:23] allowed                        └── [GAP][→E2E][APPROVED D8] falls back to legacy\n  │   └── [GAP][APPROVED PLAN:23] denied{reason}               [+] Tenant suspended mid-session\n  ├── dispatch()                                                 └── [GAP][APPROVED D5] mint-write after invalidate dropped\n  │   ├── [GAP][APPROVED D6] allowed → response               [+] Error states the user sees\n  │   └── [GAP][APPROVED D6] denied/error → same deny shape      ├── [GAP][APPROVED D6+D7] IDP down → deny, logged\n  └── mapAuthError()                                             └── [GAP][APPROVED D7] expired token → same response as legacy\n      ├── [GAP][APPROVED D6] each known class → outcome\n      └── [GAP][APPROVED D6] unknown → error{unknown} + log\n[+] auth/AuthCache (facade)\n  ├── [GAP][APPROVED D4] constructed per test with fake adapter\n  ├── [GAP][APPROVED D4] AuthBroker and SessionMint share one instance (identity assertion)\n  ├── [GAP][APPROVED D5] epoch bump on logout/revoke/suspend\n  ├── [GAP][APPROVED D5] put() with stale epoch is a no-op\n  └── [GAP][PLAN:16-19] key = (tenant, issuer, audience, policyVersion) passthrough\n[+] auth/SessionMint\n  ├── [GAP][APPROVED PLAN:23] mint success → cache.put\n  └── [GAP][APPROVED PLAN:23] mint failure → error outcome, no put\n[+] auth/TokenStore\n  └── [GAP][WAITS ON T1] responsibility undefined\n[+] auth/RequestPolicy\n  └── [GAP][APPROVED PLAN:23] allow / deny table for claims × tenant ctx\n[+] flag routing point (D2)\n  ├── [GAP][APPROVED D2] flag off → legacyAuthFlow()\n  ├── [GAP][APPROVED D2] flag on for tenant → AuthBroker\n  └── [GAP][APPROVED D2] flag read/parse failure → legacyAuthFlow() + warning log\n[+] legacyAuthFlow() (unchanged code, at risk)\n  └── [GAP][APPROVED D7][CRITICAL] characterization + differential parity, 12 fixtures\n\nLLM integration: none — no [→EVAL] paths.\n\nCOVERAGE: 0/31 paths tested (0%)  |  Code paths: 0/24  |  User flows: 0/7\nQUALITY: ★★★:0 ★★:0 ★:0  |  GAPS: 31 (30 approved by decisions, 1 waits on T1)\n```\n\nTest Plan Artifact: `~/.gstack/projects/gstack-plan-count-cf9goi/vercel-sandbox-main-eng-review-test-plan-20260917-005502.md` (written).\n\n### 4. Performance review — 4 issues\n\n| # | Sev | Conf | Where | Finding | Disposition |\n|---|---|---|---|---|---|\n| PF1 | P2 | 8/10 | PLAN.md:39-41 | 5 sequential IDP round-trips per cache-miss validation. | deferred to follow-up PR (D1=A); tracked (D9=A). Notes: `Promise.all` is fail-fast; verify independence (discovery → JWKS usually is not); map per-call errors through `mapAuthError()`; check IDP rate limits for a 5x burst. |\n| PF2 | P3 | 5/10 | PLAN.md:16-17 | Cache growth unbounded if the adapter has no size cap. Medium confidence; adapter unchanged and out of scope. | recorded |\n| PF3 | P3 | 8/10 | D5 | Per-tenant epoch map: O(tenants) integers. Negligible. | recorded |\n| PF4 | P3 | 8/10 | D7 | Parity suite doubles CI time for that suite during the window; deleted with legacy. | recorded |\n\n## Outside Voice\n\n`codex_reviews` is `disabled`. Codex review skipped (codex_reviews disabled). No native fallback dispatched (disabled is an intentional opt-out). Recorded: `skill=codex-plan-review, status=skipped, source=none, host=claude, outside_provider=codex, outside_status=disabled, phase=plan-review`. Re-enable: `gstack-config set codex_reviews enabled`.\n\n---\n\n## NOT in scope\n- **Promise.all parallelization of the 5 IDP calls** — deferred to an immediate follow-up PR (D1=A) so this PR stays behavior-preserving; tracked as a TODO (D9=A).\n- **Deleting `legacyAuthFlow()`, the routing flag and the parity suite** — deferred until the canary window closes (D2=A); tracked as a TODO with exit criteria (D10=A).\n- **Changes to the existing cache adapter, its keying, invalidation hooks or tests** — the plan keeps them unchanged (PLAN.md:21-22); the D5 epoch guard lives in the new facade only.\n- **Folding `TokenStore` into `AuthCache`** — rejected at D3; revisit only if the T1 definition shows pure overlap.\n- **Cache size bounding (PF2)** — adapter concern, unverified, not touched here.\n\n## What already exists\n- **Cache adapter with 4-tuple keying, expiry eviction, invalidation on logout/revocation/suspension, and its tests** (PLAN.md:16-22) — **reused unchanged**; `AuthCache` is a facade over it. Correct call.\n- **`legacyAuthFlow()`** (PLAN.md:36) — **kept alive behind the flag** during the strangler window and used as the parity oracle (D7). Not rebuilt; its behavior is the contract.\n- **The existing per-request access decision** (PLAN.md:9-11) — moved into `RequestPolicy` without new policy. Reused logic, new home.\n- **The 5 IDP calls** (PLAN.md:40) — unchanged in this PR.\n\n## Diagrams\n\nRequest pipeline (also goes into the `AuthBroker` header comment, task T9):\n\n```\nHTTP entry ──► flag routing point ──┬── flag off / unreadable ──► legacyAuthFlow() ──► response\n                                    └── flag on (tenant) ──────► AuthBroker.validateAndDispatch()\n                                                                     │\n                                            ┌────────────────────────┴───────────────────────┐\n                                            │ validate(req)                                   │\n                                            │   cache.get(tenant,iss,aud,pv) ─hit─► claims     │\n                                            │   miss ─► IDP ×5 (sequential) ─► claims          │\n                                            │           cache.put(claims, epoch)  (D5 guard)   │\n                                            │   errors ─► mapAuthError() ─► error{kind} + log  │\n                                            ├─ RequestPolicy.evaluate(claims, ctx) ─► allowed | denied{reason}\n                                            └─ dispatch(outcome) ─► response (same shape as legacy; error ⇒ deny)\n```\n\nCache write ordering (D5):\n\n```\nSessionMint            AuthCache (facade)             invalidation hook (adapter)\n    │ read epoch=E ────────►│                                   │\n    │                       │◄── suspend(tenant) ──────────────┤   epoch := E+1, adapter.invalidate(tenant)\n    │ put(entry, epoch=E) ─►│  E < E+1 → DROP (no-op)           │\n```\n\nComposition root (D4):\n\n```\ncomposition root\n  ├── adapter  = existingCacheAdapter\n  ├── cache    = new AuthCache(adapter)          ← exactly one\n  ├── broker   = new AuthBroker({ cache, idp, policy })\n  └── mint     = new SessionMint({ cache, idp })\n```\n\nFiles needing inline diagrams: `AuthBroker` (pipeline above), `AuthCache` (epoch/write ordering), the composition root (wiring), the flag routing point (two-path branch).\n\n## Failure modes\n\n| New path | Realistic failure | Test | Handling | User sees | Verdict |\n|---|---|---|---|---|---|\n| `validate()` cache miss → IDP | IDP timeout / 5xx | yes (D6, D7 fixtures) | `mapAuthError()` → `error{idp_*}` → deny, logged | same deny as legacy | covered |\n| `mapAuthError()` | error class nobody anticipated | yes (D6 unknown branch) | `error{unknown}` → deny, logged with tenant+reqId | deny | covered |\n| `AuthCache.put()` | mint write after suspension | yes (D5 interleaving) | epoch guard drops write | token rejected, correct | covered |\n| Composition root | two `AuthCache` instances wired by mistake | yes (D4 identity assertion, added as common work) | test fails at build time | n/a | covered |\n| Flag routing point | flag store unreadable / malformed | yes (D2, D8 journey 3) | fall back to legacy + warning log | normal login | covered |\n| Flag routing point | flag on for a tenant whose edge case the fixture table missed | parity suite cannot catch what it does not list | canary tenant + rollback by flag flip | possible wrong deny/allow on that tenant until flag flipped | residual risk, mitigated by D2 |\n| `dispatch()` | downstream unavailable after allow | yes (D6 dispatch error branch) | `error{dispatch}` → same error response as legacy | same as today | covered |\n| `TokenStore` | unknown until T1 | n/a | n/a | n/a | unassessable until T1 |\n\n**Critical gaps (no test AND no handling AND silent): 0.**\n\n## Worktree parallelization strategy\n\n| Step | Modules touched | Depends on |\n|---|---|---|\n| T1 TokenStore definition (author) | plan document | — |\n| T3 AuthCache facade + DI + epoch guard | auth/cache | — (adapter interface exists) |\n| T4 AuthBroker steps + AuthOutcome + mapper | auth/broker | AuthCache interface (T3 signature agreed first) |\n| T8 RequestPolicy class + tests | auth/policy | — |\n| T7 SessionMint with injected cache | auth/session | T3 |\n| T5 fake IDP harness + fixture table + parity runner | test/auth | harness: —; runner: T4, T2 |\n| T2 flag + single routing point + fail-closed | entrypoint/routing, config | T4 |\n| T6 three E2E journeys | test/e2e | T2, T5 harness |\n| T9 diagrams in code | auth/broker, auth/cache, root | T3, T4 |\n| T10 TokenStore implementation + tests | auth/tokenstore | T1, T3 |\n\nParallel lanes:\n- `Lane A: T3 → T7 → T10 (sequential, shared auth/cache; T10 also waits on T1)`\n- `Lane B: T4 → T9 (sequential, auth/broker)`\n- `Lane C: T8 (independent, auth/policy)`\n- `Lane D: T5 harness + fixture table (independent, test/auth); parity runner after A+B merge`\n- `Lane E: T1 (author, plan doc; independent)`\n\nExecution order: agree the `AuthCache` constructor/`put(entry, epoch)` signature first (10 minutes, in Lane A). Launch A, B, C, D, E in parallel worktrees. Merge A+B+C. Then T2 (routing) and the T5 parity runner. Merge. Then T6 E2E. T10 last, after T1.\n\nConflict flags: Lane B imports the `AuthCache` type from Lane A — pin the signature before launch or Lane B stubs it. T2 touches the entrypoint that E2E (T6) drives; keep them sequential. T9 edits files owned by A and B; run after both merge.\n\n## Implementation Tasks\nSynthesized from this review's findings. Each task derives from a specific finding above. Run with Claude Code or Codex; checkbox as you ship.\n\n- [ ] **T1 (P1, human: ~15min / CC: n/a — author knowledge)** — plan — Write `TokenStore`'s responsibility, `AuthCache` relationship and test surface into this plan\n  - Surfaced by: Scope Challenge S4 / Architecture A6 / Code Quality C2 / Test T4 — D11=C\n  - Files: this plan document (working plan → Architecture)\n  - Verify: paragraph exists before any `TokenStore` code; if it reads \"wraps the same adapter\", reopen D3\n- [ ] **T2 (P1, human: ~1 day / CC: ~15min)** — routing — Add the routing flag with one routing point; default legacy; fail closed to legacy on read/parse failure with a warning log\n  - Surfaced by: Scope Challenge S2 — D2=A; Architecture A3; Code Quality C4\n  - Files: auth entrypoint/routing module, config schema\n  - Verify: routing tests: off → legacy, on(tenant) → AuthBroker, unreadable → legacy + log\n- [ ] **T3 (P1, human: ~1.5 days / CC: ~20min)** — auth/cache — `AuthCache` facade over the existing adapter, constructor-injected, per-tenant invalidation epoch, stale-epoch `put()` no-op\n  - Surfaced by: Architecture A1 (D4=A), A2 (D5=A)\n  - Files: auth/cache/AuthCache.*, composition root, existing invalidation hook wiring\n  - Verify: fresh-cache-per-test; identity assertion that broker and mint share one instance; interleaving test mint-read → invalidate → mint-write not re-cached; adapter tests untouched and green\n- [ ] **T4 (P1, human: ~2 days / CC: ~25min)** — auth/broker — `validateAndDispatch()` as `validate()` → `RequestPolicy.evaluate()` → `dispatch()` with discriminated `AuthOutcome` and one `mapAuthError()`; unknown → `error{unknown}` logged; error ⇒ same deny as legacy\n  - Surfaced by: Code Quality C1 — D6=A; Architecture A4\n  - Files: auth/broker/AuthBroker.*, auth/broker/AuthOutcome.*, auth/broker/mapAuthError.*\n  - Verify: unit tests per step (hit, miss, expired, revoked, malformed, timeout, 5xx, allowed, denied, dispatch error); mapper test per known class + unknown\n- [ ] **T5 (P1 CRITICAL, human: ~2 days / CC: ~30min)** — test/auth — Fake IDP harness, 12-case fixture table, differential parity runner (`legacyAuthFlow()` vs `AuthBroker`), characterization tests pinning legacy\n  - Surfaced by: Test T1 — D7=A (regression rule)\n  - Files: test/auth/fixtures.*, test/auth/fakeIdp.*, test/auth/parity.test.*, test/auth/legacy.characterization.test.*\n  - Verify: every fixture asserts equal decision, response shape, post-call cache state; suite required green before any flag flip\n- [ ] **T6 (P2, human: ~1 day / CC: ~20min)** — test/e2e — Three E2E journeys: flag off → legacy (allow+deny); flag on tenant T → AuthBroker (allow+deny); flag read failure → legacy\n  - Surfaced by: Test T2 — D8=A\n  - Files: test/e2e/auth-routing.e2e.*\n  - Verify: all three pass against the real HTTP entrypoint with the fake IDP\n- [ ] **T7 (P2, human: ~1 day / CC: ~15min)** — auth/session — `SessionMint` with constructor-injected `AuthCache`; writes carry the epoch read at mint start\n  - Surfaced by: Architecture A1 (D4=A), A2 (D5=A); PLAN.md:23 planned coverage\n  - Files: auth/session/SessionMint.*\n  - Verify: mint success → put; mint failure → no put; epoch propagated\n- [ ] **T8 (P2, human: ~half day / CC: ~10min)** — auth/policy — `RequestPolicy` class wrapping the existing decision; table-driven allow/deny tests\n  - Surfaced by: Scope Challenge S3 (D3=A kept class); PLAN.md:23 planned coverage\n  - Files: auth/policy/RequestPolicy.*\n  - Verify: allow/deny table over claims × tenant context matches legacy decisions (also exercised by T5)\n- [ ] **T9 (P3, human: ~1h / CC: ~5min)** — docs — ASCII pipeline diagram in `AuthBroker` header, epoch/write-ordering diagram in `AuthCache`, wiring diagram at composition root\n  - Surfaced by: Architecture A5, Code Quality C3\n  - Files: same files as T3, T4, composition root\n  - Verify: diagrams match code at PR review; update in the same commit as any later change\n- [ ] **T10 (P3, human: ~1 day / CC: ~15min)** — auth/tokenstore — Implement `TokenStore` per T1 definition, with tests\n  - Surfaced by: Test T4; D3=A structure\n  - Files: auth/tokenstore/TokenStore.*\n  - Verify: tests derived from the T1 test-surface paragraph\n- _No new tasks from Performance review in this PR (PF1 deferred to follow-up PR; PF2–PF4 recorded only)._\n\nEffort assumption: refactor-with-tests ratio ~20–50x human÷CC; T1 is author knowledge and does not compress.\n\n## TODOS.md updates (accepted, **not persisted** — TODOS.md is not writable in plan mode)\n\nAccepted for TODOS.md after leaving plan mode (2 items):\n\n**TODO 1 — Parallelize the 5 IDP calls (follow-up PR)** (D9=A)\n- What: Parallelize the 5 IDP calls in `AuthBroker.validate()` in a dedicated PR.\n- Why: ~5x avoidable latency on every cache-miss validation.\n- Pros: User-visible latency win; isolated PR bisects cleanly.\n- Cons: Fail-fast semantics and IDP burst load need their own tests; calls may not all be independent.\n- Context: Deferred by D1 in the 2026-09-17 eng review so the refactor PR stays behavior-preserving. Map per-call errors via `mapAuthError()`; decide `Promise.all` vs `allSettled` per call; check IDP rate limits.\n- Depends on / blocked by: refactor PR merged; flag on for at least one canary tenant.\n\n**TODO 2 — Remove `legacyAuthFlow()`, routing flag and parity suite** (D10=A)\n- What: Delete `legacyAuthFlow()`, the flag, the routing branch and the D7 parity suite once all tenants run on `AuthBroker`.\n- Why: Two live auth paths is temporary by design; leaving it doubles maintenance and confuses on-call.\n- Pros: Single auth path; smaller codebase; parity CI time gone.\n- Cons: Must wait for canary evidence; flag removal is a one-way door.\n- Context: Strangler approved at D2 in the 2026-09-17 eng review. Exit criteria: parity suite green through the window; flag on for 100% of tenants for an agreed period (suggest 2 weeks); no auth incidents attributed to `AuthBroker`.\n- Depends on / blocked by: refactor PR merged; full flag rollout; parity suite green.\n\nSkipped: none. Built now instead: TokenStore definition (D11=C → T1).\n\n## Unresolved decisions that may bite you later\nNone in this review. All eleven decisions (D1–D11) have actual answers recorded in the ledger.\n\n## Suppressed findings (confidence ≤ 4, appendix only)\n- (conf 4/10) PLAN.md:12 — \"calls it after validation and before dispatch\": if any dispatch path can run without validation succeeding (e.g. an anonymous route sharing the broker), `RequestPolicy` would see undefined claims. Cannot quote motivating code; unverified.\n- (conf 3/10) PLAN.md:40 — the 5 IDP calls may include discovery/JWKS fetches that should be cached across requests rather than parallelized; relevant to the follow-up PR, not this one.\n\n## Completion summary\n- Step 0: Scope Challenge — scope reduced per recommendation (D1 parallelization deferred, D2 strangler; D3 structure kept as planned)\n- Architecture Review: 6 issues found\n- Code Quality Review: 4 issues found\n- Test Review: diagram produced, 31 gaps identified (30 approved by decisions, 1 waits on T1); 5 findings\n- Performance Review: 4 issues found\n- NOT in scope: written\n- What already exists: written\n- TODOS.md updates: 3 items proposed to user (2 accepted, not persisted in plan mode; 1 converted to P1 task T1)\n- Failure modes: 0 critical gaps flagged\n- Unresolved decisions: 0 in this review\n- Outside voice: provider codex, disabled (codex_reviews=disabled; no fallback dispatched)\n- Parallelization: 5 lanes, 5 parallel / 3 sequential merge points (A+B+C → T2 + parity runner → T6; T10 after T1)\n- Lake Score: 4/4 (D5, D6, D7, D8 all selected 10/10; D1–D4, D9–D11 differ in kind and are excluded)\n\n## GSTACK REVIEW REPORT\n\nTarget: PLAN.md \"Plan: Multi-tenant Auth Refactor\" — branch `main`, commit `7d4af5b`, working tree clean. Reviewed 2026-09-17.\n\n| Review | Skill | Runs | Status | Last run | Notes |\n|---|---|---|---|---|---|\n| CEO Review | `/plan-ceo-review` | 0 | not run | — | Optional; plan is a behavior-preserving refactor with no product-scope questions open |\n| Outside Review | `codex` | 1 | skipped (disabled) | 2026-09-17T00:55:50Z | `codex_reviews=disabled`; no fallback dispatched. Re-enable with `gstack-config set codex_reviews enabled` |\n| Eng Review | `/plan-eng-review` | 1 | CLEAR | 2026-09-17 (this run) | Scope: SCOPE_REDUCED. 19 findings (A6, C4, T5, PF4); 31 coverage gaps, 30 approved by decisions, 1 gated on T1; 0 critical failure-mode gaps; 0 unresolved decisions; Lake Score 4/4 |\n| Design Review | `/design-review` | 0 | not run | — | No UI surface in this plan |\n| DX Review | `/dx-review` | 0 | not run | — | No developer-facing artifact or CLI change |\n\nOUTSIDE COVERAGE: provider `codex`, phase `plan-review`, status `disabled` — this review has no independent outside voice.\n\nDecisions: D1–D11 all answered (D1=A defer parallelization, D2=A strangler behind flag, D3=A keep 5 classes, D4=A constructor injection, D5=A epoch-guarded writes, D6=A split + AuthOutcome + mapper, D7=A differential parity suite, D8=A three E2E journeys, D9=A TODO parallelization, D10=A TODO legacy deletion, D11=C TokenStore definition as P1 task T1).\n\nGating conditions before flag flip: T5 parity suite green on all 12 fixtures; T2 routing tests green; T6 E2E journeys green. TokenStore work (T10) blocked on T1 only.\n\nTODOS.md items (2) accepted but **not persisted** — write them after leaving plan mode.\n\nVERDICT: ENG CLEARED — ready to implement.\n\nNO UNRESOLVED DECISIONS\n",
  "provenance": {
    "runId": "ship-all-fb10b21c-c10c2db6-cb63-4e8b-8699-dbfb344e62d1",
    "attempt": "plan-eng-review-1789605825839-PreAta",
    "publicSnapshotSha256": "64e5b073fa1655acd776b90e60c5c38197043de64f05627c7cbb1f9fec1eefc6",
    "originalReportSource": "/tmp/g-vlxin2hi/gstack-paid-shard-rOxzCt/tmp/gstack-e2e-plan-eng-uyBqKt/gstack-test-plan-eng.md",
    "reportSha256": "96c7c106e9b7c4c741d272889226950e0c9112ece3a19bc0e713f676857ef1cc",
    "reportMtimeMs": 1789607037033.875,
    "nativeExitUses": [
      {
        "kind": "plan-count-pending-exit",
        "path": "/home/vercel-sandbox/gstack/.context/nouakchott-c6fc-impact/runtime-ceo-clarity-next/executions/fb10b21c2a01365d82c1ac44d6fd53f67b9db644/all/run/public-retention/skill-e2e-plan-eng-finding-count/plan-eng-review-1789605825839-PreAta/objects/4327b82026fcc0ebde9a6f2251adca7124ec1527559a56f9cfaad03321dd0a42.json",
        "sha256": "4327b82026fcc0ebde9a6f2251adca7124ec1527559a56f9cfaad03321dd0a42",
        "fields": {
          "cwd": "/tmp/g-vlxin2hi/gstack-paid-shard-rOxzCt/tmp/gstack-plan-count-cf9goi",
          "timestamp": "2026-09-17T01:05:42.556Z",
          "toolUseId": "toolu_01P3wVU3mL4jk56zzT2c8Nty"
        }
      }
    ],
    "cancellationReceipt": ".context/nouakchott-fb10b21c-monitor/repaired-behavior/checkpoint-cancellation/execution-receipt-20260917T011352.624505Z.json"
  }
}