ward

/ward — Test-Gap Audit

Cast over the code to reveal where it sits unprotected and raise wards against regression. This is the ad-hoc, in-session successor to the removed testgaps background worker: instead of a billed daemon loop re-scanning the whole tree every 20 minutes into a report nobody reads, /ward runs when you ask, scopes to what actually changed, and surfaces gaps — with test skeletons — in the conversation where you can act on them.

Arguments: $ARGUMENTS

Phase 1: Memory first (gate requirement)

mcp__moflo__memory_search { query: "<the symbols/files in scope> test coverage", namespace: "tests" }

The tests namespace maps source → covering tests; use it to see what's already covered before flagging a gap. Also check patterns for the project's test framework and conventions so skeletons match house style.

Phase 2: Decide scope

Pick the smallest scope that answers the ask — a whole-codebase re-scan is exactly the waste this skill was built to end.

Argument	Scope
(none)	The current diff: git diff HEAD + git diff main...HEAD. Ward the changed code only.
a path or glob	That subtree (e.g. /ward src/api).
an area in prose	Resolve to files via code-map search, then ward those.
--all	Whole codebase. Only on explicit request — say so and expect it to be slower.

If the diff is empty and no target was given, ask what to ward rather than defaulting to --all.

Phase 3: Detect the framework

Before writing any skeleton, determine the project's test runner and conventions (vitest / jest / pytest / go test / etc.) from config files, existing tests, and the tests memory. Skeletons MUST be in the project's actual framework and match its file naming, import style, and assertion idiom — a skeleton in the wrong dialect is noise.

Phase 4: Find the gaps

For the in-scope code, look for, in rough order of risk:

1. Untested functions / classes / exports — public surface with no covering test. Cross-check against the tests namespace before flagging.
2. Uncovered edge cases — boundaries (empty, null/undefined, zero, negative, max), off-by-one, unusual-but-valid inputs the happy-path test skips.
3. Missing error-handling tests — throw/reject/error branches with no test asserting the failure path; validation that nothing exercises.
4. Integration gaps — units tested in isolation but the seam between them (I/O, DB, external calls, cross-module contracts) is unexercised.
5. Regression-prone changes — in a diff, logic that changed behavior but whose tests didn't.