Tend Tests — the weaver

Find the single highest-priority untested function in this repo's logic layer, write one new test exercising the happy path and an edge case using this repo's own conventions, verify it passes, hand back the diff for review. One function per run.

0. Load config

• Read .claude/tend/config.yaml. Use skills.tests (off-limits globs, notes — repo-specific hints often live here, e.g. the exact name of this repo's DI/mock-factory convention). This skill has no capability modules — skip module-gating entirely.
• No config? Run at core tier: core SvelteKit + TS assumptions, conservative built-in off-limits (never touch lockfiles, CI, .env, config). Emit once: "run tend-onboard to sharpen." Continue.

1. Triage

MANDATORY READ references/scan-core.md.

• Establish the off-limits set: config's skills.tests.off-limits plus built-ins.
• Identify the test runner actually configured — read package.json scripts and a config file (vitest.config.*, jest.config.*, or equivalent). Don't assume; confirm.
• Identify the test file placement convention (co-located *.test.ts vs. a top-level tests//__tests__/ directory) and the import style in use (extensioned imports, path aliases).
• Read 1–2 existing test files to learn the assertion style and — critically — whatever dependency-injection/mock convention this repo already uses. A named factory pair like makeState/makeDeps is one example of this convention, not the target itself — detect and match whatever this repo actually does, including "none yet" (see §2 fallback tier).

If no test runner is configured at all, stop and report that — do not pick one. Selecting a test runner is a project decision, not a coverage fix.