harness-golden-principles

Distill recurring review comments into general principles, then check whether each can be written as a lint rule — if yes, encode it directly; if not, document it as a taste principle for periodic scanning. Each principle must trace back to real signals like review feedback or bug reports.

Run periodic entropy sweeps that compare the codebase against encoded golden principles using lint, grep, or semantic search. Each scan produces small fix PRs limited to one deviation type, with purely mechanical fixes tagged for auto-merge.

Golden principles govern taste and habit consistency through post-merge periodic sweeps, while architecture boundaries are structural invariants enforced as pre-merge CI blocks. Taste preferences must never become merge blockers, and structural constraints must never be treated as suggestions.

Skip it when the project is extremely small with no repeated patterns, when structural architecture constraints are actually needed, or when the codebase is undergoing a major active refactor that would produce noise instead of signal.

Use incremental adoption: scope each sweep to one module, file type, or pattern type rather than fixing everything at once. Record the full violation inventory in the tech-debt tracker and process it in prioritized batches.

Oversized fix PRs create review backlog, get ignored, and break the sweep rhythm. Limiting each PR to one deviation type, at most 5 files and 50 lines, keeps reviews fast enough for the continuous cleanup cycle to sustain itself.