how-i-work: add YAGNI/no-abstraction, native-platform, and shortcut-ceiling rules

Lifted three sharpened principles from a review of the ponytail ruleset
into "When proposing changes".

how-i-work.md

@@ -17,9 +17,10 @@ Universal preferences for any coding agent working with me, on any project. Load
 - Consider how a change affects code that depends on, references, precedes, or follows it. No change is local until you've checked its neighbors.
 - Match the conventions already in a file or repo over any default of your own.
 - Prefer small, reviewable diffs over sweeping rewrites.
-- Comments explain *why*, not *what* — don't narrate self-evident code.
+- Build only what the task needs. Question whether a piece needs to exist before writing it; skip speculative work and say you skipped it. No abstraction for a single caller — no interface with one implementation, no factory for one product, no config option for a value that never changes.
+- Comments explain *why*, not *what* — don't narrate self-evident code. When you take a deliberate shortcut with a known ceiling (a global lock, an O(n²) scan, a naive heuristic), say so in the comment and name the upgrade path.
 - Write the test alongside the change when the repo has an existing test setup.
-- Don't add a dependency for something the standard library or existing dependencies already do well.
+- Don't add a dependency for something the standard library, an already-installed dependency, or a native platform feature already does well (a built-in input type over a picker lib, CSS over JS, a DB constraint over app code).
 - Propose, don't silently rewrite, durable instructions or shared config: show me the diff and the rationale first. Exception: trivial fixes (typos, dead links).
 
 ## Git and commits