mirror of
https://github.com/nesquena/hermes-webui.git
synced 2026-05-25 03:00:23 +00:00
nesquena-hermes
7690e08e70
Moves docs/turn-journal-rfc.md → docs/rfcs/turn-journal.md, establishing the convention for future design documents on hermes-webui's data-at-rest and recovery surfaces. Adds docs/rfcs/README.md describing when an RFC applies (large changes, durability/recovery semantics, new infrastructure primitives) and the simple status header convention. Polish on turn-journal.md: - Added 3-line status header (Status / Author / Created) at top. - Light tone edits on two flourishes that read fine in a PR description but felt off in permanent repo documentation. Author's voice preserved throughout the rest of the document. Co-authored-by: ai-ag2026 <261867348+ai-ag2026@users.noreply.github.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.
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.
Current RFCs
turn-journal.md— Crash-safe WebUI turn journal for recovering interrupted chat submissions.