// the find
EduardoManduca/Hermas
A safety-oriented runtime for executing verified, typed action graphs with explicit delivery uncertainty and crash recovery.
Hermas is a local, single-host runtime that executes graphs of independent app Actions, with inputs and outputs checked against typed HSchema contracts before anything runs. It is aimed at people who want a small, auditable workflow engine on one Linux machine and care more about what happens after a crash than about throughput. At 0.1.0-alpha.1 with three stars, it is an early experiment, not something to build a production pipeline on yet.
- The delivery model is the strongest part. A send lost before it completes is NotSent, a send lost after it may have reached the app is Unknown, and Unknown work is never replayed automatically. Most workflow engines hide this behind at-least-once retries and push idempotency onto the app. Here the uncertainty is a first-class state in the durable history.
- Validation happens before execution. 'hermas workflow plan' reports dependency-derived readiness stages and saga recovery order without producing an image, and '--json' exposes graph-local Type IDs and per-Action contracts for tooling. The README says reordering schema files does not change identity, and the bounded-order-total test exercises that.
- Resource limits are fixed up front. Arenas cap active group executions, item count, concurrency, and payload storage before a run starts, so an oversized graph fails at validation rather than partway through. CI runs GCC and Clang under ASan and UBSan, plus fuzz smoke tests on the decoders, which is the right amount of effort for hand-written C.
- Writing a safety-oriented runtime in C means the guarantees rest on sanitizers, fuzzing, and reviewer discipline rather than on the language. The Rust compiler gets the type-system help, but the daemon, journal, and C ABI carry the delivery claims and have the least language-level protection. Contributors will need to be careful, and the bar for review is high.
- Recovery hands work back to a human. Unknown deliveries are never replayed and forward execution closes after a restart, but the README does not explain how an operator resolves an Unknown delivery or confirms whether the app acted. Anyone adopting this inherits that step with no procedure in the entry-point docs.
- The documentation load is far out of proportion to the adoption. There is a master plan, a philosophy doc, a feature-admission guide, a roadmap, and versioned specs such as history JSON v1 and v2 and the graph image format. That is a lot of process to read before running the quickstart, and it reads more like a design project than a tool people are using. Three stars and zero forks suggests few outside users have tested it yet.