chore(workspace): fix cross-workspace path deps + document naming violation

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>

Cargo.toml

@@ -16,17 +16,34 @@ license = "Apache-2.0"
 
 [workspace.dependencies]
 # M1: depend on the canonical proto-generated SAT types from the substrate
-# workspace. Path dep across workspaces; CI mounts both checkouts side by
+# workspace. Path dep across workspaces.
-# side. substrate-proto is itself a thin facade over substrate-common which
+#
-# owns the tonic-build invocation, so consumers only need to worry about
+# Layout: working trees nested under the substrate-project umbrella;
-# the substrate-proto import surface.
+# bascule-oss is a sibling checkout to substrate/ (NOT side-by-side with
-substrate-proto = { path = "../substrate-project/substrate/crates/substrate-proto" }
+# substrate-project at a higher directory). Paths resolve relative to
+# bascule-oss's root Cargo.toml: `../substrate/...` → the sibling
+# substrate/ checkout. If a future layout supports side-by-side checkouts,
+# a parallel `[patch]`-based override or a second path alternative can be
+# added.
+#
+# substrate-proto is itself a thin facade over substrate-common, which owns
+# the tonic-build invocation, so consumers only need to worry about the
+# substrate-proto import surface.
+#
+# Open item: the substrate-* naming on these crates violates this repo's
+# CLAUDE.md "zero substrate deps" rule in spirit and the CI contamination
+# check in letter, despite the CONTENT being a legitimate neutral protocol
+# contract. See NOTES-SUBSTRATE-PROTO-NAMING-VIOLATION.md for the proposed
+# rename (substrate-proto → sat-proto) and CNCF-sandbox-positioning
+# rationale. Not v1-blocking; tracked for post-foundation cleanup.
+substrate-proto = { path = "../substrate/crates/substrate-proto" }
 # Post-M6: optional HFL kernel-dispatch path. Pulled by `bascule-core`
-# under the `hfl` feature so the M5/M1 SAT compose path can route
+# under the `hfl` feature so the M5/M1 SAT compose path can route through
-# through audit::SAT_BUNDLE on nodes with /dev/substrate-hfl loaded.
+# audit::SAT_BUNDLE on nodes with /dev/substrate-hfl loaded. Same
-# Cross-workspace path dep — CI mounts both checkouts side by side.
+# cross-workspace path conventions as above; same NOTES-* open item covers
-hfl-types = { path = "../substrate-project/substrate/crates/hfl-types" }
+# the naming-violation question for these crates.
-substrate-hfl = { path = "../substrate-project/substrate/crates/substrate-hfl" }
+hfl-types = { path = "../substrate/crates/hfl-types" }
+substrate-hfl = { path = "../substrate/crates/substrate-hfl" }
 russh = "0.46"
 russh-keys = "0.46"
 tokio = { version = "1", features = ["full"] }

NOTES-SUBSTRATE-PROTO-NAMING-VIOLATION.md

