Skip to content

feat: add governed Hermes builder dispatch capability - #84333

Open
fanuman123 wants to merge 12 commits into
NousResearch:mainfrom
fanuman123:feat/hermes-builder-dispatch-smoke-002
Open

feat: add governed Hermes builder dispatch capability#84333
fanuman123 wants to merge 12 commits into
NousResearch:mainfrom
fanuman123:feat/hermes-builder-dispatch-smoke-002

Conversation

@fanuman123

@fanuman123 fanuman123 commented Aug 12, 2026

Copy link
Copy Markdown

Summary

Adds the production hermes.builder_dispatch.v1 capability as a supervised local Unix-domain-socket service backed by Hermes Kanban.

The implementation includes authenticated and idempotent dispatch handling, governed repository/worktree and path checks, confined builder tools, effective DeepSeek profile attestation, race-resistant completion evidence, adapter-owned result commits, cancellation handling, registered isolated validation, and an operator CLI covering preparation through evidence retrieval.

Why

The orchestrator needs a narrow, auditable way to delegate implementation work to Hermes without granting callers direct shell, process, unrestricted filesystem, approval, push, PR, merge, or live-execution authority.

Safety and behavior

  • Binds only to a mode-0600 local Unix socket.
  • Resolves governance, repository coordinates, validation profile, retry policy, and timeout policy from trusted runtime state.
  • Attests the exact deepseek-builder / deepseek-v4-pro route with an empty fallback chain.
  • Restricts the worker tool surface and validates changed paths against the registered manifest.
  • Runs registered validation in a disposable, network-disabled, read-only container environment.
  • Produces deterministic completion evidence and a clean adapter-owned commit.
  • Does not push, merge, approve, or affect live execution from inside the capability.

Operator workflow

The hermes orchestrate command provides health, cycles, prepare, activate, start, status, evidence, and cancel. Preparation and activation start no worker; each cycle binds immutable objective, acceptance criteria, paths, repository commit, validation profile, and limits.

Current published head

  • Base feature head: 17a1af49a3b0382eee41414e4a51e8de399b326c
  • Reconciled upstream main: 649c20629eedea5a26d34b01ec8f3e14e96e9249

Review-feedback follow-up

The current head hardens operational recovery paths:

  • worker identity-probe failures now roll back cleanly with a controlled error;
  • worker tool allowlists must be non-empty;
  • downstream update-guard bypass is explicit and prominently warned for operator recovery only;
  • process-group termination remains fail-closed unless kernel absence is proven;
  • completion evidence keeps task and governance snapshots distinct;
  • updater tests isolate downstream-guard state.

Post-follow-up local validation:

  • broad no-live matrix: 751 passed, 5 skipped, 0 failed;
  • focused follow-up and adjacent suites: 232 passed, 3 skipped, 0 failed;
  • Ruff and git diff --check: passed;
  • reconciliation worktree: clean.

Fresh GitHub CI is pending for this exact head.

Prior canary validation

The earlier end-to-end canary completed successfully at commit df864d81900bfcb11863e5b4fab6847915202390: registered tests and Ruff passed, strict validation passed, dispatch succeeded, worktree remained clean, and no duplicate rows or leftover validation resources remained.

Publication status

No merge or self-approval has been performed.

Hermes Builder Adapter and others added 2 commits August 11, 2026 21:48
dispatch_id=fb96f129-cef7-4b22-97c8-4a4bbd1c4b04

request_sha256=08745f29c8b9bda55e6033a3ee83c47242a7b1fa0401e3837c09d2d839a04596

live_execution_affected=false
@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/cli CLI entry point, hermes_cli/, setup wizard comp/cron Cron scheduler and job management comp/plugins Plugin system and bundled plugins comp/tools Tool registry, model_tools, toolsets needs-decision Awaiting maintainer decision before any implementation sweeper:risk-security-boundary Sweeper risk: may affect sandboxing, auth, credentials, or sensitive data labels Aug 12, 2026
@fanuman123
fanuman123 marked this pull request as ready for review August 12, 2026 07:12
@fanuman123
fanuman123 marked this pull request as draft August 12, 2026 07:55
@fanuman123
fanuman123 marked this pull request as ready for review August 12, 2026 07:55
@Enough1122

Copy link
Copy Markdown
Contributor

AI code review — automated review for reference, author can ignore or act on any point.

PR: feat: add governed Hermes builder dispatch capability

Large, security-sensitive PR — reviewed for the sharpest edges. The governance/attestation design (hash-pinned artifacts, idempotency reservations, fail-closed dispatch, 0600 file modes) is thorough; the issues below are in the kanban integration layer.

  1. Unhandled exceptions in the _set_worker_pid lifecycle block (hermes_cli/kanban_db.py, ~line 9232): the governed-lifecycle insert calls _kernel_process_start_identity(pid) and os.getpgid(pid) with no try/except. On Windows _kernel_process_start_identity unconditionally raises OSError("kernel process-start identity unavailable"), and on POSIX a worker that exited between spawn and this call raises ProcessLookupError — both propagate up through the dispatch path. detect_crashed_workers wraps the same calls defensively, but this site does not. worker_policy is generic (any plugin can opt a task in), so a Windows board with a policy task would crash the dispatcher. Suggest degrading gracefully (skip lifecycle tracking) or failing with a clean error.

  2. Empty tool_allowlist passes create_task validation (kanban_db.py, create_task): all(isinstance(name, str) and name for name in worker_policy["tool_allowlist"]) is vacuously true for [], and the policy then reaches model_tools.py, where HERMES_INTERNAL_WORKER_TOOL_ALLOWLIST="[]" parses to an empty list — if raw_worker_allowlist: is falsy so nothing is added, but the final filter raw_worker_allowlist is not None reduces the schema to the empty allowlist, i.e. a worker with zero tools. Consider rejecting an empty tool_allowlist at create_task (it already requires non-empty strings).

  3. Update guard has no escape hatch (hermes_cli/main.py, _downstream_update_guard_status / _enforce_downstream_update_guard): a guard whose anchor is in local history but absent from origin/<branch> hard-blocks hermes update (exit 2) for every install. Inert for the upstream repo only while the anchor stays an ancestor of main; if that anchor is ever rewritten (history cleanup, force-push) all existing installs stop updating until resolved. Since the guard's purpose is protecting downstream forks, an explicit --override-guard/--force flag for operators would prevent bricking the update path.

  4. Minor: _process_group_terminated treats killpg(pg, 0) success as "still alive" and lookup-failure as "terminated" — pgid reuse across the 600s TTL window could misclassify, but the failure direction is safe (completion blocked, never falsely confirmed). The kernel start-identity check is the real proof; the pgid probe is reasonable belt-and-braces. A comment noting the reuse caveat would suffice.

Copy link
Copy Markdown
Author

Superseded by refreshed PR #89934 because GitHub’s generated head ref for this PR remained pinned to the old commit after the fork branch advanced. #89934 points at exact reviewed head 17a1af49a3b0382eee41414e4a51e8de399b326c, is currently conflict-free with upstream main, documents all addressed findings, and links passing exact-head CI/Docker/Nix evidence. This PR is retained for its original discussion and automated review history.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/cli CLI entry point, hermes_cli/, setup wizard comp/cron Cron scheduler and job management comp/plugins Plugin system and bundled plugins comp/tools Tool registry, model_tools, toolsets needs-decision Awaiting maintainer decision before any implementation P3 Low — cosmetic, nice to have sweeper:risk-security-boundary Sweeper risk: may affect sandboxing, auth, credentials, or sensitive data type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants