INGEST.md: correct the pin and the MSRV policy, and fix the links (replaces #617) #628

Merged
dcharlot merged 2 commits from mesh/ingest-reconcile-2 into main 2026-11-04 21:23:44 -05:00
Owner

Replaces #617, which went un-mergeable when main moved under it. Same two commits, replayed onto current main. A replacement branch rather than a force-push, because force-pushing is denied here.

The conflict was worth reading rather than resolving mechanically

main had meanwhile grown its own rewrite of the same section, and the two versions disagree on a point of fact. I checked the tree instead of picking a side:

claim checked against the tree
the pin is 1.99.1 ✓ rust-toolchain.toml
main's text: "The rust-version key in each Cargo.toml is a cargo convenience" ✗ there are zero first-party rust-version keys
wai/wai-verify carries a note saying it has none on purpose ✓
joule-code/.../vendor/wtransport declares 1.88 ✓ vendored third-party stating its own floor
twenty-two standards ✓ 22 directories

So the section now on main describes a convention that does not exist in the repository — it speaks of a key that no first-party manifest has. This takes the accurate text and folds in the one true sentence main's version adds that mine lacked: that CI installs the pinned version on every runner, which is what makes the pin binding rather than advisory.

That sentence is the substance of main's section; the rest of it was the claim that is wrong.

What the two commits do

  1. Correct the pin (the file said 1.95.0), drop an MSRV policy the repository does not implement, and fix 12 links pointing at the wrong forge.
  2. Remove 9 dead per-item links, and record that wai-verify pins no toolchain of its own.

Verified

  • no conflict markers remain
  • every local link in INGEST.md resolves — 0 broken of all checked

Closes #617.

🤖 Generated with Claude Code

Replaces #617, which went un-mergeable when `main` moved under it. Same two commits, replayed onto current `main`. A replacement branch rather than a force-push, because force-pushing is denied here. ## The conflict was worth reading rather than resolving mechanically `main` had meanwhile grown its **own** rewrite of the same section, and the two versions disagree on a point of fact. I checked the tree instead of picking a side: | claim | checked against the tree | |---|---| | the pin is **1.99.1** | ✓ `rust-toolchain.toml` | | main's text: "The `rust-version` key in each `Cargo.toml` is a cargo convenience" | ✗ **there are zero first-party `rust-version` keys** | | `wai/wai-verify` carries a note saying it has none on purpose | ✓ | | `joule-code/.../vendor/wtransport` declares `1.88` | ✓ vendored third-party stating its own floor | | twenty-two standards | ✓ 22 directories | So the section now on `main` describes a convention that does not exist in the repository — it speaks of a key that no first-party manifest has. This takes the accurate text and **folds in the one true sentence main's version adds** that mine lacked: that CI installs the pinned version on every runner, which is what makes the pin binding rather than advisory. That sentence is the substance of main's section; the rest of it was the claim that is wrong. ## What the two commits do 1. Correct the pin (the file said **1.95.0**), drop an MSRV policy the repository does not implement, and fix 12 links pointing at the wrong forge. 2. Remove 9 dead per-item links, and record that `wai-verify` pins no toolchain of its own. ## Verified - no conflict markers remain - **every local link in `INGEST.md` resolves** — 0 broken of all checked Closes #617. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Three things in this file were false rather than merely stale, which is worse
in the one document whose job is to say what the ecosystem is.

**The pin.** It said "Rust 1.95.0". The root `rust-toolchain.toml` says 1.99.1
after the bump that just landed, so the file was two bumps behind.

**The MSRV policy.** It said "Per-workspace MSRV is declared in each
`Cargo.toml` (`rust-version = \"1.95\"`). CI enforces both." No first-party
crate declares `rust-version` at all. The only two mentions in the tree are
`wai/wai-verify/Cargo.toml`, carrying a note that it deliberately has none
because that verifier ships its own pinned nightly, and a vendored
`wtransport` manifest declaring 1.88, which is third-party code stating its
own floor. The section now records the policy that is actually in force: one
pin at the root, no MSRV floor, because a per-crate floor is a second and
quieter version statement that drifts from the pin.

**The tracker.** Twelve links pointed at `github.com` issues. The three
"Tracked in issues labelled X" links now point at the forge, whose issue list
answers 200 anonymously. The nine per-item numbers were **dropped rather than
translated**: Forgejo numbers issues and pull requests from one counter, so a
pre-migration `#7` is not necessarily today's `#7`, and neither credential
available here can read issues to confirm a mapping — both 403. A wrong link
is worse than none, and asserting a mapping I cannot check is how this file
got into this state.

It also claimed to record "the scope of each protocol", having done so for 3
of 22. Rather than write 19 scope paragraphs by paraphrasing READMEs — a
second copy that would drift exactly as these facts did — the file now
**indexes** the 22 standards and links each to its own README and SPEC, which
are the source of truth. The four sections that carry real Included / Adding
content keep it and are marked in the index. Every one of the 44 relative
links was checked to resolve, and every README and SPEC path asserted to exist
before being written.

Guards clean: comparative prose (4104 files), vanity metrics (523 Markdown
files), spec refs (1966 citations across 17 standards), orphan sources.

Stacked on mesh/decision-training-provenance (#612), which adds the `mesh/`
section this index marks as detailed.

Co-Authored-By: Claude Opus 5 <[email protected]>
The links had nothing on the other side, and wai-verify pins no toolchain
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 22s
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m34s
2e0c56fe6b
Two corrections to the reconciliation, both from checking rather than
reasoning.

**The Adding lists were not tracked anywhere.** I had repointed the three
"Tracked in issues labelled X" links at the forge's issue list and dropped the
nine per-item numbers for want of a verifiable mapping. The real reason is
simpler and worth stating: the forge repository has its issue tracker enabled
and **empty** — `open_issues_count` is 0 — because the migration carried code
and pull requests, not issues. There was never a `#7` to point at. So the three
lines now say what is true, which is that these lists are themselves the
record, and the closing note carries the evidence and the consequence: filing
them as forge issues would be the better state, and `/issues` is 403 for both
credentials available here, so it is not something this change can do.

**`wai-verify` pins no toolchain.** The note I wrote repeated the crate's own
comment, that it "ships its own pinned nightly". It does not: there is no
`rust-toolchain.toml` in that crate. The nightly belongs to the model checker,
which brings its own toolchain for the proof harnesses; the crate only declines
to state an MSRV that would outrank it. The distinction matters for the policy
one line above it — **nothing in this repository pins a second version**, and
the corrected text says so.

Confirmed while here: both pins on `main` are 1.99.1 after #606, and 1.99.1 is
what `channel-rust-stable.toml` currently publishes, so the repository is on
latest stable with one pin and no floor.

Guards clean. 43 relative links, 0 broken. The one remaining `github.com` is
inside the prose explaining the removal.

Co-Authored-By: Claude Opus 5 <[email protected]>
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!628
No description provided.