Maurice
790fccb92c
The 20 % brake skipped a category and wiped its marks every night once a fifth of it looked unreferenced. Any user could push a small install over that line, a backlog from #2924 started braked, and a second install on the same bucket below the line was not caught at all. It is gone: - Each pass leaves a trek-owner-<install id> marker at the root of every category it judges. A category holding another install's marker is skipped as foreign_install, one where the marker cannot be written as owner_unknown. Backups leave the markers out. - The install id lives in app_settings outside the storage.* prefix. The switch is stored as that id, so a database from another install reads as off, and every reopen (a restore) writes this install's id back, turns deletion off and drops the marks, confirmations and reports. - More than a fifth unreferenced still marks and reports, but deletes only after an admin confirmed the count shown (POST .../reclaim/confirm). A larger count later waits again. A skip no longer touches the marks, so a failed listing or lookup does not restart the week. Check now runs in the background and answers 202; the admin state says running and keeps the last deleting report apart, so a report-only check never resets what was freed. A pass that deletes writes a system audit entry, a pass that stops or fails keeps its partial counts and marks the rest interrupted, a backend error stops deleting in its category, and deleting stops for the rest of the pass once the switch is off or a backup is reading the uploads. The usage scan waits for a pass still running. Sources read each category once per pass and answer the pre-delete re-check with a query narrowed to the keys' plain runs. Bare names keep their raw spelling (a '#', '?' or trailing blank is part of an upload's name), and local roots are resolved through their symlinks before the overlap check. A pass lists only a category's root.
@trek/shared
Single source of truth for TREK's API contracts, expressed as Zod schemas and consumed by both the server (request validation + inferred DTO types) and the client (typed requests/responses).
This package is part of the incremental NestJS + React 19 migration (see the "Brownfield Rewrite" board). It is intentionally dormant until modules start importing it — adding it changes nothing for users.
Rules
- One folder per domain:
src/<domain>/<domain>.schema.ts(+.spec.ts). - Domain-agnostic building blocks live in
src/common/. - A route is only considered migrated once its contract lives here.
- Schemas are the source of truth; server DTOs and client types are inferred from them
(
z.infer<typeof schema>), never hand-duplicated.
Consumption (dev)
Both apps resolve @trek/shared to this package's TypeScript source:
- Server (
tsx): viapathsinserver/tsconfig.json. - Client (
vite): viaresolve.aliasinclient/vite.config.ts(+pathsfor the type-checker).
Production packaging (Docker / workspace wiring) is introduced in card F2, when the server first depends on this package at runtime. Until then prod builds are untouched.
Not yet here
The canonical error envelope is finalised in card F5 (it must match TREK's current Express error responses byte-for-byte), so it is deliberately not invented in F1.