satellite-provider/_docs/03_implementation/reviews/batch_02_cycle3_review.md

Code Review Report — Batch 02 cycle 3

Batch: 02 (cycle 3) — AZ-491 (consolidate JWT test-mint helpers) Date: 2026-05-12 Verdict: PASS_WITH_WARNINGS

Findings

#	Severity	Category	File:Line	Title
1	Low	Maintainability	SatelliteProvider.TestSupport/SatelliteProvider.TestSupport.csproj:10-11	Pinned System.IdentityModel.Tokens.Jwt 7.0.3 lives alongside the API's transitive Microsoft.AspNetCore.Authentication.JwtBearer 8.0.25

Finding Details

F1: Pinned System.IdentityModel.Tokens.Jwt 7.0.3 lives alongside the API's transitive Microsoft.AspNetCore.Authentication.JwtBearer 8.0.25 (Low / Maintainability)

• Location: SatelliteProvider.TestSupport/SatelliteProvider.TestSupport.csproj:10-11
• Description: TestSupport's two pinned packages (Microsoft.IdentityModel.Tokens 7.0.3, System.IdentityModel.Tokens.Jwt 7.0.3) are the same versions that the integration-tests project previously pinned directly. These are not the same package family as the API's Microsoft.AspNetCore.Authentication.JwtBearer 8.0.25 — they belong to a different .NET versioning track. Token-minting logic in the test library and token-validation logic in the API consume related-but-separate IdentityModel types, so this is structurally fine, but a future agent reading the csproj could be confused about why the test library is one major version behind the API. The pre-AZ-491 IntegrationTests csproj had the same pinning; this batch preserved it for parity.
• Suggestion: Defer. The 7.0.x → 8.0.x bump for System.IdentityModel.Tokens.Jwt would be a separate hardening task — out of scope for AZ-491 (which is a refactor, not a dependency bump). If the team chooses to align minor versions, it should ship as a single coordinated bump across all IdentityModel.* references with regression coverage. For AZ-491 the existing pinning is preserved unchanged so behavior parity with cycle 2 is guaranteed.
• Task: AZ-491

Phase-by-Phase Summary

Phase	Result	Notes
1. Context Loading	OK	AZ-491 spec read; 6 ACs identified; Option A chosen with documented rationale
2. Spec Compliance	OK	6/6 ACs verified at code level. AC-2 + AC-3 wait on Step 16 final test gate; their structural prerequisites (call-site signatures preserved; subject explicitly passed) are in place
3. Code Quality	OK	New JwtTokenFactory is a stateless static class — SRP satisfied; eliminates duplication; regression-prevention comment on the notBefore branch is the only doc-comment kept (justified per coderule.mdc — references cycle-2 fix commits)
4. Security Quick-Scan	OK	No production-code change; no new attack surface. Token-minting moved into a test-only library that production code MUST NOT consume — the module-layout.md entry encodes this invariant
5. Performance Scan	OK (N/A)	Test-infrastructure refactor; no hot-path code
6. Cross-Task Consistency	OK	Single task in batch; the new code-review rule introduced by this same batch will prevent future duplicate-helper regressions
7. Architecture Compliance	OK	TestSupport is correctly placed in the Shared / Cross-Cutting layer of module-layout.md. It is referenced only by Tests + IntegrationTests (both via ProjectReference); zero production projects reference it. No cycle introduced. Layering: TestSupport sits below both test projects (foundation); both test projects sit outside the production layering table

Cross-cutting observations (info, no finding)

• The subject-value migration is the only semantic delta. Pre-AZ-491 the integration project's MintValidToken(secret) defaulted to subject = "integration-tests". Post-AZ-491 the same call site now reads JwtTokenFactory.Create(secret, JwtTestHelpers.DefaultSubject) — JwtTestHelpers.DefaultSubject = "integration-tests" is still the canonical runner subject; the explicit-pass form preserves behavior exactly. Unit tests retain their own subject choices ("alice", "test-user", explicit per-test) unchanged.
• The using System.IdentityModel.Tokens.Jwt; and using Microsoft.IdentityModel.Tokens; imports were removed from JwtTestHelpers.cs because the file no longer uses those namespaces after the mint logic moved out. No dead-import remains.
• The SatelliteProvider.Tests/TestUtilities/ folder is intentionally retained (not deleted) because it still owns UavTileImageFactory.cs. That fixture-factory is out of scope per AZ-491 § Excluded — a future task could consolidate it into TestSupport, but only if/when integration tests also need it.

Baseline Delta

Class	Count	Notes
Carried over	0	No Architecture findings in baseline; nothing recurring
Resolved	1 (informal)	The cycle-2 duplicate-helper Maintainability pattern (documented in LESSONS.md 2026-05-11 testing entry + retrospective Pattern 1) is structurally closed by this batch. Not an Architecture-class baseline entry, so it does not appear in the cycle-1 baseline; tracked here for the cycle retrospective
Newly introduced	0	—

Verdict Logic

• 0 Critical, 0 High, 0 Medium, 1 Low → PASS_WITH_WARNINGS
• The single Low finding is informational (pre-existing version pinning preserved verbatim from cycle-2 IntegrationTests csproj); does not block commit per the implement-skill auto-fix gate.

Recommendation to /implement

Proceed to commit + push + tracker transition (Steps 11-13).