@@ -0,0 +1,57 @@
+# Open item — substrate-proto naming violation
+
+**Status:** Documented 2026-04-20. Not v1-blocking. CNCF-sandbox-blocking.
+**Scope:** bascule-oss architectural positioning. Coordinated change with the substrate workspace.
+
+## The finding
+
+`bascule-oss/crates/bascule-core/Cargo.toml` depends on `substrate-proto` (via `workspace = true` in this repo's root `Cargo.toml`). `substrate-proto` is itself a facade over `substrate-common`, sourced from the sibling substrate workspace via path dependency. Both names are substrate-prefixed.
+
+This simultaneously:
+
+- Violates [CLAUDE.md](CLAUDE.md)'s rule *"Zero substrate/chronicle/gsap dependencies"*.
+- Fails [CI contamination check](.github/workflows/ci.yml) on lines matching `substrate|chronicle|gsap|hfl|metakernel` in `Cargo.lock` — current `Cargo.lock` contains `substrate-common`, `substrate-hfl`, `substrate-proto`, `hfl-types` entries.
+- Creates the optical problem of bascule-oss visibly depending on Guildhouse-substrate-named infrastructure, even though the *content* of what's depended on is legitimately neutral (SAT protocol types).
+
+## The content is fine; the packaging is the problem
+
+`substrate-proto` exposes proto-generated Substrate Attestation Token (SAT) types. SAT is a protocol contract between substrate (the attestation producer) and bascule (the session-composing consumer). bascule-core needs the wire format types to compose SATs that substrate-produced Keylime verifiers will accept. That's a legitimate cross-boundary architectural dependency — not a leak of substrate-internal types into a generic SSH-auth surface.
+
+The problem is naming. `substrate-proto` is named from substrate's perspective (substrate's single import surface for SAT types). From bascule-oss's perspective, it's consuming a *protocol contract*, not a *substrate implementation detail*. A name that reflected the content (e.g. `sat-proto`, `attestation-proto`) would accurately describe what bascule-oss depends on and would cleanly pass both the CLAUDE.md rule and the CI contamination check.
+
+## Proposed resolution (post-v1)
+
+1. **Rename `substrate-proto` → `sat-proto`** (or `attestation-proto`). This is a substrate-side change: the crate moves to a neutral namespace while its content is unchanged.
+2. **Move SAT public surface out of `substrate-common`** into a neutral location. `substrate-common` may keep substrate-internal content; the bits bascule-core needs (the generated Rust types) live behind the neutral name.
+3. Update bascule-core's `Cargo.toml` to depend on the neutrally-named crate. Update bascule-oss's workspace `Cargo.toml` likewise.
+4. Update the CI contamination check — the rule stands, but the grep is now true in both spirit and letter.
+5. Optionally update `CLAUDE.md` to name specific allowed cross-boundary protocol crates by name, so future contributors understand the rule is about *substrate/chronicle/gsap-internal-leakage*, not about *string-prefix avoidance*.
+
+## Why not now
+
+- The path fix that this NOTE accompanies unblocks local 5.5c-c work without introducing or expanding the violation. The violation pre-exists this commit; we're not making it worse.
+- The rename is a coordinated cross-workspace change (substrate-side rename, bascule-side update, possibly downstream consumers like Capstone if they import SAT types). Doing it correctly means touching multiple repos with coordinated PRs. Out of scope for the current Phase 5.5 foundation work.
+- Timing-wise, the right moment for this is immediately before CNCF sandbox application prep, when the institutional positioning argument is most concrete and the sandbox committee's read of the project is being actively shaped.
+
+## Why this matters for CNCF sandbox
+
+CNCF sandbox committees evaluate whether a project is a *generic open-source substrate* or *a specific company's product with open-source framing*. Naming is a substantial signal in that evaluation, more than content in many cases:
+
+- A sandbox application listing `substrate-proto` as a dependency reads as "bascule-oss is tightly coupled to Guildhouse-substrate; this project is Guildhouse-specific."
+- A sandbox application listing `sat-proto` / `attestation-proto` reads as "bascule-oss is part of a defensible layered architecture; the protocol crate is cross-project; Guildhouse is one of several consumers."
+
+This is the specific CNCF-sandbox-positioning work that the rename accomplishes. The architectural cleanup and the sandbox-positioning story are the same work, and should be done together with awareness that they're connected.
+
+## For a future contributor picking this up
+
+Read this NOTE, the current `CLAUDE.md`, and the CI workflow. Then:
+
+1. Decide the neutral crate name (`sat-proto` is most literal; `attestation-proto` is broader and might accommodate future additions beyond SAT; pick one based on how much the crate is expected to grow).
+2. Do the substrate-side rename: new crate at `substrate/crates/<new-name>/`, re-exports from `substrate-common` preserved, `substrate-proto` becomes a deprecation shim that re-exports from the new crate for one release cycle.
+3. Update bascule-oss to depend on the new name.
+4. Regenerate `Cargo.lock`; confirm CI contamination check passes.
+5. Coordinate with other consumers (Capstone, any sandbox applicants) on the deprecation timing.
+
+## Tracking
+
+This NOTE is the canonical reference for the issue. If/when a more formal open-items tracking system lands in bascule-oss (a `TODO.md`, a GitHub project, an issue tracker), migrate this there and leave a pointer here.