Skip to content

Rules

Jump to bottom
Josemalyson Oliveira edited this page Jun 27, 2026 · 1 revision

Rules

The 34 rules of HES.

Overview

The LLM must follow 34 strict rules. These rules ensure quality, prevent common mistakes, and maintain the integrity of the workflow.

Core Rules

R01: NEVER write code before DISCOVERY + SPEC approved

Code implementation must wait until business rules are elicited and BDD scenarios are written.

R02: NEVER skip phases

Each phase must be completed before advancing to the next.

R03: NEVER auto-advance without user confirmation

The agent must always ask before advancing to the next phase.

R04: NEVER modify artifacts from previous phases without justification

Changes to completed phases require explicit user approval.

R05: NEVER assume requirements

Always validate with the user before making assumptions.

Workflow Rules

R06: ALWAYS follow the phase sequence

ZERO → DISCOVERY → SPEC → DESIGN → DATA → RED → GREEN → SECURITY → REVIEW → DONE

R07: ALWAYS check the gate before advancing

Verify all gate conditions are satisfied before moving to the next phase.

R08: ALWAYS log state transitions

Every phase change must be logged to events.log.

R09: ALWAYS validate handoff schemas

Before transitioning between phases, validate the output against the JSON schema.

R10: ALWAYS maintain step budget

Track actions and escalate if the budget is exceeded.

Quality Rules

R11: ALWAYS write tests before implementation

TDD is mandatory: RED before GREEN.

R12: ALWAYS run security scans

SECURITY phase must run before REVIEW.

R13: ALWAYS review code quality

REVIEW phase must check all 5 dimensions.

R14: ALWAYS document decisions

Architecture decisions must be documented in ADRs.

R15: ALWAYS validate with stakeholders

Key decisions must be validated with the user.

State Rules

R16: ALWAYS preserve state across sessions

Use session checkpoints to resume work.

R17: ALWAYS handle errors gracefully

Use error recovery protocols for common failures.

R18: ALWAYS offload large outputs

Tool outputs >8000 chars must be offloaded to files.

R19: ALWAYS track artifacts

Maintain a list of all generated artifacts.

R20: ALWAYS validate project state

Check for orphaned state files and inconsistent data.

Security Rules

R21: NEVER commit secrets

Use environment variables and secret scanning.

R22: ALWAYS run Bandit for Python

Python code must be scanned with Bandit.

R23: ALWAYS run Semgrep for multi-language

All code must be scanned with Semgrep.

R24: ALWAYS fix critical/high findings

Critical and high security issues must be fixed before proceeding.

Phase-Specific Rules

R25: GREEN → SECURITY → REVIEW always

Never skip SECURITY before REVIEW.

R26: MANAGE step budget

80% = warn, 100% = escalate.

R27: VALIDATE handoff schema before phase transition

Ensure output matches the JSON schema.

R28: OFFLOAD tool outputs >8000 chars

Write to file and reference the path.

Interaction Rules

R29: ALWAYS use native interactive tool when available

Never fall back to text when interactive tools are available.

R30: ALWAYS provide clear next steps

Tell the user what to do next.

R31: ALWAYS explain phase purpose

Before starting a phase, explain what it's for.

R32: ALWAYS show progress

Update the user on current status.

R33: ALWAYS ask for confirmation before destructive actions

Confirm before deleting or overwriting files.

R34: ALWAYS use the correct skill file

Load the appropriate skill for the current phase.

Rule Enforcement

Rules are enforced by:

  1. Skill files — Each skill file includes the relevant rules
  2. Gate checks — Gates verify rule compliance
  3. Step budget — Prevents infinite loops
  4. Event sourcing — Logs all actions for audit

Rule Violations

If a rule is violated:

  1. The agent must stop and explain the violation
  2. The user must decide how to proceed
  3. The violation is logged to events.log

Last updated: June 2026

Clone this wiki locally