Review: T8: update contract_version in sign endpoint

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — Sub-ticket of westside-contracts#34, wave 3
• [x] Repo — forgejo_admin/westside-contracts
• [x] User Story — clear: "As the contract signing system, I need to derive the contract_version from the team's contract_config..."
• [x] Context — explains current hardcoded logic with exact code snippet, target state with fallback behavior
• [x] File Targets — single file with explicit exclusion list (4 files NOT to touch)
• [x] Acceptance Criteria — 4 criteria, all testable
• [x] Test Expectations — manual + automated: npm test && npm run check
• [x] Constraints — backwards compatibility documented (NULL config = current behavior)
• [x] Checklist — present
• [x] Related — parent project + parent issue + dependency noted

Traceability

• [x] story:WS-S20 — "As a parent, I want to sign contracts digitally so that paperwork is handled online"
• [x] story note verified — found in project-westside-basketball user-stories section under Parent stories
• [x] arch:contracts — contracts component
• [x] arch note verified — arch-contracts-westside-basketball exists in pal-e-docs (active, created 2026-04-04)
• [x] Forgejo issue — forgejo_admin/westside-contracts#38, open

File Targets

• [x] src/routes/contract/[token]/sign/+server.ts — verified exists (137 lines). Lines 54-65 contain the exact hardcoded contract_version logic described in the issue. The pattern isLocal ? '2026-spring-local-v1' : isGirls ? '2026-spring-girls-travel-v1' : '2026-spring-travel-v1' matches the ticket's Context section verbatim. The team query on line 54-56 currently only selects name — agent will need to add contract_config to this query.

Repo Placement

Dependencies

• [x] T1 (ID:772): contract_config JSONB on teams — in QA (wave:1). REQUIRED: this ticket reads contract_config from teams table.
• [x] T5 (ID:776): data-driven page.server.ts + merge logic — in QA (wave:2). Explicitly listed as dependency in Related section.
• [x] T3 (ID:774): seed team configs — in QA (wave:2). Config data must exist for the new code path to be testable.

Acceptance Criteria

• AC1: config-based version derivation from config.season + config.variant — testable by examining code + running against seeded data
• AC2: fallback to team-name logic when contract_config is NULL — testable by running with NULL config
• AC3: end-to-end signing flow works with both paths — testable via manual sign
• AC4: contract_version correctly written to player record — testable via DB query post-sign

Blast Radius

• contract_version is referenced in only 2 places in westside-contracts: the sign endpoint (target) and src/lib/types.ts (type definition only, no change needed).
• basketball-api does not reference contract_version derivation logic — it only stores the value written by westside-contracts.
• No other services consume or derive contract_version.
• Rollback is straightforward: revert the single file change. Existing signed records are unaffected (version string is written at sign time, not recomputed).

Decomposition Assessment

• 1 file target, 1 repo — well under 3-file limit
• 4 acceptance criteria — under the 5 AC threshold
• Estimated agent work: 2-3 minutes (modify one query, add config read, add fallback branch)
• No independent subtasks to parallelize

Recommendation