Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions 6

INGEST.md: correct the pin, drop an MSRV policy that does not exist, index all 22 standards #617

Closed
dcharlot wants to merge 2 commits from mesh/ingest-reconcile into main
pull from: mesh/ingest-reconcile
merge into: Transaction-Science:main
Conversation 0 Commits 2 Files changed 1 +58 -19

2026-11-04

Transaction Science
The links had nothing on the other side, and wai-verify pins no toolchain
All checks were successful
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m43s
Details
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 6s
Details
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
Details
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m29s
Details
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 44s
Details 
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]>
2aa14ab337
2026-11-04 14:33:28 -05:00
Transaction Science
INGEST.md said 1.95.0, an MSRV policy that does not exist, and 12 links to the wrong forge
Some checks failed
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m16s
Details
standards workspaces build + test / which workspaces this change touches (pull_request) Has been cancelled
Details
standards workspaces build + test / macOS energy backends (pull_request) Has been cancelled
Details 
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]>
638189cae6
2026-11-04 14:27:28 -05:00