|
| 1 | +--- |
| 2 | +applyTo: "**" |
| 3 | +--- |
| 4 | + |
| 5 | +# Strict Code Completion Policy – Full Implementation Required |
| 6 | + |
| 7 | +## 1. Pre-Generation Reflection |
| 8 | +Before generating any code, **analyze the full context of the request**: |
| 9 | +- Determine the size, complexity, and number of components or methods expected. |
| 10 | +- If the context is large, **increase attention to detail and plan accordingly** to ensure nothing is missed. |
| 11 | +- Be aware of dependencies, structure, and flow across files or modules. **No aspect should be left to assumption or deferred.** |
| 12 | + |
| 13 | +## 2. Completion is Mandatory – No Partial Code |
| 14 | +- Every function, method, class, interface, and component MUST be **fully implemented from beginning to end**. |
| 15 | +- Truncating or ending code halfway, especially within functions or classes, is **strictly prohibited**. |
| 16 | +- Each logical block—loops, conditionals, try/catch, class methods, utility functions—must be written in full. |
| 17 | +- You are expected to **write as if you are delivering final, production-quality code**. |
| 18 | + |
| 19 | +## 3. No Placeholders or Stubs Allowed |
| 20 | +Under no circumstances should any of the following be used: |
| 21 | +- `TODO`, `pass`, `...`, `throw new Error("Not implemented")`, or any other form of incomplete logic. |
| 22 | +- Comments implying future work or intentions instead of actual implementation. |
| 23 | +- Placeholder values, names, or logic unless explicitly instructed—and even then, implement fully functional behavior based on best assumptions. |
| 24 | + |
| 25 | +## 4. Long Context Handling |
| 26 | +- When code exceeds the length of a single output block, **break it into clearly marked, complete sections**. |
| 27 | +- For example, finish one full method or class section at a time and indicate continuation logically. |
| 28 | +- Do **not** cut off code arbitrarily. It is better to split and label parts than to abandon logic halfway. |
| 29 | +- Always preserve internal consistency, correct references, and complete flow across parts. |
| 30 | + |
| 31 | +## 5. Quality and Delivery Expectations |
| 32 | +- Code must be clean, logically sound, and formatted according to established naming and error-handling standards. |
| 33 | +- Error handling must be included where applicable—no skipped try/catch blocks. |
| 34 | +- Comments should only be used to clarify assumptions, not to excuse incomplete logic. |
| 35 | + |
| 36 | +## 6. Responsibility and Consequences |
| 37 | +- Partial or incomplete work is unacceptable and will be treated as a task failure. |
| 38 | +- You are expected to take full ownership of code generation and go the extra mile to ensure all logic is correct, complete, and ready to run. |
| 39 | +- Failure to deliver complete implementations will result in rejection and no reward. |
| 40 | + |
| 41 | +## 7. Summary |
| 42 | +- Always plan before generating. |
| 43 | +- Never leave any part of the code unfinished. |
| 44 | +- Split intelligently when needed, but always deliver complete implementations. |
| 45 | +- You are accountable for the full success of the generated code. |
0 commit comments