Documentation
¶
Overview ¶
Command github-bot is the channel example for resolute-harness-go: verified GitHub webhook ingress translated into signal dispatches, with delivery-id idempotency and one narrow application-owned tool that posts the agent's reply back to the issue.
Run it keyless (a deterministic local provider stands in for the model, and replies are logged instead of posted):
go run ./examples/github-bot
Then simulate GitHub deliveries in another terminal:
# a new issue comment (the X-GitHub-Delivery header is the idempotency key):
curl -si localhost:8487/webhooks/github \
-H 'X-GitHub-Event: issue_comment' -H 'X-GitHub-Delivery: d-1001' \
-d '{"action":"created","repository":{"full_name":"acme/website"},"issue":{"number":42},"comment":{"body":"Login breaks on v2.1","user":{"login":"alice"}}}'
# GitHub redelivery (same delivery id, same bytes) → 202 with the SAME submission:
# re-run the exact curl above
# a forged/mutated payload under the same delivery id → 409 conflict:
# re-run it with a different comment body
# watch the triage conversation live (instance is derived from repo+issue):
curl -N localhost:8487/agents/triager/acme-website-42
Environment (all optional):
GITHUB_WEBHOOK_SECRET verify X-Hub-Signature-256 over the exact request
bytes; without it, ingress is unverified demo mode
GITHUB_TOKEN post replies to the real GitHub API instead of the log
GEMINI_API_KEY, MODEL use Gemini instead of the keyless local provider
Design notes, mirroring flue's github-channel example: the handler completes dispatch admission before returning (GitHub wants a 2xx within ten seconds and does not auto-retry), the delivery id deduplicates redeliveries durably, and the reply tool is deliberately narrow application policy — it can only comment on the one issue its instance is bound to.
Source Files