Enji GuardWhat it runs
Dependency update 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 Dependency hygiene audit, but the improvement still checks the current repository before proposing work.
Starting evidence
Dependency manifests, lockfiles, package-manager metadata, dependency hygiene context, GitHub issue or pull-request history, and the requested write mode.
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 works on one dependency update when the package, target version, lockfile impact, and verification path are clear enough for review.
- One focused dependency version change.
- Lockfile updates caused by that dependency change.
- A reviewable GitHub issue or pull request with verification output.
One focused run keeps the change small enough to review.
Find one safe dependency update and open an issue or 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 update a dependency tree wholesale.
- It does not hide breaking changes inside unrelated cleanup.
- It does not claim compatibility when the package manager or test commands could not run.
Candidate selection
Guard selects one update only when the dependency, target version, and review boundary are clear enough to avoid broad package churn.
- 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 package, current and target versions, files changed, commands attempted, issue or PR outcome, and any reason it stopped short of a code change. 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. |
Outdated package has a safe target version and bounded lockfile impact
Focused dependency update proposed with package-manager verification
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
A later dependency hygiene audit evaluates the updated revision. The autofix report records the package work; the audit proves whether dependency health improved.
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.