Finding
sphragis is pulled in via a bare git = dependency with no tag, rev, or branch — it floats to whatever commit is HEAD of the default branch at build time, with no pin.
Evidence
Cargo.toml:73 (verified against the current tree):
# Post-quantum hybrid KEM — standalone fleet crate.
# WHY: extracted from akroasis crates/sphragis to forkwright/sphragis for
# cross-repo access. preview-pq gated; unaudited until cryptographic review.
sphragis = { git = "https://github.com/forkwright/sphragis", features = ["preview-pq"] }
forkwright/sphragis itself has zero tags (gh api repos/forkwright/sphragis/tags returns an empty list) and a single commit (24c0db69, the initial extraction, 2026-05-26). The build currently resolves deterministically only because there has been exactly one commit ever — that is incidental, not a pin. Any future push to sphragis's default branch changes what akroasis builds against with no version bump, no changelog entry, and no review signal on the akroasis side.
This is also flagged as a known drift/governance gap in kanon's own fleet substrate-methodology research (projects/kanon/research/substrate-methodology-ratified.md, ARCH/substrate-floating-ref), so the class of problem is already recognized — this is the concrete instance of it.
Why this matters
sphragis is explicitly UNAUDITED PREVIEW cryptography gated behind preview-pq. A floating dependency on unaudited crypto means a change on the sphragis side (even a well-intentioned fix) can silently alter akroasis's cryptographic behavior with no corresponding akroasis commit, PR, or gate run to catch it. That is the opposite of the caution the preview-pq gate is trying to enforce.
Desired correction
Pin sphragis to an explicit tag or rev in Cargo.toml:73. Since sphragis has no tagged release yet, either:
- cut a
v0.1.0 tag on forkwright/sphragis and pin tag = "v0.1.0" here, or
- pin
rev = "24c0db69..." (the current, only commit) as an interim measure until a real tag exists.
Done when: Cargo.toml's sphragis dependency entry carries an explicit tag or rev key, Cargo.lock is regenerated and committed alongside, and the same substrate-methodology doc's ARCH/substrate-floating-ref note for this specific edge is marked resolved.
Finding
sphragisis pulled in via a baregit =dependency with notag,rev, orbranch— it floats to whatever commit is HEAD of the default branch at build time, with no pin.Evidence
Cargo.toml:73(verified against the current tree):forkwright/sphragisitself has zero tags (gh api repos/forkwright/sphragis/tagsreturns an empty list) and a single commit (24c0db69, the initial extraction, 2026-05-26). The build currently resolves deterministically only because there has been exactly one commit ever — that is incidental, not a pin. Any future push to sphragis's default branch changes what akroasis builds against with no version bump, no changelog entry, and no review signal on the akroasis side.This is also flagged as a known drift/governance gap in kanon's own fleet substrate-methodology research (
projects/kanon/research/substrate-methodology-ratified.md,ARCH/substrate-floating-ref), so the class of problem is already recognized — this is the concrete instance of it.Why this matters
sphragisis explicitly UNAUDITED PREVIEW cryptography gated behindpreview-pq. A floating dependency on unaudited crypto means a change on the sphragis side (even a well-intentioned fix) can silently alter akroasis's cryptographic behavior with no corresponding akroasis commit, PR, or gate run to catch it. That is the opposite of the caution thepreview-pqgate is trying to enforce.Desired correction
Pin
sphragisto an explicittagorrevinCargo.toml:73. Since sphragis has no tagged release yet, either:v0.1.0tag onforkwright/sphragisand pintag = "v0.1.0"here, orrev = "24c0db69..."(the current, only commit) as an interim measure until a real tag exists.Done when:
Cargo.toml'ssphragisdependency entry carries an explicittagorrevkey,Cargo.lockis regenerated and committed alongside, and the same substrate-methodology doc'sARCH/substrate-floating-refnote for this specific edge is marked resolved.