Tests and delivery proof
HelmIt uses your project’s test, build, and lint commands. Preparation
records them in .helmit/KEEL.md; if a command does not exist, that is made
explicit. The agent chooses a check that matches the promised outcome, runs the
applicable commands, and records the result.
When each check runs
Section titled “When each check runs”| Moment | What is checked |
|---|---|
| At every logical commit | A quick floor checks the staged content and stops the commit if it fails. |
| When a task or correction is completed | The task’s focused check proves its declared outcome. Intermediate commits do not repeat that final check. |
| At integration and phase closure | Complete test, build, and lint commands run when the work needs to be checked together. At ship, HelmIt also checks requirements, proof, and acceptance criteria. A complete proof that is still valid can be reused. |
A CHG follows the same commit floor and has its own focused check, even
though it sits outside phases. The optional /helmit:validate command lets you
inspect final proof before ship; it adds no mandatory stage.
Choosing the right proof
Section titled “Choosing the right proof”A check must show the requested behavior, not merely exit successfully. For example, if a task fixes a broken link, a successful site build alone does not show that the link works. For a documentation-only change, checking the published page may be more useful than adding a code test.
- Reproducible defect: when possible, capture the failure before the fix and confirm that the same check passes afterward. There is no need to manufacture a red test for every change.
- New behavior: check the outcome someone using the feature can observe, along with any necessary structural checks.
- Refactor: start with a known result and confirm that behavior is preserved.
- Human judgment: reserve it for questions requiring human assessment or access. A check the agent can perform remains the agent’s responsibility.
In the plan, verify: identifies the focused check. satisfies: means a task
delivers a requirement; supports: means it contributes without completing the
requirement on its own. At ship, a requirement is proved only when its mapped
evidence passes and its acceptance criteria are met.
If a check fails
Section titled “If a check fails”A failed commit floor stops the commit. A failed focused check stops the task
from being declared complete. Failed complete proof, a missing requirement, or
unmet acceptance stops phase closure. The agent fixes the issue and repeats the
affected check; --no-verify is not an escape hatch.
Proof runs on a temporary copy of the Git content for the moment being checked. This keeps repository-relative test and build output out of the working tree. It does not isolate commands that access external paths, the network, or services; those remain subject to normal authorization.
See Project artifacts to locate plans, requirements, and results, and The delivery lifecycle to place these checks in the overall flow.