docs(framework): add dominance checks to review and rules

CLAUDE.md

@@ -18,6 +18,8 @@ All instructions and information above are willing to be up to date, but always
 - Do not commit or push yourself unless I ask you to.
 - For every plugin change, think hard about where responsibility belongs; follow the placement and orchestration rules in `docs/ARCHITECTURE.md`.
 - Never duplicate across docs - link to the canonical home.
+- Before adding any instruction, criterion, finding, documentation sentence, or code rule, check whether an existing element already covers, overrides, contradicts, or makes it impossible. If so, do not add a parallel element: delete it, merge it into the stronger element, or rewrite the set with explicit scope, priority, and exception.
+- When naming anything, prefer intention-revealing names over technical ones: describe the goal or responsibility, not the mechanism, tool, or file format.
 
 ### Answering Guidelines
 

plugins/aidd-context/skills/02-project-memory/assets/AGENTS.md

@@ -21,6 +21,8 @@
 
 - Do not commit or push unless the user asks.
 - Do not assume your knowledge is current. Be sure of an answer before giving it.
+- Before adding any instruction, criterion, finding, documentation sentence, or code rule, check whether an existing element already covers, overrides, contradicts, or makes it impossible. If so, do not add a parallel element: delete it, merge it into the stronger element, or rewrite the set with explicit scope, priority, and exception.
+- When naming anything, prefer intention-revealing names over technical ones: describe the goal or responsibility, not the mechanism, tool, or file format.
 
 ## Memory Management
 

plugins/aidd-context/skills/05-rule-generate/actions/03-validate.md

@@ -13,9 +13,10 @@ A short pass or fail line per rule file.
 ## Process
 
 1. **Exists.** Confirm each file is on disk at its expected path.
-2. **Frontmatter.** Confirm each carries its tool's scope frontmatter matching the rule's reach, per `@../references/tool-paths.md`. An all-files rule may carry no scope field.
-3. **Concise.** Confirm the body is terse and on one topic. Flag a crowded file to split.
+2. **Contract.** Validate the file against `@../references/rule-authoring.md`.
+3. **Target.** Validate target path and frontmatter against `@../references/tool-paths.md`.
+4. **Report.** Emit one pass/fail line per file.
 
 ## Test
 
-- Every written rule file exists. Its scope frontmatter matches its reach, or is absent for an all-files rule.
+Every written rule file has one pass/fail result against both referenced contracts.

plugins/aidd-context/skills/05-rule-generate/references/rule-authoring.md

@@ -8,6 +8,7 @@ The contract every generated rule must satisfy. A rule governs editor and agent
 - **R2.** Bullets only, no prose. One ultra-short rule per bullet (3-7 words). Less is more.
 - **R3.** Scope every rule to the files it applies to, or mark it as applying to all.
 - **R4.** English only, regardless of conversation language.
+- **R5.** Do not add a rule bullet that repeats, weakens, or contradicts another active bullet in the same rule.
 
 ## File naming
 

plugins/aidd-dev/agents/reviewer.md

@@ -59,6 +59,14 @@ Your output is complete when:
 - Start fresh. Don't try to reconstruct how the artifact was produced. Read the artifact, not the production history.
 - For each criterion: inspect the relevant part of the artifact, run validation commands when applicable, mark as `fulfilled` / `partial` / `unfulfilled`.
 - Surface incoherences (artifact contradicting context or other criteria) and omissions (criteria with no corresponding content).
+- When reviewing any added instruction, criterion, finding, documentation sentence, or code rule, check whether an existing element already covers, overrides, contradicts, or makes it impossible. If so, report the parallel element and suggest deleting it, merging it into the stronger element, or rewriting the set with explicit scope, priority, and exception.
+
+| Case | What to detect | Example | Action |
+| --- | --- | --- | --- |
+| Subsumption | A stronger element already implies a weaker one. | "All fixtures must be TypeScript" plus "Do not add legacy fixture formats." | Delete the weaker element, or convert it into an example under the stronger one. |
+| Override | A specific element changes a general one. | "All docs are English" plus "Onboarding examples may stay French." | Rewrite with explicit scope, priority, and exception. |
+| Invalidation | One element makes another obsolete, impossible, or false. | A doc explains an active command that another doc says was removed. | Remove the invalid element, or mark it historical with a current replacement. |
+
 - For provider work, verify that fixture unit tests and real-provider integration tests are separated. Mocks/cassettes only pass if they exercise the real provider implementation and transformer.
 - For frontend work, verify build/routing/design/accessibility contracts when they are in the validator. Do not accept screenshots or claims without command output or file evidence when a command can be run.
 - Report findings with enough detail that the next pass can fix without guessing.