DeskRPG Hermes Plugin

DeskRPG backend — install through the DeskRPG setup wizard. It is not a general-purpose Hermes plugin; on its own it only adds HTTP routes that DeskRPG calls.

Connect DeskRPG, a self-hosted virtual office, to Hermes Agent. This standalone Python plugin extends the Hermes API Server; it is not a Hermes Desktop UI extension.

Features

• Manage Hermes profiles, identity, model configuration, toolsets and skills from DeskRPG.
• Expose Hermes kanban boards, task actions, attachments and execution records.
• Manage profile-scoped cron jobs and retrieve automation events.
• Save versioned artifacts with artifact_save, and capture supported tool outputs, response code blocks and links.
• Propose kanban cards with propose_kanban_card.
• Preserve original conversation attachments and prepare verified copies for agent file tools.

Requirements and installation

Python 3.11+ and Hermes Agent >=0.21.1 with the API Server enabled. Runtime dependencies are aiohttp and PyYAML, provided by Hermes. Internal Hermes API availability is checked during registration.

plugin_sha=$(git ls-remote https://github.com/dandacompany/deskrpg-hermes-plugin.git refs/tags/v0.32.0 | cut -f1)
hermes plugins install https://github.com/dandacompany/deskrpg-hermes-plugin --ref "$plugin_sha"
hermes plugins enable deskrpg
hermes plugins doctor deskrpg

Restart your Hermes gateway after installation or updates so the HTTP routes are attached. Connect the gateway from DeskRPG using its API Server credentials.

Once admitted to the Hermes plugin catalog, installation by the catalog name deskrpg will use the reviewed commit. Catalog updates go through a reviewed SHA-bump PR and hermes plugins update deskrpg. The plugin does not download or replace its own code.

Permissions

This plugin runs inside the Hermes gateway with the gateway process’s filesystem authority. It registers an api_server platform handler, four tools (artifact_save, propose_kanban_card, deskrpg_ask_user, conversation_files), two hooks (post_tool_call, post_llm_call), system-prompt sections and an artifact skill. It requires no additional API key to load.

HTTP routes require Hermes API Server authentication. Owner-key routes can manage all profiles and shared kanban boards, dispatch or terminate workers, and read automation results across profiles. Profile routes manage identity, configuration, cron jobs, provider credentials and OAuth flows. Profile-key isolation requires Hermes multiplex profiles; single-profile gateways resolve their own profile prefix to the listener owner key. Keep owner credentials server-side and restrict access to the gateway.

Creating a profile returns its newly generated API key once to the authenticated caller. Provider credentials are stored through the profile’s Hermes configuration. Artifacts and automation metadata are persisted in local storage; automatic capture can retain content produced during agent work.

Worker propagation (off by default)

Kanban workers run as hermes -p and cron runs with HERMES_HOME=. Hermes loads user plugins only from the running home’s plugins/ directory and its plugins.enabled list, so a plugin installed only in the gateway’s root home is not loaded in those processes, and artifacts produced by workers are not captured.

When worker propagation is enabled, this plugin, on profile creation and on an owner-key POST /deskrpg/worker-plugin:

• creates a symlink /plugins/deskrpg pointing to the root installation, and
• appends deskrpg to that profile’s config.yaml plugins.enabled (a timestamped 0600 backup of the previous file is written next to it).

It never overwrites an existing non-link directory, and never enables the plugin in a profile that lists deskrpg under plugins.disabled. A symlink is used instead of a copy so every profile runs the same version as the root install. Hermes’ install-time security scan does not re-scan the linked directory; each profile loads the code that was scanned when the root copy was installed or updated.

Propagation is off by default. The plugin only reads the setting; it has no code path that turns it on. Enable it on the gateway host with either:

hermes config set plugins.entries.deskrpg.worker_propagation true
# or, in the gateway's environment
DESKRPG_WORKER_PROPAGATION=1

The DeskRPG setup wizard asks before writing this setting. The value is read on every call, so no restart is needed. While it is off, POST /deskrpg/worker-plugin returns 409 worker_propagation_disabled and writes nothing, profile creation returns workerPlugin: {"skipped": "propagation_disabled"}, and /deskrpg/info reports worker_plugin.propagation: "disabled". Turning it off does not remove links or plugins.enabled entries that already exist; /deskrpg/info keeps reporting them.

Skill management (0.15.0)

Routes under /p/{profile}/deskrpg/skills, /curator and /learning act on that profile’s Hermes home:

• Subprocesses. Skills Hub install, uninstall and update, and curator runs, start hermes -p skills install|uninstall|update … or hermes -p curator run as a background job (one per profile) using Hermes’ own executable and its profile-action environment, so the gateway profile’s credentials are not passed to the child. Only the last 4 KB of output is kept, with secret-like values masked.
• Scan override. Hub preview returns Hermes’ security-scan verdict as allow, ask or block. A caller holding the profile’s key can install an ask skill by sending force: true, which passes --force to hermes skills install — the same override Hermes’ own CLI offers. block is refused whatever force says, and force is ignored for allow.
• Network. Hub search and preview go to the skill sources configured in Hermes, through Hermes’ own source router. The plugin makes no network requests of its own.
• File writes. Creating a skill and replacing its SKILL.md go through Hermes’ skill write functions (non-local skills are refused). Reference files are read-only: writing one answers 410 skill_reference_edit_removed — ask the employee in chat to change it. Enable/disable writes skills.disabled in the profile’s config.yaml with a backup. Pin, archive and restore use Hermes’ lifecycle functions. Permanently deleting a single archived skill answers 410 skill_purge_removed; use the Hermes dashboard or hermes -p curator purge.
• Skill jobs. Hub install/uninstall/update and curator runs execute the documented CLI (hermes -p skills|curator …) in a child process: DESKRPG_HERMES_BIN or HERMES_BIN if set, else hermes on PATH, else the gateway’s own interpreter with -m hermes_cli.main. The child gets the gateway environment without the gateway .env keys and anything named like a key, token, secret, password, cookie or credential, with HERMES_HOME set to the profile. Jobs stop after 15 minutes.
• Memory. Learning-graph memory nodes are returned only on request (includeMemory=1) and are edited or deleted only when a content hash matches. Hermes has no undo for memory deletion, so each deleted chunk is appended to /plugin-data/deskrpg/memory_deleted.jsonl (0600) first.

Other settings

Optional artifact controls include HERMES_DESKRPG_CAPTURE_RESPONSES=0, HERMES_DESKRPG_CAPTURE_LINKS=0, HERMES_DESKRPG_ARTIFACT_MAX_VERSIONS (default 20; 0 is unlimited), HERMES_DESKRPG_ARTIFACT_MAX_BYTES, HERMES_DESKRPG_ARTIFACTS_ROOT, and HERMES_DESKRPG_ARTIFACT_SOURCE_ROOTS.

Task approval compatibility

New DeskRPG cards require the kanban_review_policy_v1 capability. It is advertised only when the complete native Hermes policy API is available. Installing this plugin alone does not add that API to an unpatched Hermes installation. Legacy cards and reads remain available; unsupported creation fails before writing.

The tested Hermes source is the Dante Labs compatibility branch deskrpg/mixed-approval-v1 at commit 622a2f793f in dandacompany/hermes-agent, based on upstream e2f8a0731bf2. This patch is not an upstream Hermes release. See the native policy guide for the contract and operator commands.

Stop the gateway and back up its kanban databases before replacing core code. Install the pinned source in your existing Hermes environment using its normal editable-install procedure, then restart the gateway. Keep this policy-aware core when rolling back the UI: older cores cannot enforce policies for existing protected cards. A normal upstream update can remove this compatibility patch.

New cards default to human approval. An explicitly delegated task can be approved by a different AI profile. Approvals bind to the submitted result; generic status changes cannot substitute for approval. AI reviewers must inspect the actual submitted text or artifacts; this does not guarantee the semantic quality of an AI review. Existing cards are not converted automatically.

Moving an install off the patched core

The plugin can enforce approvals on upstream Hermes with its own hooks and approval store. The order below is what moving a source install (a checkout with a Python 3.11 virtualenv and a systemd user unit) actually took.

1. Back up the Hermes home with the gateway stopped, including the core checkout, its virtualenv and the unit file, so the whole step can be undone.

2. Carry the policies over, with the gateway stopped. The patched core recreates its triggers (CREATE TRIGGER IF NOT EXISTS) whenever a board database is opened, so a running gateway would put them back:

systemctl --user stop hermes-gateway
# in the old Hermes environment, once per DeskRPG board
python -m deskrpg_plugin.review_migrate --board  --dry-run --drop-patch-triggers   # report only
python -m deskrpg_plugin.review_migrate --board  --drop-patch-triggers

It copies each card’s policy and recorded approvals into the approval store and leaves a card that was waiting for a person in review with nobody assigned. Cards it cannot move are listed under skipped. The patch’s tables are only read and are kept as a record. --drop-patch-triggers removes the eleven triggers the patch installed in the board database (listed under dropped_triggers; nothing else is touched). They outlive the patched core: without this, a card the patch had not approved could never be completed on upstream Hermes, not even through an approval in DeskRPG.

3. Install upstream Hermes with its own installer. Current upstream runs only on Python 3.14: every runtime dependency in pyproject.toml carries a python_version >= '3.14' marker, so pip install -e . into an older virtualenv installs no dependencies (upstream website/docs/getting-started/updating.md, “Python 3.14 and older interpreters”). From the checkout, at the commit you pin, run the upstream package manager — tools first, then the environment with the extras you use named explicitly:

cd  && git checkout --detach 
./venv/bin/python -m pm.cli install --tools-only
./venv/bin/python -m pm.cli install --extra messaging --extra mcp   # plus the extras the old venv had

pm.cli install given only --extra does not install the tool closure (ffmpeg, node, ripgrep…) and stops with “tools not on PATH before venv sync” (pm/cli.py, cmd_install); --tools-only first avoids that. The API server needs aiohttp, which comes with the messaging extra. PM publishes a Python 3.14 under /tools, the environment under /installs, and repoints ~/.local/bin/hermes to the launcher /.hermes/bin/hermes. (hermes update does the same but moves to the latest main; use it when you do not pin a commit.)

4. Give the checkout an install stamp. Without install-stamp.json Hermes reports a placeholder version (0.19.1), and this plugin (requires_hermes: ">=0.21.1") is skipped at load — every /deskrpg/* route disappears. Write one with the upstream script; Hermes rewrites it from git on the next start:

 scripts/write_install_stamp.py --output install-stamp.json \
    --base-version  --distance  --update-mechanism self

5. Regenerate the service unit with upstream’s own template (hermes_cli.gateway.generate_systemd_unit(), the same text hermes gateway install writes): its ExecStart, ExecStop and ExecStopPost run the launcher, and the old virtualenv leaves PATH and VIRTUAL_ENV.

6. Point kanban workers at the launcher. Under the PM runtime the gateway imports Hermes through a PYTHONPATH that Hermes strips from child environments (tools/environments/local.py), and the dispatcher’s default worker command is python -m hermes_cli.main unless $HERMES_BIN is set (hermes_cli/kanban_db_dispatch.py, _resolve_hermes_argv). Without it every worker exits with No module named 'hermes_cli' and the card is given up. Set it for the gateway service, for example in a drop-in:

# ~/.config/systemd/user/hermes-gateway.service.d/hermes-bin.conf
[Service]
Environment="HERMES_BIN=/.hermes/bin/hermes"

Then systemctl --user daemon-reload, start the gateway, and check /deskrpg/info: review_hooks_v1 present, kanban_review_policy_v1 absent.

Known gap: the DeskRPG setup wizard does not set HERMES_BIN for a gateway on the PM runtime yet; set it by hand as above.

Upstream Hermes main

CI also runs the integration suite on upstream Hermes main (job integration-upstream, non-blocking; locally scripts/ci-local.sh --upstream). Tests that need the approval-policy core patch are excluded there. Known upstream breaks are excluded from that job with the upstream_known_break marker; there are none at the moment.

Skill management is announced per feature (profile_skill_read, profile_skill_edit, profile_skill_hub, profile_curator, profile_learning_graph), so a Hermes build that moves one symbol turns off only that feature. profile_skill_admin is still announced when all five are on.

Original conversation files

Capability conversation_files_v1 lets DeskRPG keep original uploads in Hermes and prepare them for a specific profile and conversation session. The conversation_files tool lists authorized originals and prepares a selected file for reading with existing file tools. DeskRPG uploads support files up to 5 MiB and up to three files per send.

Originals remain available through their conversation links. Execution copies use short-lived leases and are reclaimed when idle. The default original-store quota is 1 GiB (DESKRPG_CONVERSATION_FILE_QUOTA_BYTES); the per-profile execution cache is limited to 256 MiB. Grants and file-tool calls remain bound to the authorized profile and Hermes session. File contents are untrusted user material.

Release

0.32.0 adds original conversation files, authenticated upload/download/delete routes, session-bound grants and the conversation_files tool. Prepared copies are verified against their original SHA256, support Hermes local and Docker file tools, and use renewable leases with idle cleanup. Requires a DeskRPG version with conversation attachments; restart the gateway after updating.

0.31.1 lists the same providers as hermes model, in its order: the catalog walks Hermes’ provider_catalog instead of PROVIDER_REGISTRY, which repeated a provider once per alias (Nebius Token Factory and Meta Model API six times each) and left out OpenRouter, Mixture of Agents and custom endpoints. Authentication comes from the picker’s own check, so an OpenRouter key or a configured custom base URL counts. Authenticated providers still come first. PUT provider-keys/openrouter now stores OPENROUTER_API_KEY.

0.31.0 adds POST /p/{profile}/deskrpg/skill-invocation (capability skill_invocation). DeskRPG chat skill chips send skill names and an instruction; the plugin builds the same message Hermes’ TUI and messaging gateway build for /skill … (one skill or up to five stacked) with Hermes’ public skill-command builders, scoped to the profile’s home. Unknown skills answer 404 skill_not_found, skills disabled for the profile or for the API server platform 409 skill_disabled, and a skill that cannot be loaded 422 skill_load_failed — the chat is never sent without the skill.

0.30.3 orders the model picker for providers whose list Hermes passes through in models.dev insertion order (Gemini, xAI, Mistral, Groq): models are grouped by family, -latest aliases first, then newest version, with stable releases above previews. xAI keeps the headline model Hermes pins to the top. Providers that Hermes orders itself, such as openai-codex, keep Hermes’ order.

0.30.2 moves the profile listing in POST /deskrpg/worker-plugin into a worker thread. Hermes checks each profile’s gateway through the gateway’s own control socket while listing profiles, which deadlocked the loop on Windows. A test now fails if any route coroutine calls those Hermes functions directly.

0.30.1 keeps the gateway’s event loop free while it answers /deskrpg/info and the profile routes. The blocking checks now run in worker threads; the slow ones (kanban.worker_launch, the per-profile worker plugin and review-hook checks) are waited on for at most two seconds, then report null (“not known yet”) and fill a 30-second cache for the next call. kanban.dispatcher_present now follows kanban.dispatch_in_gateway instead of asking the gateway’s own control socket, which stalled the loop on POSIX and deadlocked it on Windows until the loop watchdog stopped the gateway with exit 75.

0.30.0 adds install.commit to /deskrpg/info: the git commit of the plugin code the gateway loaded, read from the plugin folder’s .git files (null when there is none). DeskRPG uses it to tell container installs still on the old compose file, which track the plugin’s development branch, to download the new compose once.

0.29.1 makes kanban.worker_launch match how Hermes actually starts workers: on a multiplexed root gateway every worker loses the gateway’s PYTHONPATH, so HERMES_BIN is required; on a standalone profile gateway the answer can depend on the assignee and is reported as ok: null, reason: "assignee_dependent".

0.29.0 adds capabilities_fingerprint and started_at to /deskrpg/info and to every /deskrpg/events page, so DeskRPG notices a changed Hermes core or a gateway restart on its next poll without extra requests.

0.28.2 records a Hub skill removal as hub_uninstall in the skill job log instead of hub_update.

0.28.1 stops a profile from approving its own work: if the reviewer profile submits a card it implemented, or a reviewer run picks up its own submission, the card waits for a person instead of being approved by the same profile. /deskrpg/info now reports whether the gateway can start kanban workers (kanban.worker_launch): on an upstream package-manager runtime the dispatcher needs HERMES_BIN pointing at the Hermes launcher, otherwise workers exit with No module named 'hermes_cli'. The patched-core migration steps are rewritten to match a real move to upstream.

0.28.0 keeps NPC skill management working on upstream Hermes main. Skill jobs (hub install, uninstall, update and curator runs) run the documented hermes -p skills|curator commands in a child process with gateway credentials removed from its environment. Skill management is split into per-feature capabilities (profile_skill_read, profile_skill_edit, profile_skill_hub, profile_curator, profile_learning_graph; profile_skill_admin is still announced when all five are on), so one missing Hermes internal no longer turns the whole screen off. Editing a skill’s reference files and permanently deleting a single archived skill are removed (410 skill_reference_edit_removed, 410 skill_purge_removed): ask the employee in chat to change reference files, and purge from the Hermes dashboard or hermes -p curator purge. review_migrate --drop-patch-triggers removes the patched core’s approval triggers after moving policies.

0.27.0 enforces approval policies on upstream Hermes without a core patch (capability review_hooks_v1). Cards and swarms can carry a human, agent or mixed (AI review, then a person) policy, kept in a plugin-owned store outside Hermes’ schema next to the shared kanban home. Worker hooks stop an implementer from completing its own card and route it through kanban_request_review; a card waiting for a person sits in review with no assignee until someone approves or sends it back through the existing approve and request_changes actions. AI reviewer approvals and rejections are recorded, boards get a default policy (GET/PUT /deskrpg/kanban/boards/{slug}/default-policy), /deskrpg/info lists profiles that would run without the hooks, and python -m deskrpg_plugin.review_migrate moves policies from a patched core. On a patched core the existing policy path is still used.

0.26.0 runs on upstream Hermes main without Dante Labs patches for everything except review policies: the required Hermes API list no longer names underscore internals, status and field edits go through the public kanban verbs the upstream dashboard uses (reclaim_task, promote_task, edit_task), reopening a finished card whose descendants are running no longer fails, and PyYAML is declared in python_dependencies because upstream Hermes no longer ships it. hermes plugins enable deskrpg prepares the dependency. CI also runs the integration suite against upstream main.

0.25.0 creates swarms on boards with review policies (capability swarm_review_policy): workers get the requested policy and verifiers and synthesizers get human review, attached in the same write transaction that creates the swarm so no card becomes ready without its policy; the root stays a policy-free structure card. The capability is announced only when the Hermes internals it relies on are present with the expected signatures; otherwise a policy swarm answers 428 swarm_review_policy_unsupported.

0.24.4 keeps the artifact id clock in one process-wide place too, so an upload through the route and a save from a tool in the same millisecond still get ordered ids.

0.24.3 keeps ask_user sessions and questions in one process-wide store, because Hermes imports a directory plugin once per profile home under a different module name and the route and the tool could otherwise see different copies.

0.24.2 finds an ask_user session registration by its session id (the profile comes from the registration route) because a multiplexed gateway’s tool thread can read the root profile, and logs why a question fell back to assuming.

0.24.1 tells the model when and how to call deskrpg_ask_user in a system prompt section (Hermes Tool Search can hide plugin tools behind tool_search), and task.run.started events now carry the card’s assignee so DeskRPG shows who is working as soon as a run starts.

0.24.0 lets an NPC ask its user a question with choices in DeskRPG 1:1 chat (capability ask_user): the deskrpg_ask_user tool (question, 2-4 choices, optional free answer) waits until the user answers or stops the run, but only in chat sessions DeskRPG registered (POST /p/{profile}/deskrpg/ask-user/sessions); kanban, cron and other sessions fall back to assuming at once. Pending questions are listed with GET /p/{profile}/deskrpg/questions?session_id= and answered with POST /p/{profile}/deskrpg/questions/{id}/answer; they live in memory only. Session sources now read kanban workspaces and card attachments from Hermes’ boards root.

0.23.0 lists what a session read (capability session_sources): GET /p/{profile}/deskrpg/sessions/{session_id}/sources with the profile key reads the session’s stored tool calls and returns web pages (web_extract, browser_navigate: URL and title, with credentials, fragments and token-like query values removed) and files (read_file, delegate results: paths relative to the working directory, or / inside a kanban card workspace; absolute paths are never returned). Nothing is stored; sessions follow Hermes’ own retention.

0.22.0 issues a key for a profile that already exists (capability profile_key_issue): POST /deskrpg/profiles/{name}/key with the owner key writes a new API_SERVER_KEY to that profile’s .env and returns it once. A profile that already has a key answers 409 key_exists unless the body says {"rotate": true}; an existing key is never returned. The default profile (400 default_profile) and profiles whose key comes from an external secret provider (409 external_secret_provider) are refused. Hermes reads the new key without a restart.

0.21.0 adds run history for cards (capability kanban_run_events): card detail events carry the run_id of the run they belong to (null for card-level events), the event stream now closes runs that end as spawn_failed or rate_limited instead of dropping them, and board cards include consecutive_failures.

0.20.0 adds board status transitions for rework metrics (capability kanban_task_events): GET /deskrpg/kanban/events?board=&from=&to=&kind=status&limit= returns the status changes that happened inside the window (epoch seconds, inclusive, default 7 days), each with the status the card left even when that was set before the window; up to 1000 by default (5000 max), keeping the most recent with truncated: true.

0.19.0 adds board archiving (capability board_archive): PATCH /deskrpg/kanban/boards/{slug} accepts archived: true|false, archived boards leave GET /deskrpg/kanban/boards unless ?include_archived=true, board metadata reports archived, the default board cannot be archived (400 invalid_board), and a board with running cards is refused with 409 board_has_running_cards and its running count. A card-proposal resolve now records task_id only for the card choice, and time-based tests no longer depend on wall-clock budgets.

0.18.1 adds the cron job name (jobName, from the profile’s cron/jobs.json) to approval.blocked events.

0.18.0 adds the unattended run approval policy (capability profile_approval_policy, routes under /p/{profile}/deskrpg/approval-policy): read and set approvals.cron_mode and approvals.single_query_mode (deny/approve only) and edit command_allowlist (dangerous-pattern keys). Worker processes also record approval.blocked events (opt-in include=approvals) when a cron job or kanban run is stopped by that policy or by an untrusted MCP write tool, with the pattern key when there is one and a redacted command.

0.17.1 prevents overlapping MCP OAuth attempts for the same server. Hermes lets a new attempt cancel an older one, but if the older worker finishes after the newer attempt has been approved, its rollback restores the pre-attempt token snapshot and erases the fresh authorization. POST …/mcp/servers/{name}/oauth now returns 409 oauth_in_progress (with the open sessionId) while an attempt is still running; with {"restart": true} it cancels the open attempt, waits up to 10 seconds for its worker to exit, and only then starts a new one (409 oauth_busy if the worker has not exited). Cancelling also waits for the worker; if it has not exited the response adds workerDone: false and new attempts stay blocked until it does.

0.17.0 adds NPC MCP connector management (capability profile_mcp_admin, routes under /p/{profile}/deskrpg/mcp): list, add, edit and remove a profile’s MCP servers (http or stdio; new stdio servers must repeat their name as confirmName, and custom stdio servers default to trust: untrusted); Hermes’ own security check runs before every save and a rejection returns 422 mcp_security_rejected with its reasons; enable/disable, trust, and tool selection (tools.include/exclude); write-only secrets that live only in the profile .env (responses report hasValue, never values); connection tests as background jobs that read each tool’s read-only/destructive annotations; OAuth completed by pasting the loopback redirect URL; catalog install without prompts; reload scoped to the profile; and a secret-free export for copying a server to another profile. The last connection result and a value-free change log are kept in plugin-data/deskrpg/.

0.16.0 makes worker propagation opt-in and switches default text to English. Propagation into profile homes now runs only when the operator enables plugins.entries.deskrpg.worker_propagation (or DESKRPG_WORKER_PROPAGATION=1); otherwise POST /deskrpg/worker-plugin returns 409 worker_propagation_disabled, profile creation skips it, and /deskrpg/info reports worker_plugin.propagation. Existing links are kept. The manifest description, the always-on system-prompt sections, tool descriptions, the artifact skill, and tool, route and log messages are now English. See Permissions.

0.15.0 adds NPC skill management (capability profile_skill_admin, routes under /p/{profile}/deskrpg/skills, /curator and /learning): skill list with provenance, usage and pin state; detail and file tree; editing SKILL.md, references/ and templates/ through Hermes’ own write path with optimistic concurrency (baseHash); creating skills; per-skill and bulk enable/disable; pin, archive, restore and single-skill purge from the archive (ledger-recorded; pinned skills cannot be archived); Skills Hub search, preview with scan verdict, and install/uninstall/update as background jobs (one per profile); curator status, pause/resume and run; and the learning graph, whose memory nodes are only returned on request (includeMemory=1) and are edited or deleted only against a content hash. Deleted memory chunks are kept in plugin-data/deskrpg/memory_deleted.jsonl (0600) because Hermes has no undo for them.

0.14.0 adds POST /deskrpg/events/handoff and the event_cursor_handoff capability. When DeskRPG archives the project whose board carries a channel’s event stream, the plugin merges the old carrier’s global position into the new board’s cursor so no card, cron or artifact event is lost across the handoff. DeskRPG 2026.922.3 and later requires this capability before archiving a carrier board; older DeskRPG versions ignore the route.

0.13.1 adds native per-task human and independent-agent approvals, submission-bound receipts, authenticated human display names, and capability gating. The runtime distribution excludes development instructions and test scaffolding. The source master retains CI tests.

0.13.1 corrects installation instructions for Hermes releases that require a full commit SHA in --ref. Runtime approval behavior is unchanged from 0.13.0.