Green zone

What it means

The green zone is the state Enji Guard works to reach and keep: current audit areas are healthy enough that people and coding agents can continue building without stacking new work on known risks.

Green is current evidence: dependencies age, tests drift, and new features open new failure surfaces, so a project can leave the zone when a later audit says so.

The outcome is project-level while evidence stays per audit: a weak test result remains visible beside a healthy dependency result.

Audit scores share one scale:

• 70-100 is green;
• 40-69 is yellow;
• 0-39 is red.

It is not a badge, a one-time score, or proof of a defect-free codebase, nor:

• A green CI check: one commit met one repository’s conditions.
• An SLO: a target for a measured service level.
• A RAG rating: a snapshot estimate of delivery confidence.
• A Definition of Done: one increment met its quality bar.

Where it appears in Enji Guard

Enji Guard shows the state as colors and status lines rather than the words “green zone”:

• Audit score squares. Each numbered square is the latest score for one audit group in one repository.
• Project cards. A card surfaces a subset of scores with bullets such as Security is healthy or Codebase hygiene is steady.
• Audit status and history. A report carries the status Healthy; each history row counts its healthy signals.

A color is the status of one audit result; open the report before treating a green number as a closed risk.

Why it matters for AI-written code

A green project hands coding agents clearer context, stronger checks, fewer known vulnerabilities, and less unresolved structural debt competing with the feature they were asked to build.

Agent-driven work also makes assumptions stale faster: a new dependency or a generated CI change can undo earlier health without visible breakage, so green is re-checked after every new revision instead of assumed.

How Enji Guard helps

Enji Guard moves a project toward green and keeps it there through one loop:

1. Map the repository’s identity, revision, and structure.
2. Audit one bounded question per audit, for example whether dependencies accumulate risk.
3. Choose the next risk; a person decides which improvement to attempt.
4. Prepare a change: an issue and, when a supported autofix applies, a verified pull or merge request.
5. Keep human control: a reviewer accepts, edits, or rejects; human approval is the write boundary.
6. Rerun the affected audit against the merged revision.
7. Repeat as recurring audits pick up new revisions.

Green does not prove the software is free of defects, vulnerabilities, or operational gaps, and does not replace monitoring, incident response, or manual review. Enji Guard never pushes directly to the default branch and never performs the final merge.