Enji GuardWhat it runs
Test writing autofix is part of Guard's improvement loop. The run takes one verified surface and tries to move it forward after audit or product evidence makes the next step clear.
That does not give Guard open-ended permission to rewrite the repository. The run keeps the work small, records why this candidate was chosen, and produces output a person can review before anything lands.
Its closest audit source is Test quality audit, but the improvement still checks the current repository before proposing work.
Starting evidence
Repository test commands, existing tests, source behavior, test-quality findings, and task-scoped repository metadata.
Earlier Guard context helps only when it still matches the target. The run revalidates access, looks for duplicate GitHub work, and treats stale or missing evidence as a reason to stop rather than a reason to guess.
Allowed change
The run adds tests or test-only fixtures. It is not a production-code autofix, and it must not hide a missing implementation behind a passing assertion.
- Focused tests for existing behavior.
- Test-only fixtures or helpers needed by those tests.
- A pull request with verification output when the suite can run.
One focused run keeps the change small enough to review.
Add a small set of high-value tests for under-proven behavior and open a focused pull request for review.
Boundaries
Guard improvements stay useful because they are constrained. A run stops or falls back to a report when repository access, target scope, source context, or the write path is not clear enough.
- It does not edit production code.
- It does not chase broad coverage percentages.
- It does not add tests whose expected behavior is guessed.
Candidate selection
Guard chooses a small test opportunity where the expected behavior is discoverable and a reviewer can see why the new test matters.
- 1
Resolve the target
Read the repository identity, selected improvement, and any linked website or paired audit context.
- 2
Validate current state
Check repository access and current files before relying on earlier Guard evidence.
- 3
Deduplicate existing work
Read relevant GitHub issues and pull requests so Guard does not repeat stale findings or rejected fix patterns.
- 4
Pick the smallest useful candidate
Prefer one improvement that can be explained, reviewed, and verified.
- 5
Record the stopping reason
If the run cannot safely write, the report explains whether the outcome is report-only, issue-only, or blocked by missing evidence.
Outputs
The report names the tests added, commands attempted, pass/fail outcome, and any setup limitation that blocked execution. Output choice depends on the runbook and product mode. The report remains the durable record even when the visible result is a GitHub issue or pull request.
| Output | When it fits |
|---|---|
| Report | The run inspected the target and needs to record the outcome, limitation, or verification. |
| Issue | The evidence is real but the fix needs product, security, or architecture judgment. |
| Pull request | The candidate is narrow, reviewable, and has a credible verification path. |
Billing retry branch has no behavior-level test
Focused test PR opened with the selected command result
Product surface
Guard exposes improvements from the audit or repository surface, not a separate code-writing workspace. The same action can appear in the control panel, recent activity, and report history after a completed run.
Review and rerun
The next test quality audit decides whether the new tests improve confidence. Guard keeps the PR reviewable and the score evidence separate.
This is the same health model as the audit pages: Guard improves a concrete surface, a person reviews the output, and a later audit or improvement rerun evaluates the new revision. The maintained state is the green zone, not an untouched backlog of findings.