better-dsh 0.2.5-c → 0.2.5-e

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/user-guide/features/goals.md

@@ -1,293 +0,0 @@
----
-sidebar_position: 16
-title: "Persistent Goals"
-description: "Set a standing goal and let Hermes keep working across turns until it's done. Our take on the Ralph loop."
----
-
-# Persistent Goals (`/goal`)
-
-`/goal` gives Hermes a standing objective that survives across turns. After every turn a lightweight judge model checks whether the goal is satisfied by the assistant's last response. If not, Hermes automatically feeds a continuation prompt back into the same session and keeps working — until the goal is achieved, you pause or clear it, or the turn budget runs out.
-
-It's our take on the **Ralph loop**, directly inspired by [Codex CLI 0.128.0's `/goal`](https://github.com/openai/codex) by Eric Traut (OpenAI). The core idea — keep a goal alive across turns and don't stop until it's achieved — is theirs. The implementation here is independent and adapted to Hermes' architecture.
-
-## When to use it
-
-Use `/goal` for tasks where you want Hermes to iterate on its own without you re-prompting every turn:
-
-- "Fix every lint error in `src/` and verify `ruff check` passes"
-- "Port feature X from repo Y, including tests, and get CI green"
-- "Investigate why session IDs sometimes drift on mid-run compression and write up a report"
-- "Build a small CLI to rename files by their EXIF dates, then test it against the photos/ folder"
-
-Tasks where the agent does one turn and stops don't need `/goal`. Tasks where *you'd otherwise have to say "keep going" three times* are where this shines.
-
-## Goals vs Kanban: which one do I want?
-
-`/goal` and [Kanban](./kanban) both keep Hermes working without you re-prompting, so it's tempting to assume one flows into the other. It doesn't — the boundary is sharp:
-
-- **`/goal` is single-session.** The loop feeds continuation prompts back into *this* conversation until the judge says done. Setting a goal never creates a kanban card, never assigns work to another profile, and never fans out. There is no handoff to the board, implicit or otherwise.
-- **Kanban is a board of many tasks.** Each card is dispatched to its own worker process with its own session. Cards, dependencies, assignees, and handoffs live on the board — not in `/goal`.
-- **The overlap is deliberate, and small.** A kanban card created with `--goal` runs the same Ralph-style continuation engine as `/goal` — but *inside that one card's worker session*. It borrows the engine, not the board. See [Goal-mode cards](./kanban#goal-mode-cards---goal).
-
-| You want | Reach for |
-|---|---|
-| Keep iterating on one task in this chat until it's done | `/goal <text>` |
-| Many independent tasks, with dependencies, handoffs, or multiple profiles | [Kanban](./kanban) — `hermes kanban create …` |
-| One card on the board that should keep iterating until its acceptance criteria are met | A kanban card with `--goal` |
-
-:::note
-If you want work on the board, put it there yourself (`hermes kanban create …`) — `/goal` won't do it for you. The reverse is also true: pausing, resuming, or clearing a goal in this chat never creates, claims, or moves a kanban card.
-:::
-
-## Quick start
-
-```
-/goal Fix every failing test in tests/hermes_cli/ and make sure scripts/run_tests.sh passes for that directory
-```
-
-What you'll see:
-
-1. **Goal accepted** — `⊙ Goal set (20-turn budget): <your goal>`
-2. **Turn 1 runs** — Hermes starts working as if you'd sent the goal as a normal message.
-3. **Judge runs** — after the turn, the judge model decides `done`, `continue`, or `blocked`.
-4. **Loop fires if needed** — if `continue`, you'll see `↻ Continuing toward goal (1/20): <judge's reason>` and Hermes takes the next step automatically.
-5. **Terminates** — eventually you see either `✓ Goal achieved: <reason>` or `⏸ Goal paused — N/20 turns used`.
-
-## Commands
-
-| Command | What it does |
-|---|---|
-| `/goal <text>` | Set (or replace) the standing goal. Kicks off the first turn immediately so you don't need to send a separate message. |
-| `/goal draft <text>` | Draft a structured completion contract from a plain-language objective, then set it. See [Completion contracts](#completion-contracts). |
-| `/goal show` | Print the active goal's completion contract. |
-| `/goal` or `/goal status` | Show the current goal, its status, and turns used. |
-| `/goal pause` | Stop the auto-continuation loop without clearing the goal. |
-| `/goal resume` | Resume the loop (resets the turn counter back to zero). |
-| `/goal clear` | Drop the goal entirely. |
-| `/goal wait <pid> [reason]` | Park the loop on a background process — it stops re-poking the agent every turn while the process runs, and auto-resumes when it exits. |
-| `/goal unwait` | Drop the wait barrier and resume the loop immediately. |
-| `/goal gate add <command>` | Add a **quality gate**: a shell command that must pass before the goal can be judged done. See [Quality gates](#quality-gates). |
-| `/goal gate` or `/goal gate list` | List the goal's gates and their pass/fail state. |
-| `/goal gate remove <N>` | Remove the Nth gate (1-based). |
-| `/goal gate clear` | Remove all gates. |
-
-The classic CLI, TUI, Desktop, dashboard chat, and messaging gateway use one shared `/goal` command handler. This includes draft/show, inline contracts, wait/unwait, quality gates, and the clear/stop/done aliases. Desktop goal controls use the same handler, too. ACP does not currently advertise or implement `/goal`.
-
-`/goal draft <text>` both creates the goal and starts its first turn, including when drafting is unavailable and Hermes falls back to a free-form goal. `draft` is a whole-word subcommand: `/goal drafting docs` keeps `drafting docs` as the literal objective without calling the draft model.
-
-Messaging platforms retain their access rules: `/goal gate add` requires an explicitly configured gateway admin; listing, removing, and clearing gates remain available for recovery. Rendering and turn scheduling are surface-specific, but command parsing and persisted goal changes are shared.
-
-## Completion contracts
-
-A bare `/goal <text>` works fine, but a *vague* goal makes for vague judging — the judge can only check what you told it to want. Codex's `/goal` guidance makes the same point: a durable objective works best when it names **what done means, how to prove it, what not to break, what's in scope, and when to stop**. Hermes adapts this as an optional **completion contract** layered on top of the existing goal loop.
-
-A contract has five fields, all optional:
-
-| Field | Meaning |
-|---|---|
-| `outcome` | The single end state that must be true when done. |
-| `verification` | The specific test / command / artifact that *proves* the outcome. |
-| `constraints` | What must not change or regress. |
-| `boundaries` | Which files, dirs, tools, or systems are in scope. |
-| `stop_when` | The condition under which Hermes should stop and ask for input. |
-
-When a contract is set, both prompts change: the **continuation prompt** tells the agent to target the verification surface and respect the constraints, and the **judge prompt** decides `done` *only when the verification criterion is met with concrete evidence* (a command result, file excerpt, test output) — not a loose "looks done" claim. This directly tightens the most common `/goal` failure mode (premature completion or endless over-continuation on an underspecified objective).
-
-### Two ways to set a contract
-
-**1. Let Hermes draft it** (recommended — adapted from Codex's "let the agent draft the goal" tip):
-
-```
-/goal draft Migrate the auth service from session cookies to JWT
-```
-
-Hermes expands your one-liner into a full contract via the `goal_judge` auxiliary model, sets it, and shows you the result so you can review or tighten any field. If the aux model is unavailable, it falls back to a plain free-form goal — drafting never blocks setting a goal.
-
-**2. Write it inline** with `field: value` lines:
-
-```
-/goal Migrate auth to JWT
-verify: pytest tests/auth passes
-constraints: keep the /login response shape unchanged
-boundaries: only touch services/auth and its tests
-stop when: a DB schema migration is required
-```
-
-The first non-field line(s) are the goal headline; recognized field prefixes (`verify:`, `verified by:`, `constraints:`, `preserve:`, `boundaries:`, `scope:`, `stop when:`, `blocked:`, …) populate the contract. A plain goal with an incidental colon (`Fix bug: the parser drops commas`) is **not** mangled — only known field prefixes are pulled out.
-
-Use `/goal show` to review the active contract. Contracts persist in `SessionDB.state_meta` alongside the goal, so they survive `/resume`. Old goals from before this feature load unchanged (no contract). Contracts and `/subgoal` criteria compose: subgoals fold into the contract as extra criteria the judge must also satisfy.
-
-## Adding criteria mid-goal: `/subgoal`
-
-While a goal is active you can append extra acceptance criteria with `/subgoal <text>` without resetting the loop. Each call adds one numbered item to the goal's subgoal list; the **continuation prompt** the agent sees on the next turn includes the original goal plus an "Additional criteria the user added mid-loop" block, and the **judge prompt** is rewritten so the verdict must consider every subgoal — the goal isn't marked done until the original objective **and** every subgoal are met.
-
-| Command | What it does |
-|---|---|
-| `/subgoal <text>` | Append a new criterion to the active goal. Requires an active `/goal`. |
-| `/subgoal` (no args) | Show the current numbered subgoal list. |
-| `/subgoal remove <N>` | Remove the Nth subgoal (1-based). |
-| `/subgoal clear` | Drop every subgoal but keep the original goal intact. |
-
-Subgoals are persisted alongside the goal in `SessionDB.state_meta`, so they survive `/resume`. Setting a new `/goal <text>` replaces the goal and clears the subgoal list; `/goal clear` does the same.
-
-Use this when you start a loop ("fix the failing tests") and notice partway through that you also want it to "and add a regression test for the bug you just patched" — `/subgoal add a regression test` tightens the success criteria without breaking the running loop.
-
-## Quality gates
-
-A completion contract makes the judge stricter, but the judge is still an LLM reading prose. A **quality gate** is stronger: a deterministic shell command that must exit 0 before the goal can complete at all. Inspired by Prime-Agent's bounded autonomous mode (`--autonomous-gate`).
-
-```
-/goal Fix the flaky session tests
-/goal gate add scripts/run_tests.sh tests/hermes_cli/test_goals.py
-```
-
-How it works, each turn:
-
-1. **Gates run before the judge.** If any gate fails, the judge is *not called* — a red gate is deterministic evidence the goal isn't done. The gate's exit code and output tail (last ~3 KB) become the continuation prompt, so the agent iterates against the actual failure instead of a vibe.
-2. **All gates pass → normal judging.** The LLM judge then decides done/blocked/continue/wait exactly as before.
-3. **Every boundary re-runs a failed gate.** The command executes against the current inputs each time; a stale result is never replayed, so a gate whose input you just repaired passes on the next boundary. The retry cap bounds a genuinely stuck red suite.
-4. **Retries are bounded.** Each gate defaults to 3 retries and a 5-minute timeout. When a gate exhausts its retries the goal auto-pauses (like the turn budget) with a message telling you to fix it manually, remove the gate, or `/goal resume`.
-
-Gates persist with the goal in `SessionDB.state_meta` (they survive `/resume` and context compression), and gate management (`/goal gate …`) is safe mid-run on the gateway — gates only run at turn boundary.
-
-Gates and contracts compose: use a contract to shape *what the agent aims for*, and gates to make *"done" mechanically checkable*. When both are set, gates run first.
-
-## Parking on a background process: automatic, with a manual override
-
-Some goals are gated on something that takes minutes and runs on its own — CI on a pushed PR, a long build, a test matrix, a deploy, a rate-limit cooldown. Without help, the goal loop would re-poke the agent every turn into "is it done yet?" busy-work while it waits.
-
-**This is handled automatically.** Every turn, the judge is shown the agent's own live background processes (the `terminal(background=true)` registry entries this session spawned — pid, session id, command, uptime, recent output, and any `watch_patterns` / `notify_on_complete` trigger; processes started by delegated subagents are not shown, so a fan-out parent is never parked on a worker's poller) alongside the goal and the agent's response. When the agent's progress is genuinely gated on one of them, the judge returns a **`wait`** verdict instead of `continue`, and the loop **parks**: the next turns are skipped (no judge call, no continuation, no turn consumed) until the wait is satisfied — then it resumes normally with the result in hand. A pid/session wait is capped at 30 minutes; a process that never exits (a watcher, a forgotten poller) cannot park the goal indefinitely. The judge can also park on a **time** basis (`wait_for_seconds`) for backoff/cooldown waits. `/goal status` shows `⏳ Goal (parked …)` while parked.
-
-The judge picks the right kind of wait from the process's own signal:
-
-- **`wait_on_session <id>`** — releases when the process's *own trigger* fires: it exits, **or** (if it was started with `watch_patterns`) its pattern matches. This is the one for a long-lived watcher / server / poller that signals **mid-run** (e.g. a build process that prints `BUILD SUCCESSFUL` and keeps running, or a `notify_on_complete` watcher) and may never exit on its own.
-- **`wait_on_pid <pid>`** — releases on process exit only.
-- **`wait_for_seconds <n>`** — releases after a fixed delay.
-
-You don't type anything for this — it's the judge's decision, made from the process context the loop hands it. The manual commands exist as an override:
-
-| Command | What it does |
-|---|---|
-| `/goal wait <pid> [reason]` | Manually park the loop until the process with that PID exits. The PID must be a live process on the Hermes host; a remote or already-exited PID is rejected (and a judge `wait_on_pid` naming one continues instead of parking). |
-| `/goal unwait` | Clear any wait barrier (judge- or manually-set) and resume immediately. |
-
-The barrier (pid- or time-based) is persisted with the goal in `SessionDB.state_meta`, so it survives `/resume`. `/goal pause`, `/goal resume`, and `/goal clear` all drop it. If the PID is already dead when the barrier is set (or dies while parked), or the time deadline passes, the barrier clears on the next check — a stale barrier can never wedge the loop.
-
-Typical flow: the agent pushes a PR, starts a CI watcher with `terminal(background=true, notify_on_complete=true)`, and reports "watching CI." The judge sees the watcher process still running, returns `wait` on its pid, and the loop goes quiet — then picks back up the instant CI finishes and judges the goal against the actual result.
-
-## Behavior details
-
-### The judge
-
-After every turn, Hermes calls an auxiliary model with:
-
-- The standing goal text
-- The agent's most recent final response (last ~4 KB of text)
-- A system prompt telling the judge to reply with strict one-line JSON: `{"verdict": "done" | "blocked" | "continue" | "wait", "reason": "<one-sentence rationale>"}` (wait verdicts add `wait_on_session` / `wait_on_pid` / `wait_for_seconds`; the legacy `{"done": <bool>, "reason": "..."}` shape is still accepted)
-
-The judge is deliberately conservative: it marks a goal `done` only when the response **explicitly** confirms the goal is complete, when the final deliverable is clearly produced. A goal the agent explains is **unachievable** (impossible, out of scope, needs user input) gets a `blocked` verdict instead — never `done`: the goal **pauses** with the judge's reason (`🚫 Goal judged unachievable — paused`), so you can re-scope it with `/goal <text>` or override with `/goal resume` rather than burning budget or having an impossible task waved through as complete.
-
-### Fail-open semantics
-
-If the judge errors (network blip, malformed response, unavailable aux client), Hermes treats the verdict as `continue` — a broken judge never wedges progress. The **turn budget** is the real backstop.
-
-### Turn budget
-
-Default is 20 continuation turns (`goals.max_turns` in `config.yaml`). When the budget is hit, Hermes auto-pauses and tells you exactly how to proceed:
-
-```
-⏸ Goal paused — 20/20 turns used. Use /goal resume to keep going, or /goal clear to stop.
-```
-
-`/goal resume` resets the counter to zero, so you can keep going in measured chunks.
-
-### User messages always preempt
-
-Any real message you send while a goal is active takes priority over the continuation loop. On the CLI your message lands in `_pending_input` ahead of the queued continuation; on the gateway it goes through the adapter FIFO the same way. The judge runs again after your turn — so if your message happens to complete the goal, the judge will catch it and stop.
-
-### Mid-run safety (gateway)
-
-While an agent is already running, `/goal status`, `/goal pause`, `/goal clear`, `/goal wait`, and `/goal unwait` are safe to run — they only touch control-plane state and don't interrupt the current turn. Setting a **new** goal mid-run (`/goal <new text>`) is rejected with a message telling you to `/stop` first, so the old continuation can't race the new one.
-
-### Persistence
-
-Goal state lives in `SessionDB.state_meta` keyed by `goal:<session_id>`. That means `/resume` picks up right where you left off — set a goal, close your laptop, come back tomorrow, `/resume`, and the goal is still standing exactly as you left it (active, paused, or done).
-
-### Prompt cache
-
-The continuation prompt is a plain user-role message appended to history. It does **not** mutate the system prompt, swap toolsets, or touch the conversation in any way that invalidates Hermes' prompt cache. Running a 20-turn goal costs the same cache-wise as 20 turns of normal conversation.
-
-## Configuration
-
-Add to `~/.hermes/config.yaml`:
-
-```yaml
-goals:
-  # Max continuation turns before Hermes auto-pauses and asks you to
-  # /goal resume. Default 20. Lower this if you want tighter loops;
-  # raise it for long-running refactors.
-  max_turns: 20
-```
-
-### Choosing the judge model
-
-The judge uses the `goal_judge` auxiliary task. By default it resolves to your main model (see [Auxiliary Models](/user-guide/configuration#auxiliary-models)). If you want to route the judge to a cheap fast model to keep costs down, add an override:
-
-```yaml
-auxiliary:
-  goal_judge:
-    provider: openrouter
-    model: google/gemini-3-flash-preview
-```
-
-The judge call is small (~200 output tokens) and runs once per turn, so a cheap fast model is usually the right call.
-
-## Example walkthrough
-
-```
-You: /goal Create four files /tmp/note_{1..4}.txt, one per turn, each containing its number as text
-
-  ⊙ Goal set (20-turn budget): Create four files /tmp/note_{1..4}.txt, one per turn, each containing its number as text
-
-Hermes: Creating /tmp/note_1.txt now.
-  💻 echo "1" > /tmp/note_1.txt   (0.1s)
-  I've created /tmp/note_1.txt with the content "1". I'll continue with the remaining files on the next turn as you specified.
-
-  ↻ Continuing toward goal (1/20): Only 1 of 4 files has been created; 3 files remain.
-
-Hermes: [Continuing toward your standing goal]
-  💻 echo "2" > /tmp/note_2.txt   (0.1s)
-  Created /tmp/note_2.txt. Two more to go.
-
-  ↻ Continuing toward goal (2/20): 2 of 4 files created; 2 remain.
-
-Hermes: [Continuing toward your standing goal]
-  💻 echo "3" > /tmp/note_3.txt   (0.1s)
-  Created /tmp/note_3.txt.
-
-  ↻ Continuing toward goal (3/20): 3 of 4 files created; 1 remains.
-
-Hermes: [Continuing toward your standing goal]
-  💻 echo "4" > /tmp/note_4.txt   (0.1s)
-  All four files have been created: /tmp/note_1.txt through /tmp/note_4.txt, each containing its number.
-
-  ✓ Goal achieved: All four files were created with the specified content, completing the goal.
-
-You: _
-```
-
-Four turns, one `/goal` invocation, zero "keep going" prompts from you.
-
-## When the judge gets it wrong
-
-No judge is perfect. Two failure modes to watch for:
-
-**False negative — judge says continue when the goal is actually done.** The turn budget catches this. You'll see `⏸ Goal paused` and can `/goal clear` or just send a new message.
-
-**False positive — judge says done when work remains.** You'll see `✓ Goal achieved` but you know better. Send a follow-up message to continue, or re-set the goal more precisely: `/goal <more specific text>`. The judge's system prompt is deliberately conservative to make false positives rarer than false negatives.
-
-If you find a judge verdict unconvincing, the reason text in the `↻ Continuing toward goal` or `✓ Goal achieved` line tells you exactly what the judge saw. That's usually enough to diagnose whether the goal text was ambiguous or the model's response was.
-
-## Attribution
-
-`/goal` is Hermes' take on the **Ralph loop** pattern. The user-facing design — keep a goal alive across turns, don't stop until it's achieved, with create/pause/resume/clear controls — was popularised and shipped in [Codex CLI 0.128.0](https://github.com/openai/codex) by Eric Traut on OpenAI's Codex team. Our implementation is independent (central `CommandDef` registry, `SessionDB.state_meta` persistence, auxiliary-client judge, adapter-FIFO continuation on the gateway side) but the idea is theirs. Credit where credit's due.

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/user-guide/features/heartbeat.md

@@ -1,68 +0,0 @@
----
-sidebar_position: 17
-title: "Session Heartbeats"
-description: "A recurring prompt that re-enters your current session whenever it's idle — /heartbeat every 10m Check the deployment."
----
-
-# Session Heartbeats (`/heartbeat`)
-
-`/heartbeat` gives the **current session** one recurring instruction. Whenever the session is idle and the interval has elapsed, the prompt fires as a normal user turn — same conversation, same context, same prompt cache.
-
-```
-/heartbeat every 10m Check the deployment and report meaningful changes
-```
-
-Inspired by Prime-Agent's `/heartbeat`. The Hermes adaptation keeps the strict message-flow invariants: the heartbeat is injected only between turns (never mid-run), as a plain user-role message.
-
-## Heartbeat vs cron: which one do I want?
-
-They look similar but serve different jobs:
-
-| | `/heartbeat` | [`hermes cron`](./cron) |
-|---|---|---|
-| Runs in | **This conversation** — full context, memory of the discussion | A fresh isolated session per tick |
-| Survives process restart | State survives (SessionDB); gateway watches resume automatically after restart | Yes — fully durable scheduler |
-| How many | One per session | Unlimited jobs |
-| Best for | "Keep an eye on X *in this thread* while we work" | Standing jobs, reports, watchdogs, deliveries |
-
-Rule of thumb: if the recurring prompt needs the conversation's context, use `/heartbeat`. If it's a self-contained job, use cron.
-
-## Commands
-
-| Command | What it does |
-|---|---|
-| `/heartbeat every <interval> <prompt>` | Set (or replace) the session's heartbeat. Intervals: `90s`, `10m`, `2h`, `1d` (minimum 60s). |
-| `/heartbeat` or `/heartbeat status` | Show the heartbeat, its interval, and time to next fire. |
-| `/heartbeat pause` | Stop firing without clearing. |
-| `/heartbeat resume` | Resume (re-anchors the timer — no instant stale fire). |
-| `/heartbeat clear` | Remove the heartbeat. |
-
-`/hb` is an alias. Works on the CLI, the TUI / Desktop app, and gateway platforms (on Slack, use `/hermes heartbeat …`).
-
-## Behavior details
-
-- **Idle-only.** A heartbeat never interrupts a running turn. If the agent is busy when the tick comes due, it fires at the next idle poll. In the gateway, an idle watched session wakes proactively; no new inbound message is needed.
-- **Missed ticks coalesce.** If the session was busy (or the process wasn't running) through several intervals, you get **one** heartbeat turn, not a backlog. The timer re-anchors on every fire.
-- **User messages win.** A queued user message always takes priority; the heartbeat waits for the input queue to drain.
-- **Owned by the surface that set it.** A heartbeat set from a messaging chat fires from the gateway and replies into that chat even while the same session is open in the TUI / Desktop app; the viewer never claims the tick.
-- **Cache-safe.** The injected prompt is an ordinary user message. No system-prompt mutation, no toolset change.
-- **Gateway recovery.** Startup restores active heartbeats using the current persisted conversation and thread routing, in the owning profile. Each poll retries recovery after temporary storage failures or adapter downtime; paused and cleared heartbeats and suspended conversations do not restart. No new chat message is required.
-- **Persistence and conversation boundaries.** State lives in `SessionDB.state_meta` keyed by `heartbeat:<session_id>` and follows context-compression session rotations. In the messaging gateway, leaving a conversation through reset, switch, or suspension clears its heartbeat; resuming that archived conversation does not resurrect it. Firing requires the owning process (CLI session or gateway) to be running. An already-admitted gateway tick is checked again after session resolution and before agent execution: it may follow a compression child, but cannot carry its old instruction into a reset or switched conversation.
-- **Execution accounting.** The gateway reserves a due tick at adapter admission. If that exact attempt ends before entering the agent runner (including cancellation or a routing, authorization, emergency-stop, or preparation rejection), it refunds the tick unless the schedule has since changed. Once the agent runner is entered, the fire remains counted even if execution fails or is interrupted. This count is **not** proof of a successful model response or outbound delivery; abrupt process death can prevent the refund callback.
-- **Don't-invent-work guard.** The injected prompt tells the agent to reply briefly and stop when nothing meaningful changed, so an idle heartbeat doesn't generate busywork.
-
-## Example
-
-```
-You: /heartbeat every 15m Check whether the CI run for PR #1234 finished; summarize the result when it does
-
-  ♥ Heartbeat set (every 15m): Check whether the CI run for PR #1234 finished; ...
-
-[15 minutes of you working on other things in the same session]
-
-Hermes: [Heartbeat — recurring instruction, fires every 15m]
-  💻 gh pr checks 1234   (1.2s)
-  CI is still running (14/37 checks complete). Nothing to report yet.
-```
-
-When the answer stops changing, `/heartbeat clear` it — or let it keep watch.

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/user-guide/features/honcho.md

@@ -1,276 +0,0 @@
----
-sidebar_position: 99
-title: "Honcho Memory"
-description: "AI-native persistent memory via Honcho — dialectic reasoning, multi-agent user modeling, and deep personalization"
----
-
-# Honcho Memory
-
-[Honcho](https://github.com/plastic-labs/honcho) is an AI-native memory backend that adds dialectic reasoning and deep user modeling on top of Hermes's built-in memory system. Instead of simple key-value storage, Honcho maintains a running model of who the user is — their preferences, communication style, goals, and patterns — by reasoning about conversations after they happen.
-
-:::info Honcho is a Memory Provider Plugin
-Honcho is integrated into the [Memory Providers](./memory-providers.md) system. All features below are available through the unified memory provider interface.
-:::
-
-## What Honcho Adds
-
-| Capability | Built-in Memory | Honcho |
-|-----------|----------------|--------|
-| Cross-session persistence | ✔ File-based MEMORY.md/USER.md | ✔ Server-side with API |
-| User profile | ✔ Manual agent curation | ✔ Automatic dialectic reasoning |
-| Session summary | — | ✔ Session-scoped context injection |
-| Multi-agent isolation | — | ✔ Per-peer profile separation |
-| Observation modes | — | ✔ Unified or directional observation |
-| Conclusions (derived insights) | — | ✔ Server-side reasoning about patterns |
-| Search across history | ✔ FTS5 session search | ✔ Semantic search over conclusions |
-
-**Dialectic reasoning**: After each conversation turn (gated by `dialecticCadence`), Honcho analyzes the exchange and derives insights about the user's preferences, habits, and goals. These accumulate over time, giving the agent a deepening understanding that goes beyond what the user explicitly stated. The dialectic supports multi-pass depth (1–3 passes) with automatic cold/warm prompt selection — cold start queries focus on general user facts while warm queries prioritize session-scoped context.
-
-**Session-scoped context**: Base context now includes the session summary alongside the user representation and peer card. This gives the agent awareness of what has already been discussed in the current session, reducing repetition and enabling continuity.
-
-**Multi-agent profiles**: When multiple Hermes instances talk to the same user (e.g., a coding assistant and a personal assistant), Honcho maintains separate "peer" profiles. Each peer sees only its own observations and conclusions, preventing cross-contamination of context.
-
-## Setup
-
-```bash
-hermes memory setup    # select "honcho" from the provider list
-```
-
-Or configure manually:
-
-```yaml
-# ~/.hermes/config.yaml
-memory:
-  provider: honcho
-```
-
-```bash
-echo 'HONCHO_API_KEY=***' >> ~/.hermes/.env
-```
-
-Get an API key at [honcho.dev](https://honcho.dev).
-
-## Architecture
-
-### Two-Layer Context Injection
-
-Every turn (in `hybrid` or `context` mode), Honcho assembles two layers of context injected into the system prompt:
-
-1. **Base context** — session summary, user representation, user peer card, AI self-representation, and AI identity card. Refreshed on `contextCadence`. This is the "who is this user" layer.
-2. **Dialectic supplement** — LLM-synthesized reasoning about the user's current state and needs. Refreshed on `dialecticCadence`. This is the "what matters right now" layer.
-
-Both layers are concatenated and truncated to the `contextTokens` budget (if set).
-
-### Cold/Warm Prompt Selection
-
-The dialectic automatically selects between two prompt strategies:
-
-- **Cold start** (no base context yet): General query — "Who is this person? What are their preferences, goals, and working style?"
-- **Warm session** (base context exists): Session-scoped query — "Given what's been discussed in this session so far, what context about this user is most relevant?"
-
-This happens automatically based on whether base context has been populated.
-
-### Three Orthogonal Config Knobs
-
-Cost and depth are controlled by three independent knobs:
-
-| Knob | Controls | Default |
-|------|----------|---------|
-| `contextCadence` | Turns between `context()` API calls (base layer refresh) | `1` |
-| `dialecticCadence` | Turns between `peer.chat()` LLM calls (dialectic layer refresh) | `2` (recommended 1–5) |
-| `dialecticDepth` | Number of `.chat()` passes per dialectic invocation (1–3) | `1` |
-
-These are orthogonal — you can have frequent context refreshes with infrequent dialectic, or deep multi-pass dialectic at low frequency. Example: `contextCadence: 1, dialecticCadence: 5, dialecticDepth: 2` refreshes base context every turn, runs dialectic every 5 turns, and each dialectic run makes 2 passes.
-
-### Dialectic Depth (Multi-Pass)
-
-When `dialecticDepth` > 1, each dialectic invocation runs multiple `.chat()` passes:
-
-- **Pass 0**: Cold or warm prompt (see above)
-- **Pass 1**: Self-audit — identifies gaps in the initial assessment and synthesizes evidence from recent sessions
-- **Pass 2**: Reconciliation — checks for contradictions between prior passes and produces a final synthesis
-
-Each pass uses a proportional reasoning level (lighter early passes, base level for the main pass). Override per-pass levels with `dialecticDepthLevels` — e.g., `["minimal", "medium", "high"]` for a depth-3 run.
-
-Passes bail out early if the prior pass returned strong signal (long, structured output), so depth 3 doesn't always mean 3 LLM calls.
-
-### Session-Start Prewarm
-
-On session init, Honcho fires a dialectic call in the background at the full configured `dialecticDepth` and hands the result directly to turn 1's context assembly. A single-pass prewarm on a cold peer often returns thin output — multi-pass depth runs the audit/reconcile cycle before the user ever speaks. If prewarm hasn't landed by turn 1, turn 1 falls back to a synchronous call with a bounded timeout.
-
-### Query-Adaptive Reasoning Level
-
-The auto-injected dialectic scales `dialecticReasoningLevel` by query length: +1 level at ≥120 chars, +2 at ≥400, clamped at `reasoningLevelCap` (default `"high"`). Disable with `reasoningHeuristic: false` to pin every auto call to `dialecticReasoningLevel`. Available levels: `minimal`, `low`, `medium`, `high`, `max`.
-
-## Configuration Options
-
-Honcho is configured in `~/.honcho/config.json` (global) or `$HERMES_HOME/honcho.json` (profile-local). The setup wizard handles this for you.
-
-### Self-Hosted Honcho with Authentication
-
-When pointing Hermes at a self-hosted Honcho server, `hermes honcho setup` (and `hermes memory setup`) ask for a **local JWT / bearer token** after the base URL. Paste a JWT signed with the server's `AUTH_JWT_SECRET` (the Honcho compose env var) to enable authenticated access; leave it blank for servers running with `AUTH_USE_AUTH=false`. The local token is stored under the host block (`hosts.<host>.apiKey` in `honcho.json`), separate from any cloud `apiKey`, so you can flip the `Cloud or local?` prompt back to `cloud` later without losing either credential.
-
-### Full Config Reference
-
-| Key | Default | Description |
-|-----|---------|-------------|
-| `contextTokens` | `null` (uncapped) | Token budget for auto-injected context per turn. Set to an integer (e.g. 1200) to cap. Truncates at word boundaries |
-| `contextCadence` | `1` | Minimum turns between `context()` API calls (base layer refresh) |
-| `dialecticCadence` | `2` | Minimum turns between `peer.chat()` LLM calls (dialectic layer). Recommended 1–5. In `tools` mode, irrelevant — model calls explicitly |
-| `dialecticDepth` | `1` | Number of `.chat()` passes per dialectic invocation. Clamped to 1–3 |
-| `dialecticDepthLevels` | `null` | Optional array of reasoning levels per pass, e.g. `["minimal", "low", "medium"]`. Overrides proportional defaults |
-| `dialecticReasoningLevel` | `'low'` | Base reasoning level: `minimal`, `low`, `medium`, `high`, `max` |
-| `dialecticDynamic` | `true` | When `true`, model can override reasoning level per-call via tool param |
-| `dialecticMaxChars` | `600` | Max chars of dialectic result injected into system prompt |
-| `recallMode` | `'hybrid'` | `hybrid` (auto-inject + tools), `context` (inject only), `tools` (tools only) |
-| `writeFrequency` | `'async'` | When to flush messages: `async` (background thread), `turn` (sync), `session` (batch on end), or integer N |
-| `saveMessages` | `true` | Whether to persist messages to Honcho API |
-| `observationMode` | `'directional'` | `directional` (all on) or `unified` (shared pool). Override with `observation` object for granular control |
-| `messageMaxChars` | `25000` | Max chars per message sent via `add_messages()`. Chunked if exceeded |
-| `dialecticMaxInputChars` | `10000` | Max chars for dialectic query input to `peer.chat()` |
-| `sessionStrategy` | `'per-directory'` | `per-directory`, `per-repo`, `per-session`, or `global` |
-| `pinUserPeer` | `false` | Gateway only. When `true`, every platform user collapses to `peerName` |
-| `userPeerAliases` | `{}` | Gateway only. Map of runtime IDs to peers (`{"7654321": "alice"}`). Many-to-one |
-| `runtimePeerPrefix` | `""` | Gateway only. Namespaces unknown runtime IDs (`telegram_7654321`) when no alias matches |
-| `a2aSessions` | `true` | Write DMs from other bots into their own Honcho session per sender bot, never the human's. `false` skips bot-authored turns entirely |
-
-**Session strategy** controls how Honcho sessions map to your work:
-- `per-session` — each `hermes` run gets a fresh session. Clean starts, memory via tools. Recommended for new users.
-- `per-directory` — one Honcho session per working directory. Context accumulates across runs.
-- `per-repo` — one session per git repository.
-- `global` — single session across all directories.
-
-Directory-based strategies and manual `sessions` mappings use the logical session working directory, not the backend's launch directory. Desktop/TUI project workspaces and ACP session directories are passed during agent construction, including deferred builds. When no directory is supplied, Honcho uses the runtime cwd resolver: session context, then the scoped `terminal.cwd` setting, then the process launch directory.
-
-Messaging gateways keep their stable per-chat session key regardless of strategy or title. For other sessions, `per-session` identity takes priority, followed by a manual directory mapping, an explicit title, and the configured strategy.
-
-Automatically generated Hermes titles (`derived` or `llm`), including lineage titles for Desktop branches, are display metadata and do not override `sessionStrategy`. An explicit user title remains an intentional session-name override for non-gateway, non-`per-session` sessions without a manual mapping.
-
-Sessions created before title provenance was recorded retain legacy behavior: because an old automatic title cannot be distinguished from an old user title, a title with no source is treated as an explicit override.
-
-**Recall mode** controls how memory flows into conversations:
-- `hybrid` — context auto-injected into system prompt AND tools available (model decides when to query).
-- `context` — auto-injection only, tools hidden.
-- `tools` — tools only, no auto-injection. Agent must explicitly call `honcho_reasoning`, `honcho_search`, etc.
-
-**Settings per recall mode:**
-
-| Setting | `hybrid` | `context` | `tools` |
-|---------|----------|-----------|---------|
-| `writeFrequency` | flushes messages | flushes messages | flushes messages |
-| `contextCadence` | gates base context refresh | gates base context refresh | irrelevant — no injection |
-| `dialecticCadence` | gates auto LLM calls | gates auto LLM calls | irrelevant — model calls explicitly |
-| `dialecticDepth` | multi-pass per invocation | multi-pass per invocation | irrelevant — model calls explicitly |
-| `contextTokens` | caps injection | caps injection | irrelevant — no injection |
-| `dialecticDynamic` | gates model override | N/A (no tools) | gates model override |
-
-In `tools` mode, the model is fully in control — it calls `honcho_reasoning` when it wants, at whatever `reasoning_level` it picks. Cadence and budget settings only apply to modes with auto-injection (`hybrid` and `context`).
-
-## Gateway Identity Mapping
-
-These settings only matter when you run the [Hermes gateway](../../developer-guide/gateway-internals.md) — the one entrypoint where users arrive with platform-native runtime IDs (Telegram UID, Discord snowflake, Slack user). CLI, TUI, and desktop sessions have no runtime ID and always resolve to `peerName`, so off-gateway these keys do nothing.
-
-The setup wizard detects whether a gateway platform is connected and skips this step entirely if not. When it runs, it asks one question — *who talks to this gateway?* — and derives the keys:
-
-| Answer | Result |
-|--------|--------|
-| **just me** | `pinUserPeer: true` — every non-agent gateway user collapses to your peer. Pin overrides all aliases, so pick this only when no user-side identity needs its own peer. If separate agents reach the gateway and each needs a distinct peer, do **not** pin — leave `pinUserPeer: false` and map them via `userPeerAliases` (the `[e]` editor) instead |
-| **me + other people** (pooled) | `pinUserPeer: false` + `userPeerAliases` mapping your runtime IDs to `peerName` — you stay on your shared history, others get their own peers |
-| **only other people** | `pinUserPeer: false`, optional `runtimePeerPrefix` — each user gets their own peer |
-
-Pick `[e]` at the prompt to set the three keys directly instead.
-
-The resolver tries the keys top-down, first match wins: `pinUserPeer` → `userPeerAliases[id]` → `runtimePeerPrefix + id` → raw runtime ID → `peerName` → session-key fallback.
-
-Each turn is written under the peer of whoever wrote it, so in a shared chat the first person to message no longer collects everyone else's facts. A turn from another bot (a Bot Mode DM tagged `bot:<profile>`, or a platform account the adapter flags as a bot) always gets its own peer: `pinUserPeer` unifies one person's accounts, never a bot. Its turn lands in a per-sender `a2a` session (see `a2aSessions`), and `honcho_conclude` / `honcho_profile` refuse writes while such a turn runs, since conclusions and cards describe the human.
-
-:::warning Un-pinning orphans pooled memory
-Flipping `pinUserPeer` from `true` to `false` does not migrate data — memory accumulated under `peerName` stays there, and platform users resolve to fresh, empty peers. To keep your own continuity, choose the **pooled** path so your runtime IDs alias back to `peerName`. The wizard offers this steer automatically when it detects the transition.
-:::
-
-:::note Deprecated key
-`pinPeerName` is a legacy alias for `pinUserPeer` — still read for back-compat (`pinUserPeer` wins where both are set), never written. Re-running setup migrates it onto the canonical key.
-:::
-
-## Observation (Directional vs. Unified)
-
-Honcho models a conversation as peers exchanging messages. Each peer has two observation toggles that map 1:1 to Honcho's `SessionPeerConfig`:
-
-| Toggle | Effect |
-|--------|--------|
-| `observeMe` | Honcho builds a representation of this peer from its own messages |
-| `observeOthers` | This peer observes the other peer's messages (feeds cross-peer reasoning) |
-
-Two peers × two toggles = four flags. `observationMode` is a shorthand preset:
-
-| Preset | User flags | AI flags | Semantics |
-|--------|-----------|----------|-----------|
-| `"directional"` (default) | me: on, others: on | me: on, others: on | Full mutual observation. Enables cross-peer dialectic — "what does the AI know about the user, based on what the user said and the AI replied." |
-| `"unified"` | me: on, others: off | me: off, others: on | Shared-pool semantics — the AI observes the user's messages only, the user peer only self-models. Single-observer pool. |
-
-Override the preset with an explicit `observation` block for per-peer control:
-
-```json
-"observation": {
-  "user": { "observeMe": true,  "observeOthers": true },
-  "ai":   { "observeMe": true,  "observeOthers": false }
-}
-```
-
-Common patterns:
-
-| Intent | Config |
-|--------|--------|
-| Full observation (most users) | `"observationMode": "directional"` |
-| AI shouldn't re-model the user from its own replies | `"ai": {"observeMe": true, "observeOthers": false}` |
-| Strong persona the AI peer shouldn't update from self-observation | `"ai": {"observeMe": false, "observeOthers": true}` |
-
-Server-side toggles set via the [Honcho dashboard](https://app.honcho.dev) win over local defaults — Hermes syncs them back at session init.
-
-## Tools
-
-When Honcho is active as the memory provider, five tools become available:
-
-| Tool | Purpose |
-|------|---------|
-| `honcho_profile` | Read or update peer card — pass `card` (list of facts) to update, omit to read |
-| `honcho_search` | Semantic search over context — raw excerpts, no LLM synthesis |
-| `honcho_context` | Full session context — summary, representation, card, recent messages |
-| `honcho_reasoning` | Synthesized answer from Honcho's LLM — pass `reasoning_level` (minimal/low/medium/high/max) to control depth |
-| `honcho_conclude` | Create or delete conclusions — pass `conclusion` to create, `delete_id` to remove (PII only) |
-
-## CLI Commands
-
-The `hermes honcho` subcommand is **only registered when Honcho is the active memory provider** (`memory.provider: honcho` in `config.yaml`). On a fresh install, configure Honcho directly with `hermes memory setup honcho` (or run `hermes memory setup` and pick it from the list); the `hermes honcho` subcommand then appears on the next invocation.
-
-```bash
-hermes memory setup honcho    # Configure Honcho directly (works before activation)
-hermes honcho status          # Connection status, config, and key settings
-hermes honcho setup           # Redirects to `hermes memory setup` (post-activation alias)
-hermes honcho strategy        # Show or set session strategy (per-session/per-directory/per-repo/global)
-hermes honcho peer            # Show or update peer names + dialectic reasoning level
-hermes honcho mode            # Show or set recall mode (hybrid/context/tools)
-hermes honcho tokens          # Show or set token budget for context and dialectic
-hermes honcho identity        # Seed or show the AI peer's Honcho identity
-hermes honcho sync            # Sync Honcho config to all existing profiles
-hermes honcho peers           # Show peer identities across all profiles
-hermes honcho sessions        # List known Honcho session mappings
-hermes honcho map             # Map current directory to a Honcho session name
-hermes honcho enable          # Enable Honcho for the active profile
-hermes honcho disable         # Disable Honcho for the active profile
-hermes honcho migrate         # Step-by-step migration guide from openclaw-honcho
-```
-
-## Migrating from `hermes honcho`
-
-If you previously used the standalone `hermes honcho setup`:
-
-1. Your existing configuration (`honcho.json` or `~/.honcho/config.json`) is preserved
-2. Your server-side data (memories, conclusions, user profiles) is intact
-3. Set `memory.provider: honcho` in config.yaml to reactivate
-
-No re-login or re-setup needed. Run `hermes memory setup` and select "honcho" — the wizard detects your existing config.
-
-## Full Documentation
-
-See [Memory Providers — Honcho](./memory-providers.md#honcho) for the complete reference.