Repository navigation
mem-mcp 上架执行 G1–G6（MCP hubs 硬前置，运营派单） #104
Description
schemaVersion: requirement-record.v1
revision: R2
status: ready
priority: P1
productOwner: "@PeterGuy326"
technicalOwner: "unassigned"
userOutcome: "mem-mcp is listed and discoverable on the four MCP channels (official MCP Registry, Smithery, Glama, PulseMCP): installable, searchable, and parseable, with every channel entry evidenced before any external claim."
requirements:
- REQ-001
- REQ-002
- REQ-003
- REQ-004
- REQ-005
- REQ-006
acceptanceCriteria:
- AC-001
- AC-002
- AC-003
- AC-004
- AC-005
- AC-006
parent: null
dependencies: []
supersedes:
- "R1 free-form ops dispatch record (2026-08-24)"
lastDecisionAt: "2026-08-29T02:30:46Z"User problem and observable outcome
Ops dispatch (DevRel gap list, 2026-08-24, re-verified by live pull): the org's only MCP asset is this repo's mem-mcp (Go stdio, protocol 2024-11-05, ~20 tools), currently listed on zero channels — no GitHub Release, npm @fullstack-ai-infra/mem-mcp 404, no smithery.yaml, no mcp-server topic, and the tool table only exists in docs/mcp.md (unparseable by PulseMCP). G1–G3 are hard prerequisites: without them none of the four channels can list the server.
Observable outcome: each channel entry is live and evidenced — Release page, parseable README tool table + topic, Smithery validation, npm-installable wrapper, official Registry searchable, and Smithery/mcp.so/PulseMCP submissions receipted.
Requirements (G5 depends on G4; G6 depends on G1–G5)
- REQ-001 (G1): Publish a GitHub Release with install instructions and artifacts.
- REQ-002 (G2): README gains a parseable Tools table (extracted from docs/mcp.md) and the repo gains the
mcp-servertopic. - REQ-003 (G3): repo root gains
smithery.yaml(stdio launch config incl. MEM_TOKEN env declaration). - REQ-004 (G4): npm wrapper package so the Go binary can ride the official Registry (npm carrier);
npm imust launch mem-mcp. - REQ-005 (G5): publish to the official MCP Registry via
mcp-publisher; package.json gainsmcpName: io.github.fullstack-ai-infra/mem-mcp. - REQ-006 (G6): submit to Smithery and mcp.so; recheck PulseMCP topic (listing window 1–2 weeks; submission receipts posted back to this issue).
Acceptance criteria
- AC-001: Release page visible with version and install commands.
- AC-002: README contains a tool name/description table; topics include
mcp-server. - AC-003: Smithery validation passes for smithery.yaml.
- AC-004:
npm iof the wrapper launches mem-mcp. - AC-005: Official Registry search returns the server.
- AC-006: Smithery/mcp.so submission receipts posted; PulseMCP recheck scheduled with the 1–2 week window recorded.
Channel mechanism notes (verified 2026-08-23)
- Official Registry stores metadata only: npm package + GitHub login verification; mcpName must carry the
io.github.<user>/prefix →mcp-publisher initgenerates server.json then publish. - PulseMCP lists via topic automatically: requires the
mcp-servertopic plus a parseable README Tools table; appearance window 1–2 weeks.
Lifecycle, status, priority, blockers, and open decisions
- status=ready; priority P1 (assigned at formalization; original dispatch carried no priority label); technicalOwner unassigned (implementation via tech line; ops line tracks channel receipts).
- Suggested timeline from the dispatch: G1–G3 first week (zero external deps); G4–G5 second week; G6 observe 1–2 weeks after submission.
- Blockers: none for G1–G3.
Evidence plan and discipline
- Each G carries its own acceptance evidence; channel receipts are posted back to this issue.
- Discipline (from the dispatch, retained): no external "listed" claim before listing completes; after completion, ops backfills the competitor-radar ledger (P7 observation slot).
Decisions
- DEC-MEM-104-001 (2026-08-29T02:30:46Z): record formalized to requirement-record.v1 (R2) per founder-approved governance completion batch (2026-08-29); R1 free-form dispatch content restructured without semantic change; status=ready (dispatch fully specified), priority P1 assigned at formalization (no prior priority label). Decision comment: mem-mcp 上架执行 G1–G6（MCP hubs 硬前置，运营派单） #104 (comment)
Revision history
- R1 (2026-08-24): free-form ops dispatch record as created (DevRel gap list, 2026-08-24).
- R2 (2026-08-29T02:30:46Z): formalization revision — requirement-record.v1 with numbered REQ/AC, Decisions, and revision history; scope unchanged. Decision comment: mem-mcp 上架执行 G1–G6（MCP hubs 硬前置，运营派单） #104 (comment)
Activity
PeterGuy326 commentedon Aug 25, 2026
分诊处置：保留（运营线执行载体，清库留痕，CEO 派单 2026-08-26）
裁决：mem-mcp 上架执行 G1–G6 为运营负责人/DevRel 线的在途派单载体（MCP hubs 硬前置），产品线不按偏离关闭。
产品锚点：mem-mcp 作为记忆能力外化通道，未来与 org-workbench 簇 #37⑥（网盘=项目大脑）的挂接另行立项评估；G1–G6 执行与验收口径维持运营线既定安排。
—— 产品经理 P9（triage 裁决）
PeterGuy326 commentedon Aug 26, 2026
现势核验单回执（技术 P9 · 任务 #10，8/27 前回收）
基线：main @
4c714aa（2026-08-23）；核验执行 2026-08-26，独立 worktree + 本地复跑 + main CI 留痕。证据刻度 E1（文档阅读）→ E2（单测本地绿）→ E4（main CI head 级绿）。① 工具清单一致性：一致，且口径需更正。 实现注册 26 工具（
TestRegisterAll_RegistersExpectedToolNames钉死，本地复跑 PASS），docs/mcp.md表格 26 工具与实现集合 diff 为空。派单中"约 20 工具"为过时口径，现势 26，外宣须用 26（附基线）。mem_ask已退役，口径干净。② grant-revoke-forget + provenance 验证状态：
mem_putsource_metadata 为规范溯源对象（source_kind/source_name/captured_at/location），MCP/CLI/API 三面测试齐。③ 一核四通道可复现范围（现势）：
宣言回填口径（供 DevRel）：mem core across API/MCP/CLI/UI 可升 ✅ 已验证（基线 4c714aa）；grant/revoke 治理面标 ⏳ 不写 works；MCP distribution 维持 ⏳（G1–G6 在途、零上架，上架前不得宣称）。
全文存档：workspace
outputs/mem-核验单-证据等级-2026-08-26.md（含最小复现命令集）。—— 技术 P9
PeterGuy326 commentedon Aug 29, 2026
fix(mcp): cover windows and linux-arm64 in mem-mcp distribution
feat(mcp): MCP distribution packaging — G1–G6 for mem-mcp publishing (#…
PeterGuy326 commentedon Aug 30, 2026
Decision comment (Tech P9) — ownership routing for the six permission-gated steps from PR #105's "Who has to do what", requested in the ops thread 2026-08-29.
mcp-serverrepo topic (G2)v0.1.0, aligned withnpm/package.json@fullstack-ai-infra/mem-mcp(G4)oslinux/darwin/win32, postinstall downloader aligned with Release assets, platform map single-sourced innpm/platforms.jsmcp-publisher(G5)mcpName: io.github.fullstack-ai-infra/mem-mcpalready in place (merged via #105); runs after G1 + G4Dependencies unchanged: G5 depends on G4; G6 depends on G1–G5. Discipline retained from the dispatch: no external "listed" claim until each channel is evidenced; after completion ops backfills the competitor-radar ledger.
chore(release): cut v0.1.0
PeterGuy326 commentedon Aug 30, 2026
G1 (GitHub Release) — DONE, evidence read back
mem-mcp v0.1.0 released via the release workflow (run 33324440841, all jobs green). Tag
v0.1.0→ commitd2dd534(GOFLAGS fix #115 + download-artifact SHA fix #117).Release assets (7):
mem-mcp-checksums.txt(SHA256SUMS)mem-mcp-linux-amd64,mem-mcp-linux-arm64mem-mcp-darwin-amd64,mem-mcp-darwin-arm64mem-mcp-windows-amd64.exe,mem-mcp-windows-arm64.exeRelease: https://github.com/fullstack-ai-infra/mem/releases/tag/v0.1.0
Remaining gates
@fullstack-ai-infra/mem-mcpwrapper (npm/ , v0.1.0) downloads the release binaries at install time. Needs a publish token for thefullstack-ai-infranpm org.io.github.fullstack-ai-infra/mem-mcpalready in npm/server.json).Discipline held: no external "listed" claim until each channel is evidenced.
waterbro-8 commentedon Aug 31, 2026
独立核验回执:上架渠道代码侧已就绪,剩余全卡 npm token(技术核验)
核验范围:main @
d2dd534(v0.1.0),本地复跑 + 四渠道实查,执行 2026-08-31。证据刻度 E1(制品阅读)→ E2(本地复跑绿)→ E3(外部渠道实查)。① G1–G3 代码侧:完成
npm/server.json26 工具集合 diff 为空;repo 已带mcp-servertopicstartCommand/commandFunction/configSchema结构与microsoft/mcpsmithery.yaml 一致(当前 Smithery schema)。校验回执需 Smithery 账号smithery mcp publish产出,无法离线取证② G4 npm wrapper:代码完成,端到端本地验证通过,发布阻塞于 org npm token
E3 本地链路复跑(npm pack → tarball 安装 → postinstall → 启动):
npm pack产出 6 文件 tarball(package.json/install.js/mem-mcp/platforms.js/README/LICENSE)mem-mcp-linux-amd64mem-mcp --help经 wrapper 正常启动二进制,输出-server/-token/-workspace用法结论:wrapper 代码路径可用,
npm i即装即跑在代码层已成立。唯一缺口 =@fullstack-ai-infranpm org 的 publish token(G4 owner = founder line)。③ 四渠道现势实查(E3):零上架确认
io.github.fullstack-ai-infra/mem-mcp已就位待发)smithery mcp search mem仅返回无关的 mem.ai)④ 结论:无可提 PR,瓶颈是凭证不是代码
四渠道串联依赖 npm 发布:G5 以 npm 为载体;G6 Smithery stdio 模式靠
commandFunction装 npm 包本地运行,npm 没发则提交也装不上;mcp.so 同理。只要 org 不给 npm token,四渠道一个都动不了。#120(checksum 校验,0.1.1 前置)与 #118(download-artifact pin)已覆盖 npm wrapper 健壮性缺口,不另提 PR。
⑤ 一个口径缺口(记录层,非代码)
#104 的 user outcome 列四渠道为「Registry、Smithery、Glama、PulseMCP」,但 G6 REQ 写的是「Smithery 和 mcp.so」——Glama 在任何 REQ/AC 无对应项。建议 owner 定夺 Glama 是否纳入 G6。
下一步(需 owner 执行)
@fullstack-ai-infranpm org 的 publish token → 发 v0.1.1(勿发 0.1.0,fix(npm): verify release binary checksums #120 警示)mcp-publisher(mcpName 已就位)smithery mcp publish+ mcp.so,回执贴回本 issuesmithery mcp publish流程一并产出fix(npm): verify release binary checksums (#120)
sun-970 commentedon Sep 1, 2026
口径缺口提示（外部贡献者审阅）
在跟进 #104 上架执行时，发现两个口径不一致，供 owner 定夺：
① Glama 在 REQ/AC 中缺失
issue body 的
userOutcome列四渠道为「official MCP Registry, Smithery, Glama, PulseMCP」，但 REQ-006 / AC-006 仅覆盖「Smithery 和 mcp.so」——Glama 没有任何 REQ/AC 对应项。核验者 waterbro-8 的独立核验回执也指出了同一缺口（「建议 owner 定夺 Glama 是否纳入 G6」）。建议 owner 明确裁决：
userOutcome将 Glama 移除，使四渠道与 REQ/AC 一致。② npm 包名 / mcpName 与仓库坐标的一致性
当前状态：
@fullstack-ai-infra/mem-mcpio.github.fullstack-ai-infra/mem-mcp（npm/server.json、npm/package.json）https://github.com/bytefolk/mem（已迁移）Official MCP Registry 要求
mcpName携带io.github.<user>/前缀，其中<user>是 GitHub 登录名。请 owner 确认：fullstack-ai-infra（bytefolk是显示名或 alias），则当前mcpName正确，无需改动。bytefolk，则mcpName应更新为io.github.bytefolk/mem-mcp，npm 包名也需相应调整（@bytefolk/mem-mcp），并在 v0.1.1 发布前完成。这两项不影响 G1–G3 的已完成验收，但会在 G5（Registry 发布）和 G6 提交时成为阻塞项，建议尽早裁决。
sun-970 commentedon Sep 1, 2026
跟进：② 已由 #142 解决，① 仍待裁决
PR #142（
10d4bf7，2026-09-01 合入）已将仓库 URL 统一迁移到bytefolk/mem，npm 包名和mcpName按 cutover 计划暂保留fullstack-ai-infra坐标，等 org rename 窗口完成后统一切换。② 已关闭。① Glama 缺口仍待 owner 裁决：
userOutcome列 Glama 为四渠道之一，但 REQ/AC 无对应项。请 owner 明确纳入或移除，以便 G6 执行口径完整。PeterGuy326 commentedon Sep 1, 2026
G1 release evidence (founder 08-30 ruling: G1 = v0.1.0) — read back
Release: https://github.com/fullstack-ai-infra/mem/releases/tag/v0.1.0
(resolves via the org fork parent to bytefolk/mem; same release object)
Tag
v0.1.0→ commitd2dd534(GOFLAGS #115 + download-artifact SHA #117). Release workflow run 33324440841 all green.SHA256SUMS (mem-mcp-checksums.txt):
6 platform binaries + checksums published. mem has no npm/GHCR channel in release.yml (per repo channel discipline, G1 = GitHub Release is the published channel).
Downstream: G5 (official Registry) depends on G1+G4; G6 depends on G1–G5 (DevRel fire-ready). G4 (npm publish) pending org npm token (browser 2FA in progress).
PeterGuy326 commentedon Sep 1, 2026
G4 (npm publish) — implementation landed as dedicated workflow; two founder action-items
Implemented (PR #152):
npm-publish.yml— OIDC Trusted Publishing for@fullstack-ai-infra/mem-mcp:permissions: contents: read+id-token: write; noNPM_TOKEN/NODE_AUTH_TOKENcd npm && npm publish --provenance --access publicgh release viewgate), holding the G1→G4 dependencyWhy a separate workflow, not release.yml:
scripts/test_release_guards.sh(the release safety guard) explicitly forbidsnpm publishinside release.yml and requires--draft=falseto be release.yml's final command. Adding npm-publish to release.yml fails that guard. So G4 lives in its own workflow, triggered byrelease: published/workflow_dispatch(version input). release.yml is untouched and its guard still passes.Founder action-item 1 (npmjs Trusted Publisher): your npmjs Trusted Publisher config must reference workflow =
npm-publish.yml(notrelease.yml), org=fullstack-ai-infra / repo=mem / no environment.Founder action-item 2 (review): PR #152 touches
.github/workflows/, which CODEOWNERS assigns to Bindy-lbb (third independent reviewer).--admindoes not bypass it. It needs Bindy-lbb's review, or your explicit bypass.G1 (v0.1.0 GitHub Release) remains published and is the G4 prerequisite (install.js pulls binaries from the Release).
ci(release): add npm-publish job (OIDC Trusted Publishing) for mem-mcp (
waterbro-8 commentedon Sep 3, 2026
渠道实测回读（2026-09-03，against
main@1332bf4）先把话说在前面：这条只是把 AC-001…AC-006 逐条拿去对可外部读回的事实，不是验收、不代表任何一票、不隐含合并或关单。合与关由 owner 定。里面也包含一条对我自己 09-01 那条评论的更正（当时说"本机跑不了安装测试"，今天网络条件变了，跑通了）。
已达成（可回读）
main的README.md:81起是 26 行可解析的工具表；mcp-server在 topics 里（ai-agents, ai-infrastructure, knowledge-management, mcp, mcp-server, memory, self-hosted）。顺手核了一致性，结论是正面的：npm/server.json的tools数组与 README 表逐名相等（各 26 条，双向零差异），两份渠道元数据不会互相打脸。$HOME、--userconfig=/dev/null（不给--allow-scripts）的条件下装@fullstack-ai-infra/mem-mcp@0.1.1：rc=0、added 1 package, and audited 2 packages、found 0 vulnerabilities、没有任何 lifecycle script 被跑、node_modules/.bin/mem-mcp正常存在。首次显式调用mem-mcp --help：stdout 0 字节，320 字节诊断全部落在 stderr。所以 userOutcome 里"装的时候不用批准依赖 lifecycle script""诊断不污染 MCP stdio"这两句，在已发布的 0.1.1 制品上成立，不只是在单测里成立。部分达成
v0.1.0（2026-08-30T17:10Z）与v0.1.1（2026-08-31T06:34Z）均为非 draft / 非 prerelease，tag 都在，各带 6 个平台二进制 +mem-mcp-checksums.txt。但 REQ-001 那句 "with install instructions" 没满足：两个 release 的正文都只有变更日志（v0.1.1是从 CHANGELOG[0.1.1]段落渲染出来的，v0.1.0是自动生成的 What's Changed 列表），页面上一条安装命令都没有。所以"Release 页看得到版本"成立，"带安装指引"这半句要么补进 release 模板、要么由 owner 明确说不在 G1 范围内。smithery.yaml在仓库根，stdio launch config 与必填memToken都在。"Smithery validation passes" 仍是未验证：那需要他们的 validator，本机没有账号，所以这一格不能打勾。未达成
AC-005 (G5) ❌ 决定性负证据。 官方 MCP Registry 的公开 API 直接查：
search=io.github.fullstack-ai-infra→{"servers":[],"metadata":{"count":0}}search=bytefolk→count:0search=mem-mcp只回第三方io.github.Bumblebiber/hmem-mcp根因不止"没人跑
mcp-publisher"：npm/server.json的mcpName仍然是io.github.fullstack-ai-infra/mem-mcp，而 org 已经改名bytefolk。G5 发布前必须先定坐标 —— 这和 [Release] Migrate mem-mcp to @bytefolk/mem-mcp v0.1.2 #153 / chore(npm): migrate to @bytefolk/mem-mcp v0.1.2 (#153) #154 是同一次动作，分头做会做出一个带旧坐标的 registry 记录。AC-006 (G6) ❌ 但要把"没做"和"还没到期"分开。 这个线程里没有任何 Smithery / mcp.so 的提交回执，而 AC-006 要求的就是"回执贴回本 issue"，所以这半条确定没做。PulseMCP 那半边不该算失败：可解析工具表与
smithery.yaml是随 feat(mcp): MCP distribution packaging — G1–G6 for mem-mcp publishing #105 在 2026-08-29T16:44Z 落地的，mcp-servertopic 属于仓库设置项、没法从 PR 定日期（只能确定不晚于今天），所以窗口起点按 08-29 算起，今天第 5 天，还没到 1–2 周窗。我用限定站点的方式在 pulsemcp.com / mcp.so / smithery.ai / glama.ai 搜mem-mcp是零命中，但搜索引擎的收录滞后会让这个读数失真，所以它只算指示性证据，不算结论。一个仍待裁决的口径问题
@sun-970 在 2026-09-01 提的那条还没人回：
userOutcome把 Glama 列为四渠道之一，但 REQ / AC 里没有对应项，G6 的执行范围因此是不完整的。要么补一条 REQ/AC，要么把它从userOutcome移除。结论
建议 保持 open。按上面的证据，G2 与 G4 可以打勾；G1 缺 Release 页的安装指引、G3 缺一次 validator 回读；剩下的大头是 G5/G6 的实际提交与回执，而这两步同时被 npm 坐标迁移（#153）和
bytefolk/.github#22的 npm 凭据 HOLD 挡着。userOutcome 那句"listed on zero channels"目前仍然成立，但性质变了：从"东西没有"变成"东西都造好了、还没交出去"。一条需要更正的记录（免得有人照它开 bug）
已发布的 0.1.1 里
install.js实际下载走的是https://github.com/fullstack-ai-infra/mem/releases/download/v0.1.1/...，看着像"安装器还指着旧 org"。这不是源码缺陷：main:npm/install.js:34已经是bytefolk/mem，那串旧坐标来自 2026-08-31 发布的不可变制品自己。它现在靠 org 改名重定向存活，下一次发布会自动带走 —— 不用为它单开 issue，但它是"下一个版本越早发越好"的又一个理由（#122 的 OIDC 实测需要同一个版本）。waterbro-8 commentedon Sep 3, 2026
The Glama gap is not new: @sun-970 raised it on 2026-09-01 (#5489824037, followed up in #5489897162) and I restated it in the 2026-09-03 read-back (#5519961115). What changed is that it is now a decision to be made rather than an observation -- the founder's instruction today is "要么把 Glama 从
userOutcome删掉,要么在 R2 里补对应的 REQ/AC,产品定,别挂着". This comment exists to make that one-edit decidable, and adds one fact nobody has written down yet.New fact: the mismatch runs both ways
userOutcomeGlama is promised and unspecced. mcp.so is specced and not promised. Removing only Glama therefore leaves the record inconsistent in the opposite direction rather than fixing it --
AC-006would still require a receipt for a channel the stated outcome never mentions. Any resolution needs both names settled in the same pass.Also unchanged so far: with R2 as written there is no criterion whose failure would tell a reviewer Glama was skipped, which is why "every channel entry evidenced before any external claim" is currently unverifiable for that channel.
Option A -- drop Glama (edit-only, no new work)
In the
requirement-record.v1block,userOutcomebecomes three channels andmcp.sois named:Cost: zero implementation work. Requirement and acceptance lists stay as they are, because REQ-006/AC-006 already specced mcp.so -- this edit makes the outcome match the plan instead of the reverse. The "four" count survives unchanged.
Option B -- keep Glama (one AC plus one unverified prerequisite)
requirementsgainsREQ-007,acceptanceCriteriagainsAC-007:Before AC-007 can be written honestly, Glama's entry mechanism has to be verified and recorded under "Channel mechanism notes" the way the Registry and PulseMCP mechanisms were. Nothing in this issue establishes whether Glama auto-discovers from the
mcp-servertopic, imports from the official Registry, or needs its own submission -- and that determines whether G7 is a submission task or a monitoring task. An AC for an unverified mechanism produces a criterion nobody can satisfy, which is exactly the shape the 1-2 week window note in G6 exists to prevent. mcp.so needs the same mechanism note either way, since it is already specced and still unverified.Either way
This should land as R3 with a
Decisionsentry, the wayDEC-MEM-104-001recorded R2 (#5459795704) rather than as an unattributed body edit --userOutcomeand the REQ/AC lists live inside the machine-readable block, so the revision and the decision record are how anyone downstream learns the outcome changed.Recorded ownership:
productOwner: @PeterGuy326,technicalOwner: unassigned. I have not edited this issue's body, opened a PR against it, changedstatus, or picked an option -- A and B are not equivalent in cost and that trade-off is the product call.waterbro-8 commentedon Sep 17, 2026
No change to the 2026-09-03 read-back. I cannot finish G5/G6 from this environment.
Still true:
main(README tools table,mcp-servertopic, npm wrapper,smithery.yaml).mcpNameisio.github.bytefolk/mem-mcpin source, blocked on npm scope migration [Release] Migrate mem-mcp to @bytefolk/mem-mcp v0.1.2 #153 / chore(release): prepare ByteFolk mem-mcp 0.1.2 #193 and org npm credentials.userOutcomeis still an unmade product decision (A vs B in the 2026-09-03 comment).I will not claim any channel listing. Keep open.
waterbro-8 commentedon Sep 18, 2026
G5 按约定顺序推进，停在 founder 凭据，没有宣称已上架。
npm whoami仍是 ENEEDAUTH；@bytefolk/mem-mcp仍 404。Parent .github#22 HOLD。需要 org 绑定 Trusted Publisher：repo=bytefolk/mem，workflow=npm-publish.yml，environment=npm-release。io.github.bytefolk/mem-mcp）。无 tag、无 npm publish、不 deprecate 0.1.1。docs/maintainers/releasing.md打 tag（维护者动作，这条 PR 不打）。MCP Registry Publish（mcp-publisher login github-oidc）。npm 上还没有@bytefolk/mem-mcp时 job 会主动失败，避免写出坏的 Registry 记录。waterbro-8 commentedon Sep 19, 2026
G5 预备 PR #222 head
72b9347：独立技术 Approve（wadrzl / sun-970），hosted CI 21 pass，MERGEABLE。仍 未合（CODEOWNER；崔泽生 CHANGES_REQUESTED 挂在旧 headb57cf1c）。不打 tag、不 npm publish、不 dispatch Registry。feat(release): add OIDC workflow for official MCP Registry (G5)
feat(release): add OIDC workflow for official MCP Registry (G5)
chore(release): rebase ByteFolk mem-mcp 0.1.2 and add MCP Registry OI…