Hermit is a feature-rich Discord moderation and community bot for the OpenClaw ecosystem, deployed to Cloudflare Workers with a Bun-based gateway forwarder relaying Discord gateway events. In production it runs as a single Worker isolate using Carbon (@buape/carbon) for Discord interactions and Drizzle ORM over Cloudflare D1 for persistence. It exposes 14+ slash commands (claim, nominate, slap, lobster, say, admin, role, maintainer, helper, github, beta-pings), context-menu commands, webhook APIs for ClawHub search intelligence and publisher abuse digests, scheduled cron tasks (nomination expiry, thread monitoring, card sync), and a React-SSR form system with OAuth flows for ban appeals, content rights cases, and moderated submissions. The bot is tightly coupled to one Discord guild, with guild/channel/role/user IDs hardcoded across config files, though the domain modules (moderation, nominations, forms, games) are cleanly separated and extensively unit-tested against a SQLite D1 shim. A substantial secondary character is deterministic content/data engineering: the repo bundles a frozen WoRMS taxonomy snapshot of 264 accepted lobster species across 6 families, plus meticulously provenance-tracked AI artwork pipelines (1056 lobster scenes, ~327 slap scenes) with SHA-256 checksums, batch manifests, QA gates (RIFF signature checks, dwebp decode, perceptual dHash near-duplicate detection), remediation loops, and byte-identical rebuild tests. These pipelines feed the in-bot lobster encounter and fish-slap games rather than serving external research, so the repository is best classified as an application with strong data-engineering DNA. The build scripts are genuinely reusable for any biodiversity-data or generative-asset workflow. Drift risks include hardcoded local generation paths (e.g. /Users/hrudolph/...), pinned dependency overrides (esbuild, postcss, ws), future-dated snapshot timestamps as data artifacts, and checksum locks that make data updates deliberately expensive.
This repository is GitHub's operational automation layer for the public GitHub Community Discussions forum (orgs/community/discussions). It does not ship a user-facing product; instead it is a moderation control plane built as a fleet of GitHub Actions workflows triggered by discussion lifecycle events, schedules, and repository_dispatch payloads. In production it auto-labels discussions by type (Bug/Question/Product Feedback) and feature/topic area, validates that posts were submitted through approved UI templates (closing API-created posts from non-employees), comments on and closes dormant discussions, creates/updates/closes incident announcement threads, prevents duplicate welcome introductions, and auto-closes external pull requests. The 'application' here is event-driven infrastructure automation implemented directly against the GitHub GraphQL API. The code is split into Ruby action scripts (in .github/actions/ with shared libraries in .github/lib) and Python helper scripts (in .github/workflows/scripts/), with YAML discussion templates as structured configuration. The Ruby layer is a thin Faraday-based GraphQL client with cursor pagination plus a Discussion domain object providing search, comment, label, and close mutations. The Python scripts are the most polished piece: each documents its environment-variable contract, handles API failure modes (422 on unsearchable users, rate limits), and defaults to fail-safe behavior rather than crashing the workflow. Notable engineering: integration_test_runner.py creates real discussions in the production forum with an '[IT]' prefix, waits for the triggered labeler workflows to run, verifies label and closure outcomes, and then closes all test discussions — an unusually thorough end-to-end testing pattern that also captures the subtle requirement that a PAT (not the built-in job token) is needed to trigger downstream discussion-created workflows. Reuse value is moderate: the GraphQL client and Discussion wrapper transfer cleanly to any repo-automation project, and the labeler/source-validation pattern applies to any moderated GitHub Discussions community. Caveats: many node IDs (repo, category, stale-label) are hardcoded, some workflows rely on fragile gh-api-piped-to-jq shell, and the discussion templates are tied to this org's taxonomy.