A custom rule stores a prompt and a pinned interpretation of that prompt. Creating the rule analyzes the prompt once and freezes the checks. Later evaluations run those persisted checks; Warestack does not accept a conclusion from an unpinned, per-evaluation reinterpretation. The name, prompt, parameters, and where the rule is enabled stay in place when the interpretation changes.

Per-check outcomes

Every pinned check must return one of passed, failed, not_applicable, or not_evaluated. Warestack validates the evidence selectors, conjunctive alternatives, and applicability for every check—not only the checks claimed as violations—and derives the overall rule result on the server. Missing or incomplete coverage is not a pass. For a merge-blocking rule it produces an incomplete, fail-closed check until a complete trusted evaluation is available.

Repository policy files

A prompt that names CLAUDE.md, AGENTS.md, GEMINI.md, .cursorrules, or .github/copilot-instructions.md can pin the repository_instructions capability. Each pull request then reads the selected policy files at that pull request’s base revision. The pull request that edits the policy is judged against the policy from before the edit.

The pin copies the requirements into checks: a required section, a branch pattern, a line cap. Reading the file again lets the check cite the current base revision. A new or changed requirement in the file does not become a new check. After that policy change merges, re-interpret and adopt before later pull requests should enforce it. A wording change that leaves the same requirements can stay on the current pin.

Re-interpret, then adopt

Open the custom rule in the console and choose Re-interpret. That calls:

POST /spaces/{space_alias}/rules/custom/{rule_id}/reinterpret

The response is the current interpretation, a candidate, and a diff. The saved rule stays unchanged. A candidate whose parameters differ from the saved rule is rejected; duplicate the rule to review that parameter change.

Adopt calls:

PUT /spaces/{space_alias}/rules/custom/{rule_id}/interpretation

The body is the proposal id and the base version you just reviewed. Adopt pins the next interpretation version — checks, evidence selectors, and model — only while that base version is still current. Review the diff before adopting. The MCP tools analyze_rule and create_rule draft a new rule. They do not refresh an existing interpretation.

Rules saved before this evidence

A custom rule whose prompt names one of those instruction files, and whose saved interpretation does not include repository_instructions, stays not_evaluated. The finding says to re-interpret and accept the rule. Shipping the capability does not rewrite that pin.

The same fail-closed boundary applies to any enabled custom rule without usable persisted checks. Re-interpret and adopt it before relying on the outcome.