harness-engineering

Topics in the source

• Harness Engineering
• When to Use
• Owner's architecture principles (always-on)
• Procedure
• Pitfalls

Harnesses (cron-run operational scripts, drift checkers, watchdogs, gated data pipelines around a repo or agent system) are engineered products, not scratch scripts. This skill covers how to review, restructure, and design them to this owner's standards. "review / 重构 / 工程化 harness / helper scripts"、单文件脚本超长、检查器增殖 designing a new harness home, consolidating checkers, deleting zombie dirs deciding where a harness subsystem belongs 1. Self-containment: every repo/system owns its harness. Never extract a repo's harness dependency into another repo or a shared library. 2. Reuse boundary: within one git repo, extract common modules and maximize reuse; across repos, zero dependencies — a similar feature gets a copy in each repo (expect little real similarity: each harness is purpose-designed). 3. Engineering standard: SOLID, real abstraction and modularity; functional style — less code for the same expression, data structures chosen for performance. Immutability is NOT required. 4. No checks for checks' sake: every check must bind to an owner DECISION ("this finding triggers which action?"). No defensive validation written out of caution. Git is the byte layer, declaration files are the in

This is an excerpt. Refer to the complete source and its current requirements.