fix: preserve scope before simplification

Author: Mallet-Dev

.agents/rules/ponytail.md

@@ -14,6 +14,21 @@ Before writing any code, stop at the first rung that holds:
 
 The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
 
+Scope before simplicity:
+
+- Lock the task's required outcome before simplifying. For bounded/local work,
+  simplify inside the stated behaviour. For complete/systemic work, preserve
+  the required end-to-end behaviour, coverage, integration, migration,
+  documentation, and verification, then simplify within that boundary.
+- Target the smallest complete solution, not the smallest diff. Never drop
+  requested scope, test coverage, validation, error handling, or integration
+  to reduce lines.
+- Test coverage follows the risk and behaviour matrix. One runnable check is a
+  floor for small non-trivial logic, never a ceiling for a complex test task.
+- If a smaller result would only be a temporary patch, say so and do not call
+  it complete; ask or state the assumption when the intended boundary is
+  unclear.
+
 Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
 
 Rules:
@@ -23,7 +38,8 @@ Rules:
 - No boilerplate nobody asked for.
 - Deletion over addition. Boring over clever. Fewest files possible.
 - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Question complex requests only after preserving the required boundary:
+  "Does Y cover X without dropping required behaviour?"
 - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
 - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
 

.clinerules/ponytail.md

@@ -14,6 +14,21 @@ Before writing any code, stop at the first rung that holds:
 
 The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
 
+Scope before simplicity:
+
+- Lock the task's required outcome before simplifying. For bounded/local work,
+  simplify inside the stated behaviour. For complete/systemic work, preserve
+  the required end-to-end behaviour, coverage, integration, migration,
+  documentation, and verification, then simplify within that boundary.
+- Target the smallest complete solution, not the smallest diff. Never drop
+  requested scope, test coverage, validation, error handling, or integration
+  to reduce lines.
+- Test coverage follows the risk and behaviour matrix. One runnable check is a
+  floor for small non-trivial logic, never a ceiling for a complex test task.
+- If a smaller result would only be a temporary patch, say so and do not call
+  it complete; ask or state the assumption when the intended boundary is
+  unclear.
+
 Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
 
 Rules:
@@ -23,7 +38,8 @@ Rules:
 - No boilerplate nobody asked for.
 - Deletion over addition. Boring over clever. Fewest files possible.
 - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Question complex requests only after preserving the required boundary:
+  "Does Y cover X without dropping required behaviour?"
 - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
 - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
 

.cursor/rules/ponytail.mdc

@@ -20,6 +20,21 @@ Before writing any code, stop at the first rung that holds:
 
 The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
 
+Scope before simplicity:
+
+- Lock the task's required outcome before simplifying. For bounded/local work,
+  simplify inside the stated behaviour. For complete/systemic work, preserve
+  the required end-to-end behaviour, coverage, integration, migration,
+  documentation, and verification, then simplify within that boundary.
+- Target the smallest complete solution, not the smallest diff. Never drop
+  requested scope, test coverage, validation, error handling, or integration
+  to reduce lines.
+- Test coverage follows the risk and behaviour matrix. One runnable check is a
+  floor for small non-trivial logic, never a ceiling for a complex test task.
+- If a smaller result would only be a temporary patch, say so and do not call
+  it complete; ask or state the assumption when the intended boundary is
+  unclear.
+
 Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
 
 Rules:
@@ -29,7 +44,8 @@ Rules:
 - No boilerplate nobody asked for.
 - Deletion over addition. Boring over clever. Fewest files possible.
 - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Question complex requests only after preserving the required boundary:
+  "Does Y cover X without dropping required behaviour?"
 - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
 - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
 

.github/copilot-instructions.md

@@ -14,6 +14,21 @@ Before writing any code, stop at the first rung that holds:
 
 The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
 
+Scope before simplicity:
+
+- Lock the task's required outcome before simplifying. For bounded/local work,
+  simplify inside the stated behaviour. For complete/systemic work, preserve
+  the required end-to-end behaviour, coverage, integration, migration,
+  documentation, and verification, then simplify within that boundary.
+- Target the smallest complete solution, not the smallest diff. Never drop
+  requested scope, test coverage, validation, error handling, or integration
+  to reduce lines.
+- Test coverage follows the risk and behaviour matrix. One runnable check is a
+  floor for small non-trivial logic, never a ceiling for a complex test task.
+- If a smaller result would only be a temporary patch, say so and do not call
+  it complete; ask or state the assumption when the intended boundary is
+  unclear.
+
 Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
 
 Rules:
@@ -23,7 +38,8 @@ Rules:
 - No boilerplate nobody asked for.
 - Deletion over addition. Boring over clever. Fewest files possible.
 - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Question complex requests only after preserving the required boundary:
+  "Does Y cover X without dropping required behaviour?"
 - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
 - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
 

.kiro/steering/ponytail.md

@@ -19,6 +19,21 @@ Before writing any code, stop at the first rung that holds:
 
 The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
 
+Scope before simplicity:
+
+- Lock the task's required outcome before simplifying. For bounded/local work,
+  simplify inside the stated behaviour. For complete/systemic work, preserve
+  the required end-to-end behaviour, coverage, integration, migration,
+  documentation, and verification, then simplify within that boundary.
+- Target the smallest complete solution, not the smallest diff. Never drop
+  requested scope, test coverage, validation, error handling, or integration
+  to reduce lines.
+- Test coverage follows the risk and behaviour matrix. One runnable check is a
+  floor for small non-trivial logic, never a ceiling for a complex test task.
+- If a smaller result would only be a temporary patch, say so and do not call
+  it complete; ask or state the assumption when the intended boundary is
+  unclear.
+
 Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
 
 Rules:
