Long-run Rule Persistence — 長任務規則怎麼不飄

When to use

• CLAUDE.md / project rules are followed early, then ignored around turn ~5+ on open-ended work.
• Without an engineering harness: hallucinated deps, broken tests, forgotten architecture.
• You already chose a model — the problem is rule drift, not “which vendor.”

Diff vs existing multi-model harness skill

Use both: pick a model stack, then harden long-run obedience. Do not merge this into “just swap models.”

Problem framing

Public signal: rules fade mid-run; agents without harness invent libraries and trash tests. Need persistence mechanisms, not a longer markdown file alone.

Mechanisms checklist

1. Re-inject on a cadence — every N turns or every file-batch, re-read rules + architecture card.
2. Progress checkpoints — after each chunk: what changed, what still matches rules.
3. Test gate — no “done” without green tests (or explicit waiver).
4. Architecture card — one-pager forced re-read before refactors.
5. Drift detector — if agent edits test expectations to pass, hard stop.

Failure modes

Minimal playbook

1. Put non-negotiables in a short RULES.md (≤40 lines).
2. Harness: read RULES.md at turn 0, 5, 10, …
3. After each feature slice: run tests; on fail, fix code not tests (unless tests were wrong — human decides).
4. Log drift events in DRIFT.md.

Anti-patterns

• One giant CLAUDE.md never re-read
• “Trust the model” with no test gate
• Fixing CI by deleting coverage
• Confusing this with mobile remote UX or provider routing

Acceptance test

On a 15+ turn task, spot-check turns 5 and 10: agent still cites / obeys RULES.md; tests not silently weakened.

Output template

RULES.md path + non-negotiables:
Re-inject cadence:
Test gate command:
Architecture card path:
Drift log:

Out of scope

Full harness implementation; multi-model vendor bake-offs (see multi-model skill); publishing without operator approval.