substrate(otto-357): 2nd recurrence (Aaron 2026-04-28) + stronger pre-write self-scan rule

[AceHack]

Summary

Documents the 2nd Otto-357 violation (Aaron 2026-04-28: "aaron does not have directives, only one there are no directives. Please fix your future self too.") and strengthens the future-self check from passive-vigilance to a pre-write token-scan rule.

Why this matters

Otto-357 has been violated TWICE despite:

• The memory file existing
• CLAUDE.md wake-time discipline citing it
• A "future-self check" rule literally written in the prior file

Otto-275-FOREVER applies: knowing-rule != applying-rule. The 2nd recurrence demonstrates vigilance-only enforcement is insufficient.

What changes

Three additions to the existing memory file:

1. Recurrences section — empirical log of each catch. The count itself is structural signal.

2. Pre-write self-scan rule — explicit forbidden-token list to scan EVERY draft (commit / PR / memo / and conversational chat text which the prior version missed):

   directive | directives | order | orders | command | commands | told me |
   required | demanded | per Aaron's directive | per Aaron's order |
   follow Aaron's | obey
   

3. Backlog candidate — automated lint composes with prompt-protector skill's invisible-Unicode lint shape (write-time scan); until that exists, vigilance-with-explicit-checklist is the bridge.

What this doesn't do

• Doesn't rename existing memory files (Otto-357 already noted those stay as-is per git-history append-only discipline)
• Doesn't propose specific lint implementation yet (that's the backlog candidate)
• Doesn't change CLAUDE.md (the wake-time discipline pointer at Otto-357 still resolves correctly to this updated file)

Test plan

• Otto-357 file lints clean (memory/ is in markdownlint ignore list)
• Frontmatter unchanged; only body extended
• Recurrence log future-extensible (next recurrence appends as "3rd caught: ...")

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the Otto-357 memory entry to record a second recurrence of the “directive” framing issue and to strengthen the future-self check into an explicit pre-write token scan.

Changes:

• Adds a Recurrences section documenting the first and second Otto-357 violations.
• Introduces a pre-write self-scan mechanism with a forbidden-token list intended to be checked before sending user-facing text / commit messages / PR bodies.
• Extends retrieval triggers to include the 2026-04-28 recurrence and the strengthened check.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[Copilot]

P1: Line 114 is doing too much in one parenthetical sentence (recurrence claim + why-count-matters + Otto-275-FOREVER explanation + inline path). It’s hard to parse and will be easy to misread later; consider splitting this into multiple sentences/paragraphs and moving the Otto-275-FOREVER explanation (and the referenced filename) onto its own line/bullet.

Suggested change

	This rule has been violated multiple times despite the memory file existing. Each recurrence is documented here as evidence — the count itself is signal that vigilance-only enforcement is insufficient (Otto-275-FOREVER applies — the "-FOREVER" suffix marks Otto-275 (`memory/feedback_rapid_backlog_input_context_switch_drift_counterweight_log_dont_implement_otto_275_2026_04_24.md`) as a permanent meta-pattern, not a one-time fix: knowing-rule != applying-rule, every recurrence re-confirms the meta-rule, the meta-rule never expires).
	This rule has been violated multiple times despite the memory file existing.
	Each recurrence is documented here as evidence. The count itself is signal that vigilance-only enforcement is insufficient.
	- Otto-275-FOREVER applies.
	- `memory/feedback_rapid_backlog_input_context_switch_drift_counterweight_log_dont_implement_otto_275_2026_04_24.md`
	- The `-FOREVER` suffix marks Otto-275 as a permanent meta-pattern, not a one-time fix: knowing-rule != applying-rule, every recurrence re-confirms the meta-rule, and the meta-rule never expires.

[Copilot]

P1: The pre-write scan rule says to “match in any compound” for tokens like order. If this is ever automated as a substring search, it will fire on unrelated words (e.g., “recorder”, “preorder”, “border”), creating noisy false positives. Consider tightening the wording to whole-word matching (word boundaries) for single-word tokens, and keeping multi-word phrases as explicit phrase matches.