@@ -28,7 +43,8 @@ Rules:
 - No boilerplate nobody asked for.
 - Deletion over addition. Boring over clever. Fewest files possible.
 - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Question complex requests only after preserving the required boundary:
+  "Does Y cover X without dropping required behaviour?"
 - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
 - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
 

.openclaw/skills/ponytail/SKILL.md

@@ -17,6 +17,24 @@ ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if
 unsure. Off only: "stop ponytail" / "normal mode". Default: **full**.
 Switch: `/ponytail lite|full|ultra`.
 
+## Scope before simplicity
+
+Before climbing the ladder, lock the task's required outcome and classify its
+scope:
+
+- **Bounded/local:** simplify freely inside the stated behaviour.
+- **Complete/systemic:** preserve the end-to-end behaviour, coverage,
+  integration, migration, documentation, and verification the task requires;
+  then simplify the implementation inside that boundary.
+
+The target is the **smallest complete solution**, not the smallest diff. Never
+drop requested scope, test coverage, validation, error handling, or integration
+just to reduce lines. For tests, coverage follows the risk and behaviour
+matrix: the one-check rule is a floor for small non-trivial logic, never a
+ceiling for a complex test task. If a smaller result would only be a temporary
+patch, say so and do not present it as complete; ask or state the assumption
+when the intended boundary is unclear.
+
 ## The ladder
 
 Stop at the first rung that holds:
@@ -47,7 +65,9 @@ every sibling caller still broken. Fix it once, where all callers route through.
 - No boilerplate, no scaffolding "for later", later can scaffold for itself.
 - Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
 - Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
+- Complex request? Complete the required boundary first, then use the ladder
+  inside it. Do not silently substitute a temporary patch for the requested
+  solution; if the boundary is unclear, ask or state the assumption.
 - Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
 - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path (`# ponytail: global lock, per-account locks if throughput matters`).
 

.qoder/rules/ponytail.md

@@ -14,6 +14,21 @@ Before writing any code, stop at the first rung that holds:
 
 The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
 
+Scope before simplicity:
+
+- Lock the task's required outcome before simplifying. For bounded/local work,
+  simplify inside the stated behaviour. For complete/systemic work, preserve
+  the required end-to-end behaviour, coverage, integration, migration,
+  documentation, and verification, then simplify within that boundary.
+- Target the smallest complete solution, not the smallest diff. Never drop
+  requested scope, test coverage, validation, error handling, or integration
+  to reduce lines.
+- Test coverage follows the risk and behaviour matrix. One runnable check is a
+  floor for small non-trivial logic, never a ceiling for a complex test task.
+- If a smaller result would only be a temporary patch, say so and do not call
+  it complete; ask or state the assumption when the intended boundary is
+  unclear.
+
 Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
 
 Rules:
@@ -23,7 +38,8 @@ Rules:
 - No boilerplate nobody asked for.
 - Deletion over addition. Boring over clever. Fewest files possible.
 - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Question complex requests only after preserving the required boundary:
+  "Does Y cover X without dropping required behaviour?"
 - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
 - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
 

.windsurf/rules/ponytail.md

@@ -14,6 +14,21 @@ Before writing any code, stop at the first rung that holds:
 
 The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
 
+Scope before simplicity:
+
+- Lock the task's required outcome before simplifying. For bounded/local work,
+  simplify inside the stated behaviour. For complete/systemic work, preserve
+  the required end-to-end behaviour, coverage, integration, migration,
+  documentation, and verification, then simplify within that boundary.
+- Target the smallest complete solution, not the smallest diff. Never drop
+  requested scope, test coverage, validation, error handling, or integration
+  to reduce lines.
+- Test coverage follows the risk and behaviour matrix. One runnable check is a
+  floor for small non-trivial logic, never a ceiling for a complex test task.
+- If a smaller result would only be a temporary patch, say so and do not call
+  it complete; ask or state the assumption when the intended boundary is
+  unclear.
+
 Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
 
 Rules:
@@ -23,7 +38,8 @@ Rules:
 - No boilerplate nobody asked for.
 - Deletion over addition. Boring over clever. Fewest files possible.
 - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Question complex requests only after preserving the required boundary:
+  "Does Y cover X without dropping required behaviour?"
 - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
 - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
 

AGENTS.md

@@ -14,6 +14,21 @@ Before writing any code, stop at the first rung that holds:
 
 The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
 
+Scope before simplicity:
+
+- Lock the task's required outcome before simplifying. For bounded/local work,
+  simplify inside the stated behaviour. For complete/systemic work, preserve
+  the required end-to-end behaviour, coverage, integration, migration,
+  documentation, and verification, then simplify within that boundary.
+- Target the smallest complete solution, not the smallest diff. Never drop
+  requested scope, test coverage, validation, error handling, or integration
+  to reduce lines.
+- Test coverage follows the risk and behaviour matrix. One runnable check is a
+  floor for small non-trivial logic, never a ceiling for a complex test task.
+- If a smaller result would only be a temporary patch, say so and do not call
+  it complete; ask or state the assumption when the intended boundary is
+  unclear.
+
 Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
 
 Rules:
@@ -23,7 +38,8 @@ Rules:
 - No boilerplate nobody asked for.
 - Deletion over addition. Boring over clever. Fewest files possible.
 - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Question complex requests only after preserving the required boundary:
+  "Does Y cover X without dropping required behaviour?"
 - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
 - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.