[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CXYPYPEAAMYRK8SPC1SXAF":3,"skill-same:01M6CXYPYPEAAMYRK8SPC1SXAF":110},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6CXYPYPEAAMYRK8SPC1SXAF","reconcile-normative",null,"Reconcile normative content across decision archives, project memory, and host-native project instructions. Use to detect redundancy, contradictions, uncodified patterns, or stale rules across AGENTS.md\u002F.agents rules on Codex and .claude\u002Frules on Claude Code.","RebelliousSmile\u002Fmy-claude-marketplace","RebelliousSmile","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F40766799?v=4","01M6CXW595637KNM9Z3TYT9F7R","François-Xavier Guillois","01M6CXW5DBBQTQ9JM1BKH9VQGK",1,"MIT","https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"reconcile normative","reconcile","Rules","project","across","patterns","files","stale","use","instructions","codex","decision","Bash","productivity","content","code","automation","workflow","memory","2026-11-10 10:12:30",false,"---\nname: reconcile-normative\ndescription: Reconcile normative content across decision archives, project memory, and host-native project instructions. Use to detect redundancy, contradictions, uncodified patterns, or stale rules across AGENTS.md\u002F.agents rules on Codex and .claude\u002Frules on Claude Code.\nauthor: François-Xavier Guillois\nversion: 4.8.0\nvibe_version: \">=1.0.0\"\npermissions:\n  - files\n  - bash\ntags:\n  - productivity\n  - workflow\n  - automation\n---\n\nRead [host portability](..\u002F..\u002Freferences\u002Fhost-portability.md) before resolving plugin files, invoking sibling skills, or persisting project guidance.\n\n# Reconcile-normative — normative content reconciliation\n\n## Purpose\n\nApply the project's normative-load rule to all normative sources: drain the archive, consolidate existing host instructions, move explanatory content to project memory, detect duplicates and contradictions, elevate recurring patterns when justified, and flag potentially stale rules.\n\n## When to invoke\n\n- As a sub-phase of `harvest` (global orchestration)\n- Standalone when the user wants to audit normative content without triggering tracker\u002Ffile lifecycle work\n\n## Rules\n\n- Never delete an archive file without explicit confirmation\n- Never modify an existing rule without explicit confirmation\n- Batch mode allowed: > 5 entries of the same nature → 3-sample preview then bulk\n- Resolve `PROJECT_RULES_ROOT` from host portability. On Codex, include the nearest applicable `AGENTS.md` in every mapping and maintain a bounded index there for rules stored under `.agents\u002Frules\u002F`. On Claude Code, use `.claude\u002Frules\u002F`. When both exist, reconcile their semantics rather than treating one as stale by default.\n\n## Configuration (overridable via argument)\n\n| Parameter | Default | Description |\n|---|---|---|\n| `rule_elevation_threshold` | 3 | Minimum number of decisions on the same topic to elevate to a rule |\n| `rule_freshness_days` | 90 | Beyond this age, an unmodified rule becomes a candidate for the freshness pass |\n\n---\n\n## Phase A — Mapping (incremental scan + archive sweep)\n\n### Sources\n\n- `aidd_docs\u002Fmemory\u002Finternal\u002Fdecisions\u002F` — normative archive to drain (ADR destination of `aidd-context:10-learn`); legacy projects keep it at `aidd_docs\u002Finternal\u002Fdecisions\u002F` — sweep whichever exists\n- `aidd_docs\u002Fmemory\u002F` — project memory bank, **flat**: `aidd_docs\u002Fmemory\u002F\u003Cbank>.md`, with `internal\u002F` and `external\u002F` reserved for on-demand notes (`aidd-context:02-project-memory`, `references\u002Fstructure.md`)\n- `${PROJECT_RULES_ROOT}\u002F` — codified rule references (all categories 00-09)\n- Every applicable `AGENTS.md` — auto-loaded Codex project instructions, when present; include ancestor and nested files that govern the project\n- `.claude\u002Frules\u002F` and `.agents\u002Frules\u002F` when present — inspect both host surfaces, even when one is not the current host\n\n### Reference rule\n\n```markdown\n${PROJECT_RULES_ROOT}\u002F01-standards\u002F1-normative-vs-archive.md\n```\n\n### Last-run detection\n\nRead the most recent file in `aidd_docs\u002Fharvests\u002F`:\n\n```bash\n# macOS \u002F Linux\nls -t aidd_docs\u002Fharvests\u002F*.md | head -1\n\n# Windows (PowerShell)\nGet-ChildItem aidd_docs\u002Fharvests\\*.md | Sort-Object LastWriteTime -Descending | Select-Object -First 1 -ExpandProperty FullName\n```\n\n### Incremental scan\n\nList files in `aidd_docs\u002Fmemory\u002F`, `${PROJECT_RULES_ROOT}\u002F`, and the applicable `AGENTS.md` modified since that date (if no prior harvest: scan all). Skip absent optional paths without failing:\n\n```bash\n# macOS \u002F Linux\nfind aidd_docs\u002Fmemory ${PROJECT_RULES_ROOT} \\\n  -type f -name \"*.md\" -newer aidd_docs\u002Fharvests\u002F\u003Clast-report>.md | sort\n\n# Windows (PowerShell)\n$lastHarvest = Get-ChildItem aidd_docs\\harvests\\*.md | Sort-Object LastWriteTime -Descending | Select-Object -First 1\nGet-ChildItem -Recurse -Filter \"*.md\" aidd_docs\\memory, ${PROJECT_RULES_ROOT} |\n  Where-Object { $_.LastWriteTime -gt $lastHarvest.LastWriteTime } | Sort-Object Name | Select-Object -ExpandProperty FullName\n```\n\n### Archive sweep\n\nList **every** file in `aidd_docs\u002Fmemory\u002Finternal\u002Fdecisions\u002F`, in the legacy `aidd_docs\u002Finternal\u002Fdecisions\u002F`, and in any detected `*\u002Fdecisions\u002F`, `*\u002Fadr\u002F`, `*\u002Farchive\u002F`, with no date filter — their mere presence is the anomaly to resolve.\n\n**The incremental scan is NOT a sweep replacement.** A prior harvest may have audited DEC-001 to DEC-024 and a new run may be tempted to scan only DEC-025+. Every file must be **classified** at every run (normative \u002F historical \u002F mixed) — even if previously seen. If a file was classified `historical` in a prior report and remains unchanged, log it as \"skipped — historical, audited YYYY-MM-DD\" rather than silently ignoring it. Never skip without explicit log entry.\n\n**If both incremental scans return nothing and the archive sweep is empty, still run Phase D (existing-rule consolidation) before the freshness pass and report.** Existing rules may be bloated or duplicated without having changed since the last Harvest.\n\nRead each returned file. Build a topic map (lib\u002Ftechnology, functional domain) recording for each file: main topic, identified normative content, identified historical content.\n\nIndependently inventory **every current rule file and applicable `AGENTS.md`**, regardless of modification date or last-run status. Record host, path scope, and whether the content is always loaded, conditionally loaded, or only reached through an explicit index. The incremental scan limits archive\u002Fmemory work; it never limits existing-rule consolidation.\n\n---\n\n## Phase B — Detection\n\nFor each scanned file, look for:\n\n| Issue | Definition | Action |\n|---|---|---|\n| **Normative in archive** | File in `decisions\u002F`, `adr\u002F` or `archive\u002F` — content with `must \u002F never \u002F always \u002F required` or names a file\u002Ffunction\u002Fflag binding the future | Classify as `normative \\| historical \\| mixed`. Migrate the normative slice. See Phase C. |\n| **Duplicate** | Same constraint repeated in 2+ effective instruction locations for the same host and scope | Merge without removing the only effective copy for another host |\n| **Contradiction** | Two files prescribe opposite behaviors | Keep the most recent or specific, annotate the choice |\n| **Recurring pattern** | Same constraint type in ≥ `rule_elevation_threshold` files in `memory\u002F`, absent from host instructions | Elevate under `${PROJECT_RULES_ROOT}\u002F\u003Ccategory>\u002F` and index it from `AGENTS.md` on Codex |\n| **Obsolete decision** | References a lib, function or pattern that no longer exists | Flag to user |\n\nThe `rule_elevation_threshold` only applies to patterns observed in `memory\u002F`. For archive files, **a single normative occurrence is enough** to trigger migration.\n\n---\n\n## Phase C — Consolidation\n\nApply Phase B actions. For each change:\n\n- **Migrate a normative entry from archive**:\n  0. **Verify no existing rule already covers the topic**: `rg` with **≥ 2 terms** in `${PROJECT_RULES_ROOT}\u002F` — functional topic AND named technical symbol (file, flag, function, constant). Read the matched passage and check **normative force**, not just term presence:\n     - **Full coverage** → matched passage uses `must` \u002F `always` \u002F `never` \u002F `required` to enforce the same constraint. Do not duplicate, skip to next entry (count under \"rule already covers\")\n     - **Partial coverage** → matched passage mentions the term but is descriptive (table, example, narrative) without imperative enforcement, OR rule's `paths:` does not cover the surface where the constraint applies. Enrich the **existing** rule (not memory), keep its `paths:` or extend it\n     - **No coverage** → no match or matched passage is unrelated. Continue to step 1\n\nA keyword grep that finds the term inside an example block or descriptive table is **not coverage** — the rule must impose the constraint, not merely mention it.\n  1. Split normative slice \u002F historical slice\n  2. **Choose target — rule or memory** per the criterion below\n  3. If **rule**: create\u002Fenrich a path-scoped rule; on Codex, also update the bounded normative index in `AGENTS.md` so the reference is discoverable\n  4. If **memory**: pick the target file via the mapping below. For the expected sections, read the template shipped by `aidd-context:02-project-memory` (`skills\u002F02-project-memory\u002Fassets\u002Ftemplates\u002Fmemory\u002F\u003Ccapability>\u002F\u003Cfile>.md`, resolved through host portability; `references\u002Fmemory-destinations.md` maps template → bank file). If the plugin is not reachable, infer the sections from the target file itself — never fail on a missing template\n  5. Insert in the section's format (table row, 3-15 word bullet, H3 subtitle, mermaid block) — prefer existing sections; create a new section only if the file's spirit justifies it.\n\n     **Content shaping rules** (apply to memory inserts only; for the rule branch at step 3, follow `${PROJECT_RULES_ROOT}\u002F01-standards\u002F1-rule-writing.md` — 3-7 word imperatives, no inline rationale):\n\n     - **Normative memory only**: when a decision is intentionally retained as on-demand guidance rather than an active host rule, express its constraint clearly with `Always X` \u002F `Never Y` \u002F `Must Z`. Explanations, history, and runbooks moved out of existing rules remain descriptive; do not turn them into duplicate imperatives.\n     - **Why-line for normative memory when needed**: place rationale on a separate indented line below the short constraint (`  **Why:** \u003Creason>`). Explanatory memory can carry its rationale in normal prose.\n     - **No source trace back to the deleted ADR**: a `(cf. DEC-XYZ)` pointer dies the moment the source is deleted, and keeping the source as archive pollutes memory load 100 % of the time for a revert that happens ~1 % of the time. The bullet's own rationale is what carries the rule forward; the ADR is git history.\n     - **For chain migrations into a consolidated section**: place rationale once in the H3 intro paragraph, not per bullet — individual bullets stay terse.\n  6. Preserve frontmatter, ordering and style **of the target file** (informed by its template, not slavishly copied)\n  7. Show the user the content to insert + propose **full deletion of the source** as default. Memory load is paid 100 % of the time; an archive (or even a stub) is consulted ~1 % of the time and weighs against every future read — git history is the revert path, not a kept file. Stub only if the user explicitly asks. **Distinct confirmation** per decision (or per grouped chain). **Batch mode**: if > 5 entries of the same nature, present a sample of 3 full decisions; if the user validates, apply the rest in bulk with a single final confirmation\n- **Merge duplicate**: target file is the most recent; on tie, the most complete. Show both files and the proposed merge → **distinct confirmation**: \"Merge and delete source?\" Rewrite the target, delete the source only after agreement.\n- **Elevate to rule**: create `${PROJECT_RULES_ROOT}\u002F\u003Ccategory>\u002F\u003Cn>-\u003Ctopic>.md` (category 00-09 per `1-rule-structure.md`) following the template and rule-writing convention. On Codex, add a concise `AGENTS.md` instruction naming when to read that file; preserve unrelated sections. Show the created rule and source list → **distinct confirmation**: \"Does the rule fully cover these files? Delete sources?\"\n\n  **After creating any rule with a forbidden pattern**: grep the codebase scoped by the new rule's `paths:` to count violations. Forbidden patterns are bullets formed with `never`, `forbidden`, `must not`, `do not use`, etc.\n\n  ```bash\n  # Example — rule forbids `transition-all`, paths: **\u002F*.vue, **\u002F*.css\n  rg -n \"transition-all|transition: all\" --glob \"**\u002F*.vue\" --glob \"**\u002F*.css\"\n  ```\n\n  If N > 0 violations: surface to the user as a separate signal — \"Règle créée, mais N violations existent dans le code. Créer un audit \u002F issue de cleanup ?\". Never silent — a rule violated immediately at creation is dead weight.\n\n### Target criterion — rule vs memory\n\n| Pick a **rule** (`${PROJECT_RULES_ROOT}\u002F...`) if | Pick **memory** (`aidd_docs\u002Fmemory\u002F...`) if |\n|---|---|\n| Topic is **path-scopable on a narrow surface** (glob isolating \u003C ~30 % of code: `firebase.json`, `nuxt.config.ts`, `server\u002Fapi\u002F**`, `models\u002F*.js`), or it is a genuinely universal constraint needed on every task and fits in a short host instruction | Topic is **transverse but explanatory** or conceptual, or the natural glob is too broad (`**\u002F*.vue`, `**\u002F*.ts` alone — cover almost all app code) without requiring an always-loaded instruction |\n| Rule is **verifiable at write-time** (concrete convention, named anti-pattern, constant, required value) | Content is **explanatory**: why, context, principle, learning, runbook |\n| Agent must obey it when touching the affected files; on Codex, `AGENTS.md` points to the scoped reference | Agent may consult it on demand for explanation, history, decisions or a runbook; memory is not assumed to auto-load |\n\nOn ambiguity: if the decision can be expressed as a testable code convention **and** scoped to a narrow surface, prefer **rule**. Keep a truly universal mandatory constraint as a short host instruction. Put its rationale in memory. Otherwise prefer **memory**.\n\n### Topic → memory file mapping\n\nBank files are **flat** — `aidd_docs\u002Fmemory\u002F\u003Cfile>.md`, kebab-case, never nested. `memory\u002Finternal\u002F` and `memory\u002Fexternal\u002F` hold on-demand notes and ADRs, never a bank file. The canonical file list is `aidd-context:02-project-memory`, `references\u002Fmemory-destinations.md`; a bank only holds the files its capabilities warranted, so a row's file may legitimately be absent.\n\nThe mapping below is a starting point, not exhaustive. When a topic spans multiple rows (e.g. auth ∈ {auth, api}), pick the file whose **template section** most closely matches the decision's substance. When no row fits, follow the fallback heuristic at the bottom.\n\n| Decision topic | Memory file | Template sections to favor |\n|---|---|---|\n| Stack, naming, modules, service organization, i18n | `architecture.md` | Language\u002FFramework, Naming Conventions, Services communication |\n| Internal API surface, request\u002Fresponse types, validation, error handling | `api.md` | Services, Data Flow, Error Handling, Validation |\n| Third-party integrations, SDK wiring, webhooks | `integration.md` | existing sections |\n| Auth flows, security rules, custom claims, session handling | `auth.md` — prefer a path-scoped rule if the convention is verifiable at write-time | existing sections |\n| Real-time listeners, websocket \u002F `onSnapshot` patterns | `realtime.md` | existing sections |\n| DB schema, entities, migrations, seeding | `database.md` | Main entities, Migrations, Seeding |\n| Data modeling, pipelines, storage formats | `data.md` | existing sections |\n| Design system, theme, tokens, UI components, accessibility | `design.md` | Design Implementation, Component Standards, Layout System |\n| Forms, client validation, form state | `forms.md` | State Management, Validation, Error handling, Form Flow |\n| Navigation, browsing flow, lists\u002Ffilters, product UX | `navigation.md` | existing sections |\n| CI\u002FCD, hosting, env vars, URLs, monitoring, observability, tracking, consent\u002FRGPD | `deployment.md` | CI\u002FCD Pipeline, Environments Variables, URLs, Monitoring & Logging |\n| Runtime topology, containers, provisioning | `infra.md` | existing sections |\n| Caching strategy (HTTP headers, hosting cache, store TTL, query result cache) | `deployment.md` (hosting\u002FCDN angle) or `architecture.md` (in-app cache angle) | CI\u002FCD Pipeline, Services |\n| Feature flags, kill switches, gradual rollout | `deployment.md` | Environments Variables |\n| Notifications (transactional email, marketing flows, push) | `messaging.md` | existing sections |\n| Test strategy, fixtures, mocks, test types | `testing.md` | Testing Strategy, Tools and Frameworks, Mocking |\n| Repo overview | `codebase-map.md` | single flowchart |\n| VCS, branches, commit conventions | `vcs.md` | template sections |\n| Constants binding the future, business value assertions, transverse guardrails | `coding-assertions.md` | existing sections |\n| Product context, vision, target audience | `project-brief.md` | existing sections |\n| Backlog conventions, refinement workflow | `backlog.md` | existing sections |\n| Vendor ecosystem, external services in use | `ecosystem.md` | existing sections |\n| Packaging, publishing, versioning, release channels | `package.md` | existing sections |\n| CLI surface, commands, flags conventions | `cli.md` | existing sections |\n| Mobile-specific conventions | `mobile.md` | existing sections |\n| Desktop-specific conventions | `desktop.md` | existing sections |\n| Performance decisions accumulated within an iteration | custom file, e.g. `iteration-N-perf-learnings.md` | dedicated section per chain |\n| Multi-agent coordination, sub-agent invocation rules | custom file, e.g. `agents-coordination.md` | dedicated section |\n| Project-specific orchestration deviating from the default AIDD flow | custom file, e.g. `custom-main-workflow.md` | dedicated section |\n| Outside the taxonomy above | **First**: scan existing custom bank files (`aidd_docs\u002Fmemory\u002F*.md` not listed above) for a thematic fit. **Only if no fit**: propose creation to the user, justifying the new file against the canonical list in `references\u002Fmemory-destinations.md`. | dedicated section |\n\nTeam-owned documents — `aidd_docs\u002FREADME.md`, `GUIDELINES.md`, `CONTRIBUTING.md` — are never a migration target: their placeholders belong to a human.\n\nIf no file fits, **propose creation** to the user before acting: every new bank file must either match a capability row of `references\u002Fmemory-destinations.md` or be justified as a custom bank file.\n\nAny other deletion of a memory file → **user confirmation** before acting.\n\nWhen several archive entries form a chain (supersession, shared topic), propose a grouped migration into **a single consolidated section** of the target file rather than per-entry inserts.\n\n---\n\n## Phase D — Existing-rule consolidation, then freshness\n\n### Full consolidation pass\n\nUse Phase A's **complete** rule inventory on every run, including unchanged files. Work at the level of individual instructions and sections, not whole files. For each item, record its host and path scope, the behavior it requires, any exceptions, its source, and whether a current memory bank already covers its explanation.\n\nClassify each item:\n\n| Class | Criterion | Destination |\n|---|---|---|\n| **Keep as rule** | A current, actionable constraint that changes agent behavior on a future task; concrete enough to check, with the narrowest applicable scope | One concise effective host instruction or scoped rule; retain necessary cross-host equivalents |\n| **Narrow scope** | A current, write-time-verifiable rule whose declared `paths:` cover significantly more files than the measured call sites of the technical symbol(s) it names, or whose path list contains an entry wholly covered by another entry | Keep the rule, remove redundant entries, and propose the smallest measured scope that still contains every current site; do not move the constraint to memory |\n| **Move to memory** | Rationale, decision history, architecture explanation, examples, troubleshooting steps, or runbook material without an independent enforceable constraint | Existing thematic `aidd_docs\u002Fmemory\u002F\u003Cbank>.md` section, following Phase C's memory mapping and format |\n| **Resolve** | Duplicate, overlapping, contradictory, obsolete, or superseded instruction | Merge, narrow, update, or remove only after checking the surviving effective instruction and required confirmations |\n\nBefore assigning a class to a path-scoped rule, extract the concrete technical symbols it names\n(function, constant, flag, command, configuration key; never generic prose) and measure its effective\npopulation:\n\n```bash\nnode \"${OVERCODE_PLUGIN_ROOT}\u002Fskills\u002Freconcile-normative\u002Ftools\u002Fscope-audit.mjs\" \\\n  --root \u003Cproject-root> --rule \u003Crule.md> --symbol \u003Cliteral> --json\n```\n\nPass one `--symbol` per independently named mechanism. The report compares the union of files matched\nby `paths:` with the union of literal symbol sites, lists sites outside the scope, and compares every\npath entry with its siblings. A path whose measured file set is wholly contained by another entry is\nredundant even when their glob strings look different. A declared population at least twice the symbol\npopulation, or carrying at least three files with no site, is a **Narrow scope candidate**, not an\nautomatic edit: inspect dynamic dispatch, generated calls, conventions that apply before the first call,\nand non-literal use before proposing the narrower paths. A symbol site outside the current scope is a\ncoverage defect and blocks narrowing until the surviving scope includes it.\n\nImperative wording alone does not prove that content is a current rule. Verify the current code, decisions, and supported workflow before retaining or elevating it. A mixed file may need a short surviving rule plus a memory entry. Preserve exceptions, paths, and host-specific syntax when shortening; do not silently weaken a constraint. Do not move a real constraint only to on-demand memory.\n\nCompare rules **within each host and applicable path scope**. A Codex `AGENTS.md` index and `.agents\u002Frules\u002F` reference form one effective path; Claude's `.claude\u002Frules\u002F` may need an equivalent constraint. Cross-host equivalents are not redundant copies to delete. For Codex, keep the `AGENTS.md` entry bounded to when and where the scoped file should be read. Remove index entries that no longer point to an active rule.\n\nFor each proposed consolidation, show the current instruction, the concise surviving rule, the memory destination and text, the affected hosts\u002Fscopes, and any source removal. Follow the existing-rule edit and file-deletion confirmation boundaries. Apply the memory and surviving-rule updates before removing duplicate or obsolete instructions; if an approval is declined, leave the current instruction effective and report the proposal as pending. Use the Phase C memory-target rule when no suitable bank exists.\n\nMeasure context load **before and after** each accepted set of edits: report bytes or tokens for applicable always-loaded `AGENTS.md` content and Claude rule content, plus separately the size of conditionally loaded rule references. Do not count on-demand memory as auto-loaded. If an exact host token count is unavailable, use byte counts with the method stated. Report no reduction when no edit was made or when effective load is unchanged.\n\nFor every accepted **Narrow scope** edit, Phase E names the before\u002Fafter file populations, the symbols\nused for the measurement, any redundant path removed, and this tradeoff explicitly: the tighter scope\nreduces irrelevant automatic loading but a future legitimate call site outside it will not load the rule.\nThat risk is reported in prose, not hidden in the consolidation count.\n\nThis pass is complete only after every existing rule file and applicable `AGENTS.md` has been classified, including files unchanged since the last run. Record counts for rules inspected, consolidated, retained, moved to memory, and pending approval.\n\n### Existing-rules freshness pass\n\n### Goal\n\nDetect rules in `${PROJECT_RULES_ROOT}\u002F` and normative `AGENTS.md` sections whose content may have been invalidated by a more recent decision or memory entry. This is the **inverse** of Phase C step 0: instead of asking \"does a rule cover this new input?\", ask \"is this rule still consistent with recent inputs?\"\n\n### Candidate rule selection\n\nList rules unmodified for `rule_freshness_days` days:\n\n```bash\n# macOS \u002F Linux\nfind ${PROJECT_RULES_ROOT} -type f -name \"*.md\" -mtime +90 | sort\n\n# Windows (PowerShell)\nGet-ChildItem -Recurse -Filter \"*.md\" ${PROJECT_RULES_ROOT} |\n  Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-90) } |\n  Sort-Object Name | Select-Object -ExpandProperty FullName\n```\n\n### For each candidate rule\n\n1. Extract **key terms**: technical symbols named in the rule (file, flag, function, constant, lib). Ignore generic words (`must`, `never`, `pattern`, etc.).\n2. For each term, grep in `aidd_docs\u002Fmemory\u002F` (bank + `internal\u002Fdecisions\u002F`) and in the legacy `aidd_docs\u002Finternal\u002Fdecisions\u002F`:\n   ```bash\n   rg \"\u003Cterm>\" aidd_docs\u002Fmemory aidd_docs\u002Finternal\u002Fdecisions 2>\u002Fdev\u002Fnull\n   ```\n3. Filter hits with `mtime` > rule's modification date.\n4. **If hits found**: flag \"rule potentially stale — verify contradiction\" with:\n   - rule path\n   - rule date\n   - list of newer files mentioning the same terms\n   - excerpt of relevant passages\n5. **Distinct confirmation** per flagged rule: show to user, ask:\n   - \"Update rule?\" → manual or guided edit\n   - \"Rule still valid?\" → touch the file (`touch` \u002F `(Get-Item).LastWriteTime = Get-Date`) to push the next freshness deadline\n   - \"Rule obsolete?\" → deletion after explicit confirmation\n\n### Why this pass\n\nThe Phase A incremental scan covers what moved recently. A rule written 6 months ago and never edited since **will never be in the scan** — even if newer memory and decisions have rendered it obsolete. The freshness pass plugs that hole by starting from the rules themselves.\n\n---\n\n## Phase E — Report\n\nList:\n- N normative entries migrated from archive\n- N existing rules enriched (partial coverage)\n- N entries already covered by a rule (skip)\n- N duplicates merged\n- N contradictions resolved\n- N patterns elevated to rules\n- N obsolete decisions flagged\n- N existing rules inspected, consolidated, retained, and moved to memory; N proposals pending approval\n- Always-loaded bytes or tokens before and after, with conditional-rule size reported separately\n- N rules flagged in freshness pass (updated \u002F touched \u002F deleted)\n\nIf invoked as a sub-phase of `harvest`, return these metrics to the orchestrator. Otherwise, write a standalone report at `aidd_docs\u002Fharvests\u002FYYYY_MM_DD-reconcile-normative.md`.\n\n## Evals\n\n- [Existing-rule consolidation scenarios](evals\u002Frule-load-scenarios.md)\n","Read [host portability](..\u002F..\u002Freferences\u002Fhost-portability.md) before resolving plugin files, invoking sibling skills, or persisting project guidance.\n\n# Reconcile-normative — normative content reconciliation\n\n## Purpose\n\nApply the project's normative-load rule to all normative sources: drain the archive, consolidate existing host instructions, move explanatory content to project memory, detect duplicates and contradictions, elevate recurring patterns when justified, and flag potentially stale rules.\n\n## When to invoke\n\n- As a sub-phase of `harvest` (global orchestration)\n- Standalone when the user wants to audit normative content without triggering tracker\u002Ffile lifecycle work\n\n## Rules\n\n- Never delete an archive file without explicit confirmation\n- Never modify an existing rule without explicit confirmation\n- Batch mode allowed: > 5 entries of the same nature → 3-sample preview then bulk\n- Resolve `PROJECT_RULES_ROOT` from host portability. On Codex, include the nearest applicable `AGENTS.md` in every mapping and maintain a bounded index there for rules stored under `.agents\u002Frules\u002F`. On Claude Code, use `.claude\u002Frules\u002F`. When both exist, reconcile their semantics rather than treating one as stale by default.\n\n## Configuration (overridable via argument)\n\n| Parameter | Default | Description |\n|---|---|---|\n| `rule_elevation_threshold` | 3 | Minimum number of decisions on the same topic to elevate to a rule |\n| `rule_freshness_days` | 90 | Beyond this age, an unmodified rule becomes a candidate for the freshness pass |\n\n---\n\n## Phase A — Mapping (incremental scan + archive sweep)\n\n### Sources\n\n- `aidd_docs\u002Fmemory\u002Finternal\u002Fdecisions\u002F` — normative archive to drain (ADR destination of `aidd-context:10-learn`); legacy projects keep it at `aidd_docs\u002Finternal\u002Fdecisions\u002F` — sweep whichever exists\n- `aidd_docs\u002Fmemory\u002F` — project memory bank, **flat**: `aidd_docs\u002Fmemory\u002F\u003Cbank>.md`, with `internal\u002F` and `external\u002F` reserved for on-demand notes (`aidd-context:02-project-memory`, `references\u002Fstructure.md`)\n- `${PROJECT_RULES_ROOT}\u002F` — codified rule references (all categories 00-09)\n- Every applicable `AGENTS.md` — auto-loaded Codex project instructions, when present; include ancestor and nested files that govern the project\n- `.claude\u002Frules\u002F` and `.agents\u002Frules\u002F` when present — inspect both host surfaces, even when one is not the current host\n\n### Reference rule\n\n```markdown\n${PROJECT_RULES_ROOT}\u002F01-standards\u002F1-normative-vs-archive.md\n```\n\n### Last-run detection\n\nRead the most recent file in `aidd_docs\u002Fharvests\u002F`:\n\n```bash\n# macOS \u002F Linux\nls -t aidd_docs\u002Fharvests\u002F*.md | head -1\n\n# Windows (PowerShell)\nGet-ChildItem aidd_docs\u002Fharvests\\*.md | Sort-Object LastWriteTime -Descending | Select-Object -First 1 -ExpandProperty FullName\n```\n\n### Incremental scan\n\nList files in `aidd_docs\u002Fmemory\u002F`, `${PROJECT_RULES_ROOT}\u002F`, and the applicable `AGENTS.md` modified since that date (if no prior harvest: scan all). Skip absent optional paths without failing:\n\n```bash\n# macOS \u002F Linux\nfind aidd_docs\u002Fmemory ${PROJECT_RULES_ROOT} \\\n  -type f -name \"*.md\" -newer aidd_docs\u002Fharvests\u002F\u003Clast-report>.md | sort\n\n# Windows (PowerShell)\n$lastHarvest = Get-ChildItem aidd_docs\\harvests\\*.md | Sort-Object LastWriteTime -Descending | Select-Object -First 1\nGet-ChildItem -Recurse -Filter \"*.md\" aidd_docs\\memory, ${PROJECT_RULES_ROOT} |\n  Where-Object { $_.LastWriteTime -gt $lastHarvest.LastWriteTime } | Sort-Object Name | Select-Object -ExpandProperty FullName\n```\n\n### Archive sweep\n\nList **every** file in `aidd_docs\u002Fmemory\u002Finternal\u002Fdecisions\u002F`, in the legacy `aidd_docs\u002Finternal\u002Fdecisions\u002F`, and in any detected `*\u002Fdecisions\u002F`, `*\u002Fadr\u002F`, `*\u002Farchive\u002F`, with no date filter — their mere presence is the anomaly to resolve.\n\n**The incremental scan is NOT a sweep replacement.** A prior harvest may have audited DEC-001 to DEC-024 and a new run may be tempted to scan only DEC-025+. Every file must be **classified** at every run (normative \u002F historical \u002F mixed) — even if previously seen. If a file was classified `historical` in a prior report and remains unchanged, log it as \"skipped — historical, audited YYYY-MM-DD\" rather than silently ignoring it. Never skip without explicit log entry.\n\n**If both incremental scans return nothing and the archive sweep is empty, still run Phase D (existing-rule consolidation) before the freshness pass and report.** Existing rules may be bloated or duplicated without having changed since the last Harvest.\n\nRead each returned file. Build a topic map (lib\u002Ftechnology, functional domain) recording for each file: main topic, identified normative content, identified historical content.\n\nIndependently inventory **every current rule file and applicable `AGENTS.md`**, regardless of modification date or last-run status. Record host, path scope, and whether the content is always loaded, conditionally loaded, or only reached through an explicit index. The incremental scan limits archive\u002Fmemory work; it never limits existing-rule consolidation.\n\n---\n\n## Phase B — Detection\n\nFor each scanned file, look for:\n\n| Issue | Definition | Action |\n|---|---|---|\n| **Normative in archive** | File in `decisions\u002F`, `adr\u002F` or `archive\u002F` — content with `must \u002F never \u002F always \u002F required` or names a file\u002Ffunction\u002Fflag binding the future | Classify as `normative \\| historical \\| mixed`. Migrate the normative slice. See Phase C. |\n| **Duplicate** | Same constraint repeated in 2+ effective instruction locations for the same host and scope | Merge without removing the only effective copy for another host |\n| **Contradiction** | Two files prescribe opposite behaviors | Keep the most recent or specific, annotate the choice |\n| **Recurring pattern** | Same constraint type in ≥ `rule_elevation_threshold` files in `memory\u002F`, absent from host instructions | Elevate under `${PROJECT_RULES_ROOT}\u002F\u003Ccategory>\u002F` and index it from `AGENTS.md` on Codex |\n| **Obsolete decision** | References a lib, function or pattern that no longer exists | Flag to user |\n\nThe `rule_elevation_threshold` only applies to patterns observed in `memory\u002F`. For archive files, **a single normative occurrence is enough** to trigger migration.\n\n---\n\n## Phase C — Consolidation\n\nApply Phase B actions. For each change:\n\n- **Migrate a normative entry from archive**:\n  0. **Verify no existing rule already covers the topic**: `rg` with **≥ 2 terms** in `${PROJECT_RULES_ROOT}\u002F` — functional topic AND named technical symbol (file, flag, function, constant). Read the matched passage and check **normative force**, not just term presence:\n     - **Full coverage** → matched passage uses `must` \u002F `always` \u002F `never` \u002F `required` to enforce the same constraint. Do not duplicate, skip to next entry (count under \"rule already covers\")\n     - **Partial coverage** → matched passage mentions the term but is descriptive (table, example, narrative) without imperative enforcement, OR rule's `paths:` does not cover the surface where the constraint applies. Enrich the **existing** rule (not memory), keep its `paths:` or extend it\n     - **No coverage** → no match or matched passage is unrelated. Continue to step 1\n\nA keyword grep that finds the term inside an example block or descriptive table is **not coverage** — the rule must impose the constraint, not merely mention it.\n  1. Split normative slice \u002F historical slice\n  2. **Choose target — rule or memory** per the criterion below\n  3. If **rule**: create\u002Fenrich a path-scoped rule; on Codex, also update the bounded normative index in `AGENTS.md` so the reference is discoverable\n  4. If **memory**: pick the target file via the mapping below. For the expected sections, read the template shipped by `aidd-context:02-project-memory` (`skills\u002F02-project-memory\u002Fassets\u002Ftemplates\u002Fmemory\u002F\u003Ccapability>\u002F\u003Cfile>.md`, resolved through host portability; `references\u002Fmemory-destinations.md` maps template → bank file). If the plugin is not reachable, infer the sections from the target file itself — never fail on a missing template\n  5. Insert in the section's format (table row, 3-15 word bullet, H3 subtitle, mermaid block) — prefer existing sections; create a new section only if the file's spirit justifies it.\n\n     **Content shaping rules** (apply to memory inserts only; for the rule branch at step 3, follow `${PROJECT_RULES_ROOT}\u002F01-standards\u002F1-rule-writing.md` — 3-7 word imperatives, no inline rationale):\n\n     - **Normative memory only**: when a decision is intentionally retained as on-demand guidance rather than an active host rule, express its constraint clearly with `Always X` \u002F `Never Y` \u002F `Must Z`. Explanations, history, and runbooks moved out of existing rules remain descriptive; do not turn them into duplicate imperatives.\n     - **Why-line for normative memory when needed**: place rationale on a separate indented line below the short constraint (`  **Why:** \u003Creason>`). Explanatory memory can carry its rationale in normal prose.\n     - **No source trace back to the deleted ADR**: a `(cf. DEC-XYZ)` pointer dies the moment the source is deleted, and keeping the source as archive pollutes memory load 100 % of the time for a revert that happens ~1 % of the time. The bullet's own rationale is what carries the rule forward; the ADR is git history.\n     - **For chain migrations into a consolidated section**: place rationale once in the H3 intro paragraph, not per bullet — individual bullets stay terse.\n  6. Preserve frontmatter, ordering and style **of the target file** (informed by its template, not slavishly copied)\n  7. Show the user the content to insert + propose **full deletion of the source** as default. Memory load is paid 100 % of the time; an archive (or even a stub) is consulted ~1 % of the time and weighs against every future read — git history is the revert path, not a kept file. Stub only if the user explicitly asks. **Distinct confirmation** per decision (or per grouped chain). **Batch mode**: if > 5 entries of the same nature, present a sample of 3 full decisions; if the user validates, apply the rest in bulk with a single final confirmation\n- **Merge duplicate**: target file is the most recent; on tie, the most complete. Show both files and the proposed merge → **distinct confirmation**: \"Merge and delete source?\" Rewrite the target, delete the source only after agreement.\n- **Elevate to rule**: create `${PROJECT_RULES_ROOT}\u002F\u003Ccategory>\u002F\u003Cn>-\u003Ctopic>.md` (category 00-09 per `1-rule-structure.md`) following the template and rule-writing convention. On Codex, add a concise `AGENTS.md` instruction naming when to read that file; preserve unrelated sections. Show the created rule and source list → **distinct confirmation**: \"Does the rule fully cover these files? Delete sources?\"\n\n  **After creating any rule with a forbidden pattern**: grep the codebase scoped by the new rule's `paths:` to count violations. Forbidden patterns are bullets formed with `never`, `forbidden`, `must not`, `do not use`, etc.\n\n  ```bash\n  # Example — rule forbids `transition-all`, paths: **\u002F*.vue, **\u002F*.css\n  rg -n \"transition-all|transition: all\" --glob \"**\u002F*.vue\" --glob \"**\u002F*.css\"\n  ```\n\n  If N > 0 violations: surface to the user as a separate signal — \"Règle créée, mais N violations existent dans le code. Créer un audit \u002F issue de cleanup ?\". Never silent — a rule violated immediately at creation is dead weight.\n\n### Target criterion — rule vs memory\n\n| Pick a **rule** (`${PROJECT_RULES_ROOT}\u002F...`) if | Pick **memory** (`aidd_docs\u002Fmemory\u002F...`) if |\n|---|---|\n| Topic is **path-scopable on a narrow surface** (glob isolating \u003C ~30 % of code: `firebase.json`, `nuxt.config.ts`, `server\u002Fapi\u002F**`, `models\u002F*.js`), or it is a genuinely universal constraint needed on every task and fits in a short host instruction | Topic is **transverse but explanatory** or conceptual, or the natural glob is too broad (`**\u002F*.vue`, `**\u002F*.ts` alone — cover almost all app code) without requiring an always-loaded instruction |\n| Rule is **verifiable at write-time** (concrete convention, named anti-pattern, constant, required value) | Content is **explanatory**: why, context, principle, learning, runbook |\n| Agent must obey it when touching the affected files; on Codex, `AGENTS.md` points to the scoped reference | Agent may consult it on demand for explanation, history, decisions or a runbook; memory is not assumed to auto-load |\n\nOn ambiguity: if the decision can be expressed as a testable code convention **and** scoped to a narrow surface, prefer **rule**. Keep a truly universal mandatory constraint as a short host instruction. Put its rationale in memory. Otherwise prefer **memory**.\n\n### Topic → memory file mapping\n\nBank files are **flat** — `aidd_docs\u002Fmemory\u002F\u003Cfile>.md`, kebab-case, never nested. `memory\u002Finternal\u002F` and `memory\u002Fexternal\u002F` hold on-demand notes and ADRs, never a bank file. The canonical file list is `aidd-context:02-project-memory`, `references\u002Fmemory-destinations.md`; a bank only holds the files its capabilities warranted, so a row's file may legitimately be absent.\n\nThe mapping below is a starting point, not exhaustive. When a topic spans multiple rows (e.g. auth ∈ {auth, api}), pick the file whose **template section** most closely matches the decision's substance. When no row fits, follow the fallback heuristic at the bottom.\n\n| Decision topic | Memory file | Template sections to favor |\n|---|---|---|\n| Stack, naming, modules, service organization, i18n | `architecture.md` | Language\u002FFramework, Naming Conventions, Services communication |\n| Internal API surface, request\u002Fresponse types, validation, error handling | `api.md` | Services, Data Flow, Error Handling, Validation |\n| Third-party integrations, SDK wiring, webhooks | `integration.md` | existing sections |\n| Auth flows, security rules, custom claims, session handling | `auth.md` — prefer a path-scoped rule if the convention is verifiable at write-time | existing sections |\n| Real-time listeners, websocket \u002F `onSnapshot` patterns | `realtime.md` | existing sections |\n| DB schema, entities, migrations, seeding | `database.md` | Main entities, Migrations, Seeding |\n| Data modeling, pipelines, storage formats | `data.md` | existing sections |\n| Design system, theme, tokens, UI components, accessibility | `design.md` | Design Implementation, Component Standards, Layout System |\n| Forms, client validation, form state | `forms.md` | State Management, Validation, Error handling, Form Flow |\n| Navigation, browsing flow, lists\u002Ffilters, product UX | `navigation.md` | existing sections |\n| CI\u002FCD, hosting, env vars, URLs, monitoring, observability, tracking, consent\u002FRGPD | `deployment.md` | CI\u002FCD Pipeline, Environments Variables, URLs, Monitoring & Logging |\n| Runtime topology, containers, provisioning | `infra.md` | existing sections |\n| Caching strategy (HTTP headers, hosting cache, store TTL, query result cache) | `deployment.md` (hosting\u002FCDN angle) or `architecture.md` (in-app cache angle) | CI\u002FCD Pipeline, Services |\n| Feature flags, kill switches, gradual rollout | `deployment.md` | Environments Variables |\n| Notifications (transactional email, marketing flows, push) | `messaging.md` | existing sections |\n| Test strategy, fixtures, mocks, test types | `testing.md` | Testing Strategy, Tools and Frameworks, Mocking |\n| Repo overview | `codebase-map.md` | single flowchart |\n| VCS, branches, commit conventions | `vcs.md` | template sections |\n| Constants binding the future, business value assertions, transverse guardrails | `coding-assertions.md` | existing sections |\n| Product context, vision, target audience | `project-brief.md` | existing sections |\n| Backlog conventions, refinement workflow | `backlog.md` | existing sections |\n| Vendor ecosystem, external services in use | `ecosystem.md` | existing sections |\n| Packaging, publishing, versioning, release channels | `package.md` | existing sections |\n| CLI surface, commands, flags conventions | `cli.md` | existing sections |\n| Mobile-specific conventions | `mobile.md` | existing sections |\n| Desktop-specific conventions | `desktop.md` | existing sections |\n| Performance decisions accumulated within an iteration | custom file, e.g. `iteration-N-perf-learnings.md` | dedicated section per chain |\n| Multi-agent coordination, sub-agent invocation rules | custom file, e.g. `agents-coordination.md` | dedicated section |\n| Project-specific orchestration deviating from the default AIDD flow | custom file, e.g. `custom-main-workflow.md` | dedicated section |\n| Outside the taxonomy above | **First**: scan existing custom bank files (`aidd_docs\u002Fmemory\u002F*.md` not listed above) for a thematic fit. **Only if no fit**: propose creation to the user, justifying the new file against the canonical list in `references\u002Fmemory-destinations.md`. | dedicated section |\n\nTeam-owned documents — `aidd_docs\u002FREADME.md`, `GUIDELINES.md`, `CONTRIBUTING.md` — are never a migration target: their placeholders belong to a human.\n\nIf no file fits, **propose creation** to the user before acting: every new bank file must either match a capability row of `references\u002Fmemory-destinations.md` or be justified as a custom bank file.\n\nAny other deletion of a memory file → **user confirmation** before acting.\n\nWhen several archive entries form a chain (supersession, shared topic), propose a grouped migration into **a single consolidated section** of the target file rather than per-entry inserts.\n\n---\n\n## Phase D — Existing-rule consolidation, then freshness\n\n### Full consolidation pass\n\nUse Phase A's **complete** rule inventory on every run, including unchanged files. Work at the level of individual instructions and sections, not whole files. For each item, record its host and path scope, the behavior it requires, any exceptions, its source, and whether a current memory bank already covers its explanation.\n\nClassify each item:\n\n| Class | Criterion | Destination |\n|---|---|---|\n| **Keep as rule** | A current, actionable constraint that changes agent behavior on a future task; concrete enough to check, with the narrowest applicable scope | One concise effective host instruction or scoped rule; retain necessary cross-host equivalents |\n| **Narrow scope** | A current, write-time-verifiable rule whose declared `paths:` cover significantly more files than the measured call sites of the technical symbol(s) it names, or whose path list contains an entry wholly covered by another entry | Keep the rule, remove redundant entries, and propose the smallest measured scope that still contains every current site; do not move the constraint to memory |\n| **Move to memory** | Rationale, decision history, architecture explanation, examples, troubleshooting steps, or runbook material without an independent enforceable constraint | Existing thematic `aidd_docs\u002Fmemory\u002F\u003Cbank>.md` section, following Phase C's memory mapping and format |\n| **Resolve** | Duplicate, overlapping, contradictory, obsolete, or superseded instruction | Merge, narrow, update, or remove only after checking the surviving effective instruction and required confirmations |\n\nBefore assigning a class to a path-scoped rule, extract the concrete technical symbols it names\n(function, constant, flag, command, configuration key; never generic prose) and measure its effective\npopulation:\n\n```bash\nnode \"${OVERCODE_PLUGIN_ROOT}\u002Fskills\u002Freconcile-normative\u002Ftools\u002Fscope-audit.mjs\" \\\n  --root \u003Cproject-root> --rule \u003Crule.md> --symbol \u003Cliteral> --json\n```\n\nPass one `--symbol` per independently named mechanism. The report compares the union of files matched\nby `paths:` with the union of literal symbol sites, lists sites outside the scope, and compares every\npath entry with its siblings. A path whose measured file set is wholly contained by another entry is\nredundant even when their glob strings look different. A declared population at least twice the symbol\npopulation, or carrying at least three files with no site, is a **Narrow scope candidate**, not an\nautomatic edit: inspect dynamic dispatch, generated calls, conventions that apply before the first call,\nand non-literal use before proposing the narrower paths. A symbol site outside the current scope is a\ncoverage defect and blocks narrowing until the surviving scope includes it.\n\nImperative wording alone does not prove that content is a current rule. Verify the current code, decisions, and supported workflow before retaining or elevating it. A mixed file may need a short surviving rule plus a memory entry. Preserve exceptions, paths, and host-specific syntax when shortening; do not silently weaken a constraint. Do not move a real constraint only to on-demand memory.\n\nCompare rules **within each host and applicable path scope**. A Codex `AGENTS.md` index and `.agents\u002Frules\u002F` reference form one effective path; Claude's `.claude\u002Frules\u002F` may need an equivalent constraint. Cross-host equivalents are not redundant copies to delete. For Codex, keep the `AGENTS.md` entry bounded to when and where the scoped file should be read. Remove index entries that no longer point to an active rule.\n\nFor each proposed consolidation, show the current instruction, the concise surviving rule, the memory destination and text, the affected hosts\u002Fscopes, and any source removal. Follow the existing-rule edit and file-deletion confirmation boundaries. Apply the memory and surviving-rule updates before removing duplicate or obsolete instructions; if an approval is declined, leave the current instruction effective and report the proposal as pending. Use the Phase C memory-target rule when no suitable bank exists.\n\nMeasure context load **before and after** each accepted set of edits: report bytes or tokens for applicable always-loaded `AGENTS.md` content and Claude rule content, plus separately the size of conditionally loaded rule references. Do not count on-demand memory as auto-loaded. If an exact host token count is unavailable, use byte counts with the method stated. Report no reduction when no edit was made or when effective load is unchanged.\n\nFor every accepted **Narrow scope** edit, Phase E names the before\u002Fafter file populations, the symbols\nused for the measurement, any redundant path removed, and this tradeoff explicitly: the tighter scope\nreduces irrelevant automatic loading but a future legitimate call site outside it will not load the rule.\nThat risk is reported in prose, not hidden in the consolidation count.\n\nThis pass is complete only after every existing rule file and applicable `AGENTS.md` has been classified, including files unchanged since the last run. Record counts for rules inspected, consolidated, retained, moved to memory, and pending approval.\n\n### Existing-rules freshness pass\n\n### Goal\n\nDetect rules in `${PROJECT_RULES_ROOT}\u002F` and normative `AGENTS.md` sections whose content may have been invalidated by a more recent decision or memory entry. This is the **inverse** of Phase C step 0: instead of asking \"does a rule cover this new input?\", ask \"is this rule still consistent with recent inputs?\"\n\n### Candidate rule selection\n\nList rules unmodified for `rule_freshness_days` days:\n\n```bash\n# macOS \u002F Linux\nfind ${PROJECT_RULES_ROOT} -type f -name \"*.md\" -mtime +90 | sort\n\n# Windows (PowerShell)\nGet-ChildItem -Recurse -Filter \"*.md\" ${PROJECT_RULES_ROOT} |\n  Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-90) } |\n  Sort-Object Name | Select-Object -ExpandProperty FullName\n```\n\n### For each candidate rule\n\n1. Extract **key terms**: technical symbols named in the rule (file, flag, function, constant, lib). Ignore generic words (`must`, `never`, `pattern`, etc.).\n2. For each term, grep in `aidd_docs\u002Fmemory\u002F` (bank + `internal\u002Fdecisions\u002F`) and in the legacy `aidd_docs\u002Finternal\u002Fdecisions\u002F`:\n   ```bash\n   rg \"\u003Cterm>\" aidd_docs\u002Fmemory aidd_docs\u002Finternal\u002Fdecisions 2>\u002Fdev\u002Fnull\n   ```\n3. Filter hits with `mtime` > rule's modification date.\n4. **If hits found**: flag \"rule potentially stale — verify contradiction\" with:\n   - rule path\n   - rule date\n   - list of newer files mentioning the same terms\n   - excerpt of relevant passages\n5. **Distinct confirmation** per flagged rule: show to user, ask:\n   - \"Update rule?\" → manual or guided edit\n   - \"Rule still valid?\" → touch the file (`touch` \u002F `(Get-Item).LastWriteTime = Get-Date`) to push the next freshness deadline\n   - \"Rule obsolete?\" → deletion after explicit confirmation\n\n### Why this pass\n\nThe Phase A incremental scan covers what moved recently. A rule written 6 months ago and never edited since **will never be in the scan** — even if newer memory and decisions have rendered it obsolete. The freshness pass plugs that hole by starting from the rules themselves.\n\n---\n\n## Phase E — Report\n\nList:\n- N normative entries migrated from archive\n- N existing rules enriched (partial coverage)\n- N entries already covered by a rule (skip)\n- N duplicates merged\n- N contradictions resolved\n- N patterns elevated to rules\n- N obsolete decisions flagged\n- N existing rules inspected, consolidated, retained, and moved to memory; N proposals pending approval\n- Always-loaded bytes or tokens before and after, with conditional-rule size reported separately\n- N rules flagged in freshness pass (updated \u002F touched \u002F deleted)\n\nIf invoked as a sub-phase of `harvest`, return these metrics to the orchestrator. Otherwise, write a standalone report at `aidd_docs\u002Fharvests\u002FYYYY_MM_DD-reconcile-normative.md`.\n\n## Evals\n\n- [Existing-rule consolidation scenarios](evals\u002Frule-load-scenarios.md)\n",{"name":5,"tags":43,"author":12,"version":44,"description":7,"permissions":45,"vibe_version":47},[32,36,35],"4.8.0",[25,46],"bash",">=1.0.0","main","a33208351920c3cd0562b6ccf0846a9abe46741c","plugins\u002Fovercode\u002Fskills\u002Freconcile-normative",0,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace","https:\u002F\u002Fgithub.com\u002FRebelliousSmile","https:\u002F\u002Fwww.scriptami.com\u002F","2026-11-11 04:40:59",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add RebelliousSmile\u002Fmy-claude-marketplace --skill reconcile-normative",{"tool":62,"command":63},"bunx","bunx skills add RebelliousSmile\u002Fmy-claude-marketplace --skill reconcile-normative",{"tool":65,"command":66},"pnpm","pnpm dlx skills add RebelliousSmile\u002Fmy-claude-marketplace --skill reconcile-normative","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002FSKILL.md",true,[70,76,82,86,90,94,98,102,106],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"evals\u002Ffixtures\u002Fscope-audit\u002Fbroad-rule.md","REFERENCE","参考文档",110,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002Fevals\u002Ffixtures\u002Fscope-audit\u002Fbroad-rule.md",{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Fcontent-manager.js","SCRIPT","脚本",36,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002Fevals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Fcontent-manager.js",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"evals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Ficon-helper.js",78,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002Fevals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Ficon-helper.js",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Finit.js",32,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002Fevals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Finit.js",{"path":91,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":92,"sourceHtmlUrl":93},"evals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Fviews\u002Fcard.js",89,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002Fevals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Fviews\u002Fcard.js",{"path":95,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":96,"sourceHtmlUrl":97},"evals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Fviews\u002Flist.js",30,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002Fevals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Fviews\u002Flist.js",{"path":99,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":100,"sourceHtmlUrl":101},"evals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Fviews\u002Fmodal.js",33,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002Fevals\u002Ffixtures\u002Fscope-audit\u002Fproject\u002Flib\u002Fviews\u002Fmodal.js",{"path":103,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":104,"sourceHtmlUrl":105},"evals\u002Frule-load-scenarios.md",3218,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002Fevals\u002Frule-load-scenarios.md",{"path":107,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":108,"sourceHtmlUrl":109},"tools\u002Fscope-audit.mjs",7687,"https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fovercode\u002Fskills\u002Freconcile-normative\u002Ftools\u002Fscope-audit.mjs",[111,120,133,140,145,151],{"skillNo":112,"name":113,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":38},"01M6CY3N1KXYQQG47SD4966CMS","web-optimize","https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Ftools\u002Feval\u002Ffixtures-pivot-map\u002Fvalid\u002Fplugins\u002Fovercode\u002Fskills\u002Fweb-optimize\u002FSKILL.md",[],[117,118,119],"web","optimize","web optimize",{"skillNo":121,"name":122,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":130,"publishedAt":38},"01M6CY3KR1H8WTNM1GV1SH6DY8","data-optimize","https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Ftools\u002Feval\u002Ffixtures-pivot-map\u002Fvalid\u002Fplugins\u002Fovercode\u002Fskills\u002Fdata-optimize\u002FSKILL.md",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":128,"taxonomyTypeDesc":129},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[131,118,132],"data","data optimize",{"skillNo":134,"name":135,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":38},"01M6CY3JJJGXQG2X5X5PVTTB2A","ap-optimize","https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Ftools\u002Feval\u002Ffixtures-pivot-map\u002Fvalid\u002Fplugins\u002Fovercode\u002Fskills\u002Fap-optimize\u002FSKILL.md",[],[118,139],"ap optimize",{"skillNo":141,"name":113,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":38},"01M6CY3HD94NANM2AE5JA7Z22D","https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Ftools\u002Feval\u002Ffixtures-pivot-map\u002Forphan\u002Fplugins\u002Fovercode\u002Fskills\u002Fweb-optimize\u002FSKILL.md",[],[117,118,119],{"skillNo":146,"name":122,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":38},"01M6CY3G6M0NC688HYCFD9TDV1","https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Ftools\u002Feval\u002Ffixtures-pivot-map\u002Forphan\u002Fplugins\u002Fovercode\u002Fskills\u002Fdata-optimize\u002FSKILL.md",[149],{"categoryNo":126,"categoryName":127,"taxonomyType":128,"taxonomyTypeDesc":129},[131,118,132],{"skillNo":152,"name":135,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":38},"01M6CY3ES1CAT89NKBXPBGEFZ9","https:\u002F\u002Fgithub.com\u002FRebelliousSmile\u002Fmy-claude-marketplace\u002Fblob\u002Fmain\u002Ftools\u002Feval\u002Ffixtures-pivot-map\u002Forphan\u002Fplugins\u002Fovercode\u002Fskills\u002Fap-optimize\u002FSKILL.md",[],[118,139]]