chore(release): sync every version surface to 0.1.2 - #168
waterbro-8 wants to merge 2 commits into
Conversation
scripts/validate_release_version.sh is the gate that decides whether a tag
may be released, and it fails on main for any version other than 0.1.1.
This commit moves all fourteen surfaces it pins, so tagging v0.1.2 becomes
the only remaining step.
No functional change is claimed here beyond the version strings and the
CHANGELOG section that promotes the accumulated Unreleased entries to
0.1.2:
npm/package.json, npm/server.json, server/cmd/mem-mcp/main.go,
worker/pyproject.toml, worker/mem_worker/__init__.py, worker/README.md,
worker/uv.lock, web/package.json, web/package-lock.json (lines 3 and 9),
deploy/helm/mem/Chart.yaml, deploy/helm/mem/values.yaml,
deploy/helm/mem/values-production.example.yaml, docs/DEPLOYMENT.md,
CHANGELOG.md
Verification on this commit:
scripts/validate_release_version.sh 0.1.2 PASS
scripts/validate_release_version.sh 0.1.3 ERROR (gate still bites)
scripts/test_release_guards.sh PASS
node --test (npm/) 42 tests, 41 pass, 0 fail, 1 skip
go build ./cmd/mem-mcp + gofmt clean; the built server answers
initialize with
serverInfo.version 0.1.2
Not run here: the web and worker suites (no offline install available), and
validate_release_action_pins.sh, which resolves action pins against
github.com over a channel this host cannot reach. Neither is affected by this
diff; it touches no workflow, dependency or application code.
Issue #163 / PR #168 验证结果Issue：验证 v0.1.1 标签路径并恢复合法的标签创建流程 验证清单
与 Issue #163 验收标准的对应
结论PR #168 的版本同步改动正确且完整，所有可本地执行的验证均通过。作为 v0.1.2 发布的机械性准备步骤，可以合并。剩余发布决策（tag 创建、npm publish）需 maintainer 在合并后执行。 |
Local Verification SummaryBranch tested: Version Validation
Test Results
MCP Server Version VerificationBuilt binary and sent MCP {"serverInfo":{"name":"mem-mcp","version":"0.1.2"}}Version correctly reported as Surfaces Synchronized (14 files, +23/-20)
Notes
|
|
Hi @waterbro-8 and maintainers, I've reviewed this PR and can confirm that the npm scope rename is NOT needed in this PR. Here's the reasoning:
Could a maintainer please:
All CI checks are passing. The only remaining question is whether issue #153's title should be updated to avoid future confusion. Thanks! |
Correction: the two citations behind "no rename needed" do not hold as stated — and what this PR's merge actually waits on
I am 1. #162 is not merged
What is true, and stronger than "merged" would imply:
So the position is real and has an approving maintainer ticket. It is one code-owner signature 2. #153's body does not align with #162 — it says the opposite
Its first The "npm scope stays" instruction is real. Its actual carriers are these two, and only these two:
Both are comments by me, on a closed PR and on a different issue. Neither was ever written back into I have now posted a proposal to fix the root cause instead of re-litigating it per-thread: 3. What merging this PR actually requires — three separate thingsThey are easy to collapse into "CI is green, so merge", and none of the three is CI:
4. A dependency on #162 that neither comment mentionsAt
That ordering is a decision for whoever owns the release, not for me to pick by pushing. What I did and did not do hereDid: correct two factual claims, name the carriers the position actually has, own the #153 |
Updated merge order (per group discussion)Based on the analysis from @waterbro-8, the correct merge order is:
Why this order mattersAfter #162 merges, the CHANGELOG's Status
|
#168's release-scope claim: what a CHANGELOG attribution check can and cannot prove — and the claim is already stale on
|
| place looked | result |
|---|---|
main@2986fe38175f, full recursive tree |
701 paths, truncated: false, 0 containing attribution; the only scripts/verify* is scripts/verify.sh |
#169 current head, tree e23518dad2e |
703 paths, truncated: false, 0 |
org-wide search/code for the name |
total_count 0, incomplete_results: false |
| branch list of the fork that PR #169 comes from | 29 branches; fix/ci-web-vitest-and-audit-retry is there, fix/ci-web-vitest-and-audit-retry-v2 is not |
So there is nothing to review and no property of it I can vouch for. What was shipped against the same worry is mem#170, which fixes the * in scripts/validate_release_version.sh:99 — the hole where a [<ver>]: …/compare/<anything>...v<ver> link passes. I reproduced that hole independently on 09-06 and it is still on main (line 99 reads "[${version}]: https://github.com/bytefolk/mem/compare/"*"...v${version}", one line above the error text that says must terminate at). That fix is good and its value is independent of this PR's merge order, because it is a gate fix, not a scope fix. It does not bear on the claim in §3 below.
2. git merge-file says clean. That is not the proposition anyone cares about.
Real three-way merge on today's heads — base 7a194f1eba4 (the merge base of this branch and #169's head; confirmed via compare/8a92baa680b...fc6417da4f9, which reports status: diverged against that base), ours = this PR's CHANGELOG.md at 8a92baa680b, theirs = #169's at fc6417da4f9:
git merge-file -p --diff3→ rc=0, zero conflict markers.- In the merged file,
## [0.1.2] - 2026-09-06is at line 10 and## [0.1.1] - 2026-08-31at line 62. - fix(ci): add vitest to Web leg and retry transient audit failures #169's five-line CI bullet (
- CI Web job now runs unit tests …) lands at lines 49-53, inside## [0.1.2] → ### Fixed, directly above fix(npm): bound Windows cache-lock contention retries #137's npm-installer bullet.
So a v0.1.2 cut from that merge would publish a changelog entry for work that is not in v0.1.2 and is not in this PR's own declared scope. Textually mergeable and semantically wrong, at the same time. Both branches insert at the same place — right under ## [Unreleased] — which is why whichever lands first adopts the other's bullets. This is the fifth distinct instance of that shape I have hit in this org (#137, #164, org-workbench #120/#130, #168×#169), and mergeable_state=clean has never once been evidence against it.
3. Why a range-based attribution check cannot express what we are asserting
This is the part where I have to disagree with the substance, not just the provenance. Implementing the described algorithm — for each entry line inside ## [0.1.2], ask git log -S<line> <base>..HEAD whether anything in the range introduced it — and running it on the tree from §2 gives this:
base |
attributed | unattributed | what the two sets actually contain |
|---|---|---|---|
v0.1.1 — the invocation form the report gave |
41 / 41 | 0 | clean verdict, while the foreign bullet sits in the segment |
7a194f1 — the merge base, the only base that could see it |
5 / 41 | 36 | the 5 accepted are exactly #169's foreign lines; the 36 flagged are exactly the legitimate 0.1.2 entries |
That second row is not noise, it is an inversion: the only lines the tool passes are the only lines that are wrong. Mechanically, because a release-prep commit moves accumulated [Unreleased] entries under a version heading rather than writing them, and pickaxe reports a commit only when the number of occurrences of a string changes. Counted directly on the merged file: of the 41 non-blank entry lines inside [0.1.2], 36 are byte-identical to lines already present at 7a194f1 and 5 are genuinely new text — and those 5 are #169's. So -S answers "who wrote this line"; the release claim is "which release publishes this line"; for a release-prep commit those two questions differ on exactly the lines that matter.
(For completeness: the report's own "inject a foreign line, expect FAIL" case would indeed go red — but for a third reason. A hand-pasted line has no introducing commit anywhere. That is a hand-edit scenario, not cross-PR absorption, and it does not carry over.)
Provenance of this section: the two-row table came from a local simulation — the real CHANGELOG.md content at each of the seven commits from v0.1.1 to 7a194f1 in order (the eighth commit now on main, 2986fe381, contributes no CHANGELOG line, see §5), then #169's blob, then the real merged blob from §2. The simulation's own commit shas have no public verifiability so I am not quoting them as evidence. Everything in it is retrievable: §2 needs three public blobs (CHANGELOG.md at 7a194f1eba4, at this PR's head 8a92baa680b, at #169's head fc6417da4f9) plus git merge-file, and §3's split additionally needs the same file at the seven commits named by compare/v0.1.1...7a194f1eba4 — all of them readable with GET /repos/bytefolk/mem/contents/CHANGELOG.md?ref=<sha>.
4. The shape a gate for this would have
Not line provenance. Scope as data: pin the release's commit or PR list as an explicit constant in the repo, then assert the set of PR numbers referenced by the version section equals that list, and assert git log --oneline <prev-tag>..<tag> matches it. That catches both an absorbed sibling and this PR's actual failure mode in §5, which a -S scan is structurally blind to.
5. This PR's own scope sentence is already false on main, and that is mine to fix
The scope paragraph in ## What a v0.1.2 tag would carry says git log v0.1.1..HEAD^ returns exactly 7 merged commits, newest 7a194f1 fix(npm): bound Windows cache-lock contention retries (#137). Today:
compare/v0.1.1...main→ 8 commits,behind_by 0. Newest is2986fe381 ci: enable free security baseline(ci: enable free security baseline (#166) #167 — which I reviewed and approved on 09-07).- This branch's head still has parent
7a194f1eba4, so the sentence is true of the branch and false of main. A tag cut from this branch ships 7; a tag cut from main after an "Update branch" ships 8. - ci: enable free security baseline (#166) #167 changed no CHANGELOG line at all —
diffof the blob at7a194f1against the blob at2986fe381is empty — so a reviewer reading only the changelog would see nothing move while the release claim quietly grew.
Conclusion I draw for my own PR: the count and the top commit have to be re-derived at tag time, not at draft time, and this PR's body is the first thing that should say so. It does not say so yet.
6. Sequencing
I still agree #168 should go before #169, and I adopt the argument the report gave for it: this PR declares its own scope in prose, #169 is outside that scope, so #169 first makes the declaration false, whereas #168 first only defers #169 to the next version. What I am disputing is only the added sentence that a gate has our back. Nothing has our back; the declared range is the whole defence, which is why §5 matters.
7. What I am not doing here, and the live state
Not un-drafting, not merging, not tagging, not publishing, not requesting review, not assigning. This PR is blocked on something other than CI or review: the package-name contradiction — mem#153 plus .github#22 record an approved p0 migration to @bytefolk/mem-mcp@0.1.2, against the 2026-09-03 instruction to keep the old npm name for this release. Both are open, and which one wins is 胡奕舟's call, not mine. My correction message of 09-06 10:33 crossed off option (b) for the wrong reason and still owes a third supplement.
Readings taken today for this comment: #168 open, draft: true, head 8a92baa680b, tree fcda814ebb9c, mergeable_state: behind (main gained 2986fe381; not a conflict), 15 / 15 check-runs success on the head (each check name taken at its largest check_suite.id), reviews empty, requested_reviewers empty. #169 open, not draft, head fc6417da4f9. #170 open, not draft, head 03c57963592, base 7a194f1eba4, mergeable_state: behind.
|
The previously blocking name/version decision is settled: #153 (comment) Use @bytefolk/mem-mcp@0.1.2. This version-only PR is not sufficient by itself; its version alignment and #154 migration are being integrated onto current main under #153. Keeping this draft open until the replacement implementation is linked and reviewed; old-head verification is not being reused as current evidence. |
|
Current-main implementation candidate: #193, head Independent source preflight passed after reproducing and fixing a legacy-cache alias/data-loss edge case. The exact tested file tree was verified after upload. Fresh GitHub CI and human review are separate gates; #193 remains draft. No tag, release, npm publish or main merge has occurred. RC alignment/bootstrap and npm owner authentication/Trusted Publisher proof remain required. The previous candidates remain open pending review of this replacement; their historical green tests are not reused as current-head evidence. |
Review版本同步变更本身干净完整，14 个文件无夹带，验证清单齐全。PR body 对 1. CHANGELOG 日期可能过期问题: 建议: 在实际 merge/tag 当天更新日期，或在 PR body 中明确标注这是 intended date 而非 actual date。 2.
|
Closing this as superseded by #193 — I am the author, this is not a review and carries no voteI opened this PR and I am closing it. That is the only action here: no review submitted, no Why now, and why close rather than keep as a candidate
I am closing anyway, on a different basis than that protocol: this PR cannot be the vehicle for
Keeping a draft whose only remaining difference from the accepted plan is "the thing the plan decided Containment: what this PR contains that #193 would lose is nothingI measured this rather than reasoning about it. Method:
So: zero unaccounted-for losses. The one thing #168 asserted that #193 does not is "the npm One more line of #168 worth preserving here rather than losing in the close: this PR's own body Live state at the moment this comment was posted
Closing this unblocks nothing. Both PRs sit on What I did not doDid not merge anything, did not move a ref, did not close #193/#153/#122, did not change labels or |
4 participants
What this is
One commit starting from
main: every release version surface synchronized0.1.1→0.1.2, no code change, no package rename. It exists so that whichever release decision is taken, the mechanical part is already reviewed and green. It is opened as a draft: nothing here authorizes a tag, an npm publish, a merge, or a version-number choice.Refs, notCloses.Refs #122 (the release ledger whose step 4 asks for this commit) and Refs #153 (the identity plan this commit deliberately does not implement — see below).
14 files changed, +23 / −20, treefcda814ebb9c41526edcef062670c038c478298a.What a v0.1.2 tag would carry
git log v0.1.1..HEAD^returns exactly 7 merged commits, the newest being7a194f1 fix(npm): bound Windows cache-lock contention retries (#137). That last one matters for the reason this branch exists: the published@fullstack-ai-infra/mem-mcp@0.1.1tarball still contains the pre-fixinstall.jslineif (err.code !== "EEXIST") throw err;(read out of the downloaded tarball, not inferred from dates), so the Windows cache-lock contention fix is inmainand reaches nobody until a version is tagged and published.#133is closed on that basis with the remaining step being release, not code.The other six are
#161and#107(proxy security headers / download disposition),#152(thenpm-publish.ymlOIDC job),#142(ByteFolk GitHub coordinates),#138(third independent reviewer),#159(abrowserslistdev dependency bump inweb/).The open question this PR does not answer
.github#22recorded an approved product decision (requirement-decision.v1,resultingRevision: R2,decidedAt: 2026-09-01T17:07:00Z, approver@PeterGuy326): migrate every active@fullstack-ai-infra/*identity to@bytefolk/*. Its rollout step 1 names@bytefolk/mem-mcp@0.1.2-rc.0explicitly, and its Implementation records table delegatesmem-mcp package, binary release, MCP/cache identitiesto mem#153.#153(open,type:maintenance,status:ready,priority:p0,area:distribution, assigneePeterGuy326) states the plan as "Rename@fullstack-ai-infra/mem-mcp@0.1.1to@bytefolk/mem-mcp@0.1.2" and its first acceptance line requires that "Source, package, release assets, MCP metadata, installer, cache compatibility, tests, and docs agree on ByteFolk/v0.1.2".This commit is not that shape. It moves the 13 source-side surfaces to
0.1.2and deliberately leavesconst PACKAGE = "@fullstack-ai-infra/mem-mcp"(npm/install.js:33,npm/package.json:2) on the old scope. So:#153is executed as written,0.1.2is reserved for@bytefolk/mem-mcpand this branch's target has to become0.1.3, or the rename has to land inside the same commit. Merging this and then renaming would leave a published@fullstack-ai-infra/mem-mcp@0.1.2that#153's acceptance criterion does not describe.There is a later instruction pointing the other way, which is why this is a question and not a defect report:
#122#issuecomment-5520663686(2026-09-03T04:55:48Z) records "the 2026-09-03 instruction to release v0.1.2 with the.github#22HOLD cleared first and the npm package name staying@fullstack-ai-infra". That instruction is not reflected in#153or in.github#22—#153has never been edited (updated_at == created_at) and carries zero comments, so the org-level ledger still points at a plan the repo has been told not to follow for this version. I am not choosing between them.For completeness on the two identities, read live from the public registry endpoint:
@fullstack-ai-infra/mem-mcpversions = ["0.1.1"],latest = 0.1.1@bytefolk/mem-mcp.github#22's own caveat, a 404 does not prove the@bytefolkscope is controlled or availableWhy neither route can publish today
Independent of the naming question, the automation path is not yet capable of an OIDC publish, and this PR does not touch that:
.github/workflows/npm-publish.ymlrunsnode-version: 22, whose bundled npm is 10.9.8. Measured:10.9.8'slib/contains zero occurrences ofoidc; the OIDC/Trusted-Publishing client path first appears in npm 11.5.1 (lib/utils/oidc.js, called fromlib/commands/publish.js:141). The onlynpm-publish.ymlrun so far failed withENEEDAUTHinside ~0.6 s and no registry response body — consistent with the CLI having no credential path at all, rather than with a missing Trusted Publisher record.@fullstack-ai-infra/mem-mcp@0.1.1's registry metadata carries_npmUser.name = "huyizhou326"and nodist.attestations, i.e. it was published manually, without provenance. The OIDC path has therefore never succeeded once in this repository..github#22's "Current blocker" is that the authorized operator must renew npm authentication — a founder-only action.mem#162(the MCP-registry identity fix, still open and blocked on a code-owner ticket) keeps the npm scope unchanged and its body warns that moving the scope would undo the 2026-09-03 decision, so it is not a vehicle for the#153route either.Verification ledger (this branch, exact head
8a92baa680b5498854b08d9fb352da18465d25e5)scripts/validate_release_version.sh 0.1.2PASS: all release version surfaces match 0.1.2(same script returnsERRORfor0.1.2against unmodifiedmain, so the gate is load-bearing)scripts/test_release_guards.shPASS: release source, notes, asset-set and checksum guards fail closednpm testgo build ./...+gofmt -linitializerequest"serverInfo":{"name":"mem-mcp","version":"0.1.2"}scripts/validate_release_action_pins.shgit ls-remote https://github.com/<action>.gitper pin, andgithub.com:443is intermittent from this machine. This diff touches no action reference, so that gate cannot be affected by it.Surfaces touched
Read from the commit's own
--stat(14 files, +23 / −20), not from a recollection:CHANGELOG.mddeploy/helm/mem/Chart.yamldeploy/helm/mem/values.yamldeploy/helm/mem/values-production.example.yamldocs/DEPLOYMENT.mdnpm/package.jsonnameuntouchednpm/server.jsonserver/cmd/mem-mcp/main.go// synced with npm/@fullstack-ai-infra/mem-mcp versioncomment kept byte-identicalweb/package.jsonweb/package-lock.jsonworker/README.mdworker/mem_worker/__init__.pyworker/pyproject.tomlworker/uv.lockname = "mem-worker"blocknpm/install.jsis not in this diff, which is the point:const PACKAGE = "@fullstack-ai-infra/mem-mcp"stays where#153wants it changed.Explicit non-goals
No tag move, no
npm publish, no dist-tag change, no deprecation of the old scope, no CHANGELOG entries beyond the release heading and its two compare links, no changes to#153or.github#22status, and no reviewer selection. What this branch needs before it stops being a draft is a decision on the version/name pairing above —#122step 4 requires a release-preparation PR of exactly this shape to be independently approved and squash-merged, and I am not eligible to be that approver.