Follow-up to #819. The supply-chain risk (git deps pinned by rev) is filed; this is the cheapest mitigation that can land independently.
Problem
#819 flagged that contextgraph-types, contextgraph-host, contextgraph-trace, and contextgraph-conformance are git dependencies sourced from github.com/macanderson/context-graph-protocol, pinned by commit rev. They appear in three separate Cargo.toml files:
stella-cli/Cargo.tomlstella-context/Cargo.tomlstella-graph/Cargo.toml
Each carries its own copy of the rev. Bumping the pinned rev (a normal maintenance operation) requires editing three files, and a partial bump leaves the crates at different commits — a silent desynchronization that's hard to detect.
Proposal
Centralize the rev so a bump touches one place:
Option A — workspace [patch]: Add a single [patch.crates-io] section in the root Cargo.toml (or a dedicated [patch] for the git source) that pins all four crates to one rev. The individual Cargo.toml files reference the crate names without repeating the rev.
Option B — a shared constant: If [patch] doesn't fit the dependency shape, extract the rev string into a single workspace-level definition (e.g. a .cargo/config.toml or a build-script constant) so all three manifests reference it.
Either way, cargo update -p contextgraph-types should work without editing multiple manifests.
Where
Cargo.toml (root) — the [patch] section.stella-cli/Cargo.toml, stella-context/Cargo.toml, stella-graph/Cargo.toml — remove the per-manifest rev.
Acceptance
- All
contextgraph-* git dependencies resolve through a single source of truth for the rev.
- Bumping the rev is a one-line change in one file.
cargo update -p contextgraph-types succeeds without manual edits to multiple manifests.cargo check --workspace passes (the workspace still resolves all four crates).- Tested: the lockfile resolves cleanly after the centralization.
Notes
This doesn't resolve #819 (the crates should still be vendored or published to crates.io), but it makes the interim state safe to maintain.
Follow-up to #819. The supply-chain risk (git deps pinned by rev) is filed; this is the cheapest mitigation that can land independently.
Problem
#819 flagged that
contextgraph-types,contextgraph-host,contextgraph-trace, andcontextgraph-conformanceare git dependencies sourced fromgithub.com/macanderson/context-graph-protocol, pinned by commit rev. They appear in three separate Cargo.toml files:stella-cli/Cargo.tomlstella-context/Cargo.tomlstella-graph/Cargo.tomlEach carries its own copy of the rev. Bumping the pinned rev (a normal maintenance operation) requires editing three files, and a partial bump leaves the crates at different commits — a silent desynchronization that's hard to detect.
Proposal
Centralize the rev so a bump touches one place:
Option A — workspace
[patch]: Add a single[patch.crates-io]section in the rootCargo.toml(or a dedicated[patch]for the git source) that pins all four crates to one rev. The individualCargo.tomlfiles reference the crate names without repeating the rev.Option B — a shared constant: If
[patch]doesn't fit the dependency shape, extract the rev string into a single workspace-level definition (e.g. a.cargo/config.tomlor a build-script constant) so all three manifests reference it.Either way,
cargo update -p contextgraph-typesshould work without editing multiple manifests.Where
Cargo.toml(root) — the[patch]section.stella-cli/Cargo.toml,stella-context/Cargo.toml,stella-graph/Cargo.toml— remove the per-manifest rev.Acceptance
contextgraph-*git dependencies resolve through a single source of truth for the rev.cargo update -p contextgraph-typessucceeds without manual edits to multiple manifests.cargo check --workspacepasses (the workspace still resolves all four crates).Notes
This doesn't resolve #819 (the crates should still be vendored or published to crates.io), but it makes the interim state safe to maintain.