build-and-check
Build and Check
Own the implementation-first loop and current local evidence, not independent review or delivery acceptance. Use directly for matching requests or inline through a bounded authorized handoff. Read validation when changing or validating this package.
1. Establish scope and checks
Read target instructions, the authoritative agreement/revision and acceptance references, exclusions, affected files/callers, existing coverage and supplied readiness evidence. Compare deciding sources, dirty work, tests, configuration and environment; reuse current evidence and investigate only material gaps. Ordinary request/context supplies these facts without a mandatory form.
Identify one owner, protected work, approved file/run effects, data/retention constraints and expected return. Plan-only authority returns an increment/check plan without writes. This method grants no installation, service startup, disclosure, spending, delegation, tracker mutation, merge or release authority.
Discover conditional companions through the runtime catalog or an explicit approved location, not sibling paths. Read complete entries and relevant references, record source/revision or digest and check semantic capabilities. Missing, ambiguous or incompatible helpers block their dependent route without installation or legacy fallback:
- Before Git writes, consume compatible
implementation-preflightor inspect a current caller-supplied result for this scope/state. Outside Git retain a before/after manifest. - Changed meanings or qualifying decisions use discovered
domain-modeling; reading definitions alone needs no invocation. - Delegation or correction of recorded acceptance findings consumes discovered
work-on's execution/repair library without invoking delivery. Retain root ownership, ledger, bounds and finding lineage; workers request additional work from the root. Ordinary direct development increments need no delivery companion.
Map each scoped acceptance/risk to an appropriate existing check or focused inspection, expected result, command/environment and finite run bound. Inspect assertions and relevant paths rather than relying on test names/counts. Reuse sufficient coverage; add or extend checks only for a real gap. No new-test quota, coverage target or mandatory unit suite applies. Binding project method/check policy still applies; selecting this method cannot waive it.
For documentation check affected facts, frontmatter, links/anchors and rendered structure; for configuration use its actual parser/schema or consumer check where available, including relevant safety settings. Code checks cover changed behavior and meaningful regression/failure paths. Record why focused inspection suffices when no executable check is appropriate. Material unavailable checks remain gaps, not green results. Run safe relevant baselines when useful to distinguish existing failures.