arch-deviate · git:20260930.d863924 · 2026-09-30 · sha256 4aec0669a248bd26
arch-deviate git:20260930.d863924A
Immutable. This exact content never changes and is served at /api/v1/blob/4aec0669a248bd26.
--- name: arch-deviate description: "Record a deliberate deviation from the guideline as an ADR under docs/adr/: the rule quoted, the decision, the consequences. Use when a finding is accepted as intentional." allowed-tools: Read, Grep, Glob, Write, Edit, Bash(date:*) --- # arch-deviate A project that follows the guideline may still need to diverge from a rule. The divergence is recorded, not argued about in review threads: one ADR quotes the rule, states the decision, and names what the project accepts in exchange. A breach whose ADR is cited next to the code is a documented exception. A review reports it on one line under Deviations. It is not a finding, and it never lowers a severity. ## Input The arguments name the rule being deviated from, as a lens id (`STO-02`), a section by title (`The Storage Layer, Storage Principles`), or a sentence describing it, optionally followed by a one-line reason. A technology substitution (an equivalent in place of a technology the guideline names) is not a deviation and is recorded in the project's technology-choices ADR instead, as the guideline's "Technology Choices and How to Override Them" section states; when the arguments describe one, say so and stop. Ask in one message for what is missing: the reason, the scope of the deviation (which namespace, service, or table), and whether it is permanent or has a condition for ending. ## Procedure 1. Resolve the rule: find the lens in `../../lenses/` and the section in `../../architecture.md`, paths from this skill's folder as `realpath` resolves it. Quote the principle verbatim. When the rule itself allows what the arguments describe, there is nothing to record: say so, quote the words that allow it, and stop. A manager interface kept whole past its count because its operations are one duty is such a case (CON-01): a review's pass names it. 2. The ADR goes under `docs/adr/`, created when it does not exist: `arch-check` refuses a deviation whose `adr` is anywhere else. Number the new record as one more than the highest numeric prefix present (`NNNN-<slug>.md`). Refuse to write a path that already exists. 3. Take the date from `date +%F`: the ADR records the day the decision is made, which is today, not the day of the last commit. 4. Write the ADR with the template below, under `docs/adr/` only. Keep it under one page. 5. When `specs/architecture.md` exists and has a `## Deviations` table, append one row: the ADR number, the rule, and a one-line summary. 6. An `arch-check` entry goes only with a finding the checker reports. The lens's `Check` line says which part that is: the whole lens when it reads "decides it", and only the part it names when it ends "the rest is judged". What the line says the checker names as no finding, under `to_judge`, is judged too. A deviation in a judged part, or under a lens with no `Check` line, gets no entry and no inline comment: the checker reports nothing there, and an entry that matches no finding is itself a finding that fails the gate. The ADR, the Deviations row, and the citation beside the code are its record. For a deviation in the part the checker decides, the ADR alone does not pass the gate: the checker still fails on the code. Give it the entry that names the ADR, in the shape `checkers/README.md` in this plugin shows (`../../checkers/README.md`, Exceptions); the rule id is the lens id. A whole rule turned off is a `[[tool.arch-check.disable]]` entry with `rule`, `adr` (the ADR's path), and `reason`. A rule broken in some files is a `[[tool.arch-check.exception]]` entry with `rule`, `path` (a glob), `adr`, and `reason`. One line is the inline comment `# arch-check: ignore[<LENS-ID>] ADR-NNNN` at the end of that line. Append a table entry to the root `pyproject.toml` when it has a `[tool.arch-check]` table, and print it otherwise. Print the inline comment and never place it: which line it goes on is the person's call. The checker resolves an inline comment only to `docs/adr/NNNN-*.md` with a four-digit number. When the folder's records are numbered otherwise, give only the table entry, and say why. Its `adr` still names a Markdown file under `docs/adr/`: the checker refuses any other path. 7. Whatever the lens, tell the person to cite `ADR-NNNN` in a comment beside the code that deviates. A review reports the code under Deviations, and not as a finding, only when the ADR is cited there. Do not commit. Do not edit the guideline or the lenses; a deviation belongs to the project, not to the rule. Edit nothing but the ADR folder, the deviations table, and the `[tool.arch-check]` entry. ## Output The path of the new ADR, the row appended to the deviations table (or "no deviations table"), the `arch-check` entry written or printed (or "judged by review only" when the checker decides no part the deviation is in), the reminder to cite `ADR-NNNN` beside the code, and the one-line summary for the reviewer. Nothing else. ## ADR template ```markdown # ADR NNNN: <title that names the deviation> **Status**: accepted (<date>) ## Context <The rule: lens id, section, and the principle quoted verbatim. Why it does not fit here. Facts, not preferences.> ## Decision <What the project does instead, in the present tense. Where it applies. Whether it is permanent or ends when a named condition holds.> ## Consequences <What the project accepts: the guarantee it gives up, the test or check that stands in for it, the reviews that must treat the cited code as an exception.> ```