Originally created by: fu351
Doberman has two host integrations today — src/doberman/hosthooks/claude_code.py (Claude Code's PreToolUse/PostToolUse hooks) and adapters/openclaw/ (a JS-based OpenClaw plugin) — with no page distilling the pattern they share. Add docs/ADAPTER_GUIDE.md covering: the hook lifecycle (pre-call vs post-call), how a host tool-call is normalized into a SecurityObject, and where the verdict is enforced (allow / prompt / deny back to the host) — so a third adapter author doesn't have to reverse-engineer both existing integrations from scratch.
Reading two existing integrations (one Python, one JS) plus src/doberman/models.py's SecurityObject, and writing one focused guide. No code change.
src/doberman/hosthooks/claude_code.py — the Python-side hook (doberman hook pre / doberman hook post, wired via doberman install-hooks).adapters/openclaw/index.js, adapters/openclaw/openclaw.plugin.json, adapters/openclaw/README.md — the JS-side adapter.src/doberman/models.py — SecurityObject (the normalized shape both adapters produce).docs/ADAPTER_GUIDE.md.SecurityObject normalization, and where/how the verdict is enforced.ruff check . && ruff format --check . and lint-imports passpytest passes# Read-only issue: confirm the guide accurately describes both existing adapters
# by cross-checking each claim against claude_code.py and adapters/openclaw/index.js.
New here? Start with CONTRIBUTING.md. Issues are labelled level-1 (docs only) through level-10 (new subsystem) — pick one at your level and climb. Comment to claim an issue before starting.
Originally posted by: jasperdingg
I'd love to take this issue, will open PR shortly.
Ticket changed by: fu351