home: raw drizzle in internal/layout-cache.ts bypasses repo.ts

[electather]

Module: home · Dimension: architecture · Severity: medium · Location: apps/server/src/home/internal/layout-cache.ts:1

Problem

The home module has no repo.ts. internal/layout-cache.ts imports drizzle-orm directly (line 1) and reads/writes the owned homeLayoutCache table from ../../db/schema/home (line 4, used at lines 38-42 and 70-78) itself, rather than going through a dedicated repo.ts as required by the service-and-repo contract ('Sole place drizzle-orm imported in module' / 'repo.ts owns drizzle queries on owned tables').

Why it matters

Per module-layout.md's reserved-file-role table, internal/<x>.ts is for 'Private helpers' and is explicitly not supposed to touch drizzle ('drizzle drift in internal/: helpers inside internal/ start importing drizzle → move to repo.ts'). Because layout-cache.ts is not repo.ts, drizzle access is scattered outside the one sanctioned data-access surface: a future table rename/reshape or query-pattern change (e.g. adding a transaction wrapper, switching insert-on-conflict semantics) has no single file to edit, and other internal/ files may be tempted to copy the pattern and also start querying homeLayoutCache directly, defeating the point of isolating drizzle access.

Suggested fix

Extract the drizzle queries in layout-cache.ts into a proper repo.ts (e.g. HomeRepo with getCachedLayout/upsertCachedLayout methods) and have layout-cache.ts (or service.ts) call the repo instead of touching drizzle-orm/db/schema/home directly.

Fable-panel validated: 3/3 votes.

---

Filed from automated per-module audit workflow (Opus/Sonnet research → Fable-panel decision). Unverified by a human — triage before acting.