Quick CI note on this draft follow-up:

• I checked the red checks after opening it.
• build-and-push is failing in the Dockerfile/npm layer with spawn git ENOENT; that same Docker workflow is already red on recent upstream main runs.
• The repo-wide test workflow is also already red on current main; I reproduced the baseline locally from a clean origin/main worktree before blaming this branch.
• The focused H007 validation relevant to this follow-up is green locally: 434 passed, 1 warning for the receipt/direct-lane + work-order queue slice listed in the PR body.

So the current red CI does not appear to be introduced by this H007 follow-up itself.

Refresh — April 14 2026

Branch restructured and rebased onto current origin/main. Conflicts with upstream resolved.

What changed in this refresh

The original branch had two commits stacked: an older version of execution_receipts (pre-#9209) plus the durable_work_orders feature. This refresh:

1. Rebuilt the branch on top of origin/main with the clean execution receipts from PR feat: add execution receipts — auditable records of delegated task execution #9209 (b101301e)
2. Cherry-picked only the durable_work_orders commit (feat: add durable execution work orders)
3. Resolved 5 cherry-pick conflicts (hermes_cli/commands.py, hermes_cli/main.py, hermes_cli/tools_config.py, model_tools.py, toolsets.py) — all caused by the older receipts baseline
4. Added attribution housekeeping commit (chore: add MestreY0d4-Uninter to AUTHOR_MAP and .mailmap)

Test results

Commit log

85857d55 feat: add durable execution work orders
9d9f8ed0 chore: add MestreY0d4-Uninter to AUTHOR_MAP and .mailmap
b101301e feat: execution receipts with auto-instrumentation

Dependency note

This PR builds on top of PR #9209 (execution receipts). The branch currently includes the #9209 commits inline; if #9209 merges first, this branch can be trimmed to just the durable_work_orders commit on top of the updated origin/main.

CI notes

• No merge conflicts with current origin/main
• check-attribution — fixed via housekeeping commit
• test job — pending new CI run (previous failure was upstream acp module collection error, not caused by this PR)

Stacking note

This PR depends on #9209 (execution receipts). The current branch includes the #9209 commits inline so it is reviewable and testable in isolation, but the intended merge order is:

1. Merge feat: add execution receipts — auditable records of delegated task execution #9209 first
2. Rebase this branch onto the updated origin/main (drops the inline receipts commits, leaving only the feat: add durable execution work orders commit)
3. Merge this PR

If you prefer to review both together before any merge, no action is needed — the branch is self-contained as-is.

Refresh concluído em branch limpa a partir de origin/main. Cherry-pick aplicado e push forçado para h007-durable-work-orders. Validação: py_compile nos .py alterados e pytest -o addopts='' -q nos testes afetados (13 passed).

⚠️ Audit follow-up (2026-04-19)

There is substantial real work here and the PR body includes strong local evidence:

• durable JSON + SQLite work-order ledger
• queue/run_due/retry/resume/cancel/reclaim_stale operations
• CLI + slash-command surfaces
• 434 passing tests reported locally

So this is not a “throwaway” PR. However, it is still not merge-ready as packaged today.

Main reasons:

1. this is the largest PR in the backlog (very high review cost)
2. it is explicitly part of the same H007 line as feat: add execution receipts and direct terminal work-order lane #8402, and that base PR is closed/unmerged, so the acceptance path for this control-plane layer is still socially/architecturally unresolved
3. CI is currently red, including check-attribution
4. even if the direction is good, this likely needs either a clearer accepted base or smaller reviewable slices

Recommendation: KEEP OPEN, but treat it as blocked on packaging + dependency/acceptance decisions.

Suggested next step:

• first resolve whether the execution-receipts / direct-lane substrate (now represented in the newer line, e.g. feat: add execution receipts — auditable records of delegated task execution #9209) is actually desired upstream
• if yes, repackage this PR into smaller reviewable slices on top of the accepted base
• clean up attribution/CI issues before re-requesting review

So: likely still relevant, but currently too large and too dependent on unresolved base decisions to push for merge as-is.

Batch 4 — technical follow-up required

Fechando para Reavaliação Arquitetural

Como parte de uma auditoria completa do backlog (23 PRs abertas auditadas), esta PR foi identificada como dependente de clareza arquitetural upstream.

Contexto:
Esta PR implementa work orders duráveis (JSON + SQLite ledger) como parte da linha H007, que por sua vez depende conceitualmente da PR #8402 (execution receipts + direct terminal work-order lane) — que está fechada sem merge.

Motivo do fechamento:

• A arquitetura de execução durável no Hermes ainda não tem consenso upstream
• A linha H007 (feat: add execution receipts and direct terminal work-order lane #8402 + feat: add durable execution work orders #8403) representa uma mudança significativa no modelo de execução
• Manter esta PR aberta sem clareza arquitetural gera ruído no backlog

O que acontece agora:

• O código está disponível na branch original:
• Se houver interesse futuro em execution receipts + work orders duráveis, esta PR pode ser reaberta ou recriada com base em nova arquitetura aceita
• O trabalho não está perdido — apenas arquivado até haver clareza sobre a direção desejada

Agradecimento:
Obrigado pela revisão e feedback até aqui. Reabrirei quando houver consenso sobre a arquitetura de execução durável no Hermes.

Fechado como parte do audit de backlog 2026-04-19: 21 PRs refreshadas, 4 fechadas (2 absorvidas, 2 reavaliadas)