docs(adr): apply targeted fixes from PR #535 review

- ADR-0003: clarify UUID v5 values are pre-computed constants in seed
  scripts, not derived at runtime from squad number
- ADR-0005: replace "all domain fields are required" with accurate
  breakdown — 4 required fields, 6 optional
- ADR-0007: rephrase hardcoded file paths to generic structure
  description
- template.md: add explicit Alternatives Considered section

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: nanotaboada

docs/adr/0003-uuid-surrogate-primary-key.md

@@ -28,14 +28,17 @@ across environments so that tests can reference them by ID.
 UUID v4 (random) cannot satisfy this: regenerating the seed would
 produce different IDs each time. UUID v5 (deterministic, derived from
 a namespace and a name) produces the same UUID for the same input,
-making seeded records reproducible.
+making seeded records reproducible. The project stores pre-computed
+UUID v5 constants directly in the seed scripts rather than deriving
+them at runtime from the squad number.
 
 ## Decision
 
 We will use a UUID surrogate primary key stored as a hyphenated string
 (`HyphenatedUUID` custom SQLAlchemy type). API-created records receive
 a UUID v4 (random); migration-seeded records receive a UUID v5
-(deterministic, derived from the player's squad number).
+(deterministic, pre-computed and stored as constants in the seed
+scripts).
 
 The v4/v5 split preserves the benefits of each approach in its context:
 randomness for API-created records (opaque, non-predictable), and

docs/adr/0005-full-replace-put-no-patch.md

@@ -23,10 +23,12 @@ design (all fields required vs optional), the service layer logic
 (overwrite all vs merge), and the client contract (must send all fields
 vs only changed fields).
 
-The current implementation uses a single `PlayerRequestModel` where all
-domain fields are required. The service's
-`update_by_squad_number_async` overwrites every field on the existing
-record using the request body values.
+The current implementation uses a single `PlayerRequestModel` shared by
+both POST and PUT. Four fields are required (`first_name`, `last_name`,
+`squad_number`, `position`); the remaining six are optional (`middle_name`,
+`date_of_birth`, `abbr_position`, `team`, `league`, `starting11`). The
+service's `update_by_squad_number_async` overwrites every field on the
+existing record using the request body values.
 
 ## Decision
 

docs/adr/0007-integration-only-test-strategy.md

@@ -28,10 +28,9 @@ synchronous integration tests that exercise the full stack — routing,
 dependency injection, service logic, ORM queries, and the database —
 without a running server process.
 
-All tests live in `tests/test_main.py`, use stubs from
-`tests/player_stub.py` for consistent test data, and rely on a
-`function`-scoped `client` fixture from `conftest.py` for per-test
-isolation.
+All tests live in a single test module under `tests/`, use a stubs
+module for consistent test data, and rely on a `function`-scoped
+`client` fixture in `conftest.py` for per-test isolation.
 
 ## Decision
 

docs/adr/template.md

@@ -10,9 +10,17 @@ Date: YYYY-MM-DD
 
 <!--
 State facts, not conclusions. Describe the problem or situation that
-required a decision. List the alternatives that were evaluated.
-Include language- or framework-specific constraints that shaped the
-decision. Do not argue for the chosen option here.
+required a decision. Include language- or framework-specific
+constraints that shaped the decision. Do not argue for the chosen
+option here.
+-->
+
+## Alternatives Considered
+
+<!--
+List each option that was evaluated. One or two sentences per option
+is enough — enough to show it was genuinely considered and why it was
+set aside.
 -->
 
 ## Decision