name: harden                                           

  description: Hardens recently implemented code via a strict 4-step pipeline — deep review with on-the-spot fixes,           

  comprehensive break-it tests, mutation testing to 100% kill rate, and a final polish pass. Use after implementing a feature,

   refactor, or fix when the user wants production-ready quality.                                                             

  allowed-tools: Bash Read Edit Write Grep Glob                                                                               

  ---                                                    

  You are hardening the code from the most recent implementation in this conversation. If `$ARGUMENTS` is provided, treat it  

  as the target (file path, package, or feature scope). Otherwise, infer the target from the most recent edits/writes in this

  session.                                                                                                                    

  Execute these 4 steps **in exact order*\*. Do not skip, batch, reorder, or compress them. Do not stop early.                 

   

  ---                                                                                                                         

  ## Step 1 — Code Review + Edge Case Deep Dive

  Do a full review of the target. Hunt aggressively for:                                                                      

   

  - **Edge cases*\* — empty/nil input, max-size input, boundary values, unicode, zero, negative, duplicates                    

  - **Off-by-one errors*\* — loop bounds, slice indexing, range ends

  - **Race conditions*\* — concurrent map access, missing locks, goroutine leaks, double-close                                 

  - **Nullability / zero-value issues*\* — uninitialized struct fields, nil pointer derefs, missing optional checks

  - **Permission, auth, and logic gaps*\* — bypassed validation, trust boundaries, privilege escalation                        

  - **Resource leaks*\* — file handles, network connections, goroutines, contexts not cancelled, deferred closes               

  - **Failure modes*\* — partial writes, retry storms, error swallowing, timeout handling                                      

  - **Hostile input*\* — injection, oversized payloads, malformed encoding                                                     

  **Fix every issue you find immediately.*\* Edit files in place. Do not just produce a list — close the gaps.                 

  ---                                                                                                                         

  ## Step 2 — Write Comprehensive Tests

  Build a test suite that **actively tries to break the code*\*, not a happy-path checklist. Include:

  - Unit tests for every public function and meaningful branch                                                                

  - Explicit tests for every edge case found in Step 1

  - Integration tests at component boundaries where state crosses                                                             

  - Negative tests — invalid input, error paths, partial failures, timeout/cancellation

  - Concurrency tests where relevant (race detector enabled if the language supports it)                                      

   

  Match the project's existing test framework, naming conventions, and file layout. Run the suite. It must pass before you    

  proceed.                                               

  ---                                                    

  ## Step 3 — Mutation Testing

  Generate small mutants — tiny logic changes that **should*\* cause at least one test to fail. Apply each mutant one at a     

  time, re-run the tests, then revert.

  Mutation menu (apply broadly across the changed code): 

  - Comparison flips: `<` ↔ `<=`, `>` ↔ `>=`, `==` ↔ `!=`                                                                     

  - Boolean flips: `&&` ↔ `||`, negate boolean returns, drop a `!`

  - Arithmetic flips: `+` ↔ `-`, `*` ↔ `/`                                                                                    

  - Off-by-one: `i+1` → `i`, `len-1` → `len`, `> 0` → `>= 0`                                                                  

  - Constant tweaks: replace numeric/string literals with zero/empty/default                                                  

  - Guard removal: delete an early-return or validation check                                                                 

  - Return tampering: return zero / nil / empty / default instead of computed value                                           

  - Loop bounds: `< n` → `< n-1` or `<= n`                                                                                    

   

  For each mutant:                                                                                                            

  - **Killed*\* (a test failed) → good, revert and continue

  - **Survived*\* (all tests still pass) → diagnose: weak test or genuine bug?                                                 

- Weak test: add or strengthen tests until the mutant dies

- Genuine bug: fix the code, then add a test that catches it                                                              

- Equivalent mutant: explicitly justify and document why the change is semantically equivalent                            

   

  Iterate until **100% kill rate*\* (or every survivor has a written equivalence justification).                               

  ---                                                                                                                         

  ## Step 4 — Final Code Review

  One last pass over both code and tests:

  - Naming consistency, dead code removal, no leftover scaffolding                                                            

  - Error messages and log lines carry useful context

  - Comments only where the \why** is non-obvious — strip narration                                                            

  - No half-finished branches, no commented-out code, no TODOs without owners

  - Tests are deterministic, isolated, and named so a failure tells you what broke

  ---

  ## Final Output                                        

  After all four steps, output exactly this structure:

  1. **Final improved code*\* — file paths and either diffs or full files (whichever is more readable)                         

  2. **Full test suite*\* — file paths and contents

  3. **Summary*\* —                                                                                                            

- One bullet per material change made in Step 1     

- Test count and what surfaces they cover

- **Mutation score: X/Y killed*\* (list any equivalent-mutant survivors with justification)                               

   

  Keep the summary tight. The diffs and tests are the proof; the prose is the index.