[SunnyRad]

What this is

A one-line test expectation + its stale comment, split out of #7 on purpose. It fixes the single red that main currently carries into every PR's plugin tests on linux job.

0f1724a — "docs: reflect Core v1.3.1 as released (README pins, pairing table, stale RC note)" — updated both READMEs' install examples to sessionFlow.git@v1.3.1, updated the compatibility table to 1.2.0 ↔ v1.3.1, and removed the "v1.3.1 is a release candidate" wording from the READMEs. Core v1.3.1 is published (draft: false, prerelease: false, 2026-11-11T16:04:55Z).

tests/readme-consistency.test.ts was not updated in that commit. Lines 102–104 still say:

// Core v1.3.0 is the released tag this plugin version was tested against.
// v1.3.1 is a release candidate and must NOT appear as a stable pin yet.
assert.deepEqual([...pins].sort(), ['1.3.0']);

So the test now fails on main itself with actual ['1.3.1'] / expected ['1.3.0'].

Evidence that this is base-carried, not introduced by a PR

• Maintainer's own push run on 0f1724a: 43063357502 → completed/failure, 5 cold-start matrix jobs green, only plugin tests on linux red on install examples pin a version, not a moving branch (pass 101 / fail 1). Previous commit e85f397's run 42993530120 was success, so it localizes to 0f1724a.
• My #7 run 43073295149 has the same single not ok and nothing else; it touches only tests/bridge.test.ts + CHANGELOG.md.
• Reproduced locally on a pristine main snapshot with zero PR changes: node --experimental-strip-types --test tests/readme-consistency.test.ts → 6 tests / 5 pass / 1 fail, the one failure above.

The change — 1 file, 3 lines

-  // Core v1.3.0 is the released tag this plugin version was tested against.
-  // v1.3.1 is a release candidate and must NOT appear as a stable pin yet.
-  assert.deepEqual([...pins].sort(), ['1.3.0']);
+  // Core v1.3.1 is the released tag this plugin version was tested against;
+  // both READMEs' install examples were updated to pin it in 0f1724a ("docs:
+  // reflect Core v1.3.1 as released (README pins, pairing table, stale RC note)").
+  assert.deepEqual([...pins].sort(), ['1.3.1']);

No README, no product code, no other 1.3.0 reference touched. The remaining v1.3.0 mentions in the repo are the historical 1.1.0 ↔ v1.3.0 compatibility row, dependency prerelease pins (0.1.5-rc.3 etc.), and the "v1.3.1 is additive over v1.3.0" note — all still correct.

Verification

check	result
pristine main, single file (before)	6 tests / 5 pass / 1 fail (actual ['1.3.1'] / expected ['1.3.0'])
this change, single file	6 / 6 pass / 0 fail
mutation: assertion reverted to ['1.3.0']	precisely red again (5 pass / 1 fail); restored byte-identically → 0 fail
npm ci / npm run build	clean, Node v24.18.0
full npm test (no core installed)	102 tests / 82 pass / 0 fail / 20 skipped

The mutation step matters here: a version-bump assertion is trivially satisfiable, so the check is that reverting it to the pre-fix value turns the test red — i.e. it actually guards the pin rather than being a no-op.

Why a separate PR

Issue #6 is scoped to test-harness hygiene only and #7 is deliberately 2 files with CI already run. Folding this in would have made #7 3 files and invalidated its completed CI run — the exact "don't widen scope" constraint I committed to there. A standalone PR keeps both independently reviewable: you can take this one first to unblock main, or close it and fix it yourself if you prefer a different release-note wording.

I am not merging anything, and I will not push further commits to this branch after CI, so the result cannot be invalidated by a re-run. Decision on the release-note/comment wording stays yours — only the assertion value is a factual consequence of 0f1724a + the published v1.3.1 tag.

Branch based on current upstream main (0f1724a), one parent, diff is exactly the one file above.

[HarryHeYu]

Closing as redundant — the fix is already on main, with thanks.

This PR changes the same single assertion (['1.3.0'] → ['1.3.1']) that I landed directly on main in c4c658a (test(readme): expect Core pin v1.3.1 (was 1.3.0) in install examples), whose push CI 43156366514 is success. The base-carried red on 0f1724a that you diagnosed is therefore fixed; PR #7's CI was re-checked after that and introduced 0 new failures, and it was squash-merged as f39be17.

Your analysis was correct and is preserved: I read both of your comments on #7 and this PR's body while reviewing. You had explicitly left the choice of wording to the maintainer ("close it and fix it yourself if you prefer"), so I took the direct-to-main route to unblock the base first. The only difference is the comment wording (mine is shorter and does not cite the commit hash) — no semantic difference, no loss of attribution: you are credited in the #7 review and in issue #6's closing note.

c4c658a is the commit that repairs the pin; this PR's branch can be deleted safely. Thank you for splitting the readme pin out of #7 to keep that PR's CI result valid — that was the right call.