Review the generated change adversarially, test it, and produce evidence that it is ready for handoff.
examples/demo-app/src/auth/session-store.tsexamples/demo-app/tests/auth/refresh-token.test.ts
- Implement Phase 1 only.
- Inspect the diff for scope drift.
- Run adversarial code review.
- Add meaningful tests.
- Run
pnpm test. - Fix failures without guessing.
- Create PR handoff notes.
cd examples/demo-app
pnpm test
pnpm demoReview this change as if you are the strictest reviewer on the team.
Focus on:
1. scope drift,
2. behavioral regressions,
3. missing tests,
4. unnecessary complexity,
5. mismatch with the Implementation Plan.
Return findings first, ordered by severity.
Use this outline:
- summary of what changed
- files touched
- tests run
- risks or open questions
- follow-up work
Use these questions during the diff review:
- Did the change follow the Implementation Plan?
- Did it touch files outside the approved work package?
- What assumptions are still untested?
- What would a skeptical reviewer flag?
- Is there a simpler implementation that preserves behavior?
- working code branch or patch
- review findings
- verification evidence
- PR handoff
- reusable verification gate candidate
The review findings, verification evidence, and PR handoff become required workflow phases and output artifacts in Lab 06.
One correct end-state is a single change in SessionStore.rotate (src/auth/session-store.ts): delete the previously presented refresh token from the store when the new one is issued, so only the new token validates. Compare against your own change after review and testing — do not start from it.
This lab passes when:
- the diff has been reviewed against the plan
- verification commands were actually run
- the evidence is recorded clearly enough for a reviewer to evaluate
- the PR handoff explains risks, follow-ups, and what was verified
What issue would have escaped if you had only run tests and skipped a structured diff review?