#150 Consider scope-aware enforcement semantics for code-like vs prose-like matches

[Anonymous]

Originally created by: TheoV823

Context

Recent dogfooding on PR [#149] showed that the Mneme self-check path is working, but also surfaced noisy false positives from broad lexical anti-pattern rules.

Examples from the PR self-governance comment included site/content files triggering rules from generic words such as:

• open
• without
• inline
• google
• before
• content

The valuable part: the enforcement path, sticky comment, unknown handling, and ADR freshness warnings are visible in the PR loop.

The problem: some rules are currently too broad when applied uniformly across source code, scripts, generated HTML, prose content, and metadata files.

Problem

Rules such as open() without encoding= or Set-Content without -Encoding are intended to catch automation/code patterns. They should not fire merely because prose or HTML content contains generic terms like open, without, or content.

This creates noisy FAIL output in warn-mode dogfooding and makes it harder to distinguish true architectural violations from lexical overlap.

Scope

This issue is for architecture/design only unless a separate implementation PR is explicitly scoped.

In-scope areas:

• CLI enforcement output semantics
• DecisionRetriever / enforcement matching behavior
• ConflictDetector alignment if relevant
• ADR alignment for rule scope and provenance
• Benchmark harness coverage for false-positive selectivity

Out of scope:

• GTM, outreach, pricing
• Rewriting site/content rules ad hoc
• Weakening existing governance by deleting useful rules
• Changing PR [#149] directly

Possible direction

Explore a deterministic way to distinguish rule applicability by context, for example:

• rule-level applies_to metadata such as code, script, html, markdown, prose, workflow, or path_glob
• pattern classes such as exact literal, regex, code-token, prose-token, dependency name, path pattern
• file-type-aware enforcement before lexical matching
• diagnostics that explain why a rule applied to a file
• benchmark fixtures for code-like false positives vs true positives

Acceptance criteria for a future implementation

A future PR should be able to demonstrate:

• true code violations such as open(path) without encoding= are still caught
• generic prose containing open, without, or content does not trigger the code-specific encoding rule
• existing ADR freshness warnings remain unaffected
• benchmark coverage includes at least one false-positive regression fixture
• enforcement traces make the applicability decision explainable

Dogfooding signal

This issue came from live Mneme dogfooding, not hypothetical roadmap work. The current behavior proves the governance loop is visible, but also shows the next architectural refinement needed before stricter enforcement modes become credible.