Adopt context-graph 2.0.0: ContextQueryResult gained two attestation fields and stella-context no longer compiles against CGP HEAD

[macanderson]

Problem

context-graph-protocol's scheduled Downstream Canary builds stella against CGP main HEAD and runs cargo test -p stella-cli -p stella-graph -p stella-context. It is red, and since CGP moved to 2.0.0 it fails at compile time rather than on an assertion:

error[E0063]: missing fields `frame_attestations` and `result_attestation`
              in initializer of `ContextQueryResult`

CGP 2.0.0 added two fields to ContextQueryResult (contextgraph-types/src/query.rs): frame_attestations: Vec<FrameAttestation> and result_attestation: Option<ProvenanceAttestation>. Stella still pins contextgraph-types / -host / -trace / -conformance at "=0.1.2" in the root Cargo.toml [workspace.dependencies], so stella's own main is green. This is forward incompatibility with unreleased upstream, which is what the canary exists to catch early.

Why it cannot be fixed today

crates.io serves only 0.1.2 of every contextgraph-* crate (index checked 2026-09-05). Pinning =2.0.0 fails resolution and lockfile-sync, and no partial adaptation compiles against 0.1.2, because the fields do not exist there.

The upstream blocker is macanderson/context-graph-protocol#102 — the crates-io GitHub Environment and token that release.yml needs do not exist, so nothing has been published since the by-hand 0.1.2 cut. CGP#16, named in the first version of this issue, is closed and is no longer the blocker.

What stella attests

Stella's built-in context providers hold no signing key and mint no commitment, so both new fields are empty for every answer stella produces: Vec::new() and None. Write them out at each site with a comment naming the producer that owes them, rather than ..Default::default(), which would absorb the next upstream field in silence.

Both fields carry #[serde(default, skip_serializing_if = ...)] upstream, so an unattested result serializes exactly as it does today and invariant 4 holds.

Duplicates folded in

#6012 and #6263 reported the same break and were closed as duplicates of this issue. #6429 (2026-09-07) is a third report of the same break, closed as a duplicate of this one — its one new finding is folded into the checklist below: the record_hash coupling comment in the root Cargo.toml needs a re-check against whatever version actually lands, since a major-version bump can change what that hash covers. #6436 did that re-check against CGP main and corrected the comment; confirming it against the published artifact is what remains.

Definition of done

