From 43677b046da118ffaaacfb214adaf1b3f1a5ec76 Mon Sep 17 00:00:00 2001 From: nesquena-hermes Date: Tue, 12 May 2026 00:05:28 +0000 Subject: [PATCH] docs(rfcs): add anti-speculative-implementation conventions guidance MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- docs/rfcs/README.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/rfcs/README.md b/docs/rfcs/README.md index 4e2d1d37..ae50b3ce 100644 --- a/docs/rfcs/README.md +++ b/docs/rfcs/README.md @@ -18,6 +18,12 @@ cutting infrastructure. 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