Activate the weaver-spec conformance suite in CI (replace the placeholder job)

[dgenio]

Summary

Turn the conformance_stub CI job into a real gate: define the kernel-side target
interface the weaver-spec conformance runner needs, run it against weaver_kernel
when weaver_contracts.conformance ships (dgenio/weaver-spec#4), and meanwhile
pin the expected contract version and validate the pieces that already exist
(weaver-contracts 0.2.0 schemas).

Why this matters

The kernel claims to implement weaver-spec invariants (I-01, I-02, I-06) and shares
contracts with sibling repos (contextweaver, ChainWeaver, AgentFence). A placeholder
job that only echoes means contract drift between repos is invisible until an
integration breaks. Preparing the kernel side now — adapters from kernel types to
contract payloads, fixtures, version pinning — converts the cross-repo coherence
issues (#110, #111) from aspirations into a mechanically checked property the day
the runner lands.

Current evidence

• .github/workflows/ci.yml:51-77: conformance_stub job is an echo noting "weaver-contracts 0.2.0 is on PyPI; weaver_contracts.conformance runner not yet available (Add conformance suite (downstream repos can run it in CI) weaver-spec#4)".
• Open issues coherence: adopt the canonical Frame seam (producer side) — resolve "two firewalls" with contextweaver#352 / weaver-spec#84 #110 (Frame seam) and coherence: consume the shared Policy + safety-class contract (weaver-spec#78 / agentfence#76) — write once, enforce embedded + at the edge #111/Add shared policy contract roadmap with AgentFence #116–Add shared policy contract roadmap with AgentFence #120 (shared policy contract) define the contracts the suite would verify.
• weaver-spec's own agent docs describe the conformance suite design (conformance/, scoreboard) — the runner shape is known.

External context

Sibling repo dgenio/weaver-spec tracks the runner (weaver-spec#4); conformance
scoreboards across implementations are the standard mechanism for multi-repo
contract ecosystems.

Proposed implementation

1. Add weaver-contracts (pinned range) to a conformance optional/dev dependency
   group; in CI, validate now-available pieces: round-trip kernel
   Frame/ActionTrace/token payloads against the published JSON schemas where
   mappings exist.
2. Write the target adapter module the runner will invoke (map kernel objects to
   contract payloads) with fixtures, so activation is a one-line job change later.
3. Keep the job non-blocking until the runner ships, then flip to required.
4. Track activation against weaver-spec#4 in the job comment (already referenced).

AI-agent execution notes

• Inspect first: .github/workflows/ci.yml conformance job, models.py (Frame/ActionTrace shapes), weaver-contracts 0.2.0 package contents (pip download/inspect), docs in docs/integrations/.
• Do not vendor weaver-spec schemas — consume the published package (single source of truth).
• Edge cases: contract version skew (pin + Dependabot per ISSUE 55); fields the kernel has that contracts lack (document the mapping policy).
• Cross-repo wording: changes here may surface contract gaps — file them upstream rather than bending kernel types.

Acceptance criteria

• CI validates at least Frame and ActionTrace payload mappings against weaver-contracts schemas (real assertions, no echo).
• The adapter module + fixtures exist with tests.
• The job documents exactly what flips when weaver-spec#4 ships.

Test plan

Schema round-trip tests in CI; local pytest coverage of the adapter module.
Run make ci.

Documentation plan

docs/integrations.md conformance section; CHANGELOG Added (CI).

Migration and compatibility notes

Not expected to require migration. Contract mismatches discovered become tracked
issues, not silent changes.

Risks and tradeoffs

Coupling CI to an external package version adds a maintenance touchpoint — pin with
a range and keep the job optional until stable.

Suggested labels

ecosystem, testing, integrations