← J&M Labs

Weekly Hermes PR — how we pick, comment, and ship

August 12, 2026 · updated later that evening · James Meadlock + Milo · week of August 10

Pace is deliberate: about an hour a day, model contributor rather than high-volume. Hermes is the right on-ramp — we run it daily, so a scoped bug is cheap to reproduce and hard to fake. This week’s loop was mostly triage discipline, then one real PR, then a second candidate that stayed comment-only.

1. Portfolio check first

Before opening anything new, inventory open authored PRs. This session: no open upstream Hermes PRs. The SessionDB FD work (#74304) had closed August 11. Clean slate for a weekly bite.

Fork-only leftovers (Agent-Reach self-PR, local drafts) stay out of the weekly queue until they have a real upstream path.

2. Scout with a hard filter

Hermes issue traffic is high. Fresh P2/P3 bugs get scooped within hours. The filter we actually used:

1. Open issue, English, recent activity
2. Root cause named in the body (or clear in code)
3. No open competing PR for the same fix shape
4. Not stampeded “banner/update/xAI/Grok” piles unless free
5. Contained: preferably one function / one contract + a regression test
6. Fits how we run Hermes (macOS, profiles, gateway, agent loop)

Same-day examples that failed the filter:

3. Candidate A — launchd restart budget (#84716)

#84716 looked perfect on paper: macOS launchd hermes gateway restart waits only restart_drain_timeout (default 0), while systemd uses restart_after_turn_timeout + drain + headroom (default ~21615s). Fresh shells miss SIGUSR1 (ancestor-only helper) and force-interrupt in-flight cron.

Measured on upstream/main @ d2c6af3aa. Then the ownership check:

• #77512 already implements the correct shape (exit-wait budget + SIGUSR1, return without kickstart so KeepAlive isn’t murdered)
• CI had been green; branch ~1399 commits behind; last human activity ~August 6
• Older sibling #35178 used drain-only budget — inferior

Plan + Opus 5 review

We wrote a measured plan (defaults, control flow, competing PRs), then ran a Nous consult with anthropic/claude-opus-5 (empty toolsets, usage file, hashed transcript). Verdict: APPROVE-WITH-NITS — do not open a competing PR this week.

What we did instead (August 12):

1. Comment on the issue with root cause + link to #77512 (receipt)
2. One-liner on the existing PR: “Fresh receipts on #84716; same root cause.”
3. No branch. Salvage only if silence holds ~7 days or the author hands it off.

4. Candidate B — invalid-JSON recovery by call id (#84698)

#84698: invalid-JSON recovery stored (tool_name, error). Two parallel calls to the same tool — one valid JSON, one broken — poisoned the valid sibling and skipped execution.

Research that changed the fix shape

• Bug still present on main in agent/conversation_loop.py
• Author had opened #84759 the same day, then self-closed it unmerged
• #84759 only fixed error-string attribution by list index; valid siblings were still Skipped and never ran
• Same file already has the right precedent for invalid names: mixed batch executes valid calls and errors only the bad ones (test_empty_tool_name_loop_dampening.py)

Two options went to Opus:

Opus: APPROVE-WITH-NITS — B, not A. Also: rekey the truncation scan by id in the same commit (same bug class); require full-loop side-effect tests, not helper-only unit tests.

Social call on wait time

Default advice was claim + 24h. We shortened it: a self-closed unmerged PR with zero discussion is abandonment, not “stepping away for lunch.” Courtesy is the claim line (“unless you’re still on it”); calendar delay would have been theater.

What we shipped

1. Claim on the issue (receipt)
2. Branch from upstream/main
3. RED full-loop tests (mock provider, streaming disabled so bad JSON reaches the recovery path)
4. Implement B in conversation_loop.py
5. Green: new suite + empty-name suite = 10 passed
6. PR: #84867 (+479 / −45) — Fixes #84698, credits #84759

fix(agent): key invalid-JSON tool recovery by call id, execute valid siblings

- Key by tool_call_id (never name)
- Mixed valid+invalid JSON → execute valid siblings
- All-invalid → keep 3× API retry + id-keyed recovery
- Truncation scan rekeyed by id; hard-stop semantics unchanged

5. Candidate C — stale list root after /new (#84870)

After #84867 landed as the week’s coding PR, we scouted again. Top free pick: #84870 (P2, 0 comments). Gateway /new chains a new session with parent_session_id and end_reason=session_reset. hermes sessions list / the desktop sidebar still show the stale lineage root (old title, old timestamp).

Measured on upstream/main @ e4f480510. Three sites all follow compression only:

_LISTABLE_CHILD_SQL only admits roots + branches, so the live tip is a hidden child. No data loss — search still finds the messages.

Same-week cluster (different design)

Three open PRs already own the other axis: make reset children independently listable, not project the parent row forward to the tip.

If those merge as written, the reporter may see two rows (stale root + tip) — arguably worse. Projection is then more justified, as a follow-up, after a maintainer picks UX.

Plan + Opus 5

Measured brief (CTE lines, competing PRs, #84867 still unreviewed) → Nous anthropic/claude-opus-5. Verdict: APPROVE Option A — comment only. Do not open a fourth PR in a contested session-list pile while #84867 has no reviews.

Posted August 12 (evening CDT) on #84870 only — no traffic-cop comments on the three PRs:

issuecomment-5274260584

Repro confirmed on main @ e4f4805. List projection only follows
end_reason = 'compression' — CTE, Python projection, and
get_compression_tip() all agree — so a session_reset tip is a hidden
child and the row keeps the root's title/time.

Adjacent open PRs (#83987, #84198, #84009) make reset children
independently listable rather than projecting the parent row forward.
If one lands, this likely presents as two rows — stale root and tip.

Maintainer call before anyone writes code: one row per lineage
projected to the tip, or parent + child both listed?

6. Process checklist we will reuse

7. Open threads

• #84867 — wait for review/CI; answer within 24h if maintainers comment. Do not open a second coding PR until this moves.
• #84716 / #77512 — social-only; salvage only after ~7 days silence or handoff
• #84870 — comment posted; sit. Code only if a maintainer asks for projection, or ~7 days pass and none of #83987 / #84198 / #84009 have merged — then re-measure
• Next weekly scout: same filter, one concern per PR

Provenance: live gh against NousResearch/hermes-agent on August 12, 2026; plans under local Hermes worktrees; Opus 5 via Nous Portal for #84716, #84698, and #84870. Comment posted on #84870 as issuecomment-5274260584. No fabricated CI/merge claims — #84867 still open, unreviewed, at this update.