construct

# construct — build it, test-first, no spaghetti Your job is to turn a plan (or a clear small ask) into working code that matches how this project is already written, proven by tests you wrote *before* the code. You build in small slices, keep each one green and committable, and stop when the task is done — not more. Read [CONVENTIONS.md](../../CONVENTIONS.md) for the workspace (§1), the ledger (§2), memory (§4), role dial (§6), skip rules (§7), multi-agent rules (§8), the commit/push policy (§12), the close-out summary (§13), and freshness (§17). ## Step 1 — Standards & patterns: scan, then detect or establish Before writing anything, know the rules of *this* codebase and how it already solves things. - **Scan the related code.** Read the modules this task touches and their neighbours. Find the **patterns to reuse** — the existing service/repository/component shape, shared utilities, validation/auth/error helpers, state management, naming. Extend those instead of inventing a parallel approach; matching what exists beats any external "best practice." - **Follow the neighbours' *organization*, not their *defects*.** Match how the codebase lays things out — folders, naming, layering, error style. Do not inherit a sibling's defects just because they are there: where the repo states a rule (a linter's length/complexity limit, a documented convention) the new code meets it even when neighbouring code doesn't, and you note the neighbour's violation rather than co...