ub-mode：给代理的精简 Clean Code / TDD 原则

# ub-mode Every time you are asked to make a change follow: * First Make it Work. * Then Make it Right. * Follow Practice # First Make it Work ## Laziness Protocol * One decision lives in one place. * Ship the smallest edit that solves the problem. ## Foundational Thinking * Get the data shape right before you write the logic. * Do first whatever helps every later phase. * If a concurrent writer would matter, do not share state. ## TDD * Write the failing test before you change the code. * See it fail for the reason you expect. * Make the smallest change that makes it pass. * If an honest test is impractical, do not write a bad one. ## Redesign From First Principles * Do not bolt a new requirement onto the old design. * Ask what you would have built if it had been there from the start, think that through, and deliver it in pieces. ## Attack the Premise * When two fixes that share one premise fail the same gate, write that premise in one sentence and count which actors hold the imbalance. * Remove the assignment. * Do not start another fix until you have done that. ## Subtract Before You Add * Take complexity out before you add anything. ## Outcome-Oriented Execution * Aim at the end state you can check. * A break in the middle is allowed when you planned it and can undo it. ## Build the Lever * If the work is not obvious at a glance, build the tool that does it. * Do one unit by hand, then make the tool match that unit. ## Architecture ### Model the Domain * Put the domain in a structure that makes the illegal states impossible. * Maintain a glossary of domain terms. * If the code is already clear and local, leave it. ### Boundary Discipline * Check the data where it enters. * Inside, trust it. * Keep the business logic in a pure function. ### Type System Discipline * Make the illegal value impossible to write. * Parse outside data once, where it comes in. * Do not silence the compiler. ### Make Operations Idempotent * Running it twice, or running it after a crash halfway through, ends in the same state. ### Separate Before Serializing Shared State * If they do not need the same mutable thing, give each its own. * If they do, allow one writer, and enforce that in the structure. # Then Make it Right ## Fix Root Causes * Reproduce it. * Fix the cause. * A guard that only hides the crash is not a fix. ## Sequence work into verifiable units * Finish one small unit and check it. * Then start the next. ## Test Behavior, Not Implementation * The test calls the code the way its user does and checks the result that user would see. * If the test would still pass when every function returned nothing, throw it out. ## Crapper * Use the crapper tool * Reduce each function under CRAP 10 by splitting it, by testing it, or both. * Consider whether case statements are worth reducing. ## Dryer * Use the dryer tool to eliminate duplication that rank 0.8 or above. ## Mutator * Use the mutator tool * Cover the uncovered. * Kill the survivors. * Delete dead code. ## Refactoring * Pin what the code does. * Change the structure. * Prove the behavior did not change. # Practice ## Keep a Log * Keep a log of every action you take and the reason you took it. * Report that log upon completion. ## Guard the Context Window * Keep the main thread small. * Send the bulk elsewhere, and keep the summary. ## Worktree Cleanup * Find what is safe to remove, confirm nothing still in use needs it, then reclaim the disk. * Uncommitted work waits for a decision. ## Commit and Push * Commit often, in small ordered commits. * Each commit says why, what changed, and how you proved it. * Push to the main line at the end.