• CGP 2.0.0 is on crates.io (blocked on Publish the contextgraph 2.0.0 crates to crates.io (crates-io environment + token are not set up) context-graph-protocol#102).
• The four contextgraph-* pins in the root Cargo.toml read "=2.0.0", and Cargo.lock is regenerated with a scoped cargo update -p contextgraph-types -p contextgraph-host -p contextgraph-trace -p contextgraph-conformance --precise 2.0.0, moving no unrelated lock edge.
• The five production construction sites carry both fields as empty: provider.rs's query, retrieval/outcome.rs's From<RecallResult> for ContextQueryResult, and the three in stella-cli's contextgraph.rs. Each has a comment naming the producer that owes real evidence.
• The four test construction sites compile (stella-context's provider.rs test module, stella-cli's contextgraph/tests.rs).
• pinned_protocol_version_is_a_conformance_verified_wire_version names exactly the wire versions 2.0.0 declares, and the contextgraph/1.0-draft entry is deleted now that the pin has left 0.1.x.
• A serde round-trip test covers a result with both fields populated and one with neither, proving the unattested shape is byte-identical to today's (invariant 4).
• The record_hash coupling comment in the root Cargo.toml is confirmed against the published 2.0.0 artifact (folded in from stella no longer builds against context-graph-protocol HEAD: ContextQueryResult gained two attestation fields #6429). Most of this re-check is already done, against CGP main at 2.0.0, and shipped in fix(stella-protocol): state where the record digest stops matching CGP's #6436: the canonicalizer version matches (serde_json_canonicalizer = "0.3.2" on both sides, reached through contextgraph-types' record-hash feature rather than through contextgraph-conformance, which the comment named), and the comment's byte-identity claim was corrected — CGP's record_hash_preimage keeps null-valued object members and stella's drops them, so the two preimages agree only on a record carrying no such member. stella_protocol::hash's strip_nulls_is_the_only_divergence_from_cgps_preimage pins that boundary. What is left is re-reading the same two facts off the published crate rather than off main.
• CI is green on the bumped tree, and a manual workflow_dispatch of CGP's Downstream Canary passes.

[macanderson]

Decision needed: nothing to decide on approach here — the fix is fully specified and blocked on one external event — but worth confirming whether this issue should carry the blocked label while it waits on macanderson/context-graph-protocol#16 to publish CGP 1.0.0 to crates.io.

Recommend adding blocked now: the issue already states plainly that pinning =1.0.0 today fails resolution and lockfile-sync since crates.io only has 0.1.2, so there's no partial work to do in this repo until the upstream publish happens — surfacing that in the label keeps a backlog sweep from re-triaging it every pass, matching how the CGP integration is treated elsewhere (a registry crate pinned with exact = requirements per AGENTS.md, deliberately not touched speculatively).

Once CGP 1.0.0 is on crates.io, the implementer bumps the four =0.1.2 pins to =1.0.0 at Cargo.toml:75-78, runs the scoped cargo update -p contextgraph-types -p contextgraph-host -p contextgraph-trace -p contextgraph-conformance (single-package update — watch for unrelated lock edges moving), flips the tripwire test at crates/stella-cli/src/contextgraph/tests.rs to expect "contextgraph/1.0" and drops _draft from its name, then runs cargo test -p stella-cli -p stella-graph -p stella-context and a manual workflow_dispatch of CGP's Downstream Canary as evidence.

Recommendation from the 2026-08-23 backlog sweep; the call is yours.

[macanderson]

Automated PR/CI sweep, 2026-08-31. This issue is still the right home for the canary, but both its title and its definition of done are now superseded — the failure has changed kind, and the target version has moved.

The canary fails differently now

Latest scheduled run: 33310161674 (2026-08-30 11:56 UTC), against CGP HEAD 7e0a7dae.

This issue was filed against a run where 1944 tests passed and one assertion failed — the pinned_protocol_version_is_the_expected_draft tripwire comparing contextgraph/1.0 to contextgraph/1.0-draft. That is not what happens today. stella-context no longer compiles at all:

error[E0063]: missing fields `frame_attestations` and `result_attestation`
              in initializer of `ContextQueryResult`
   --> crates/stella-context/src/provider.rs:271:12
   --> crates/stella-context/src/retrieval/outcome.rs:297:9
error: could not compile `stella-context` (lib) due to 2 previous errors

The tripwire never ran, because the build died before the test binary existed. A version-string flip cannot fix this.

The target is 2.0.0, not 1.0.0

The same build log compiles contextgraph-types v2.0.0, contextgraph-host v2.0.0 and contextgraph-conformance v2.0.0 from the CGP checkout. CGP HEAD has moved a major version past the 1.0.0 this issue's title and DoD name. Stella still pins =0.1.2 (Cargo.toml:74-77 on b124aa30 — the issue body cites 75-78, which has drifted by one line). I have retitled the issue accordingly; the body's step 1 (=0.1.2 → =1.0.0) is wrong as written.

Scope is wider than the compiler reported

The canary stopped at stella-context, so it never reached stella-cli. Counting the construction sites directly on main at b124aa30 (grep -rn "ContextQueryResult {" crates/), there are nine, of which five are production code and will each need the two new fields:

Site	Kind
crates/stella-context/src/provider.rs:271	production — reported by the compiler
crates/stella-context/src/retrieval/outcome.rs:297	production — reported by the compiler
crates/stella-cli/src/contextgraph.rs:239	production — not reached by the build
crates/stella-cli/src/contextgraph.rs:292	production — not reached by the build
crates/stella-cli/src/contextgraph.rs:315	production — not reached by the build
crates/stella-context/src/provider.rs:464, :652	test-only (after the #[cfg(test)] at :331)
crates/stella-cli/src/contextgraph/tests.rs:73, :426	test-only

Worth stating what I checked and what I did not: the #[cfg(test)] at contextgraph.rs:65 is a use import, not a module boundary — that file's test module starts at :1038, so all three sites in it are shipping code. I have not established what frame_attestations and result_attestation should hold for a stella recall; that is a design question about what stella can honestly attest, not a mechanical fill-in, and it is the real work this issue now carries.

What has not changed

Still blocked on the same external event, for the same reason: crates.io has only 0.1.2, so no pin bump resolves today. macanderson/context-graph-protocol#16 is still the upstream publish blocker.

Still not a red main. Stella's main is green on b124aa30 (run 33353404980) because the pin holds it at 0.1.2. This is forward-incompatibility with unreleased upstream, exactly the thing the canary exists to see early — not a live breakage.

Suggested replacement for the DoD

1. CGP publishes 2.0.0 (blocked on CGP#16).
2. Decide what stella populates frame_attestations / result_attestation with, per endpoint, and record it — this is the part that needs a person.
3. Bump the four pins =0.1.2 → =2.0.0; scoped cargo update -p for the four crates.
4. Fill the five production sites; then the four test sites.
5. Flip the protocol-version tripwire to whatever 2.0.0 declares and rename it off _draft.
6. cargo test -p stella-cli -p stella-graph -p stella-context, then a manual workflow_dispatch of CGP's Downstream Canary must go green.

No labels changed — sizing and priority are triage's per SCR-005.

---

Generated by Claude Code

[macanderson]

Picked this up on 2026-09-05 against origin/main at 1b6226c8a. It is still blocked, and the blocker moved. Here is what I checked and what I found, so the next session does not re-derive it.

The pin cannot move today

The crates.io sparse index serves only 0.1.2 for all four crates:

curl -s https://index.crates.io/co/nt/contextgraph-types        -> 0.1.0, 0.1.1, 0.1.2
curl -s https://index.crates.io/co/nt/contextgraph-host         -> 0.1.0, 0.1.1, 0.1.2
curl -s https://index.crates.io/co/nt/contextgraph-trace        -> 0.1.1, 0.1.2
curl -s https://index.crates.io/co/nt/contextgraph-conformance  -> 0.1.0, 0.1.1, 0.1.2

So =2.0.0 does not resolve, cargo update --precise 2.0.0 fails, and lockfile-sync goes red. macanderson/context-graph-protocol has no release and no version tag either: gh release list is empty, and the only tags are sdk/go/v0.1.0 and ocp-v0.1.0.

The upstream blocker this body names, CGP#16, is closed — that was the by-hand 0.1.2 cut. The live one is macanderson/context-graph-protocol#102, "Publish the contextgraph 2.0.0 crates to crates.io (crates-io environment + token are not set up)". CGP's workspace Cargo.toml is on version = "2.0.0", which is why the canary compiles 2.0.0 from the checkout while stella pins 0.1.2 from the registry.

Adding the blocked label to match.

One step of the old plan already landed

crates/stella-cli/src/contextgraph/tests.rs now holds pinned_protocol_version_is_a_conformance_verified_wire_version, and it accepts both contextgraph/1.0-draft and contextgraph/1.0. Step 2 of the old checklist is done in a forward-compatible way. What remains is deleting the draft entry once the pin leaves 0.1.x, and widening the list if 2.0.0 declares a third string.

The design question is answerable now

The last sweep said someone had to decide what stella attests. Reading contextgraph-types/src/query.rs at CGP HEAD settles it, and the answer is small:

• ContextQueryResult still derives Default and is not #[non_exhaustive]. Both new fields carry #[serde(default, skip_serializing_if = ...)], so an unsigned answer serializes byte-for-byte the way it does today. Invariant 4 is safe.
• frame_attestations: Vec<FrameAttestation> is detached per-frame evidence. result_attestation: Option<ProvenanceAttestation> is one signature over a Merkle root of the frames returned.
• Stella signs nothing. Its built-in providers hold no key and mint no commitment, so the honest value at every production site is an empty vector and None — written out, with a comment naming the producer that owes them. Not ..Default::default(), which would swallow the next added field in silence.

The production sites, current line numbers

Site	Kind
crates/stella-context/src/provider.rs:271	production
crates/stella-context/src/retrieval/outcome.rs:345	production (From<RecallResult>)
crates/stella-cli/src/contextgraph.rs:239	production
crates/stella-cli/src/contextgraph.rs:292	production
crates/stella-cli/src/contextgraph.rs:315	production
crates/stella-context/src/provider.rs:464, :652	test-only (the #[cfg(test)] is at :331)
crates/stella-cli/src/contextgraph/tests.rs:73, :426	test-only (the #[cfg(test)] is at contextgraph.rs:1038)

The pins sit at Cargo.toml:76-79 today. The body said 75-78 and the last sweep said 74-77, so I have rewritten the checklist to name symbols instead of line numbers, and to name the right upstream issue.

No PR opened: there is no partial change that lands green while the registry has no 2.0.0. Nothing else in this repository is on the critical path — the remaining work is one publish away.

[macanderson]

A third duplicate report landed: #6429 (2026-09-07), same two-then-five ContextQueryResult construction sites, same crates.io-pin-vs-CGP-2.0.0 root blocker as #6012 and #6263 before it. Closing it as a duplicate of this issue.

Its one new finding is folded into the checklist above: contextgraph-conformance's record_hash coupling at Cargo.toml:85 needs a re-check against whatever version actually lands, since a major-version bump can change what that hash covers. Everything else it reported was already tracked here.

---

Generated by Claude Code

[macanderson]

macanderson e153c6b7ef42c38e

Implementing this. The claim lapses after 90 minutes, so it
cannot hold the issue shut if this session dies
(scripts/issue-claim.sh, #5224).
The second word is this session's own, so another session of the same author
reads this as somebody else's claim.