nesquena-hermes
84baa27004
* Refine live-to-final long-running session RFC * Mark RFC accepted, decouple from live PR status, normalize terminal state names Three follow-up adjustments to the refined live-to-final RFC: - Status: Proposed -> Accepted, since the doc is now referenced as the parent contract for follow-up slices; live implementation status stays in #3400. - Keep volatile PR/merge state out of the RFC body. The Public Inventory and Delivery map now state that their classification/vehicle columns record durable scope, and that #3400 is authoritative for open/merged/superseded status. Dropped the point-in-time "has shipped through release" / "remains an active PR" assertions that would drift as PRs land. - Normalize terminal-state naming: use the backticked snake_case identifiers (`cancelled`, `compression_exhausted`, `tool_limit_reached`, `no_response`, `interrupted`, `error`) consistently in prose, and add a note that these name product states, not a wire/enum or persisted schema contract (consistent with Scope, which does not own a backend schema change). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Add artifact handoff scope to live-to-final RFC * Add live-to-final lifecycle flowchart to RFC --------- Co-authored-by: Frank Song <franksong2702@gmail.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
RFCs
This directory holds design documents for hermes-webui features that are worth thinking through in writing before (or alongside) implementation — typically when the change touches durability, recovery, schema, or cross- cutting infrastructure.
Conventions
-
One file per RFC. Filename is the topic (kebab-case), not a number.
-
Top of every RFC carries a small header:
- **Status:** Proposed | Accepted | Implemented | Withdrawn - **Author:** @github-handle - **Created:** YYYY-MM-DD -
Sections usually include: Problem, Goals, Non-goals, Proposal, Open questions, Rollout plan. Skip what doesn't apply.
-
An RFC is a starting point for review. Comments and revisions land via PR edits, not separate discussion threads.
-
An RFC documents a design direction. It is not an invitation to file implementation PRs against fragments of it. Before opening any PR that implements an accepted RFC, confirm with a maintainer in the tracking issue that the implementation slice is wanted and that no other contributor is already building it. Speculative implementations of RFC fragments without a confirmed integration site will be held.
When to file an RFC
- The change is large enough that you want consensus before writing code.
- The change touches data-at-rest formats or recovery semantics.
- The change introduces a new architectural primitive (journal, queue, scheduler, cache layer) that other features will build on.
- A reviewer asks for one during code review.
When in doubt, just ship the code — small features don't need RFCs. First-time contributor RFCs should be discussed in an issue before opening a PR.
Current RFCs
hermes-run-adapter-contract.md— #1925 event/control contract, runtime-state ownership matrix, acceptance catalog, and reversible migration gates for moving WebUI execution behind an explicit adapter boundary.webui-run-state-consistency-contract.md— #2361 consistency rules for keeping transcript, model context, live streams, replay, compression, and session metadata coherent during active and recovered WebUI runs.live-to-final-assistant-replies.md— #3400 product model for long-running assistant replies, live process prose, tool activity, recovery, terminal outcomes, and the final-answer boundary.canonical-session-resolution.md— #2361 focused contract for resolving URL, query parameter, localStorage, sidebar, and compression-lineage session IDs to one canonical visible chat target.turn-journal.md— Crash-safe WebUI turn journal for recovering interrupted chat submissions.