Files
dotfiles/claude/memory/feedback-arc-flag-spec-inconsistencies.md
T
David F GliddenandClaude Opus 4.8 3f9a89b00c chore(memory): Basic Memory trial begins — sync normalization baseline (283 files)
Basic Memory v0.21.6 first sync over the live memory dir (steward-authorized
live-dir trial, Option A 2026-06-06): adds permalink: to frontmatter, refolds
long YAML description lines, strips final newlines. Bodies untouched —
verified via full diff classification. From this commit forward, any diff in
claude/memory shows only what Basic Memory or the session writes.

Trial design: MemPalace untouched as incumbent; git status check on this dir
at every wrap; end-of-day evaluation (recall quality, sync robustness,
rebuild-from-files, malformed-file behavior).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-06 09:52:17 +02:00

59 lines
3.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
name: ARC spec — actively flag inconsistencies the steward may have introduced
description: Working contract with steward for ARC typography/spec work — when a rule
the steward proposes or has previously locked creates an internal contradiction
with the spec itself or with existing content, name it explicitly rather than silently
accommodating
type: feedback
originSessionId: 8d9ac240-47df-4578-aec1-a9dd32965027
permalink: claude-memory/feedback-arc-flag-spec-inconsistencies
---
# Actively flag spec inconsistencies
**Steward verbatim 2026-05-03**: *"I hope I'm being clear—that if I've created a specification for a rule that is inconsistent, that you'd bring my attention to it."*
## Why
The steward is consciously building a typographic system in real-time. Specs accumulate; rules interact; what looked self-consistent in isolation can become contradictory when combined with another rule, or when applied to existing content that predates the rule. Silent accommodation (writing around the contradiction; using workarounds; ignoring the inconsistency) produces drift the steward cannot see and cannot correct.
The contract is: **name the contradiction in the moment**, not at wrap-up, not at audit-time. The steward will decide whether to resolve it, defer it, or accept it as a documented exception. The decision is theirs; the surfacing is mine.
## How to apply
### When proposing a new spec rule
Ask: does this contradict an existing spec section? Does it contradict existing content the rule would now retroactively govern? Does it create an edge case the spec doesn't address?
If yes — surface immediately as part of the proposal, not after.
### When implementing a steward decision
If the steward authorizes a change that creates contradictions elsewhere (e.g., switching em-dash → spaced en-dash retroactively, but the spec section that explains em-dashes still uses em-dashes pedagogically) — name the contradictions before executing, OR fix them as part of the same commit, NOT later.
### When auditing existing spec or content
Surface internal contradictions explicitly. Don't wait for a "good moment." Don't bundle into a vague "audit list." Name the specific contradiction + propose the resolution choice.
### When the steward asks me to verify or implement
If the rule-as-asked is internally inconsistent (or inconsistent with the broader spec), say so before implementing. The steward's authorization assumes I've checked.
## Anti-pattern to avoid
- "Silent accommodation" — writing around a contradiction without naming it
- "Audit-list deferral" — bundling contradictions into a vague future audit instead of naming them now
- "Polite rounding" — implementing the rule as-asked when it's clearly inconsistent, hoping the steward will notice later
## Worked example (origin of this norm)
The 2026-05-03 em-dash → spaced en-dash conversion: bulk script swept across content (848 conversions) and the spec itself (344 conversions). The spec section that EXPLAINS the em-dash convention had its own em-dashes converted, breaking the pedagogical examples. Lines like `(NOT \`word—word\`)` became `(NOT \`word – word\`)` — both alternatives now identical; the "NOT" example showed nothing.
Steward's reaction: this is the moment to flag, not to silently accept. The spec section §I.f had to be rewritten with em-dash literals preserved inside code spans (where Pandoc passes them through verbatim) so the pedagogical content survives.
The norm crystallized: actively flag inconsistencies, in the moment.
## Cross-reference
- `feedback-arc-link-treatment-one-rule-two-exceptions.md` — adjacent discipline (predictability over elaboration); together: predictable conventions, surfaced contradictions
- `feedback-trust-contract-drift-pattern-tracking-is-the-discipline.md` — the broader trust contract this sits within