fix(ramen-ai-cmcp): emit the TRACE v0.2 profile - #85
Merged
Conversation
The adapter hardcoded `tag:agentrust.io,2026:trace-v0.1`. The conformance
suite cut over to v0.2 rather than dual-accepting, so `trace-tests` >= 0.4
rejects that value outright:
TR-ENV FAIL eat_profile must be 'tag:agentrust-io.com,2026:trace-v0.2',
got 'tag:agentrust.io,2026:trace-v0.1'
The conformance workflow installs the released packages unpinned, which is
deliberate (the weekly cron exists to catch drift against latest). The drift
it caught is real: this job has been failing on main since 2026-07-28, and
because the workflow is path-filtered to this integration, ordinary main
pushes never run it. The breakage stayed invisible until three dependabot
action bumps edited the workflow file and tripped the filter.
The old value also named `agentrust.io` in its authority component, a domain
this project has never controlled. Same defect class as trace-spec#107 and
agent-manifest#263; this is one more surface of it.
Changes:
- `ramen_ai_trace.py`: `EAT_PROFILE` and the two docstring references.
- `tests/test_mapping.py`: the assertion pinned the stale value, so the test
suite was defending the bug.
- `pyproject.toml`: floor `agentrust-trace>=0.5`. A consumer installing this
adapter needs a version whose profile matches what the adapter emits;
leaving it unbounded is how this drifted silently. CI stays unpinned by
design.
- `README.md`: the profile reference, and a stale "0.3.0" pin note.
Verified locally against `agentrust-trace` 0.5.1 and
`agentrust-trace-tests` 0.4.0:
- `pytest integrations/ramen-ai-cmcp/tests -q` -> 14 passed
- `trace-tests verify --record trust-record.jwt --level 0` -> PASS,
8 checks, exit 0
The TR-SIG-005 UNVERIFIED finding is unchanged and expected: the loader
rejects a plain record carrying a top-level `signature`, so the gradable
artifact is the unsigned payload. Already documented in the README.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`tested_against.agentrust-trace` still read 0.3.0, which is the same staleness as the profile constant. Set to 0.5.1, the version the mapping tests and the level 0 conformance run were actually verified against here. `cmcp-runtime` is left at 0.3.0 deliberately: this change did not exercise it, and the field records what the integration was last tested against rather than what is current. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The
ramen-ai-cmcpconformance job has been failing on main since 2026-07-28. The adapter hardcodes the v0.1 EAT profile, and the conformance suite cut over to v0.2 rather than dual-accepting, sotrace-tests>= 0.4 rejects it:Two things kept this hidden:
integrations/ramen-ai-cmcp/**and its own workflow file, so ordinary main pushes never run it.The workflow installs the released packages unpinned, and that is correct: the weekly cron exists precisely to catch drift against latest. It did its job. The fix belongs in the committed constant, not in a CI pin.
Worth noting the stale value also named
agentrust.ioin its authority component, a domain this project has never controlled. Same defect class astrace-spec#107andagent-manifest#263, so this is one more surface of it.Changes
ramen_ai_trace.py:EAT_PROFILEplus the two docstring references.tests/test_mapping.py: the assertion pinned the stale string, so the test suite was actively defending the bug.pyproject.toml: flooragentrust-trace>=0.5. A consumer installing this adapter needs a version whose profile matches what the adapter emits; leaving it unbounded is how this drifted silently. CI stays unpinned by design.README.md: the profile reference, and a stale "released packages 0.3.0" note.Test plan
Verified locally against
agentrust-trace0.5.1 andagentrust-trace-tests0.4.0, following the same sequence CI runs:pytest integrations/ramen-ai-cmcp/tests -q-> 14 passedpython examples/emit_record.py --out trust-record.jwt-> emits both the unsigned and signed formstrace-tests verify --record trust-record.jwt --level 0-> PASS, 8 checks, exit 0The TR-SIG-005 UNVERIFIED finding is unchanged and expected: the loader rejects a plain record carrying a top-level
signature(anti-downgrade), so the gradable artifact is the unsigned payload. That is already documented under "What it does NOT claim".Scope
Profile string and the pin that let it drift. No change to the field mapping, the signing path, or what the integration claims.
🤖 Generated with Claude Code