docs(gaps): close GT-634 — 1.2.2 is published, and the row's security framing was wrong - #293
Merged
Merged
Conversation
… framing was wrong 1.2.2 shipped from main with provenance (run 30548042781). Verified against the REGISTRY rather than the workflow's tick: `npm view` returns 1.2.2 for both packages, both declare `@beyondnet/evolith-sdk: ^2.0.0`, both carry dist.attestations. The check that matters: installing @beyondnet/evolith-cli@latest into a directory that has never seen this workspace resolves sdk@2.0.0 and the binary boots. Before this release the same install pulled the 2026-07-18 build. CRITERION 2 REFUTED THE ROW'S OWN PREMISE, which is the finding worth keeping. "Verify the wave's fixes are present rather than assumed" was written to stop a version number standing in for evidence. Doing it: NONE of the seven security-wave commits (1b077ab, 3a39dd0, 60bfc63, 3f31fa6, 90eacdb, 4f29e11, 8ad4e2d) touches src/packages/sdk-client — zero files each, checked one by one — and the wave's release commit 21205d2 names the three packages it affected: evolith-mcp (15 files), evolith-cli (7), evolith-agent-runtime (1). The SDK was republished alongside them, not fixed. So sdk@1.1.0 predates the wave chronologically and carries none of it. There was no security exposure through this dependency. What WAS real, and what the row should have said: a caret range under 1.x cannot cross a major, so both consumers were pinned a MAJOR behind on a contract dependency, and the lockfile nested the registry tarball inside each consumer where it shadowed the workspace link — the GT-625 class. The hedge written in when the row was opened (it measured dates and resolution, not contents) is what made the correction cheap instead of embarrassing. AND A CORRECTION TO MY OWN EARLIER WORK, made rather than left standing: the GT-624 deprecations of evolith-core-domain, evolith-core and evolith-infra-providers at 1.1.0 claimed "Security fixes landed in 1.2.0". The same evidence refutes it. All three registry messages were rewritten to say those versions were republished alongside the wave, not fixed by it. A false security claim on a public registry is worse than no claim. Criterion 3: sdk@1.1.0 deprecated, with the real reason (`.passed` -> `verdict`) and an explicit "not a security advisory". Verified after `npm cache clean --force` — the first read-back served the previous message from cache. Left open on purpose and recorded: cli@1.2.1 and mcp@1.2.1 are not deprecated (stale contract, not exposure, and one patch old is an owner's call), and contracts@1.1.0 still has no successor to point a deprecation at. Verified: 08-validate-tracking (635 gaps, 611/611 EN/ES, 578 closure records), 41 at 38 dead on a clean checkout against a budget of 40, 01-validate-docs (1491 files), 04 bilingual parity, 46 chain at a fixed point, 48-validate-security- publish-lag green. Counters 595/635 -> 596/635. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
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.
Pull Request Summary
Closes GT-634. 1.2.2 is published — and verifying the second criterion refuted the row's own premise.
Published, verified against the registry rather than the workflow's tick
Run 30548042781 succeeded from
main.evolith-mcpevolith-clilatest^2.0.0^2.0.0dist.attestationsThe check that actually matters: installing
@beyondnet/evolith-cli@latestinto a directory that has never seen this workspace resolves@beyondnet/evolith-sdk@2.0.0, and the binary boots printing 1.2.2. Before this release, the same install pulled the 2026-07-18 build.The finding: criterion 2 refuted the premise
That criterion existed so a version number could not stand in for evidence. Executing it: none of the seven security-wave commits (
1b077ab6,3a39dd03,60bfc63a,3f31fa64,90eacdbc,4f29e114,8ad4e2de) touchessrc/packages/sdk-client— zero files each, checked one by one. The wave's own release commit21205d24names the three packages it affected:evolith-mcp(15 files),evolith-cli(7),evolith-agent-runtime(1). The SDK was republished alongside them, not fixed.So
sdk@1.1.0predates the wave chronologically and carries none of it. There was no security exposure through this dependency.What was real, and what the row should have said: a caret range under 1.x cannot cross a major, so both consumers were pinned a major behind on a contract dependency —
.passedagainst a payload that emitsverdict— andpackage-lock.jsonnested the registry tarball inside each consumer where it shadowed the workspace link. The GT-625 class, not a security one.The hedge written into the row when it was opened — that it measured dates and resolution, not contents — is what made this correction cheap instead of embarrassing.
A correction to my own earlier work, made rather than left standing
The GT-624 deprecations of
evolith-core-domain,evolith-coreandevolith-infra-providersat 1.1.0 said "Security fixes landed in 1.2.0". The same commit-by-commit evidence refutes that. All three registry messages were rewritten to say those versions were republished alongside the wave, not fixed by it. A false security claim on a public registry is worse than no claim.Criterion 3
@beyondnet/evolith-sdk@1.1.0deprecated, with the real reason (superseded by 2.0.0,.passed→verdict) and an explicit "Not a security advisory." Verified afternpm cache clean --force— the first read-back served the previous message from cache, which is the same lag noted in the GT-624 record.Left open on purpose, and recorded
cli@1.2.1/mcp@1.2.1are not deprecated: they resolve a superseded SDK major, which is a stale contract rather than an exposure, and deprecating a version one patch old is an owner's call.contracts@1.1.0is still that package's only published version, so there remains no upgrade path to point a deprecation at.Verified
08-validate-tracking→ 635 gaps, 611/611 EN/ES sections, 578 closure records41-validate-evidence-commands→ 38 dead on a clean checkout against a budget of 40; this closure record adds none01-validate-docs(1491 files),04-check-bilingual-parity,46chain at a fixed point48-validate-security-publish-lag→ green: every security-marked commit is inside a version the registry servesEvolith Core Quality Gates
01-validate-docs.mjsgreen.04-check-bilingual-parity.mjsgreen.Linked ADRs / Issues
Conventional Commits
🤖 Generated with Claude Code