tend-tests

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.

Completion criterion: test runner identified, an example existing test read, off-limits known.

2. Scan — priority order, stop at the first real hit

1. DI/mockable-dependency candidates (highest priority). Grep the logic/library directory for the repo's dependency-injection idiom — a deps parameter injecting browser/platform globals (fetch, storage, timers), constructor injection, or an equivalent explicit seam. This is the highest-value target because the codebase has already signalled "designed to be tested without module-level mocking."
2. Coverage cross-check. For each candidate, grep the test directory/convention for any reference to the function name. Zero references = untested candidate.
3. Fallback tier — pure functions. If no DI-pattern candidate is untested, fall back to any pure exported function (deterministic output, no hidden module-level state) in the logic layer with zero test references. Note explicitly in your output that this is the fallback tier, since it carries a weaker "designed to be tested" signal than tier 1.