defense-parity-worker

name	defense-parity-worker
description	Implement source-accurate defense, parry, pushblock, and throw-vs-defense behavior.

Defense Parity Worker

NOTE: Startup and cleanup are handled by worker-base. This skill defines the WORK PROCEDURE.

When to Use This Skill

Use for features that change universal defense behavior: parry timing, block/pushblock flow, ParryAuto paths, throwability during defense, and closely related sim/env legality surfaces.

Required Skills

None.

Work Procedure

1. Read the assigned feature in features.json, the referenced assertions in the mission validation contract, .factory/library/architecture.md, .factory/library/environment.md, and .factory/library/user-testing.md.
2. Read the authoritative Godot defense sources before editing Python code. At minimum inspect the relevant files under hustle/characters/states/ and any supporting logic in hustle/characters/BaseChar.gd / hustle/game.gd that determines defense outcomes.
3. Inspect the current Python runtime and tests that cover the same surface (yomi_hustle/states/defense.py, yomi_hustle/game/simulation.py, yomi_hustle/env/action.py, targeted tests under tests/).
4. Write or update failing targeted tests first. The red step must prove the missing defense behavior before implementation begins. If the session resumes on top of existing red/green test work, explicitly verify that the prior evidence still reproduces the missing behavior before relying on it.
5. Implement the smallest source-backed runtime changes needed. Keep legality/timing in runtime or state code, not in training-only wrappers.
6. Run the narrowest relevant pytest targets until green. Ensure every assertion in the feature's fulfills list is backed by at least one direct test assertion or fixture expectation, not only adjacent routing coverage. Add at least one deterministic manual sanity check (for example, a one-off simulation script or mirrored replay) and record it in interactiveChecks.
7. Run manifest validators before handoff: lint, typecheck, and full test suite unless the orchestrator limited scope.
8. In the handoff, cite the exact Godot files consulted, the tests added, the commands run, and any remaining ambiguity.

Example Handoff

{
  "salientSummary": "Implemented exact parry timing payload handling plus pushblock/parry routing in the simulation and env validation layers. Added red-first tests for perfect parry timing, throw-vs-block gating, and mirrored defense traces; all validators passed.",
  "whatWasImplemented": "Extended the richer action payload with parry timing, ported NewParry/PushBlock timing rules into the state/simulation path, added throwability checks that match defensive state, and updated parity tests plus env-action validation so the runtime and training surfaces agree.",
  "whatWasLeftUndone": "",
  "verification": {
    "commandsRun": [
      {
        "command": "uv run pytest tests/test_simulation.py -k 'parry or block or pushblock or throw' -v",
        "exitCode": 0,
        "observation": "New defense-focused tests passed and older defense regressions stayed green."
      },
      {
        "command": "uv run ruff check yomi_hustle tests",
        "exitCode": 0,
        "observation": "No lint violations."
      
      
         
         
         
      
      
         
         
         
      
    
     
      
         
         
      
    
  
   
     
      
         
         
          
             
             
          
          
             
             
          
        
      
    
  
   

When to Return to Orchestrator

• Godot source is ambiguous or contradictory about defense timing and the conflict materially affects behavior.
• The feature requires a broader action-interface redesign beyond the assigned defense surface.
• Pre-existing regressions in unrelated training or global-parity areas prevent trustworthy validation.