Enforcing KDD's implementer/validator split mechanically with a toolFilter-restricted subagent

[MauricioPerera]

Not a new plugin — a config pattern on top of kdd-gates, documented in its README under "Forzar la separación implementador/validador con un subagente restringido".

KDD's core thesis is "the agent that implements is never the one that decides it's correct" — normally that's just a system-prompt instruction the model is trusted to follow. @deepseek-ai/dsh-tool-subagent already ships everything needed to make it a mechanical restriction instead: a second instance with provider: spawn (fresh child, no inherited history — the task contract is the interface, not shared conversation memory) and a toolFilter.deny list naming the gate tools (kdd_validate, kdd_seal, kdd_perimeter, kdd_preflight, kdd_scaffold).

- insert:
    - id: tool-subagent-kdd-implementer
      name: '@deepseek-ai/dsh-tool-subagent'
      config:
        provider: spawn
        toolName: kdd_delegate_implementer
        backgroundMode: one-shot
        toolFilter:
          deny: [kdd_validate, kdd_seal, kdd_perimeter, kdd_preflight, kdd_scaffold]
        persona: >-
          You are a KDD implementer subagent. You write code to satisfy a task
          contract's frozen oracle — you never decide whether it's correct.

Real trap hit while verifying it: toolFilter.deny naming a tool that isn't mounted in that profile makes tools.restrict() throw at delegation time — Error: tools.restrict() names unknown global tool "kdd_scaffold". The deny-list has to match exactly which plugins are actually loaded alongside it.

Verified by delegating a task and asking the child to report its own tool list back — none of the 5 KDD tools appeared, confirmed it couldn't even attempt to call them.