mirror of
https://github.com/nesquena/hermes-webui.git
synced 2026-05-25 03:00:23 +00:00
nesquena-hermes
43677b046d
When merging PR #2105 (Hermes Run Adapter RFC) the standing concern was that landing the RFC unconfirmed would invite the speculative-fragment implementation pattern we just had to put on hold with PR #2071 — well- written 651-LOC standalone scripts with no callers. Add a single bullet to the conventions block so the contract is explicit: an RFC is a design direction, not an invitation to PR fragments against it. Implementation slices need maintainer confirmation first. Applied during stage-341 build, not requested from @Michaelyklam — the guardrail belongs in the conventions doc itself rather than as a one-off ask on this PR.
46 lines
2.0 KiB
Markdown
46 lines
2.0 KiB
Markdown
# 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`](hermes-run-adapter-contract.md) — Event/control
|
|
compatibility contract and gap matrix for moving WebUI chat runs to Hermes-owned
|
|
runtime execution.
|
|
- [`turn-journal.md`](turn-journal.md) — Crash-safe WebUI turn journal for
|
|
recovering interrupted chat submissions.
|