gstack/test/fixtures/eng-6aef-count-public.json

{
  "source": "6aef8d74a7835a0986694d57d4fa5748ac960379",
  "originalOutcome": "CANCELLED",
  "qualification": "Attempt 1 was CANCELLED_SUPERSEDED_DETECTOR by the root at 2026-09-16T23:23:05Z after a preserved pending native Exit. No paid verdict or completion credit; configured retry unstarted.",
  "windowStart": "2026-09-16T23:03:31.817Z",
  "windowEnd": "2026-09-16T23:18:41.882Z",
  "calls": [
    {
      "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
      "toolUseId": "toolu_019nKGnCiQxZCEX4PAecV7JB",
      "questions": [
        {
          "question": "D1 — Keep the Promise.all parallelization of the 5 IDP calls inside this refactor, or split it into its own follow-up change?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md \"Performance\" section (lines 39-41).\nELI10: The plan promises \"no product behavior change\" but also wants to fire 5 identity-provider calls at once instead of one after another. That's a real behavior change: errors arrive in a different order, the IDP sees 5x burst traffic per login, and the nested try/catch that swallows errors today will interact with Promise.all's first-rejection-wins semantics. Mixing this into a 12-file structural refactor means if a login breaks after deploy, you can't tell which change did it.\nStakes if we pick wrong: bundled = a login outage with two suspects and one revert; deferred too long = users keep waiting for 5 serial round trips.\nRecommendation: B because separating structural from behavioral change (Beck) keeps the refactor bisectable, and the follow-up is a small diff once tests exist.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Include parallelization in this refactor\n  ✅ Users get the latency win in the same release, no second PR to shepherd\n  ✅ Touches validateAndDispatch() once instead of twice\n  ❌ Behavior change hides inside a \"no behavior change\" diff; a post-deploy regression has two suspects\n  ❌ Promise.all rejection semantics collide with the three error-swallowing catch blocks before those are cleaned up\nB) Defer to an immediate follow-up PR after the refactor lands (recommended)\n  ✅ Refactor stays pure structure: bisectable, revertable, reviewable against \"same behavior\" tests\n  ✅ Follow-up lands on flattened error handling with regression tests already in place (human: ~1 day / CC: ~10 min)\n  ❌ Latency win ships one PR later; someone has to actually open the follow-up\nC) Cut it entirely from this work\n  ✅ Zero risk to the refactor\n  ❌ Leaves a known 5x latency cost on every token validation with no owner\nNet: trading one release of latency for a refactor you can actually bisect.",
          "header": "D1 Promise.all",
          "multiSelect": false,
          "options": [
            {
              "label": "B) Defer to follow-up PR (recommended)",
              "description": "Refactor stays structural only. Parallelization lands as a separate small PR immediately after, once regression tests and flattened error handling exist. Effort: human ~1 day / CC ~10 min."
            },
            {
              "label": "A) Include in this refactor",
              "description": "Ship Promise.all inside this diff. Latency win in the same release, but a behavior change hides inside the structural refactor and interacts with the nested try/catch error swallowing."
            },
            {
              "label": "C) Cut entirely",
              "description": "Remove parallelization from scope with no follow-up. Zero refactor risk; 5x serial latency on every token validation stays unowned."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D1 — Keep the Promise.all parallelization of the 5 IDP calls inside this refactor, or split it into its own follow-up change?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md \"Performance\" section (lines 39-41).\nELI10: The plan promises \"no product behavior change\" but also wants to fire 5 identity-provider calls at once instead of one after another. That's a real behavior change: errors arrive in a different order, the IDP sees 5x burst traffic per login, and the nested try/catch that swallows errors today will interact with Promise.all's first-rejection-wins semantics. Mixing this into a 12-file structural refactor means if a login breaks after deploy, you can't tell which change did it.\nStakes if we pick wrong: bundled = a login outage with two suspects and one revert; deferred too long = users keep waiting for 5 serial round trips.\nRecommendation: B because separating structural from behavioral change (Beck) keeps the refactor bisectable, and the follow-up is a small diff once tests exist.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Include parallelization in this refactor\n  ✅ Users get the latency win in the same release, no second PR to shepherd\n  ✅ Touches validateAndDispatch() once instead of twice\n  ❌ Behavior change hides inside a \"no behavior change\" diff; a post-deploy regression has two suspects\n  ❌ Promise.all rejection semantics collide with the three error-swallowing catch blocks before those are cleaned up\nB) Defer to an immediate follow-up PR after the refactor lands (recommended)\n  ✅ Refactor stays pure structure: bisectable, revertable, reviewable against \"same behavior\" tests\n  ✅ Follow-up lands on flattened error handling with regression tests already in place (human: ~1 day / CC: ~10 min)\n  ❌ Latency win ships one PR later; someone has to actually open the follow-up\nC) Cut it entirely from this work\n  ✅ Zero risk to the refactor\n  ❌ Leaves a known 5x latency cost on every token validation with no owner\nNet: trading one release of latency for a refactor you can actually bisect.": "B) Defer to follow-up PR (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-16T23:06:19.905Z"
    },
    {
      "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
      "toolUseId": "toolu_017JaL9M5FBL3Wx5WQSQKYqm",
      "questions": [
        {
          "question": "D2 — Rewrite legacyAuthFlow() inside this refactor, or keep it as a thin adapter that delegates to AuthBroker (strangler) and retire it later?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md \"Tests\" section (lines 35-37) and \"Existing contracts retained\" (lines 23-25).\nELI10: legacyAuthFlow() is the code that logs people in today. The plan rewrites it in the same PR that introduces five new classes, and says the new tests won't check that it still behaves the same. That's the single riskiest line in the plan. A strangler approach keeps the old function's signature and callers, makes its body call the new AuthBroker, and lets you delete it in a later PR once production proves the new path matches. This question is about scope (rewrite now vs. adapter now, delete later); the regression-test contract itself is a separate decision in the Test review.\nStakes if we pick wrong: full rewrite with no safety net = tenants locked out or, worse, cross-tenant access with no test to catch it; over-cautious = one extra small PR.\nRecommendation: B because a strangler adapter keeps every existing caller and its behavior pinned while the new path proves itself, and the eventual delete is a 5-minute PR.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Full rewrite of legacyAuthFlow() in this PR (as planned)\n  ✅ One less transitional layer; the codebase ends the PR with no legacy shim\n  ✅ Fewer files to touch a second time in a follow-up\n  ❌ Rewrites the live login path in the same diff as 5 new classes and 12 files; a regression has many suspects\n  ❌ Every existing caller of legacyAuthFlow() changes behavior at once with no canary\nB) Strangler: keep legacyAuthFlow() signature, body delegates to AuthBroker; delete in a follow-up PR (recommended)\n  ✅ Existing callers and their observable behavior stay pinned; the adapter is the natural place for a compatibility regression test\n  ✅ Rollback is one function body, not 12 files (human: ~2h / CC: ~10 min for the adapter)\n  ❌ Temporary shim lives in the codebase for one release; someone must open the delete PR\nC) Leave legacyAuthFlow() untouched; new services run alongside it\n  ✅ Zero risk to current logins\n  ❌ Two parallel auth paths in production with one shared cache; divergence is the real long-term hazard\nNet: trading one transitional shim for a login path you can roll back in one function.",
          "header": "D2 legacyAuth",
          "multiSelect": false,
          "options": [
            {
              "label": "B) Strangler adapter (recommended)",
              "description": "Keep legacyAuthFlow() signature; its body delegates to AuthBroker. Existing callers untouched. Delete the shim in a follow-up PR after the new path proves itself. Effort: human ~2h / CC ~10 min."
            },
            {
              "label": "A) Full rewrite now",
              "description": "Rewrite legacyAuthFlow() in this PR as originally planned. No shim, but the live login path changes in the same diff as 5 new classes and 12 files."
            },
            {
              "label": "C) Leave untouched",
              "description": "New services run alongside the untouched legacy flow. Zero login risk now, but two auth paths share one cache and will diverge."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D2 — Rewrite legacyAuthFlow() inside this refactor, or keep it as a thin adapter that delegates to AuthBroker (strangler) and retire it later?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md \"Tests\" section (lines 35-37) and \"Existing contracts retained\" (lines 23-25).\nELI10: legacyAuthFlow() is the code that logs people in today. The plan rewrites it in the same PR that introduces five new classes, and says the new tests won't check that it still behaves the same. That's the single riskiest line in the plan. A strangler approach keeps the old function's signature and callers, makes its body call the new AuthBroker, and lets you delete it in a later PR once production proves the new path matches. This question is about scope (rewrite now vs. adapter now, delete later); the regression-test contract itself is a separate decision in the Test review.\nStakes if we pick wrong: full rewrite with no safety net = tenants locked out or, worse, cross-tenant access with no test to catch it; over-cautious = one extra small PR.\nRecommendation: B because a strangler adapter keeps every existing caller and its behavior pinned while the new path proves itself, and the eventual delete is a 5-minute PR.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Full rewrite of legacyAuthFlow() in this PR (as planned)\n  ✅ One less transitional layer; the codebase ends the PR with no legacy shim\n  ✅ Fewer files to touch a second time in a follow-up\n  ❌ Rewrites the live login path in the same diff as 5 new classes and 12 files; a regression has many suspects\n  ❌ Every existing caller of legacyAuthFlow() changes behavior at once with no canary\nB) Strangler: keep legacyAuthFlow() signature, body delegates to AuthBroker; delete in a follow-up PR (recommended)\n  ✅ Existing callers and their observable behavior stay pinned; the adapter is the natural place for a compatibility regression test\n  ✅ Rollback is one function body, not 12 files (human: ~2h / CC: ~10 min for the adapter)\n  ❌ Temporary shim lives in the codebase for one release; someone must open the delete PR\nC) Leave legacyAuthFlow() untouched; new services run alongside it\n  ✅ Zero risk to current logins\n  ❌ Two parallel auth paths in production with one shared cache; divergence is the real long-term hazard\nNet: trading one transitional shim for a login path you can roll back in one function.": "B) Strangler adapter (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-16T23:06:40.465Z"
    },
    {
      "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
      "toolUseId": "toolu_01CSgoBu6HQpjY5f4oUqBEE9",
      "questions": [
        {
          "question": "D3 — Should RequestPolicy be a class, or a pure function module?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 9-13 (\"It adds no policy, network call, cache mutation or state. Its separate class boundary remains a proposal to review.\").\nELI10: The plan author describes RequestPolicy as: take claims plus tenant/request context, return allow or deny, hold no state, make no calls. That is the definition of a pure function. Wrapping it in a class adds a constructor, an instance to pass around, and a mock in every AuthBroker test, for zero behavioral gain. A `requestPolicy.ts` exporting `decide(claims, ctx): Decision` keeps the same boundary (own file, own tests) with fewer moving parts. Feature choices, contracts and other fixes are unchanged by this question; it is structure only.\nStakes if we pick wrong: class = one more thing to instantiate and mock everywhere forever; function = if policy later needs injected config, you refactor a file, which is cheap.\nRecommendation: B because a stateless single-method class is a function with ceremony; the plan author already flagged the boundary as questionable, and the file boundary gives the same testability.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) RequestPolicy as a class (as planned)\n  ✅ Symmetric with the other four classes; one construction pattern across the module\n  ✅ Easy to swap via constructor injection if policy ever needs configuration or a strategy\n  ❌ Stateless single-method class: instance + mock in every AuthBroker test for no behavioral gain\n  ❌ Adds to a 5-class count that already tripped the complexity gate\nB) Pure function module `requestPolicy.ts` exporting `decide(claims, ctx)` (recommended)\n  ✅ Same isolation and unit-testability (own file, table-driven tests), zero instantiation or mocking ceremony\n  ✅ Reduces new classes from 5 to 4; \"explicit over clever\" and matches the author's own description (human: ~1h / CC: ~5 min)\n  ❌ If policy later needs injected config, callers change from a free function to an injected dependency (small, mechanical refactor)\nNet: trading class symmetry for one fewer moving part in an already-heavy diff.",
          "header": "D3 RequestPolicy",
          "multiSelect": false,
          "options": [
            {
              "label": "B) Pure function module (recommended)",
              "description": "requestPolicy.ts exports decide(claims, ctx): allow|deny. Own file, own table-driven tests, no instance to construct or mock. New class count drops 5 to 4. Effort: human ~1h / CC ~5 min."
            },
            {
              "label": "A) Keep as a class",
              "description": "RequestPolicy stays a class as planned. Symmetric with the other services and swappable via constructor injection, at the cost of an instance and a mock in every AuthBroker test."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D3 — Should RequestPolicy be a class, or a pure function module?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 9-13 (\"It adds no policy, network call, cache mutation or state. Its separate class boundary remains a proposal to review.\").\nELI10: The plan author describes RequestPolicy as: take claims plus tenant/request context, return allow or deny, hold no state, make no calls. That is the definition of a pure function. Wrapping it in a class adds a constructor, an instance to pass around, and a mock in every AuthBroker test, for zero behavioral gain. A `requestPolicy.ts` exporting `decide(claims, ctx): Decision` keeps the same boundary (own file, own tests) with fewer moving parts. Feature choices, contracts and other fixes are unchanged by this question; it is structure only.\nStakes if we pick wrong: class = one more thing to instantiate and mock everywhere forever; function = if policy later needs injected config, you refactor a file, which is cheap.\nRecommendation: B because a stateless single-method class is a function with ceremony; the plan author already flagged the boundary as questionable, and the file boundary gives the same testability.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) RequestPolicy as a class (as planned)\n  ✅ Symmetric with the other four classes; one construction pattern across the module\n  ✅ Easy to swap via constructor injection if policy ever needs configuration or a strategy\n  ❌ Stateless single-method class: instance + mock in every AuthBroker test for no behavioral gain\n  ❌ Adds to a 5-class count that already tripped the complexity gate\nB) Pure function module `requestPolicy.ts` exporting `decide(claims, ctx)` (recommended)\n  ✅ Same isolation and unit-testability (own file, table-driven tests), zero instantiation or mocking ceremony\n  ✅ Reduces new classes from 5 to 4; \"explicit over clever\" and matches the author's own description (human: ~1h / CC: ~5 min)\n  ❌ If policy later needs injected config, callers change from a free function to an injected dependency (small, mechanical refactor)\nNet: trading class symmetry for one fewer moving part in an already-heavy diff.": "B) Pure function module (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-16T23:07:07.046Z"
    },
    {
      "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
      "toolUseId": "toolu_01HWnupvh9wgHCumEQhNoxnR",
      "questions": [
        {
          "question": "D4 — TokenStore has no stated responsibility in the plan. Define its boundary before building it, fold it into AuthCache, or keep it as-is?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md line 44 (\"5 new classes (AuthBroker, TokenStore, SessionMint, AuthCache, RequestPolicy)\") is the only mention of TokenStore.\nELI10: Four of the five new classes get at least a sentence describing what they do. TokenStore gets its name and nothing else. AuthCache is already described as the facade over the existing token cache adapter, keyed by tenant/issuer/audience/policy version. If TokenStore also stores tokens, that's two classes over one backing cache, which is exactly how tenant-key rules drift apart. If it's something else (say, refresh-token persistence or a per-request holder), the plan needs to say so before someone builds it.\nStakes if we pick wrong: two token-holding abstractions over one adapter = duplicated tenant-key logic and a real cross-tenant leak surface; over-asking = one paragraph added to the plan.\nRecommendation: A because you cannot approve or cut a class nobody has described; a bounded plan amendment (one paragraph: responsibility, owner of tenant keys, relationship to AuthCache) settles it in minutes and the class stays pending until then.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Require a responsibility statement in the plan before TokenStore is built; class stays pending (recommended)\n  ✅ Forces the overlap-with-AuthCache question to be answered on paper, where it costs a paragraph instead of a leak\n  ✅ Approves nothing prematurely; if the statement shows it duplicates AuthCache, folding is a one-line follow-up decision (human: ~30 min / CC: ~2 min)\n  ❌ Adds one round-trip with the plan author before implementation of that class can start\nB) Fold TokenStore into AuthCache now\n  ✅ One class over one backing cache; tenant-key rules live in exactly one place\n  ❌ Assumes TokenStore is a cache duplicate; if it holds a distinct responsibility (e.g. refresh-token persistence) you've just merged two concerns\nC) Keep TokenStore as planned, undefined\n  ✅ No plan churn, implementation starts immediately\n  ❌ Ships a class whose contract nobody wrote down, next to a cache that owns the same nouns\nNet: trading one paragraph of plan text for not guessing what a security-adjacent class does.",
          "header": "D4 TokenStore",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Define before build (recommended)",
              "description": "Plan amendment required: one paragraph stating TokenStore's responsibility, who owns tenant-key logic, and its relationship to AuthCache. Class stays pending until written. Approves no implementation. Effort: human ~30 min / CC ~2 min."
            },
            {
              "label": "B) Fold into AuthCache",
              "description": "Merge TokenStore into AuthCache now. One class over one backing cache. Assumes TokenStore duplicates caching; wrong if it carries a distinct concern."
            },
            {
              "label": "C) Keep as planned",
              "description": "Build TokenStore with its current (absent) description. No plan churn; contract stays unwritten next to a cache owning the same nouns."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D4 — TokenStore has no stated responsibility in the plan. Define its boundary before building it, fold it into AuthCache, or keep it as-is?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md line 44 (\"5 new classes (AuthBroker, TokenStore, SessionMint, AuthCache, RequestPolicy)\") is the only mention of TokenStore.\nELI10: Four of the five new classes get at least a sentence describing what they do. TokenStore gets its name and nothing else. AuthCache is already described as the facade over the existing token cache adapter, keyed by tenant/issuer/audience/policy version. If TokenStore also stores tokens, that's two classes over one backing cache, which is exactly how tenant-key rules drift apart. If it's something else (say, refresh-token persistence or a per-request holder), the plan needs to say so before someone builds it.\nStakes if we pick wrong: two token-holding abstractions over one adapter = duplicated tenant-key logic and a real cross-tenant leak surface; over-asking = one paragraph added to the plan.\nRecommendation: A because you cannot approve or cut a class nobody has described; a bounded plan amendment (one paragraph: responsibility, owner of tenant keys, relationship to AuthCache) settles it in minutes and the class stays pending until then.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Require a responsibility statement in the plan before TokenStore is built; class stays pending (recommended)\n  ✅ Forces the overlap-with-AuthCache question to be answered on paper, where it costs a paragraph instead of a leak\n  ✅ Approves nothing prematurely; if the statement shows it duplicates AuthCache, folding is a one-line follow-up decision (human: ~30 min / CC: ~2 min)\n  ❌ Adds one round-trip with the plan author before implementation of that class can start\nB) Fold TokenStore into AuthCache now\n  ✅ One class over one backing cache; tenant-key rules live in exactly one place\n  ❌ Assumes TokenStore is a cache duplicate; if it holds a distinct responsibility (e.g. refresh-token persistence) you've just merged two concerns\nC) Keep TokenStore as planned, undefined\n  ✅ No plan churn, implementation starts immediately\n  ❌ Ships a class whose contract nobody wrote down, next to a cache that owns the same nouns\nNet: trading one paragraph of plan text for not guessing what a security-adjacent class does.": "A) Define before build (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-16T23:07:29.113Z"
    },
    {
      "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
      "toolUseId": "toolu_015SNnWKQDswcY1WtLFo2feb",
      "questions": [
        {
          "question": "D5 — Share AuthCache by constructing it once at a composition root and injecting it, or keep the module-level mutable export?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 28-29.\nELI10: Two services need the same cache. The plan does this by exporting one mutable object from a module and having both services import it. That works until you test it: every unit test in the process shares that same object, so a test that puts tenant A's token in the cache silently affects the next test, and you cannot hand AuthBroker a fake cache without monkey-patching the module. Injection means: build the one AuthCache in a single startup file, pass it into both constructors. Same single instance in production, but tests construct their own. This question is only about the sharing mechanism; the single-backing-cache and tenant-key contracts stay exactly as the plan states.\nStakes if we pick wrong: module export = flaky auth tests that pass alone and fail in suite, and cross-test tenant bleed that looks like a real leak; injection = two constructor params and one bootstrap file.\nRecommendation: A because it is the standard remedy [Layer 1], costs two constructor parameters, and makes the tenant-isolation tests in the Test review actually trustworthy.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Composition-root injection (recommended)\n  ✅ Every test constructs its own AuthCache over a fake adapter; no shared process state, no reset hooks, no module mocking\n  ✅ Production still has exactly one instance, created once at startup, satisfying the one-backing-cache contract (human: ~half day / CC: ~10 min)\n  ❌ One more file (the root) and explicit wiring in the legacyAuthFlow adapter\nB) Keep module-level mutable export (as planned)\n  ✅ Zero wiring; any module can import the cache\n  ✅ Smallest possible diff for this concern\n  ❌ Process-global mutable state shared by every test and every request path; tenant bleed between tests is indistinguishable from a real leak\n  ❌ Cannot substitute a fake cache without module mocking, which couples tests to the import graph\nNet: trading two constructor parameters for auth tests you can trust.",
          "header": "D5 AuthCache DI",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Composition-root injection (recommended)",
              "description": "Construct AuthCache once in a composition root (auth/index.ts or app bootstrap) and pass it to new AuthBroker(cache) and new SessionMint(cache). No module-level mutable export. Tests build their own instance over a fake adapter. Effort: human ~half day / CC ~10 min."
            },
            {
              "label": "B) Keep module-level export",
              "description": "Keep the module-level mutable AuthCache export imported by both services as planned. Zero wiring, but process-global state shared by all tests and requests; fakes require module mocking."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D5 — Share AuthCache by constructing it once at a composition root and injecting it, or keep the module-level mutable export?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 28-29.\nELI10: Two services need the same cache. The plan does this by exporting one mutable object from a module and having both services import it. That works until you test it: every unit test in the process shares that same object, so a test that puts tenant A's token in the cache silently affects the next test, and you cannot hand AuthBroker a fake cache without monkey-patching the module. Injection means: build the one AuthCache in a single startup file, pass it into both constructors. Same single instance in production, but tests construct their own. This question is only about the sharing mechanism; the single-backing-cache and tenant-key contracts stay exactly as the plan states.\nStakes if we pick wrong: module export = flaky auth tests that pass alone and fail in suite, and cross-test tenant bleed that looks like a real leak; injection = two constructor params and one bootstrap file.\nRecommendation: A because it is the standard remedy [Layer 1], costs two constructor parameters, and makes the tenant-isolation tests in the Test review actually trustworthy.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Composition-root injection (recommended)\n  ✅ Every test constructs its own AuthCache over a fake adapter; no shared process state, no reset hooks, no module mocking\n  ✅ Production still has exactly one instance, created once at startup, satisfying the one-backing-cache contract (human: ~half day / CC: ~10 min)\n  ❌ One more file (the root) and explicit wiring in the legacyAuthFlow adapter\nB) Keep module-level mutable export (as planned)\n  ✅ Zero wiring; any module can import the cache\n  ✅ Smallest possible diff for this concern\n  ❌ Process-global mutable state shared by every test and every request path; tenant bleed between tests is indistinguishable from a real leak\n  ❌ Cannot substitute a fake cache without module mocking, which couples tests to the import graph\nNet: trading two constructor parameters for auth tests you can trust.": "A) Composition-root injection (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-16T23:08:59.413Z"
    },
    {
      "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
      "toolUseId": "toolu_01KeqhmN3qcikyHcAj2ZRrU2",
      "questions": [
        {
          "question": "D6 — Flatten validateAndDispatch() into named steps with one explicit error boundary, or keep the three nested swallowing try/catch blocks?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 32-33.\nELI10: The function that decides whether a request gets in is 60 lines with three try/catch blocks nested inside each other, and each one catches an error and quietly drops it. In an auth path, a silently swallowed error is how a validation failure turns into an allow. Flattening means: split it into validate, decide, dispatch as three small named functions, and put one try/catch at the top that maps each known error class to an explicit outcome and rethrows anything unknown. Same observable behavior for callers today (that is what the regression tests in the Test review pin); what changes is that nothing disappears silently. This is the \"make the change easy\" step that the deferred Promise.all work (D1) needs anyway.\nStakes if we pick wrong: keep nesting = the deferred parallelization has to thread Promise.all rejections through three swallow sites, and the next person cannot tell which catch turned a deny into an allow; flatten = one day of careful work with the regression suite as the net.\nRecommendation: A because the plan already introduces a 60-line function with three silent swallows into an auth path, and explicit-over-clever is the stated preference; with regression tests pinning outcomes, the flatten is low-risk and unblocks D1's follow-up.\nCompleteness: A=10/10, B=7/10, C=3/10\nPros / cons:\nA) Flatten into validate / decide / dispatch with one typed error boundary (recommended)\n  ✅ Every error class has one visible mapping to an outcome; unknown errors rethrow instead of vanishing (human: ~1 day / CC: ~15 min)\n  ✅ Each step is unit-testable alone; the Promise.all follow-up lands on one boundary instead of three\n  ❌ Touches the heart of the auth path; relies on the R7 regression suite existing first\nB) Keep nested structure, add a test per swallowed error class\n  ✅ Pins today's behavior with minimal code change (human: ~half day / CC: ~10 min)\n  ✅ Lower risk in this PR\n  ❌ Leaves three silent swallow sites in an auth path and makes the D1 follow-up harder\nC) Do nothing\n  ✅ Zero effort\n  ❌ Ships 60 lines of nested swallowing into a fresh class with no tests on the swallow paths\nNet: trading one day behind a regression net for an auth path where no error disappears silently.",
          "header": "D6 Error handling",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Flatten with typed boundary (recommended)",
              "description": "Split validateAndDispatch() into validate(), requestPolicy.decide(), dispatch(); one try/catch at the boundary maps each known error class to its current observable outcome (pinned by regression tests), logs where a swallow was silent, rethrows unknown errors. Completeness 10/10. Effort: human ~1 day / CC ~15 min."
            },
            {
              "label": "B) Keep nesting, test each swallow",
              "description": "Keep the three nested try/catch blocks. Add one test per swallowed error class asserting the caller-observable result. Completeness 7/10. Effort: human ~half day / CC ~10 min."
            },
            {
              "label": "C) Do nothing",
              "description": "Ship validateAndDispatch() as described with no tests on the swallow paths. Completeness 3/10."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D6 — Flatten validateAndDispatch() into named steps with one explicit error boundary, or keep the three nested swallowing try/catch blocks?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 32-33.\nELI10: The function that decides whether a request gets in is 60 lines with three try/catch blocks nested inside each other, and each one catches an error and quietly drops it. In an auth path, a silently swallowed error is how a validation failure turns into an allow. Flattening means: split it into validate, decide, dispatch as three small named functions, and put one try/catch at the top that maps each known error class to an explicit outcome and rethrows anything unknown. Same observable behavior for callers today (that is what the regression tests in the Test review pin); what changes is that nothing disappears silently. This is the \"make the change easy\" step that the deferred Promise.all work (D1) needs anyway.\nStakes if we pick wrong: keep nesting = the deferred parallelization has to thread Promise.all rejections through three swallow sites, and the next person cannot tell which catch turned a deny into an allow; flatten = one day of careful work with the regression suite as the net.\nRecommendation: A because the plan already introduces a 60-line function with three silent swallows into an auth path, and explicit-over-clever is the stated preference; with regression tests pinning outcomes, the flatten is low-risk and unblocks D1's follow-up.\nCompleteness: A=10/10, B=7/10, C=3/10\nPros / cons:\nA) Flatten into validate / decide / dispatch with one typed error boundary (recommended)\n  ✅ Every error class has one visible mapping to an outcome; unknown errors rethrow instead of vanishing (human: ~1 day / CC: ~15 min)\n  ✅ Each step is unit-testable alone; the Promise.all follow-up lands on one boundary instead of three\n  ❌ Touches the heart of the auth path; relies on the R7 regression suite existing first\nB) Keep nested structure, add a test per swallowed error class\n  ✅ Pins today's behavior with minimal code change (human: ~half day / CC: ~10 min)\n  ✅ Lower risk in this PR\n  ❌ Leaves three silent swallow sites in an auth path and makes the D1 follow-up harder\nC) Do nothing\n  ✅ Zero effort\n  ❌ Ships 60 lines of nested swallowing into a fresh class with no tests on the swallow paths\nNet: trading one day behind a regression net for an auth path where no error disappears silently.": "A) Flatten with typed boundary (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-16T23:09:59.648Z"
    },
    {
      "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
      "toolUseId": "toolu_01PBL8bo7HDJuHW4U5fNkdr8",
      "questions": [
        {
          "question": "D7 — How should the legacyAuthFlow() regression contract be covered: full characterization matrix with a differential harness and one E2E login, or adapter contract tests on the main paths only?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 23-25 and 36-37.\nELI10: You approved keeping legacyAuthFlow() as a thin adapter (D2). Now: how do you prove the adapter behaves exactly like the old function? The strong way is to write tests against the OLD code first, capturing what it returns or throws for every kind of token (valid, expired, revoked, wrong tenant, wrong audience, suspended tenant, each IDP error), then swap in the adapter and run the same tests unchanged. Add one real end-to-end login so mocking cannot hide a wiring mistake. The weak way is to test four common cases after the fact. This is an auth boundary in a multi-tenant system; the case you skip is the cross-tenant one.\nStakes if we pick wrong: thin coverage = a wrong-tenant or revoked-token path silently changes behavior and the first signal is a customer; full coverage = about 30 CC-minutes of test writing.\nRecommendation: A because this is the single P1 the plan author already flagged, the matrix is cheap with AI, and characterization-before-change is the only way a refactor can prove \"same behavior.\"\nCompleteness: A=10/10, B=7/10\nPros / cons:\nA) Full characterization matrix + differential harness + one E2E login (recommended)\n  ✅ Tests written against current code first, so \"same behavior\" is proven, not asserted; covers cross-tenant, revocation, suspension, and all three swallowed error classes (human: ~3 days / CC: ~30 min)\n  ✅ The same suite protects the D6 flatten and the deferred D1 parallelization PR\n  ❌ Largest test-writing effort in the plan; the differential harness is deleted with the adapter\nB) Adapter contract tests on main paths only\n  ✅ Fast to write, covers the paths most logins take (human: ~1 day / CC: ~10 min)\n  ✅ No throwaway differential harness\n  ❌ Leaves wrong-issuer, wrong-audience, revoked, suspended, stale-policy and the swallowed error classes unpinned in a tenant-isolation boundary\nNet: trading 30 CC-minutes for proof that a multi-tenant auth refactor changed nothing.",
          "header": "D7 Regression",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Full characterization + E2E (recommended)",
              "description": "Characterization tests against current legacyAuthFlow() for the full input matrix (valid, expired, revoked, wrong tenant/issuer/audience, stale policy, suspended tenant, 3 swallowed error classes, cache hit/miss, concurrent same- and cross-tenant), run unchanged against the adapter; differential harness during transition; one E2E login through the real entry point. Completeness 10/10. Effort: human ~3 days / CC ~30 min."
            },
            {
              "label": "B) Main-path adapter tests",
              "description": "Adapter unit tests for valid, expired, wrong tenant, IDP unavailable, written after the adapter lands. Completeness 7/10. Effort: human ~1 day / CC ~10 min."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D7 — How should the legacyAuthFlow() regression contract be covered: full characterization matrix with a differential harness and one E2E login, or adapter contract tests on the main paths only?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 23-25 and 36-37.\nELI10: You approved keeping legacyAuthFlow() as a thin adapter (D2). Now: how do you prove the adapter behaves exactly like the old function? The strong way is to write tests against the OLD code first, capturing what it returns or throws for every kind of token (valid, expired, revoked, wrong tenant, wrong audience, suspended tenant, each IDP error), then swap in the adapter and run the same tests unchanged. Add one real end-to-end login so mocking cannot hide a wiring mistake. The weak way is to test four common cases after the fact. This is an auth boundary in a multi-tenant system; the case you skip is the cross-tenant one.\nStakes if we pick wrong: thin coverage = a wrong-tenant or revoked-token path silently changes behavior and the first signal is a customer; full coverage = about 30 CC-minutes of test writing.\nRecommendation: A because this is the single P1 the plan author already flagged, the matrix is cheap with AI, and characterization-before-change is the only way a refactor can prove \"same behavior.\"\nCompleteness: A=10/10, B=7/10\nPros / cons:\nA) Full characterization matrix + differential harness + one E2E login (recommended)\n  ✅ Tests written against current code first, so \"same behavior\" is proven, not asserted; covers cross-tenant, revocation, suspension, and all three swallowed error classes (human: ~3 days / CC: ~30 min)\n  ✅ The same suite protects the D6 flatten and the deferred D1 parallelization PR\n  ❌ Largest test-writing effort in the plan; the differential harness is deleted with the adapter\nB) Adapter contract tests on main paths only\n  ✅ Fast to write, covers the paths most logins take (human: ~1 day / CC: ~10 min)\n  ✅ No throwaway differential harness\n  ❌ Leaves wrong-issuer, wrong-audience, revoked, suspended, stale-policy and the swallowed error classes unpinned in a tenant-isolation boundary\nNet: trading 30 CC-minutes for proof that a multi-tenant auth refactor changed nothing.": "A) Full characterization + E2E (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-16T23:10:59.906Z"
    },
    {
      "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
      "toolUseId": "toolu_01Cu5WhxAki7KmPtdEZ1DjEZ",
      "questions": [
        {
          "question": "D8 — Record \"coalesce concurrent same-key cache misses\" as a TODO, skip it, or build it in this PR?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 19 and 40.\nELI10: When a tenant's cached token expires and 50 of their users hit the API in the same second, every one of those requests misses the cache and each makes 5 calls to the identity provider: 250 calls for one tenant in one second. The plan says the cache deliberately does not serialize writes, so nothing stops this today. Fixing it (one in-flight promise per cache key) is a behavior change, so it does not belong in a \"no behavior change\" refactor. The question is whether to write it down so it gets done after.\nStakes if we pick wrong: skip = the thundering-herd cost stays invisible until a big tenant's IDP rate-limits you; build now = behavior change hidden in a structural refactor.\nRecommendation: A because it is real, cheap to record, and wrong to build in this PR.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md (recommended)\n  ✅ Captures the problem with enough context to pick up after the D1 parallelization lands, where it belongs\n  ✅ Zero risk to this refactor's \"same behavior\" contract (human: ~10 min / CC: ~1 min)\n  ❌ TODOS.md cannot be written in this session (plan-mode restriction); the entry is presented as not persisted until you add it\nB) Skip\n  ✅ Nothing to track\n  ❌ Known IDP burst cost with no owner\nC) Build now in this PR\n  ✅ Fixes the burst in the same release\n  ❌ Changes IDP call count under concurrency inside a refactor that promises no behavior change; collides with D1's deferral reasoning\nNet: trading one TODO line for not forgetting a 50x IDP burst.",
          "header": "D8 Coalescing TODO",
          "multiSelect": false,
          "options": [
            {
              "label": "A) Add to TODOS.md (recommended)",
              "description": "Record the coalescing work as a follow-up TODO with what/why/pros/cons/context/depends-on. No code in this PR. Presented as not persisted (plan mode forbids writing TODOS.md here)."
            },
            {
              "label": "B) Skip",
              "description": "Do not record it. No owner for the concurrent-miss IDP burst."
            },
            {
              "label": "C) Build now in this PR",
              "description": "Add a single-flight in-flight map keyed by cache key inside AuthCache in this PR. Behavior change inside the refactor."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D8 — Record \"coalesce concurrent same-key cache misses\" as a TODO, skip it, or build it in this PR?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 19 and 40.\nELI10: When a tenant's cached token expires and 50 of their users hit the API in the same second, every one of those requests misses the cache and each makes 5 calls to the identity provider: 250 calls for one tenant in one second. The plan says the cache deliberately does not serialize writes, so nothing stops this today. Fixing it (one in-flight promise per cache key) is a behavior change, so it does not belong in a \"no behavior change\" refactor. The question is whether to write it down so it gets done after.\nStakes if we pick wrong: skip = the thundering-herd cost stays invisible until a big tenant's IDP rate-limits you; build now = behavior change hidden in a structural refactor.\nRecommendation: A because it is real, cheap to record, and wrong to build in this PR.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md (recommended)\n  ✅ Captures the problem with enough context to pick up after the D1 parallelization lands, where it belongs\n  ✅ Zero risk to this refactor's \"same behavior\" contract (human: ~10 min / CC: ~1 min)\n  ❌ TODOS.md cannot be written in this session (plan-mode restriction); the entry is presented as not persisted until you add it\nB) Skip\n  ✅ Nothing to track\n  ❌ Known IDP burst cost with no owner\nC) Build now in this PR\n  ✅ Fixes the burst in the same release\n  ❌ Changes IDP call count under concurrency inside a refactor that promises no behavior change; collides with D1's deferral reasoning\nNet: trading one TODO line for not forgetting a 50x IDP burst.": "A) Add to TODOS.md (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-16T23:12:32.353Z"
    },
    {
      "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
      "toolUseId": "toolu_01KdFH4m8j5Po4XkGs7tsMnj",
      "questions": [
        {
          "question": "D9 — Next step after this engineering review?\nProject/branch/task: main — Multi-tenant Auth Refactor, reviewed plan saved with ENG CLEARED.\nELI10: The review is done and saved. This is navigation only: it approves no implementation change. The working plan's order is T1 (characterization tests) before T5 (adapter); T2/T3 are independent lanes; TokenStore code waits on the plan paragraph (T6).\nStakes if we pick wrong: none; this only chooses what happens next.\nRecommendation: C because no UI scope exists and this is a behavior-preserving refactor, so design and CEO reviews do not apply.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nC) Ready to implement — run /ship when done (recommended)\n  ✅ All relevant reviews are complete; tasks T1–T7 and 5 worktree lanes are in the report\n  ✅ Follow-up PRs (Promise.all, adapter delete) are recorded with owners in the TODO list\n  ❌ Outside-voice coverage is disabled; re-enable codex_reviews if you want a second model's read first\nNet: the plan is ready; the only open items are by design (TokenStore paragraph, follow-up PRs).",
          "header": "D9 Next step",
          "multiSelect": false,
          "options": [
            {
              "label": "C) Ready to implement (recommended)",
              "description": "All relevant reviews complete. Implement T1–T7 in the recorded lane order; run /ship when done. Navigation only, approves no code change."
            },
            {
              "label": "Re-enable outside voice first",
              "description": "Run gstack-config set codex_reviews enabled and re-run /plan-eng-review for an independent second-model read before implementing."
            }
          ]
        }
      ],
      "answered": true,
      "failed": false,
      "answers": {
        "D9 — Next step after this engineering review?\nProject/branch/task: main — Multi-tenant Auth Refactor, reviewed plan saved with ENG CLEARED.\nELI10: The review is done and saved. This is navigation only: it approves no implementation change. The working plan's order is T1 (characterization tests) before T5 (adapter); T2/T3 are independent lanes; TokenStore code waits on the plan paragraph (T6).\nStakes if we pick wrong: none; this only chooses what happens next.\nRecommendation: C because no UI scope exists and this is a behavior-preserving refactor, so design and CEO reviews do not apply.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nC) Ready to implement — run /ship when done (recommended)\n  ✅ All relevant reviews are complete; tasks T1–T7 and 5 worktree lanes are in the report\n  ✅ Follow-up PRs (Promise.all, adapter delete) are recorded with owners in the TODO list\n  ❌ Outside-voice coverage is disabled; re-enable codex_reviews if you want a second model's read first\nNet: the plan is ready; the only open items are by design (TokenStore paragraph, follow-up PRs).": "C) Ready to implement (recommended)"
      },
      "unansweredQuestionIndices": [],
      "answeredAt": "2026-09-16T23:16:23.165Z"
    }
  ],
  "report": "# Reviewed Implementation Plan: Multi-tenant Auth Refactor\n\nReview target: `PLAN.md` (\"Plan: Multi-tenant Auth Refactor\") in repo `gstack-plan-count-izp3S5`, branch `main`, commit 2331049.\nReviewed by: /plan-eng-review (Claude, host: claude) on 2026-09-16.\nRepo evidence: the repository contains only `PLAN.md` and `CLAUDE.md`. No source, tests, or test framework are present, so all \"runtime evidence\" below is **unknown** unless the plan text itself states it.\n\n---\n\n## Original plan (unchanged copy)\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.\n\n---\n\n## Step 0: Scope Challenge\n\n**Complexity gate:** triggered (12 files, 5 new classes; threshold 8+ files or 2+ classes). Resolved via D1-D4 below. Result: **scope reduced per recommendation.**\n\n**Scope Challenge answers**\n\n1. *What existing code partly or fully solves each sub-problem?* The existing cache adapter (tenant/issuer/audience/policy-version keys, expiry eviction, logout/revocation/suspension invalidation hooks, and its tests) already solves caching and invalidation; the plan reuses it unchanged behind AuthCache. `legacyAuthFlow()` already solves login orchestration end to end; it is the behavior the refactor must preserve. No source is present in this repo to verify either (runtime evidence: unknown).\n2. *Minimum changes to achieve the goal?* The stated goal is \"reorganize orchestration without changing product behavior.\" The minimum is: introduce AuthBroker + SessionMint over the existing adapter (via AuthCache), make `legacyAuthFlow()` delegate to them, prove equivalence. Parallelization (behavioral) and a full `legacyAuthFlow()` rewrite (unpinned) are creep relative to that goal.\n3. *Complexity check:* 12 files / 5 classes → after D3 and D4: 3 confirmed classes (AuthBroker, SessionMint, AuthCache) + 1 function module (`requestPolicy.ts`) + 1 class pending definition (TokenStore).\n4. *Search check:* Aside not installed; host WebSearch used for the one new architectural pattern (module-level shared mutable singleton). Standard practice: **[Layer 1]** construct shared state once at a composition root and inject it; module-level mutable singletons leak state between tests and requests. Sources: openreplay.com/singletons-javascript-tool-trap, patterns.dev/vanilla/singleton-pattern, thelazyweb.dev/modules. No custom work found that replaces an available built-in; Promise.all is stdlib (deferred by D1, not cut).\n5. *TODOS cross-reference:* no `TODOS.md` in the repo. Candidate TODOs are proposed in \"TODOS.md updates\" below.\n6. *Completeness check:* the plan's own test plan explicitly excludes `legacyAuthFlow()` compatibility. That shortcut saves human-hours and CC-minutes; it is the one place the plan must not be allowed to cut. Resolved in Test review (D7).\n7. *Distribution check:* no new binary, package, or container; N/A.\n\n**Scope Challenge findings**\n\n| # | Severity | Conf. | Source | Finding | Disposition |\n|---|---|---|---|---|---|\n| S1 | P1 | 9/10 | PLAN.md:39-41 vs :8-9 | \"Parallelized via Promise.all\" is a behavior change inside a plan whose goal is \"without changing its product behavior.\" Error ordering, IDP burst shape, and interaction with the three swallowing catch blocks all change. | **Accepted (D1 → B):** deferred to an immediate follow-up PR after the refactor lands. Not cut. |\n| S2 | P1 | 9/10 | PLAN.md:36-37, :24-25 | Full rewrite of `legacyAuthFlow()` in the same diff as 5 classes / 12 files, with the plan's own tests excluding compatibility. | **Accepted (D2 → B):** strangler adapter. Keep signature and callers; body delegates to AuthBroker; delete in a follow-up PR. Regression contract handled in Test review. |\n| S3 | P2 | 8/10 | PLAN.md:9-13 | RequestPolicy is described as stateless, call-free, single-decision; a class boundary adds ceremony without behavior. | **Accepted (D3 → B):** pure function module `requestPolicy.ts` exporting `decide(claims, ctx)`. Class count 5 → 4. |\n| S4 | P2 | 8/10 | PLAN.md:44 | TokenStore appears only in the class count; no responsibility, tenant-key ownership, or relationship to AuthCache is stated. | **Accepted (D4 → A):** plan amendment required before build (one paragraph: responsibility, tenant-key owner, relationship to AuthCache). Class stays **pending**; approves no implementation. |\n\nScope answers are committed. Scope is not re-argued below.\n\n---\n\n## Working plan (amended by accepted decisions)\n\nAmendments so far (each cites its decision):\n\n- **[D1 → B]** Performance section: Promise.all parallelization moves to a follow-up PR opened immediately after this refactor lands. This PR changes no IDP call ordering or concurrency.\n- **[D2 → B]** Tests section: `legacyAuthFlow()` is **not rewritten**. It keeps its exported signature and all existing callers; its body becomes a thin adapter delegating to `AuthBroker.validateAndDispatch()`. A follow-up PR deletes the adapter once the new path is proven in production.\n- **[D3 → B]** RequestPolicy becomes `requestPolicy.ts` exporting a pure `decide(claims, ctx): 'allow' | 'deny'` (or the existing decision type). No class. `AuthBroker.validateAndDispatch()` calls it after validation and before dispatch, as before.\n- **[D4 → A]** TokenStore is **pending**: before any TokenStore code is written, the plan author adds one paragraph stating (a) its responsibility, (b) whether it holds tenant-keyed data and who owns the tenant-key rule, (c) how it relates to AuthCache and the existing adapter. If (c) reveals overlap, a follow-up decision folds it.\n\nFurther amendments are appended under each review section below.\n\n---\n\n## Decision ledger\n\n### R1: Promise.all parallelization scope\nFinding: S1, P1, 9/10, PLAN.md:39-41, reviewer: Claude (plan-eng-review)\nPlan baseline: original proposal — parallelize 5 IDP calls via Promise.all in this refactor.\nRuntime evidence: unknown (no source in repo). Plan states calls are sequential today and independent.\nQuestion D1: Scope Challenge initial selector (no grid required). Options: A) Include in this refactor; B) Defer to immediate follow-up PR (recommended); C) Cut entirely.\nState: approved\nActual answer: B) Defer to follow-up PR (D1 answer)\nAccepted scope: this PR changes no IDP call ordering or concurrency. A follow-up PR, opened immediately after this refactor lands, parallelizes the 5 calls once regression tests and flattened error handling exist.\nHistory: none\n\n### R2: legacyAuthFlow() disposition\nFinding: S2, P1, 9/10, PLAN.md:36-37, reviewer: Claude\nPlan baseline: original proposal — full rewrite of `legacyAuthFlow()` in this work.\nRuntime evidence: unknown (no source in repo). Plan states it is the existing flow and that planned coverage excludes it.\nQuestion D2: Scope Challenge initial selector. Options: A) Full rewrite now; B) Strangler adapter, delete in follow-up (recommended); C) Leave untouched.\nState: approved\nActual answer: B) Strangler adapter (D2 answer)\nAccepted scope: `legacyAuthFlow()` keeps its exported signature and callers; body delegates to `AuthBroker.validateAndDispatch()`. Delete in a follow-up PR after production proves equivalence. The regression-test contract is a separate decision (R7).\nHistory: none\n\n### R3: RequestPolicy shape\nFinding: S3, P2, 8/10, PLAN.md:9-13, reviewer: Claude\nPlan baseline: original proposal — RequestPolicy as a class (author flagged the boundary as \"a proposal to review\").\nRuntime evidence: unknown; plan states no state, no calls, single decision.\nQuestion D3: Scope Challenge structural selector. Options: A) Class as planned; B) Pure function module `requestPolicy.ts` (recommended).\nState: approved\nActual answer: B) Pure function module (D3 answer)\nAccepted scope: `requestPolicy.ts` exports `decide(claims, ctx)`; own file, table-driven unit tests; called by `validateAndDispatch()` after validation, before dispatch. Class count 5 → 4.\nHistory: none\n\n### R4: TokenStore responsibility\nFinding: S4, P2, 8/10, PLAN.md:44, reviewer: Claude\nPlan baseline: original proposal — TokenStore as one of 5 new classes, undescribed.\nRuntime evidence: unknown; the plan gives no description.\nQuestion D4: Scope Challenge structural selector. Options: A) Define before build, class pending (recommended); B) Fold into AuthCache; C) Keep as planned.\nState: approved (as an investigate/define step; TokenStore implementation itself remains pending)\nActual answer: A) Define before build (D4 answer)\nAccepted scope: plan amendment required (responsibility, tenant-key ownership, relationship to AuthCache) before any TokenStore code. No implementation approved. Fold-or-keep is a follow-up decision once the paragraph exists.\nHistory: none\n\n### R5: AuthCache sharing mechanism (module-level mutable export vs. composition-root injection)\nFinding: A1, P1, 8/10, PLAN.md:28-29 (\"share a global mutable `AuthCache` instance via module-level export. Both services mutate it.\"), reviewer: Claude\nPlan baseline: original proposal — module-level exported mutable singleton, mutated by AuthBroker and SessionMint.\nRuntime evidence: unknown (no source). Plan states AuthCache is a facade over one existing adapter with one backing cache, and that tenant-key rules \"do not serialize mutations.\"\nComparison grid:\n\n| Choice | Current (plan) | A) Composition-root injection | B) Keep module-level export |\n|---|---|---|---|\n| R5 how AuthBroker/SessionMint obtain AuthCache | `import { authCache } from './authCache'` (module-level mutable export) | Constructed once in a composition root (e.g. `auth/index.ts` or the app bootstrap) and passed to `new AuthBroker(cache)` / `new SessionMint(cache)`; no module-level mutable export | Unchanged: module-level export imported by both services |\n| Single backing cache (contract, PLAN.md:20-21) | one adapter, one cache | fixed: still exactly one instance, created at the root | fixed |\n| Tenant-key / validity / invalidation rules (PLAN.md:16-22) | adapter-owned, unchanged | fixed, unchanged | fixed, unchanged |\n| Test isolation | each test shares process-global state | each test constructs its own AuthCache over a fake adapter; no reset hooks | shared instance; tests need reset/`jest.resetModules` or leak state |\n| R1 parallelization | deferred (D1) | pending in follow-up, unchanged | pending in follow-up, unchanged |\n| R2 legacyAuthFlow adapter | approved (D2) | adapter obtains the same root-constructed AuthBroker | adapter imports module-level export |\n| R4 TokenStore | pending (D4) | pending, unchanged | pending, unchanged |\n| Work | — | human: ~half day / CC: ~10 min (one root file + 2 constructor params + adapter wiring) | none |\n\nQuestion D5:\nD5 — Share AuthCache by constructing it once at a composition root and injecting it, or keep the module-level mutable export?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 28-29.\nELI10: Two services need the same cache. The plan does this by exporting one mutable object from a module and having both services import it. That works until you test it: every unit test in the process shares that same object, so a test that puts tenant A's token in the cache silently affects the next test, and you cannot hand AuthBroker a fake cache without monkey-patching the module. Injection means: build the one AuthCache in a single startup file, pass it into both constructors. Same single instance in production, but tests construct their own. This question is only about the sharing mechanism; the single-backing-cache and tenant-key contracts stay exactly as the plan states.\nStakes if we pick wrong: module export = flaky auth tests that pass alone and fail in suite, and cross-test tenant bleed that looks like a real leak; injection = two constructor params and one bootstrap file.\nRecommendation: A because it is the standard remedy [Layer 1], costs two constructor parameters, and makes the tenant-isolation tests in the Test review actually trustworthy.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Composition-root injection (recommended)\n  ✅ Every test constructs its own AuthCache over a fake adapter; no shared process state, no reset hooks, no module mocking\n  ✅ Production still has exactly one instance, created once at startup, satisfying the one-backing-cache contract (human: ~half day / CC: ~10 min)\n  ❌ One more file (the root) and explicit wiring in the legacyAuthFlow adapter\nB) Keep module-level mutable export (as planned)\n  ✅ Zero wiring; any module can import the cache\n  ✅ Smallest possible diff for this concern\n  ❌ Process-global mutable state shared by every test and every request path; tenant bleed between tests is indistinguishable from a real leak\n  ❌ Cannot substitute a fake cache without module mocking, which couples tests to the import graph\nNet: trading two constructor parameters for auth tests you can trust.\nHeader: D5 AuthCache DI\nOptions:\nA) Composition-root injection (recommended)\nConstruct AuthCache once in a composition root (auth/index.ts or app bootstrap) and pass it to new AuthBroker(cache) and new SessionMint(cache). No module-level mutable export. Tests build their own instance over a fake adapter. Effort: human ~half day / CC ~10 min.\nB) Keep module-level export\nKeep the module-level mutable AuthCache export imported by both services as planned. Zero wiring, but process-global state shared by all tests and requests; fakes require module mocking.\n\nState: approved\nActual answer: A) Composition-root injection (D5 answer)\nAccepted scope: AuthCache is constructed exactly once in a composition root (`auth/index.ts` or the app bootstrap) and passed to `new AuthBroker(cache)` and `new SessionMint(cache)`. No module-level mutable export. The `legacyAuthFlow()` adapter (R2) obtains the root-constructed AuthBroker. Unit tests construct their own AuthCache over a fake adapter. Single-backing-cache and tenant-key contracts (PLAN.md:16-22) unchanged. Includes the constructor signatures, root file, adapter wiring, and the tests proving one instance in production wiring.\nHistory: none\n\n### R6: validateAndDispatch() error handling (three nested swallowing try/catch blocks)\nFinding: C1, P1, 9/10, PLAN.md:32-33 (\"60 lines with three nested try/catch blocks; each catch swallows a different error class.\"), reviewer: Claude\nPlan baseline: original proposal — keep `validateAndDispatch()` as described (60 lines, three nested try/catch, each catch swallows one error class). The plan states the shape as a fact and proposes no remedy.\nRuntime evidence: unknown (no source). Plan text is the only evidence of the shape.\nComparison grid:\n\n| Choice | Current (plan) | A) Flatten: pipeline of named steps, one typed error boundary | B) Keep nested try/catch, add tests only | C) Do nothing |\n|---|---|---|---|---|\n| R6 error-handling structure | 3 nested try/catch, each swallows one class | `validate()` → `requestPolicy.decide()` → `dispatch()` as separate named functions; one try/catch at the boundary maps known error classes to explicit outcomes (deny / retry / rethrow); nothing swallowed silently; unknown errors rethrown | unchanged structure; each swallowed class gets a test asserting what the caller observes | unchanged |\n| Observable outcomes per error class | swallowed (caller sees success-shaped or undefined result?) — unknown | **fixed to current observable behavior** (this is a refactor; each class maps to the outcome the caller sees today, pinned by R7 regression tests); logging added where a swallow was silent | unchanged | unchanged |\n| Function length | 60 lines | ~15-line orchestrator + 3 small functions | 60 lines | 60 lines |\n| R1 parallelization follow-up | deferred | lands on flat structure; Promise.all rejection maps at one boundary | lands on nested catches; rejection semantics interact with 3 swallow sites | same as B |\n| R2 adapter, R5 injection | approved | unchanged | unchanged | unchanged |\n| Work | — | human: ~1 day / CC: ~15 min | human: ~half day / CC: ~10 min | none |\n\nQuestion D6:\nD6 — Flatten validateAndDispatch() into named steps with one explicit error boundary, or keep the three nested swallowing try/catch blocks?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 32-33.\nELI10: The function that decides whether a request gets in is 60 lines with three try/catch blocks nested inside each other, and each one catches an error and quietly drops it. In an auth path, a silently swallowed error is how a validation failure turns into an allow. Flattening means: split it into validate, decide, dispatch as three small named functions, and put one try/catch at the top that maps each known error class to an explicit outcome and rethrows anything unknown. Same observable behavior for callers today (that is what the regression tests in the Test review pin); what changes is that nothing disappears silently. This is the \"make the change easy\" step that the deferred Promise.all work (D1) needs anyway.\nStakes if we pick wrong: keep nesting = the deferred parallelization has to thread Promise.all rejections through three swallow sites, and the next person cannot tell which catch turned a deny into an allow; flatten = one day of careful work with the regression suite as the net.\nRecommendation: A because the plan already introduces a 60-line function with three silent swallows into an auth path, and explicit-over-clever is the stated preference; with regression tests pinning outcomes, the flatten is low-risk and unblocks D1's follow-up.\nCompleteness: A=10/10, B=7/10, C=3/10\nPros / cons:\nA) Flatten into validate / decide / dispatch with one typed error boundary (recommended)\n  ✅ Every error class has one visible mapping to an outcome; unknown errors rethrow instead of vanishing (human: ~1 day / CC: ~15 min)\n  ✅ Each step is unit-testable alone; the Promise.all follow-up lands on one boundary instead of three\n  ❌ Touches the heart of the auth path; relies on the R7 regression suite existing first\nB) Keep nested structure, add a test per swallowed error class\n  ✅ Pins today's behavior with minimal code change (human: ~half day / CC: ~10 min)\n  ✅ Lower risk in this PR\n  ❌ Leaves three silent swallow sites in an auth path and makes the D1 follow-up harder\nC) Do nothing\n  ✅ Zero effort\n  ❌ Ships 60 lines of nested swallowing into a fresh class with no tests on the swallow paths\nNet: trading one day behind a regression net for an auth path where no error disappears silently.\nHeader: D6 Error handling\nOptions:\nA) Flatten with typed boundary (recommended)\nSplit validateAndDispatch() into validate(), requestPolicy.decide(), dispatch(); one try/catch at the boundary maps each known error class to its current observable outcome (pinned by regression tests), logs where a swallow was silent, rethrows unknown errors. Completeness 10/10. Effort: human ~1 day / CC ~15 min.\nB) Keep nesting, test each swallow\nKeep the three nested try/catch blocks. Add one test per swallowed error class asserting the caller-observable result. Completeness 7/10. Effort: human ~half day / CC ~10 min.\nC) Do nothing\nShip validateAndDispatch() as described with no tests on the swallow paths. Completeness 3/10.\n\nState: approved\nActual answer: A) Flatten with typed boundary (D6 answer)\nAccepted scope: `validateAndDispatch()` becomes a short orchestrator calling `validate()`, `requestPolicy.decide()`, `dispatch()`. One try/catch at the boundary maps each currently-swallowed error class to the outcome callers observe today (pinned by R7), logs where a swallow was silent, and rethrows unknown errors. Includes unit tests per step and per error-class mapping. No observable behavior change for callers.\nHistory: none\n\n### R7: legacyAuthFlow() regression contract (REGRESSION RULE — mandatory)\nFinding: T1, P1 CRITICAL, 9/10, PLAN.md:23-25 (\"That coverage does not exercise legacyAuthFlow() or assert compatibility with its prior behavior.\") and :36-37 (\"no regression test for the prior behavior is planned.\"), reviewer: Claude\nPlan baseline: original proposal — no regression coverage. D2 approved the strangler adapter (behavior to preserve = every caller-observable outcome of `legacyAuthFlow()`), but the acceptance assertions are not yet approved.\nRuntime evidence: unknown (no source, no test framework detected in repo; TESTFILES:0). The existing adapter tests are stated to exist and remain (PLAN.md:21-22).\nComparison grid:\n\n| Choice | Current (plan) | A) Full characterization + differential + E2E | B) Adapter contract tests, main paths only |\n|---|---|---|---|\n| R7 behavior to preserve | none stated | every caller-observable outcome of `legacyAuthFlow()`: return shape, thrown/returned error per class, cache writes/reads (which keys), for the input matrix below | return shape and error for: valid token, expired token, wrong tenant, IDP unavailable |\n| Input matrix | — | valid; expired; revoked; wrong tenant; wrong issuer; wrong audience; stale policy version; suspended tenant; each of the 3 swallowed IDP/validation error classes; cache hit vs miss; concurrent same-tenant requests; concurrent cross-tenant requests | valid; expired; wrong tenant; IDP unavailable |\n| Mechanism | — | (1) characterization tests written against the CURRENT `legacyAuthFlow()` before the adapter lands, then run unchanged against the adapter; (2) differential harness running old and new on the same fixtures during the transition; (3) one E2E login flow through the real entry point [→E2E] | adapter unit tests written after the adapter lands |\n| Intentional differences | none (D1 deferred; D6 preserves outcomes) | asserted: zero. Any diff = failure | asserted on the 4 paths only |\n| Test isolation (R5) | — | each test constructs its own AuthCache over a fake adapter | same |\n| Work | — | human: ~3 days / CC: ~30 min | human: ~1 day / CC: ~10 min |\n\nQuestion D7:\nD7 — How should the legacyAuthFlow() regression contract be covered: full characterization matrix with a differential harness and one E2E login, or adapter contract tests on the main paths only?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 23-25 and 36-37.\nELI10: You approved keeping legacyAuthFlow() as a thin adapter (D2). Now: how do you prove the adapter behaves exactly like the old function? The strong way is to write tests against the OLD code first, capturing what it returns or throws for every kind of token (valid, expired, revoked, wrong tenant, wrong audience, suspended tenant, each IDP error), then swap in the adapter and run the same tests unchanged. Add one real end-to-end login so mocking cannot hide a wiring mistake. The weak way is to test four common cases after the fact. This is an auth boundary in a multi-tenant system; the case you skip is the cross-tenant one.\nStakes if we pick wrong: thin coverage = a wrong-tenant or revoked-token path silently changes behavior and the first signal is a customer; full coverage = about 30 CC-minutes of test writing.\nRecommendation: A because this is the single P1 the plan author already flagged, the matrix is cheap with AI, and characterization-before-change is the only way a refactor can prove \"same behavior.\"\nCompleteness: A=10/10, B=7/10\nPros / cons:\nA) Full characterization matrix + differential harness + one E2E login (recommended)\n  ✅ Tests written against current code first, so \"same behavior\" is proven, not asserted; covers cross-tenant, revocation, suspension, and all three swallowed error classes (human: ~3 days / CC: ~30 min)\n  ✅ The same suite protects the D6 flatten and the deferred D1 parallelization PR\n  ❌ Largest test-writing effort in the plan; the differential harness is deleted with the adapter\nB) Adapter contract tests on main paths only\n  ✅ Fast to write, covers the paths most logins take (human: ~1 day / CC: ~10 min)\n  ✅ No throwaway differential harness\n  ❌ Leaves wrong-issuer, wrong-audience, revoked, suspended, stale-policy and the swallowed error classes unpinned in a tenant-isolation boundary\nNet: trading 30 CC-minutes for proof that a multi-tenant auth refactor changed nothing.\nHeader: D7 Regression\nOptions:\nA) Full characterization + E2E (recommended)\nCharacterization tests against current legacyAuthFlow() for the full input matrix (valid, expired, revoked, wrong tenant/issuer/audience, stale policy, suspended tenant, 3 swallowed error classes, cache hit/miss, concurrent same- and cross-tenant), run unchanged against the adapter; differential harness during transition; one E2E login through the real entry point. Completeness 10/10. Effort: human ~3 days / CC ~30 min.\nB) Main-path adapter tests\nAdapter unit tests for valid, expired, wrong tenant, IDP unavailable, written after the adapter lands. Completeness 7/10. Effort: human ~1 day / CC ~10 min.\n\nState: approved\nActual answer: A) Full characterization + E2E (D7 answer)\nAccepted scope: **CRITICAL regression contract.** (1) Characterization tests written against the current `legacyAuthFlow()` BEFORE the adapter lands, covering: valid; expired; revoked; wrong tenant; wrong issuer; wrong audience; stale policy version; suspended tenant; each of the 3 currently-swallowed error classes; cache hit vs miss; concurrent same-tenant; concurrent cross-tenant. Assertions: return shape, thrown/returned error per class, and which cache keys are read/written. (2) Differential harness running old and new on identical fixtures during the transition; deleted with the adapter. (3) One E2E login through the real entry point [→E2E]. Intentional differences: zero. Tests construct their own AuthCache over a fake adapter (R5).\nHistory: none\n\n### R8: Request coalescing for concurrent same-key cache misses (TODO proposal)\nFinding: P2 (Performance), P3 severity, 6/10 (medium confidence, verify against production concurrency), PLAN.md:19 (\"they do not serialize mutations\") + :40 (\"5 sequential API calls to the IDP\"), reviewer: Claude\nPlan baseline: no proposal; AuthCache explicitly does not serialize mutations, so N concurrent requests for the same tenant/issuer/audience/policy key on a cold cache each issue 5 IDP calls.\nRuntime evidence: unknown (no source). Whether the existing adapter or callers already coalesce is unverified.\nComparison grid:\n\n| Choice | Current (plan) | A) Add to TODOS.md | B) Skip | C) Build now in this PR |\n|---|---|---|---|---|\n| R8 in-flight request coalescing on cache miss | none | recorded as a follow-up TODO with context; no code in this PR | not recorded | single-flight map keyed by cache key in AuthCache, in this PR |\n| \"No behavior change\" goal | fixed | unchanged | unchanged | violated (changes IDP call count under concurrency) |\n| R1/R2/R5/R6/R7 | approved | unchanged | unchanged | unchanged |\n| Work | — | human: ~10 min / CC: ~1 min | none | human: ~1 day / CC: ~15 min |\n\nQuestion D8:\nD8 — Record \"coalesce concurrent same-key cache misses\" as a TODO, skip it, or build it in this PR?\nProject/branch/task: main — Multi-tenant Auth Refactor, PLAN.md lines 19 and 40.\nELI10: When a tenant's cached token expires and 50 of their users hit the API in the same second, every one of those requests misses the cache and each makes 5 calls to the identity provider: 250 calls for one tenant in one second. The plan says the cache deliberately does not serialize writes, so nothing stops this today. Fixing it (one in-flight promise per cache key) is a behavior change, so it does not belong in a \"no behavior change\" refactor. The question is whether to write it down so it gets done after.\nStakes if we pick wrong: skip = the thundering-herd cost stays invisible until a big tenant's IDP rate-limits you; build now = behavior change hidden in a structural refactor.\nRecommendation: A because it is real, cheap to record, and wrong to build in this PR.\nNote: options differ in kind, not coverage — no completeness score.\nPros / cons:\nA) Add to TODOS.md (recommended)\n  ✅ Captures the problem with enough context to pick up after the D1 parallelization lands, where it belongs\n  ✅ Zero risk to this refactor's \"same behavior\" contract (human: ~10 min / CC: ~1 min)\n  ❌ TODOS.md cannot be written in this session (plan-mode restriction); the entry is presented as not persisted until you add it\nB) Skip\n  ✅ Nothing to track\n  ❌ Known IDP burst cost with no owner\nC) Build now in this PR\n  ✅ Fixes the burst in the same release\n  ❌ Changes IDP call count under concurrency inside a refactor that promises no behavior change; collides with D1's deferral reasoning\nNet: trading one TODO line for not forgetting a 50x IDP burst.\nHeader: D8 Coalescing TODO\nOptions:\nA) Add to TODOS.md (recommended)\nRecord the coalescing work as a follow-up TODO with what/why/pros/cons/context/depends-on. No code in this PR. Presented as not persisted (plan mode forbids writing TODOS.md here).\nB) Skip\nDo not record it. No owner for the concurrent-miss IDP burst.\nC) Build now in this PR\nAdd a single-flight in-flight map keyed by cache key inside AuthCache in this PR. Behavior change inside the refactor.\n\nState: approved\nActual answer: A) Add to TODOS.md (D8 answer)\nAccepted scope: TODO entry recorded (content under \"TODOS.md updates\" below, **not persisted**: plan mode forbids writing `TODOS.md` in this session). No code in this PR.\nHistory: none\n\n**Approval readiness: PASS.** Checked IDs: R1 (D1 → B), R2 (D2 → B), R3 (D3 → B), R4 (D4 → A, investigate/define; TokenStore implementation intentionally pending), R5 (D5 → A), R6 (D6 → A), R7 (D7 → A, regression contract), R8 (D8 → A). No remedy is applied without a cited answer. Open by design: R4's TokenStore build (waits on the plan paragraph); R1's parallelization follow-up (waits on this PR landing).\n\n---\n\n## Working plan — final amendments (all approved)\n\nIn addition to the D1–D4 amendments above:\n\n- **[D5 → A] Architecture:** AuthCache is constructed once in a composition root (`auth/index.ts` or app bootstrap) and injected into `new AuthBroker(cache)` and `new SessionMint(cache)`. Remove the module-level mutable export. The `legacyAuthFlow()` adapter obtains the root-constructed AuthBroker. Single backing cache and tenant-key/validity/invalidation rules unchanged.\n- **[D6 → A] Code quality:** `validateAndDispatch()` becomes a ~15-line orchestrator: `validate()` → `requestPolicy.decide()` → `dispatch()`. One try/catch at the boundary maps each currently-swallowed error class to its current caller-observable outcome, logs where a swallow was silent, rethrows unknown errors.\n- **[D7 → A] Tests:** CRITICAL regression contract as recorded in R7: characterization matrix written against current `legacyAuthFlow()` first, differential harness during transition, one E2E login. Zero intentional differences.\n- **[D8 → A] Performance:** request coalescing recorded as a TODO; no code here.\n\n### Implementation order (structural before behavioral)\n\n```\n PR 1 (this plan)                                     PR 2 (follow-ups, separate)\n ┌──────────────────────────────────────────────┐    ┌──────────────────────────────┐\n │ 1. Characterization tests vs CURRENT         │    │ Promise.all for 5 IDP calls  │\n │    legacyAuthFlow()  [D7]  ── must be green   │    │   [D1 deferred]              │\n │ 2. requestPolicy.ts (pure fn) + tests [D3]   │    ├──────────────────────────────┤\n │ 3. AuthCache facade over existing adapter     │    │ Delete legacyAuthFlow()      │\n │    + composition root + injection [D5]        │    │   adapter  [D2 follow-up]    │\n │ 4. AuthBroker: validate/decide/dispatch +     │    ├──────────────────────────────┤\n │    typed error boundary + tests [D6]          │    │ Coalesce same-key misses     │\n │ 5. SessionMint over injected AuthCache        │    │   [D8 TODO]                  │\n │ 6. legacyAuthFlow() body → adapter [D2]       │    └──────────────────────────────┘\n │ 7. Re-run characterization + differential     │\n │    + E2E: zero diffs  [D7]                    │    PENDING: TokenStore paragraph [D4]\n └──────────────────────────────────────────────┘    before any TokenStore code\n```\n\n### Request flow after refactor\n\n```\n caller ──► legacyAuthFlow(req)            (adapter, signature unchanged)\n               │\n               ▼\n        AuthBroker.validateAndDispatch(req)\n               │\n        ┌──────┴──────────────────────────────────────────┐\n        │ try {                                           │\n        │   claims = await validate(req)   ─► IDP (5 sequential calls, unchanged in PR 1)\n        │                                  ─► AuthCache.get/set (tenant,issuer,aud,policyVer)\n        │   decision = requestPolicy.decide(claims, ctx)  (pure)\n        │   if deny → return <current deny outcome>       │\n        │   return await dispatch(req, claims)            │\n        │ } catch (e) {                                   │\n        │   mapKnownError(e)  // 3 classes → current outcomes, logged\n        │   throw e           // unknown: never swallowed │\n        │ }                                               │\n        └─────────────────────────────────────────────────┘\n\n SessionMint ──► AuthCache (same injected instance) ──► existing adapter (one backing cache)\n```\n\n---\n\n## Section 1: Architecture review\n\n| # | Severity | Conf. | Location | Finding | Disposition |\n|---|---|---|---|---|---|\n| A1 | P1 | 8/10 | PLAN.md:28-29 | Module-level mutable `AuthCache` export shared and mutated by two services: process-global state, untestable without module mocking, cross-test tenant bleed. | **Accepted (D5 → A):** composition-root injection. |\n| A2 | P2 | 8/10 | PLAN.md:44 | TokenStore undefined next to AuthCache, which already owns the token-cache nouns; two abstractions over one adapter is how tenant-key rules drift. | **Accepted (D4 → A):** define before build; pending. |\n| A3 | P2 | 8/10 | PLAN.md:9-13 | RequestPolicy as a class adds a boundary with no state or behavior to isolate. | **Accepted (D3 → B):** pure function module. |\n| A4 | P2 | 7/10 | PLAN.md:19 | \"They do not serialize mutations\" is stated as a retained contract, but two services now write to the cache from different call paths (AuthBroker validation, SessionMint issuance). The plan should state which service owns writes for which key class, or that both write the same key shape idempotently. | **Accepted as documentation requirement, no code change:** add one sentence to the plan's contracts section naming write ownership per key. Carried into T6. |\n| A5 | P3 | 7/10 | PLAN.md:8-9 | Blast radius: a \"reorganization\" of tenant auth touches every authenticated request. No rollout mechanism (flag, canary) is named. The strangler adapter (D2) gives one-function rollback; a feature flag selecting old vs new body inside the adapter would give runtime rollback without a deploy. | **Noted; not a decision in this review.** Recommended as an implementation detail of T5: flag defaults to new path once characterization is green. Recorded in \"NOT in scope\" as optional. |\n\nProduction failure scenarios per new codepath:\n- **AuthBroker.validateAndDispatch:** IDP returns 503 on call 3 of 5. Today: swallowed by one of three catches; outcome unknown. After D6: mapped explicitly to the current outcome and logged; after D7: pinned by test. Accounted for.\n- **AuthCache facade:** tenant suspension hook fires mid-request. Adapter behavior unchanged (plan retains hooks); facade must not cache the pre-suspension result. Covered by the R7 \"suspended tenant\" case. Accounted for.\n- **SessionMint:** writes a session for tenant A using a key built from a claims object that AuthBroker already cached. If the two services build the key differently, one reads the other's miss. A4 addresses this; R7 concurrent cross-tenant case detects it.\n- **Composition root:** a second code path constructs its own AuthCache (two backing caches). Test in T3 asserts singleton wiring in production config.\n- **legacyAuthFlow adapter:** adapter forwards a subtly different argument shape. Differential harness (R7) detects it before merge.\n\nDistribution architecture: no new artifact. N/A.\n\n## Section 2: Code quality review\n\n| # | Severity | Conf. | Location | Finding | Disposition |\n|---|---|---|---|---|---|\n| C1 | P1 | 9/10 | PLAN.md:32-33 | 60-line `validateAndDispatch()` with three nested try/catch blocks, each swallowing a different error class. In an auth path a swallowed error is a potential deny→allow. | **Accepted (D6 → A):** flatten with one typed boundary. |\n| C2 | P2 | 7/10 | PLAN.md:28-29, :44 | DRY: AuthCache and TokenStore both name token storage over one adapter; and two services both mutate the cache. If each service builds cache keys itself, the (tenant, issuer, audience, policyVersion) tuple is constructed in 2+ places. Key construction must live in exactly one function inside AuthCache (or the adapter). | **Accepted as part of D5 scope** (AuthCache owns key construction; services never build keys). Carried into T3. |\n| C3 | P2 | 6/10 | PLAN.md:12 | Medium confidence, verify: RequestPolicy \"adds no policy\" but is described as grouping the \"existing per-request access decision.\" If that decision currently lives inline in `legacyAuthFlow()` and also somewhere else (e.g. middleware), extracting one copy leaves a duplicate. Grep for the existing deny logic before extracting. | **Accepted as a pre-implementation check** in T2 (bounded grep, no code change decided). |\n| C4 | P3 | 8/10 | whole plan | No inline ASCII diagrams planned for the pipeline or the cache key/invalidation rules. Files that need them: `authBroker.ts` (pipeline + error mapping), `authCache.ts` (key tuple + invalidation triggers), `legacyAuthFlow.ts` adapter (transitional note with delete-by condition). | **Accepted as documentation within approved tasks** (T3, T4, T5). No separate decision needed. |\n\nExisting ASCII diagrams in touched files: none known (no source in repo).\n\n## Section 3: Test review\n\nTest framework: **unknown** (CLAUDE.md has no `## Testing` section; no runtime markers or test files in this repo). Plan states existing adapter tests exist and remain. Framework selection is not decided here; use whatever the existing adapter tests use.\n\n### Coverage diagram\n\n```\nCODE PATHS                                                        USER FLOWS\n[+] auth/requestPolicy.ts (D3)                                    [+] Login (via legacyAuthFlow adapter, D2)\n  └── decide(claims, ctx)                                           ├── [GAP→R7] [→E2E] Valid login → authed request → logout → denied\n      ├── [GAP] allow (matching tenant, valid claims)               ├── [GAP→R7]        Expired token → denied, evicted\n      ├── [GAP] deny: wrong tenant                                  ├── [GAP→R7]        Revoked token → denied\n      ├── [GAP] deny: wrong issuer / audience                       ├── [GAP→R7]        Suspended tenant → denied\n      ├── [GAP] deny: stale policy version                          └── [GAP→R7]        Cross-tenant token → denied, no tenant-B cache read\n      └── [GAP] null/empty claims → deny (never throw)\n[+] auth/authCache.ts (D5)                                        [+] Concurrency\n  ├── constructor(adapter)                                          ├── [GAP→R7]        Same tenant, cold cache, N parallel → all succeed\n  ├── [GAP] get(key): hit / miss                                    └── [GAP→R7]        Different tenants in parallel → no bleed\n  ├── [GAP] set(key): idempotent for same tuple\n  ├── [GAP] buildKey(): single source of the 4-tuple (C2)          [+] Error states (user-visible)\n  └── [★★★ TESTED*] adapter expiry/invalidation — existing tests   ├── [GAP→R7]        IDP unavailable → clear error, no silent allow\n      (*asserted by plan, not verified here)                        ├── [GAP→D6]        Each of 3 swallowed classes → same outcome as today + log\n[+] auth/authBroker.ts (D6)                                         └── [GAP→D6]        Unknown error → rethrown, surfaced\n  └── validateAndDispatch()\n      ├── [GAP] validate(): 5 IDP calls, per-call failure           [+] Wiring\n      ├── [GAP] decide() deny → current deny outcome                ├── [GAP→D5]        Production root constructs exactly one AuthCache\n      ├── [GAP] dispatch() success                                  └── [GAP→D5]        Test can inject fake adapter without module mocks\n      ├── [GAP] boundary: error class 1/2/3 → mapped outcome\n      └── [GAP] boundary: unknown error → rethrow                  [+] Pending\n[+] auth/sessionMint.ts                                             ├── TokenStore (D4) — untestable until defined\n  ├── [GAP] mint over injected cache                                └── Promise.all (D1) — tests belong to follow-up PR\n  └── [GAP] cache write uses AuthCache.buildKey, never own key\n[+] auth/legacyAuthFlow.ts (adapter, D2)\n  ├── [GAP→R7] characterization matrix (12 cases) vs CURRENT code, then vs adapter\n  └── [GAP→R7] differential harness: zero diffs\n[+] auth/index.ts (composition root, D5)\n  └── [GAP] one instance, injected into both services\n\nLLM integration: none — no [→EVAL] paths.\n\nCOVERAGE: 1/34 paths tested (3%)  |  Code paths: 1/22 (5%)  |  User flows: 0/12 (0%)\nQUALITY: ★★★:1 (existing adapter tests, plan-asserted) ★★:0 ★:0  |  GAPS: 33 (1 E2E, 0 eval)\n```\n\nLegend: ★★★ behavior + edge + error | ★★ happy path | ★ smoke | [→E2E] integration test | [GAP→Rn/Dn] required by that approved decision.\n\nAll 33 gaps are covered by approved scope: R7 (regression matrix, differential, E2E), D6 (per-step and per-error-class unit tests), D5 (wiring tests), D3 (table-driven `decide()` tests). No test requirement is left pending except TokenStore (blocked on D4 paragraph) and Promise.all (follow-up PR).\n\n| # | Severity | Conf. | Location | Finding | Disposition |\n|---|---|---|---|---|---|\n| T1 | P1 CRITICAL | 9/10 | PLAN.md:23-25, :36-37 | Rewrite of the live login path with coverage that explicitly excludes it. | **Accepted (D7 → A):** full characterization + differential + E2E. |\n| T2 | P2 | 8/10 | PLAN.md:23-24 | \"Unit and integration coverage for success/error paths\" of new components does not name the tenant-isolation cases (cross-tenant, suspended, revoked). | **Accepted, folded into R7 scope** (matrix names them). |\n| T3 | P2 | 8/10 | PLAN.md:28-29 | Shared mutable singleton makes any tenant-isolation test untrustworthy (state leaks between tests). | **Accepted (D5 → A)** removes the cause. |\n\nQA Test Plan artifact written: `~/.gstack/projects/gstack-plan-count-izp3S5/vercel-sandbox-main-eng-review-test-plan-20260916-231211.md`.\n\n## Section 4: Performance review\n\n| # | Severity | Conf. | Location | Finding | Disposition |\n|---|---|---|---|---|---|\n| P1 | P2 | 8/10 | PLAN.md:40-41 | 5 sequential IDP round trips per token validation; independent calls. | **Deferred (D1 → B):** follow-up PR immediately after this refactor; lands on the flattened boundary (D6) with regression tests (D7) in place. Not cut. |\n| P2 | P3 | 6/10 | PLAN.md:19, :40 | Medium confidence, verify against production concurrency: no serialization of mutations means N concurrent same-key misses each pay 5 IDP calls (thundering herd on tenant token expiry). | **Accepted (D8 → A):** TODO, not persisted. |\n| P3 | P3 | 7/10 | PLAN.md:20-21 | AuthCache as a facade adds one indirection per lookup over the existing adapter: negligible. No N+1 or memory concern introduced; the facade holds no state of its own. | No action. |\n\nCaching opportunities beyond the above: none new; the plan already reuses the existing adapter.\n\n---\n\n## NOT in scope\n\n- **Promise.all parallelization of the 5 IDP calls** (D1): follow-up PR right after this refactor lands, so the structural change stays bisectable.\n- **Deleting `legacyAuthFlow()`** (D2): follow-up PR once the adapter has proven equivalence in production.\n- **TokenStore implementation** (D4): blocked until the plan states its responsibility and relationship to AuthCache.\n- **Request coalescing for concurrent same-key misses** (D8): TODO; it is a behavior change.\n- **Runtime feature flag inside the adapter for old/new body selection** (A5): optional hardening, not decided here; the adapter already gives one-function rollback by deploy.\n- **Test framework selection**: unknown in this repo; reuse whatever the existing adapter tests use.\n\n## What already exists\n\n- **Existing cache adapter** (keys: tenant, issuer, audience, policy version; expiry eviction; logout/revocation/suspension invalidation; tests): **reused** unchanged behind AuthCache. Correct call; do not rebuild.\n- **`legacyAuthFlow()`**: the working login orchestration. Plan originally **rebuilt** it; after D2 it is **reused** as the adapter boundary and as the oracle for characterization tests.\n- **Existing per-request access decision** (wherever it lives today): **extracted** into `requestPolicy.decide()`. C3 requires a grep for duplicates before extraction so one copy does not survive inline.\n- **`Promise.all`** (stdlib): the right tool for the deferred parallelization; nothing custom needed.\n\n## Diagrams\n\nPlan-level diagrams: implementation order and request flow (above). Files that need inline ASCII diagrams in code comments:\n- `auth/authBroker.ts`: validate → decide → dispatch pipeline with the error-class → outcome table.\n- `auth/authCache.ts`: key tuple and invalidation triggers (logout, revocation, suspension, expiry), one owner of `buildKey()`.\n- `auth/legacyAuthFlow.ts`: transitional adapter note: \"delegates to AuthBroker; delete when <condition>\".\n- `auth/index.ts`: composition root showing the single AuthCache fanning into AuthBroker and SessionMint.\n\n## Failure modes\n\n| New path | Realistic production failure | Test | Error handling | User sees | Critical gap? |\n|---|---|---|---|---|---|\n| validateAndDispatch boundary | IDP 503 on call 3 of 5 | R7 + D6 tests | explicit mapping (D6) | same outcome as today, now logged | No |\n| validateAndDispatch boundary | unexpected exception type (e.g. JSON parse) | D6 unknown-error test | rethrow (D6) | error surfaces, not silent allow | No |\n| requestPolicy.decide | null/undefined claims after a swallowed validation error | D3 table test | must return deny, never throw | denied | No |\n| AuthCache facade | second code path constructs its own AuthCache → two caches, stale invalidation | D5 wiring test | composition root is the only constructor call | none if test holds | No |\n| AuthCache facade | SessionMint and AuthBroker build keys differently | C2 (single buildKey) + R7 cross-tenant | keys built in one place | none | No |\n| legacyAuthFlow adapter | argument shape drift between old signature and AuthBroker | R7 differential harness | n/a (caught pre-merge) | none | No |\n| Concurrency (cold cache) | thundering herd, IDP rate-limits tenant | R7 concurrent test measures; no fix | none in this PR (D8 TODO) | slow or failed logins for that tenant until cache warms | **Not critical for this PR** (pre-existing behavior, explicitly deferred with owner) |\n\n**Critical gaps: 0.** Every new path has an approved test and explicit handling; the one uncovered failure is pre-existing and recorded as a TODO with an owner.\n\n## Worktree parallelization strategy\n\n| Step | Modules touched | Depends on |\n|---|---|---|\n| 1. Characterization tests vs current legacyAuthFlow | `auth/__tests__/` (or existing test dir), fixtures | — |\n| 2. requestPolicy.ts + table tests | `auth/requestPolicy` | — (grep for duplicate deny logic first, C3) |\n| 3. AuthCache facade + composition root + wiring tests | `auth/authCache`, `auth/index` | — |\n| 4. AuthBroker (validate/decide/dispatch + boundary) + tests | `auth/authBroker` | 2, 3 |\n| 5. SessionMint over injected cache + tests | `auth/sessionMint` | 3 |\n| 6. legacyAuthFlow adapter | `auth/legacyAuthFlow` | 1, 4 |\n| 7. Differential + E2E, zero diffs | test dir, E2E harness | 6 |\n\nParallel lanes:\n- `Lane A: step 1 (independent — must be green before anything replaces legacyAuthFlow)`\n- `Lane B: step 2 (independent)`\n- `Lane C: step 3 (independent)`\n- `Lane D: step 4 → step 6 → step 7 (sequential, shared auth/authBroker + auth/legacyAuthFlow)`\n- `Lane E: step 5 (independent after C)`\n\nExecution order: Launch A + B + C in parallel worktrees. Merge all three. Then launch D and E in parallel. Merge E. Finish D (6 then 7).\n\nConflict flags: `auth/index.ts` (composition root) is touched by C, D and E: have C land it first with both constructor call sites stubbed, so D and E only fill in. Test fixtures from A are consumed by D step 7: keep them in a shared fixtures module, not inline.\n\n## Implementation Tasks\nSynthesized from this review's findings. Each task derives from a specific\nfinding above. Run with Claude Code or Codex; checkbox as you ship.\n\n- [ ] **T1 (P1, human: ~3 days / CC: ~30 min)** — legacyAuthFlow regression — Write characterization tests against the CURRENT `legacyAuthFlow()` for the 12-case matrix (valid, expired, revoked, wrong tenant/issuer/audience, stale policy, suspended tenant, 3 swallowed error classes, cache hit/miss, concurrent same/cross tenant), plus a differential harness and one E2E login. Must be green before T5.\n  - Surfaced by: Test review — T1 / R7 (D7 → A)\n  - Files: existing test directory (`auth/__tests__/legacyAuthFlow.characterization.test.*`), shared fixtures module, E2E harness\n  - Verify: suite passes against unchanged `legacyAuthFlow()`; later passes unchanged against the adapter with zero diffs\n- [ ] **T2 (P2, human: ~1h / CC: ~5 min)** — requestPolicy — Create `auth/requestPolicy.ts` exporting pure `decide(claims, ctx)`; table-driven tests for allow, wrong tenant, wrong issuer/audience, stale policy, null/empty claims → deny. First grep for existing inline deny logic (C3) so exactly one copy remains.\n  - Surfaced by: Scope Challenge — S3 (D3 → B); Code quality — C3\n  - Files: `auth/requestPolicy.ts`, `auth/__tests__/requestPolicy.test.*`\n  - Verify: table test passes; grep shows no second copy of the deny decision\n- [ ] **T3 (P1, human: ~half day / CC: ~10 min)** — AuthCache + composition root — Implement `AuthCache` as a facade over the existing adapter with `buildKey()` as the single owner of the (tenant, issuer, audience, policyVersion) tuple; construct once in `auth/index.ts`; inject into AuthBroker and SessionMint; remove the module-level export. Add an inline ASCII diagram of key tuple + invalidation triggers. Test: production wiring yields exactly one instance; tests inject a fake adapter without module mocks.\n  - Surfaced by: Architecture — A1 (D5 → A), A4; Code quality — C2, C4\n  - Files: `auth/authCache.ts`, `auth/index.ts`, `auth/__tests__/authCache.test.*`\n  - Verify: wiring test; existing adapter tests still pass unchanged\n- [ ] **T4 (P1, human: ~1 day / CC: ~15 min)** — AuthBroker — Implement `validateAndDispatch()` as `validate()` → `requestPolicy.decide()` → `dispatch()` with one typed error boundary mapping each currently-swallowed class to its current outcome (logged) and rethrowing unknown errors. Inline ASCII pipeline diagram with the error → outcome table. Unit tests per step and per error class, including unknown-error rethrow.\n  - Surfaced by: Code quality — C1 (D6 → A)\n  - Files: `auth/authBroker.ts`, `auth/__tests__/authBroker.test.*`\n  - Verify: unit tests; T1 characterization suite unchanged and green after T5\n- [ ] **T5 (P1, human: ~2h / CC: ~10 min)** — legacyAuthFlow adapter — Keep the exported signature; body delegates to the root-constructed AuthBroker. Inline comment: \"transitional adapter, delete when characterization + production equivalence hold.\" Run T1 suite + differential + E2E: zero diffs.\n  - Surfaced by: Scope Challenge — S2 (D2 → B); Architecture — A5 (rollback note)\n  - Files: `auth/legacyAuthFlow.ts`\n  - Verify: T1 suite green unchanged; differential harness reports 0 differences; E2E login passes\n- [ ] **T6 (P2, human: ~30 min / CC: ~2 min)** — Plan amendments — Add to PLAN.md: (a) TokenStore paragraph: responsibility, tenant-key ownership, relationship to AuthCache (blocks any TokenStore code); (b) one sentence naming which service owns cache writes for which key class.\n  - Surfaced by: Scope Challenge — S4 (D4 → A); Architecture — A4\n  - Files: `PLAN.md`\n  - Verify: paragraph present; follow-up decision (fold or keep TokenStore) taken from it\n- [ ] **T7 (P2, human: ~1h / CC: ~10 min)** — SessionMint — Implement over the injected AuthCache; cache writes go through `AuthCache.buildKey()`, never a locally built key. Tests: mint success; write uses shared key builder.\n  - Surfaced by: Architecture — A1/A4; Code quality — C2\n  - Files: `auth/sessionMint.ts`, `auth/__tests__/sessionMint.test.*`\n  - Verify: unit tests; R7 concurrent cross-tenant case green\n\n_Performance review produced no tasks for this PR: P1 deferred to a follow-up PR (D1), P2 recorded as a TODO (D8)._\n\nEffort assumption: tests ~50x, architecture ~5x, bug-fix-with-regression ~20x human÷CC; the adapter is small so its ratio is ~12x.\n\n## TODOS.md updates\n\n`TODOS.md` does not exist in this repo and plan mode forbids creating it in this session. All entries below are **not persisted**; add them to `TODOS.md` when implementing.\n\n**TODO 1 — Parallelize the 5 IDP calls (disposition: reuse D1 → B, defer to follow-up PR)**\n- What: replace 5 sequential IDP calls in `validate()` with `Promise.all` (or `Promise.allSettled` if partial results matter).\n- Why: 5 serial round trips on every token validation; calls are independent.\n- Pros: ~5x latency reduction on validation; trivial code.\n- Cons: changes error ordering and IDP burst shape; must land on the flattened boundary (D6) with regression tests (D7) green.\n- Context: deferred from the refactor so the structural PR stays bisectable. Start at `auth/authBroker.ts::validate()`; the error boundary already maps classes, so Promise.all's first rejection maps at one place.\n- Depends on: this refactor merged; T1 suite green.\n\n**TODO 2 — Delete the `legacyAuthFlow()` adapter (disposition: reuse D2 → B follow-up)**\n- What: remove the adapter and point callers at AuthBroker directly; delete the differential harness.\n- Why: transitional shim only.\n- Pros: one fewer layer.\n- Cons: touches every caller; do it only after production equivalence is observed.\n- Context: adapter carries a \"delete when\" comment (T5). Characterization tests stay; re-point them at AuthBroker.\n- Depends on: adapter in production for one release with no auth incidents.\n\n**TODO 3 — Define TokenStore (disposition: reuse D4 → A)**\n- What: one paragraph in PLAN.md: responsibility, tenant-key ownership, relationship to AuthCache; then decide fold vs keep.\n- Why: undescribed class next to a cache owning the same nouns.\n- Depends on: nothing; blocks any TokenStore code.\n\n**TODO 4 — Coalesce concurrent same-key cache misses (disposition: D8 → A)**\n- What: single in-flight promise per cache key inside AuthCache; concurrent misses await the same validation.\n- Why: N concurrent misses for one tenant each pay 5 IDP calls (thundering herd on expiry).\n- Pros: bounds IDP load per key to one validation at a time; protects against tenant-level IDP rate limits.\n- Cons: behavior change (call count under concurrency); needs a test for the failed-in-flight case (all waiters see the error, map is cleared).\n- Context: AuthCache deliberately does not serialize mutations (PLAN.md:19). Add the in-flight map alongside, not inside, the adapter. Measure first with the R7 concurrent same-tenant test's IDP call count.\n- Depends on: TODO 1 (so the coalesced unit is the parallel validation, not 5 serial calls).\n\n## Unresolved decisions that may bite you later\n\nNone in this review. All eight D-numbered choices have actual answers. Two items are open by design, not unresolved: TokenStore implementation (waits on the D4 paragraph, T6) and the Promise.all follow-up (waits on this PR landing, D1).\n\n## Suppressed findings (appendix, confidence ≤ 5 or unverifiable)\n\n- (4/10) PLAN.md:12 \"AuthBroker.validateAndDispatch() calls it after validation and before dispatch\": if any caller today skips the access decision on cache hit, moving the decision into the broker changes behavior for cache hits. Unverifiable without source; R7 cache hit/miss case would catch it.\n- (4/10) PLAN.md:16-17 policy version in the cache key: if SessionMint mints sessions under a policy version that later bumps, sessions minted pre-bump may outlive the cache entry. Pre-existing if true; out of this refactor's scope.\n- (3/10) 12 files touched: the count may include the root, adapter, and test files; after D3/D4 the class count is 3 confirmed + 1 pending, so the file count likely drops below the gate as well. Not re-argued per scope commitment.\n\n## Completion summary\n\n- Step 0: Scope Challenge — scope reduced per recommendation (D1 deferred Promise.all, D2 strangler adapter, D3 RequestPolicy → function, D4 TokenStore pending definition)\n- Architecture Review: 5 issues found (A1–A5)\n- Code Quality Review: 4 issues found (C1–C4)\n- Test Review: diagram produced, 33 gaps identified (all covered by approved scope; 3 findings T1–T3)\n- Performance Review: 3 issues found (P1 deferred, P2 TODO, P3 no action)\n- NOT in scope: written\n- What already exists: written\n- TODOS.md updates: 4 items proposed to user (1 new via D8; 3 reuse D1/D2/D4 dispositions); not persisted\n- Failure modes: 0 critical gaps flagged\n- Unresolved decisions: 0 in this review\n- Outside voice: provider codex, disabled (codex_reviews=disabled); no native replacement; recorded as skipped/disabled\n- Parallelization: 5 lanes, 4 parallel / 1 sequential (lane D)\n- Lake Score: 2/2 (D6 and D7 were coverage choices; both selected 10/10)\n\n## GSTACK REVIEW REPORT\n\n| Review | Trigger | Why | Runs | Status | Findings |\n|--------|---------|-----|------|--------|----------|\n| CEO Review | `/plan-ceo-review` | Scope & strategy | 0 | — | — |\n| Outside Review | codex via `/plan-eng-review` (codex-plan-review) | Independent 2nd opinion | 1 | DISABLED (host: claude, outside_provider: codex, outside_status: disabled, phase: plan-review) | skipped by config; no findings |\n| Eng Review | `/plan-eng-review` | Architecture & tests (required) | 1 | CLEAR (this run, mode: SCOPE_REDUCED, commit 2331049) | 45 issues, 0 critical gaps |\n| Design Review | `/plan-design-review` | UI/UX gaps | 0 | — | — |\n| DX Review | `/plan-devex-review` | Developer experience gaps | 0 | — | — |\n\n- **OUTSIDE COVERAGE:** provider codex, phase plan-review, disabled by `codex_reviews=disabled`; no outside or native replacement review ran; no outside findings. Re-enable with `gstack-config set codex_reviews enabled`.\n- **VERDICT:** ENG CLEARED — ready to implement (scope reduced per D1–D4; TokenStore code blocked on the D4 plan paragraph; Promise.all parallelization is a follow-up PR).\n\nNO UNRESOLVED DECISIONS\n",
  "provenance": {
    "runId": "ship-all-6aef8d74-c596dc24-a45d-4b9f-83bd-b1b676000695",
    "attempt": "plan-eng-review-1789599842085-SWV2Hu",
    "reportSha256": "da19b4c49109874a9f95d1e409e949e3f5f83b6428a32c23f7ac0772ef044e84",
    "reportMtimeMs": 1789600523605.8892,
    "nativeReady": [
      {
        "sessionId": "ad1b5c99-3d17-4e0a-b14d-36e9f3188c9b",
        "toolUseId": "toolu_01JTSVSGKofBzpgBMTfoxc8w",
        "timestamp": "2026-09-16T23:17:03.231Z",
        "failed": false,
        "source": "pre_tool_use"
      }
    ],
    "originalPacketSha256": "ff1ecaacd2ff09cd5e96f1ba9ffa0817b5f716d4589b866e59c3f7eb8a15cd2c",
    "windowStartQualification": "Spool-start lower bound; every answer is minutes later, not a claim of exact test startedAt",
    "cancellationReceipt": "/home/vercel-sandbox/gstack/.context/nouakchott-6aef8d74-monitor/overall/checkpoint-cancellation/execution-receipt-20260916T232305.570898Z.json"
  }
}