≡

REA 6.5–6.7: What Changed (and What Breaks Your Evidence)

Last verified 2026-10-19, rea-agents 6.7.0 · Non-affiliated: reaguide.online is an independent tutorial site with no relationship to the REA developers.

TL;DR: The rea 6.7.0 changelog shipped eight minor releases in eleven days (6.0.0 on Oct 8 → 6.7.0 on Oct 18). Version 6.6.0 — which most users received only inside the 6.7.0 npm package — carries the release cycle's only evidence-contract BREAKING CHANGE: saved evidence bundles from 6.4.x and earlier are rejected, not migrated. We reproduced the refusal on our own machine: a bundle exported under 6.4.0 fails in 6.7.0 with evidence_integrity_mismatch, and every pre-6.6 evidence_id is invalidated because contract fields feed the content-addressed hash. Everything else in 6.5–6.7 is additive. If you pin (as our setup guide recommends), nothing breaks; if you ride @latest, re-read the migration checklist below.

The 11-day timeline

All dates from the developer-published GitHub releases, fetched 2026-10-19:

That cadence matters for one practical reason: installing rea-agents@latest means your version can move under you within days. The rea 6.7.0 changelog below is therefore organized by what each release actually changed, with the breaking parts separated out.

6.5.0 — new offline targets and analysis views

The 6.5.0 release body is enormous (893 commits, 529 merged PRs). The headline items:

6.5.0 also shipped its own smaller breaking changes — attached may now be null (treat as unknown, not false), call graphs return { graph, limitations } instead of a bare structure, and binary_session no longer repeats catalog.tools. The developer-published changelog has the full list.

6.6.0 — the big one (delivered via 6.7.0)

Because 6.6.0 was never published to npm, most users got it inside 6.7.0. Key additions:

rea 6.7.0 changelog — small release, one semantic fix

6.7.0 itself is tiny (4 commits, 1 PR): client configuration edits now follow the duplicate-member semantics MCP clients actually use — setup edits the last repeated JSON/JSONC member (the one clients read), and setup/uninstall refuse a removal that would reactivate a shadowed duplicate (#4957, #4952). Its real payload is that it ships all of 6.6.0.

BREAKING deep dive: the evidence contract (with our own test runs)

This is the section the release notes bury and the one that actually bites. Per the developer-published changelog, 6.6.0 changed the saved-evidence schema:

  1. Identity commitments now require an explicit, nullable relationship_coverage field.
  2. Artifact inventories require scoped coverage plus explicit integrity_contradictions.
  3. coverage_status and prose-based coverage inference are removed.
  4. Old files are not migrated, and missing fields are never filled with guessed defaults — you must regenerate.

We tested this on 2026-10-19 in an isolated environment (rea-agents@6.7.0, same machine as our original 6.4.0 labs, 6.4.0 install untouched). A bundle our lab exported under 6.4.0 on Oct 12 was fed back to rea evidence-export under 6.7.0:

bash — lab@realearn (isolated lab-env-670) verified: ran 2026-10-19 
$ npx rea evidence-export hello-bundle.json /tmp/old-reexport.json
error: Analysis failed
code: evidence_integrity_mismatch
message: "Evidence bundle does not match the bundle schema at
  records.0.relationship_coverage: Invalid input: expected object,
  received undefined."
retryable: false

That is the fail-closed behavior the evidence contract page describes, now with a version boundary attached.

The second, quieter break: every old evidence_id is invalidated. Because REA uses content-addressed IDs, contract fields feed the hash input — change the schema, and every derived ID changes. On the same binary (sha256 36cdabb6…, untouched), our re-run under 6.7.0 produced ev_79a48ab6… where 6.4.0 had stamped ev_6e479c83…. The analytical payload did not change: 31 sections, entry point 0x400320 — identical to our 6.4.0-era records. Only the ID moved, because the contract moved.

bash — lab@realearn (R8-A rerun under 6.7.0, same binary) verified: ran 2026-10-19 
$ npx rea inspect-binary-layout lab-env/hello   # same sha256 36cdabb6…4207352
evidence_id: ev_79a48ab6…  (6.4.0 era: ev_6e479c83… — contract fields re-hashed)
normalized_result: 31 sections / entry_point 0x400320 — unchanged
relationship_coverage: null (new explicit nullable contract field)

6.6.0's other breaking edges, briefly: inspect_adb_package.version_code is now a decimal string (use BigInt for comparison); failed native UI scenarios return typed errors with a partial_observation report; binary_session candidate availability can be unknown during finalization; swift_symbols entries may carry a null address (original value kept in evidence.reported_address); and Linux Hopper admission tightened to publisher-signed package evidence.

Migration checklist (6.4.x → 6.7.0)

  1. Pin, don't ride @latest — the tag moved three minors in a week. Pin rea-agents@6.7.0 (or @6.4.0 to reproduce older tutorials exactly).
  2. Regenerate all saved evidence bundles under the new version; do not hand-edit old JSON — the refusal is schema-level, not value-level.
  3. Expect new evidence_id values for identical inputs. Update any cross-references; the old IDs are dead, not wrong.
  4. Audit consumers of version_code — switch number parsing to string/BigInt.
  5. Update capture/native-UI error handling to the new typed-error and partial_observation shapes.
  6. Re-run rea doctor — new provider checks appear (including kuna-installation); on our host the pre-existing unsupported_host finding for opencloudos persisted in 6.7.0, unchanged from 6.4.0.

FAQ

Why does `rea evidence-export` fail with `evidence_integrity_mismatch` after upgrading?

6.6.0 made `relationship_coverage` a required identity field in saved bundles. Bundles exported before 6.6.0 lack it and are refused — we reproduced the exact refusal shown above. Regenerate the bundle under your current version; there is no migration path.

Do old tutorials still reproduce on 6.4.0?

Yes, if you pin `rea-agents@6.4.0`. Our evidence walkthroughs were recorded on 6.4.0 and remain accurate *as 6.4.0-era records* — but expect different `evidence_id` values if you re-run them on 6.7.0. That divergence is expected, not an error. Our evidence hub tracks which walkthroughs are 6.4.0-era and which are re-verified.

Which version should I lock for my own workflow?

For reproducing published tutorials (including ours), lock the version the tutorial states. For new work, use 6.7.0 and re-export your evidence under it. Never install bare `@latest` — with releases landing every few days, your toolchain and your evidence IDs can silently diverge from your notes.

Related: the setup guide (pin your version) · the rea repository guide · the REA evidence contract (deep guide) · content-addressed ID · all our evidence practices