Three path deps in this workspace's Cargo.toml (substrate-proto,
hfl-types, substrate-hfl) pointed at `../substrate-project/substrate/
crates/...`, which resolves correctly only when bascule-oss sits as a
sibling to a substrate-project-named directory at the parent level.
That's not the current layout: bascule-oss is now nested INSIDE the
substrate-project umbrella, as a working tree alongside substrate/
and other Guildhouse repos. The paths don't resolve in the current
nested layout; bascule-oss has been locally unbuildable since the
reorg (existing Cargo.lock survived only because nobody ran
`cargo update` or `cargo generate-lockfile` to force re-resolution).
Fix: update the three paths to `../substrate/crates/...`, matching
the sibling-checkout layout. Comment updated to name the current
convention explicitly rather than referencing an old side-by-side
CI claim that no longer matches CI's actual layout either (see
below on CI state).
What this fix does NOT change
- **The architectural rule in CLAUDE.md still stands** —
"zero substrate/chronicle/gsap dependencies." This fix is a path
correction, not a policy change.
- **The rule is already broken in both spirit and letter.** bascule-
core depends on substrate-proto unconditionally; substrate-proto
depends on substrate-common; both names are substrate-prefixed.
The CI contamination check at .github/workflows/ci.yml:81-88
greps Cargo.lock for "substrate|chronicle|gsap|hfl|metakernel"
and fails on any match — current Cargo.lock contains substrate-
common, substrate-hfl, substrate-proto, hfl-types, so CI would
fail on a fresh run regardless of this patch.
- **This fix is a LOCAL buildability unblock only.** It makes
`cargo check -p bascule-core` pass in the current layout. It does
NOT fix CI, which is independently broken for the reasons above.
CI state
The bascule-oss CI workflow uses `actions/checkout@v4` with no
coordinating checkout of substrate-project or its substrate/
subrepo. Regardless of whether bascule-oss's paths use
`../substrate/...` or `../substrate-project/substrate/...`, CI
currently has nothing to resolve them against. And the
contamination check would flag the resulting Cargo.lock even if
the paths did resolve. CI is already red (or will be, on next
trigger).
Re-enabling CI against bascule-oss requires separate coordination
work: either adding a substrate-project checkout step to the
workflow, or renaming substrate-proto (see below), or amending
the contamination check to allow specific neutral-protocol crates
by name. That work is out of scope for this patch.
Architectural open item: substrate-proto naming violation
Documented in the new NOTES-SUBSTRATE-PROTO-NAMING-VIOLATION.md.
Summary: substrate-proto's CONTENT is a legitimate neutral
protocol contract (proto-generated SAT types bascule-core needs
to compose session attestations). The NAMING is substrate-
prefixed, which both violates CLAUDE.md's string-match rule and
creates an optical problem for CNCF sandbox positioning —
sandbox committees read dependency names more than content when
evaluating whether a project is a generic open-source substrate
or a specific company's product with open-source framing.
Proposed resolution (post-v1): rename substrate-proto → sat-proto
(or attestation-proto), move the consumed subset of substrate-
common's public surface out of substrate-common into the neutrally-
named crate, update bascule-core and any other consumers, regenerate
Cargo.lock, confirm the contamination check passes.
This is NOT v1-blocking. This IS CNCF-sandbox-positioning work —
worth doing in coordination with sandbox application prep so the
naming story and the institutional positioning story land
together.
Why we're shipping this narrower fix now
Phase 5.5c-c of the substrate foundation work (the adapter crate
bridging bascule-core session lifecycle to bascule-revocation-
ingress SessionLookup) requires depending on bascule-core as a
cross-workspace path dep. Without this path fix, substrate-side
crates can't pull bascule-core locally, blocking 5.5c-c
implementation. The path fix costs one line per dep and
introduces no new coupling; the deeper rename is several-repo
coordination that would delay 5.5c-c unnecessarily.
Fix-what's-blocking, document-what's-underlying, keep moving.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Tyler J King <tking@guildhouse.dev>
