Enforcement

Code review catches violations after they land. The policy engine catches them before — in the session, on staged files, and in CI. This is the headline feature of v0.9.0.

Every project accumulates standards: "never throw away intermediate collections here", "dynamic SQL parameters borrow, they don't box", "this module's vocabulary is canonical — return &'static str". Until now those lived in a wiki page nobody rereads. Engrams turns them into stored, machine-checkable patterns that are enforced automatically, at the moment a violation is about to happen.

The loop: record, install, enforce

1. Record a standard — engrams pattern log

What you run:

engrams pattern log \
  --name "no-throwaway-collections" \
  --description "Never materialize a collection only to consume it immediately; fuse iterators instead" \
  --check-kind regex \
  --check 'collect::<Vec<_>>\(\)\.join\(' \
  --severity error \
  --tags "rust,performance" \
  --anchor src

What you get: a pattern that is simultaneously documentation and a check. --check-kind regex|ast declares how the rule is matched — regex for textual patterns, ast for structural ast-grep patterns that match code shape rather than spelling. --severity info|warn|error (default warn) sets what happens when the check fires. Anchors and tags bind the rule to the files and topics it governs.

Why it's valuable: the standard now lives where the work happens — in the same graph as the decisions that produced it — instead of in a document that rots. And because it's a pattern node, it participates in briefing: your agent sees it via engrams prime even when no check is running.

2. Write it into the workspace — engrams install

What you run:

engrams install --harness omp

What you get: every checkable pattern written out as harness rule files in the workspace itself, so the agent's own harness enforces them in-session — the agent is told the rule at the moment it's writing code, not after it commits. (For the raw export without installation, engrams rules export writes the same omp rulebook files to a directory of your choosing.)

Why it's valuable: this is the difference between a linter and a policy. A linter complains after the fact; an installed rule shapes the code as it's being written. The agent can't forget the standard because the standard is sitting in its context.

3. Enforce everywhere else — engrams check

What you run:

engrams check                          # scan the workspace
engrams check --staged                 # git-staged files only — pre-commit
engrams check --paths src/db,src/cli   # explicit files/dirs — CI

What you get: every stored check run against the target files, with violations reported at the severity each pattern declared. Run it as a session-end review, wire --staged into a pre-commit hook, or gate CI on it.

Why it's valuable: the same rules now guard all three boundaries — the session, the commit, and the pipeline. A violation has to survive three enforcement points to reach your main branch.

Enforced, not remembered

This repository dogfoods the policy engine on itself: the architecture decisions that shaped it (decisions #44 and #45 — the TTSR-export-led engine and its workspace-isolation semantics) are logged in the graph alongside the patterns they produced, so the rules carry their own rationale with them. When a check fires, the pattern links back to why the rule exists — enforcement with a citation, not just a red X.

Keep exploring

• For You — the human's relationship with the advisor
• Briefing — start every session oriented
• Exploration — interrogate the graph directly
• The Advisor — how the graph turns rules into advice