enola/Docs/Intent

Documentation

State the architecture you expect

Intent turns architectural decisions into rules Enola can show before an edit and verify after it.

01 · Declare

Keep the decision near its owner

Repository intent lives in enola-intent.yaml. A cluster can declare intent beside its repository list. A Markdown decision page can opt in with an enola_intent: frontmatter block.

Declarations name components and the relationships allowed between them. Constraint files in enola/constraints/*.yaml add rules without turning prose into policy.

02 · Before the edit

Ask what governs the change

QuestionTool
Which declarations cover this target?governing_intent
Which rules, exemptions, and guidance apply?constraints_for
What would these paths or this patch affect?plan_check or enola plan
Check planned pathsshell
enola plan --paths internal/auth,internal/api

03 · Modes

Choose how each rule behaves

ModeBehavior
ratchetDefault. Existing debt can remain; new violations fail the check.
advisoryReports evidence without failing the check.
strictAny violation fails unless it is recorded in the suppression ledger.

Exemptions carve out named witnesses and remain visible. Guidance gives pre-edit advice; it is not a violation.

04 · Evidence

Verdicts stop at measured facts

Enola evaluates declarations against the graph it extracted. Unsupported syntax, dynamic behavior, generated code, or missing provider facts can leave relationships unseen. Receipts record extractor and provider provenance; coverage reports show unresolved boundaries.

Intent is declared, not inferred. A rule can only judge facts available to the snapshot. Review the evidence and coverage before treating absence as proof.

05 · Full schema

Use the canonical reference for authoring

For component selectors, relation vocabularies, all thirteen rule forms, recipes, protocols, exemptions, and provider contracts, read INTENT.md.