style(13-03): apply Prettier formatting across repo

Mechanical reformat — no logic changes. 398 files changed, 19125
insertions(+), 16457 deletions(-). Prettier 3.8.4 with .prettierrc
(singleQuote:true, semi:true, tabWidth:2, trailingComma:all,
printWidth:100). Isolated per D-13-08 for reviewability.
This commit is contained in:
Lucas Berger
2026-06-11 20:35:18 -04:00
parent 4bc0445173
commit 982438dc10
398 changed files with 19050 additions and 16382 deletions
@@ -16,18 +16,18 @@ requirements: []
must_haves:
truths:
- "All files are reformatted by Prettier as ONE isolated mechanical commit, separate from Plan 02's logic fixes, for reviewability (D-13-08)"
- "CI fast-checks job gains a `Format check` step running `pnpm format:check`, inserted after Lint and before Typecheck; the stale no-op lint comment is removed (SC-2)"
- "Baseline gate ends green: `pnpm lint` exits 0 AND `pnpm format:check` exits 0 across both apps (SC-3)"
- "CI lint step now genuinely blocks a PR to main on violations (no longer the --if-present no-op), and the new format:check step blocks on format violations (SC-2)"
- 'CI fast-checks job gains a `Format check` step running `pnpm format:check`, inserted after Lint and before Typecheck; the stale no-op lint comment is removed (SC-2)'
- 'Baseline gate ends green: `pnpm lint` exits 0 AND `pnpm format:check` exits 0 across both apps (SC-3)'
- 'CI lint step now genuinely blocks a PR to main on violations (no longer the --if-present no-op), and the new format:check step blocks on format violations (SC-2)'
artifacts:
- path: ".gitea/workflows/ci.yml"
provides: "fast-checks job with a Format check step after Lint; stale no-op comment removed"
contains: "format:check"
- path: '.gitea/workflows/ci.yml'
provides: 'fast-checks job with a Format check step after Lint; stale no-op comment removed'
contains: 'format:check'
key_links:
- from: ".gitea/workflows/ci.yml fast-checks job"
to: "root package.json lint + format:check scripts"
via: "pnpm lint / pnpm format:check steps"
pattern: "pnpm format:check"
- from: '.gitea/workflows/ci.yml fast-checks job'
to: 'root package.json lint + format:check scripts'
via: 'pnpm lint / pnpm format:check steps'
pattern: 'pnpm format:check'
---
<objective>
@@ -55,15 +55,17 @@ Output: reformatted tree (isolated commit), updated ci.yml, green lint + format
<artifacts_this_phase_produces>
No NEW files. MODIFIES:
- The whole source tree (Prettier reformat — isolated commit).
- `.gitea/workflows/ci.yml` — adds the `Format check` step; removes the stale 3-line no-op lint comment (ci.yml lines 28-30).
This completes the phase's full artifact set across all three plans:
- New config files (Plan 01): eslint.config.js, .prettierrc, .prettierignore
- New scripts (Plan 01): root format/format:check + type:module; apps/api & apps/pwa lint
- New CI step (Plan 03): Format check
- State: lint-clean (Plan 02) + format-clean (Plan 03) baseline, green in CI.
</artifacts_this_phase_produces>
</artifacts_this_phase_produces>
<tasks>
@@ -80,6 +82,7 @@ This completes the phase's full artifact set across all three plans:
This reformat MUST be its own commit, isolated from Plan 02's lint fixes (D-13-08) — do not mix any logic change into it. After formatting, run `pnpm lint` to confirm the reformat did NOT introduce any lint violation (eslint-config-prettier means ESLint does not fight Prettier, so this should stay green from Plan 02). If `pnpm lint` is non-zero after reformat, a formatting/lint conflict exists — investigate the eslint-config-prettier placement (must be last) before proceeding; do not blanket-disable.
Record `git diff --stat` (file count + line churn) in the SUMMARY as evidence of the mechanical reformat.
</action>
<verify>
<automated>cd /home/luc/Projects/familysync && pnpm format:check && pnpm lint && echo FORMAT_AND_LINT_GREEN_AFTER_REFORMAT</automated>
@@ -104,6 +107,7 @@ This completes the phase's full artifact set across all three plans:
Do NOT touch the `api` or `harness` jobs, the `name: CI` line, or the `fast-checks` job id — those job ids are the required branch-protection contexts (STATE / memory: gitea main is protected, contexts must stay valid). No other CI change. No cache (D-PROBE-04 — the comment already documents why; leave it).
Validate the YAML parses after the edit.
</action>
<verify>
<automated>cd /home/luc/Projects/familysync && grep -q "Format check" .gitea/workflows/ci.yml && grep -q "pnpm format:check" .gitea/workflows/ci.yml && ! grep -q "out of this phase's scope" .gitea/workflows/ci.yml && python3 -c "import yaml,sys; yaml.safe_load(open('.gitea/workflows/ci.yml'))" && grep -q "fast-checks:" .gitea/workflows/ci.yml && echo CI_FORMAT_STEP_WIRED</automated>
@@ -129,20 +133,22 @@ This completes the phase's full artifact set across all three plans:
</tasks>
<threat_model>
## Trust Boundaries
| Boundary | Description |
|----------|-------------|
| Boundary | Description |
| ------------------- | ---------------------------------------------------------------------------------- |
| PR → main (CI gate) | The fast-checks job is the quality boundary; lint/format failures must block merge |
Dev-tooling/CI-config phase: no runtime, network, auth, or user-data surface. The only sensitive concern is preserving the branch-protection job-id contexts.
## STRIDE Threat Register
| Threat ID | Category | Component | Disposition | Mitigation Plan |
|-----------|----------|-----------|-------------|-----------------|
| T-13-05 | Tampering / Denial of Service (CI integrity) | renaming the fast-checks job id or CI name while editing ci.yml | mitigate | Task 2 explicitly forbids touching `name: CI`, the `fast-checks` job id, and the api/harness jobs — those are the required branch-protection contexts (gitea main is protected; a renamed context would silently un-gate main). Verify gate asserts `fast-checks:` still present. |
| T-13-06 | Tampering | format:check step that never fails (mis-wired) | mitigate | SC-1 (Plan 01) already proved `pnpm format:check` exits non-zero on an unformatted file; Plan 03 only adds the step that runs that proven command. Green baseline (Task 3) confirms it exits 0 on the clean tree. |
| Threat ID | Category | Component | Disposition | Mitigation Plan |
| --------- | -------------------------------------------- | --------------------------------------------------------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| T-13-05 | Tampering / Denial of Service (CI integrity) | renaming the fast-checks job id or CI name while editing ci.yml | mitigate | Task 2 explicitly forbids touching `name: CI`, the `fast-checks` job id, and the api/harness jobs — those are the required branch-protection contexts (gitea main is protected; a renamed context would silently un-gate main). Verify gate asserts `fast-checks:` still present. |
| T-13-06 | Tampering | format:check step that never fails (mis-wired) | mitigate | SC-1 (Plan 01) already proved `pnpm format:check` exits non-zero on an unformatted file; Plan 03 only adds the step that runs that proven command. Green baseline (Task 3) confirms it exits 0 on the clean tree. |
</threat_model>
<verification>
@@ -153,10 +159,11 @@ Dev-tooling/CI-config phase: no runtime, network, auth, or user-data surface. Th
</verification>
<success_criteria>
- D-13-08: reformat is one isolated mechanical commit, separate from logic fixes.
- SC-2: CI fast-checks job has a real lint step (blocks on violations) + a new format:check step; stale comment removed; branch-protection contexts intact.
- SC-3: `pnpm lint` AND `pnpm format:check` both exit 0 across both apps; baseline gate ends green.
</success_criteria>
</success_criteria>
<output>
Create `.planning/phases/13-real-lint-gate-eslint/13-03-SUMMARY.md` when done. Record: `git diff --stat` of the reformat (files + line churn), the exact ci.yml step ordering after the edit, and the final green exit codes for lint / format:check / typecheck / tests (SC-3 evidence). Note that SC-2's "CI actually blocks the PR" confirmation is a one-time observation on the next real PR to main (per 13-VALIDATION.md Manual-Only table) — flag it for the operator.