ca2ad974e1
The storage-format refusal now names the release line that wrote each internal-schema stamp (e.g. v3 -> 0.6.2-0.7.2) plus the exact export/init/load commands — fail-closed but self-service; the message is engine-shared so server boot-quarantine and cluster status get it free. Adds the OMNIGRAPH_OLD_BIN-gated cross-version test: mint a GENUINE v3 graph with a real omnigraph-cli 0.7.2 binary, assert the current binary refuses it with the release-named message, and the documented rebuild round-trips. Deliberately NOT wired into CI (the write_cost_s3 disposition): compiling 0.7.2 from source is a 15-25 min job and the stamp seam changes a few times a year — testing.md documents the on-demand invocation instead. Rebased onto current main across the Lance 9.0.0-beta.15 migration; validated locally against a genuine 0.7.2 binary — the v3 round-trip passes on the Lance-9 main, which also makes it a live cross-substrate read-compat check (a Lance-9 binary reading a Lance-7-written manifest to find the stamp). |
||
|---|---|---|
| .. | ||
| 0000-template.md | ||
| 0001-fragment-adopt-branch-merge.md | ||
| README.md | ||
| rfc-0015-ingest-embeddings.md | ||
| rfc-0018-ingest-wal.md | ||
| rfc-0019-heads-and-fences.md | ||
RFCs
Substantial changes to OmniGraph — new user-facing surface, format or protocol changes, anything irreversible or cross-cutting — go through a lightweight RFC so the design is agreed as reviewable code before implementation starts. This is the public RFC track, open to anyone, including external contributors.
This complements the always-on review bar in ../dev/invariants.md: the invariants say what every change must respect; an RFC says why this particular change is worth making and how.
Two tracks, don't conflate them. This
docs/rfcs/directory is the public contribution track (anyone authors; maintainers accept). The maintainer-internal RFCs underdocs/dev/rfc-00N-*.mdare a separate, team-owned track for in-flight internal work. If you're an outside contributor, you're in the right place here.
When you need one
- RFC required: new query/schema/CLI/HTTP surface; on-disk or wire-format changes; a new substrate dependency; anything the deny-list in ../dev/invariants.md flags; anything irreversible ("reversibility shapes evidence demand").
- RFC not required: bug fixes for an
acceptedissue, and the trivial fast-lane (typos, docs, deps) — see ../../CONTRIBUTING.md.
If you're unsure, start a Discussion; a maintainer will tell you whether it needs an RFC.
Lifecycle
Discussion (incubate, get rough consensus)
│ graduate
▼
RFC pull request → adds docs/rfcs/NNNN-title.md (Status: Proposed)
│
maintainer review ──▶ changes requested / declined (PR closed, with rationale)
│
▼
merged == Accepted (the merged file is the durable decision record)
│
▼
Implementation PR(s) reference the accepted RFC
- Author: anyone. Acceptance: a maintainer decision, performed by merging the RFC PR. Declining is closing it with rationale.
- The merged RFC is the accepted record — there is no separate sign-off step.
- Later reversals don't edit history: supersede with a new RFC that links back
and flip the old one's
StatustoSuperseded.
Numbering & naming
- File:
docs/rfcs/NNNN-kebab-title.md, whereNNNNis the next free zero-padded integer (0001,0002, …).0000-template.mdis reserved. - Pick the number when you open the PR; if it collides with another in-flight RFC, the second to merge bumps theirs.
Status values
Proposed (open PR) · Accepted (merged) · Declined (closed) ·
Superseded by NNNN · Implemented (set once the work lands, optional).
Copy 0000-template.md to start.