Skip to content

docs(maintainer): blueprint completeness and strategy review - #1766

Merged
Ikalus1988 merged 1 commit into
mainfrom
docs/blueprint-strategy-review
Sep 16, 2026
Merged

docs(maintainer): blueprint completeness and strategy review#1766
Ikalus1988 merged 1 commit into
mainfrom
docs/blueprint-strategy-review

Conversation

@Ikalus1988

@Ikalus1988 Ikalus1988 commented Sep 16, 2026 •
edited by github-actions Bot
Loading

Copy link
Copy Markdown
Owner

User description

A critical pass over what the product is today, from the four angles asked for: someone who does not know AI, a first-time agent user, multi-agent/collaboration, and commercialisation. Every claim carries a path or a number; unverifiable items are marked.

The three findings that matter

1. The trust layer is declarative, not verifiable. Audited all 440 lessons:

metric value
lessons with provenance 398 (90%)
lessons with evidence_level 96 (22%)
lessons with evidence_refs 3 (0.7%)
lessons citing any external URL 32 (7%)
provenance.source values community 289 / external 80 / internal 14 / … → 96% uncheckable labels

And the gates cannot see the difference: #1713 was 24/24 green while its source: pointed at modelcontextprotocol/mcp-memory-service, a repository that returns 404. CI checks structure, DCO and injection — not truth. So the bottleneck for "verifiable failure memory" is currently maintainer attention, which does not scale to the corpus size the flywheel needs. The cheapest structural reinforcement is a resolvability check on source: URLs (~10 lines + one CI step); it will not catch semantic falsehood, but it removes the cheapest and most numerous class of pollution.

2. "Multi-agent collaboration" is not what exists yet. What exists is one knowledge base read by several agents. No task layer, no handoff, no conflict detection, and identity is self-declared (AGENTS.md §3.3 says agent_type/client_id are not attribution evidence). The missing piece is a lease/receipt layer, and it could sit on the events table that already exists.

3. Both candidate labels score 0.5/1. "Improves efficiency" has cases but no measurement (no A/B, no hit-vs-missed comparison); "useful to large organisations" has potential but no deliverable — docs/rfc-280-90-day-roadmap.md Vision 4 mentions enterprise/federated deployment with no PRD behind it. The two cheap moves that would take both to 1: quantify hit-vs-missed tasks from data me_events already records, and two pages of self-hosting notes (data boundary / audit / quota) to test whether that demand is real.

The document also carries the 5-layer puzzle inventory, per-segment breakpoints for the non-technical user (the first-question example is English error text while the same corpus answers natural-language Chinese questions with zero hits), the flywheel diagram with its two leaks, and ten weakest assumptions each with a falsification test.

Docs only — no code. Says plainly which numbers are unverified (cloud.google.com link unreachable from this machine).

PR Type

Documentation

Description

  • Adds critical product blueprint review across four user angles

  • Audits trust layer: 440 lessons, 96% uncheckable sources

  • Identifies three hard gaps in current product state

  • Recommends six next steps ordered by leverage ÷ cost

Diagram Walkthrough

flowchart LR
  Crash["崩溃"] --> Tomb["墓碑 fatal-guard"]
  Tomb --> Draft["draft lesson"]
  Draft --> Index["语料索引"]
  Index --> Hit["检索命中"]
  Hit --> Event["E4 复用证据"]
  Event --> Rank["排行榜/声誉"]
  Rank --> More["更多贡献"]
  Draft -. "漏点① 自律提交" .-> Draft
  Hit -. "漏点② 无可感回执" .-> Event
Loading

File Walkthrough
Relevant files
Documentation
blueprint-and-strategy-review-2026-09-16.md
Blueprint completeness and strategy review                             

docs/maintainer/blueprint-and-strategy-review-2026-09-16.md

 +184/-0 

@Ikalus1988
docs(maintainer): blueprint completeness and strategy review
d5622fe 
A deliberately critical pass over what the product actually is today, from four angles
the user asked about: someone who does not know AI, someone using an agent for the first
time, multi-agent/collaboration, and commercialisation. Every claim carries a file path
or a number that can be re-derived; anything unverifiable is marked as such.

Three findings worth the read on their own:

- The trust layer is declarative, not verifiable. 440 lessons: 398 carry `provenance`,
  but 96% of those values are uncheckable labels (`community` / `external`); only 22%
  carry `evidence_level` and 0.7% carry `evidence_refs`. Meanwhile CI is green on a PR
  whose `source:` points at a repository that does not exist (#1713) — structure, DCO and
  injection scanning cannot check truth. Today the trust bottleneck is maintainer
  attention, not machinery, and that does not scale to the corpus size the flywheel needs.

- "Multi-agent collaboration" is not what exists yet. What exists is one knowledge base
  read by several agents: no task layer, no handoff, no conflict detection, and
  `agent_type`/`client_id` are self-declared (AGENTS.md §3.3 says so). The missing piece
  is a lease/receipt layer, which could sit on the existing events table.

- Both candidate labels score 0.5/1 today. "Improves efficiency" has cases but no
  measurement; "useful to large organisations" has potential but no deliverable (RFC-280
  Vision 4 mentions enterprise deployment, and there is no PRD behind it).

Also records the two cheap moves that would move the labels to 1: quantify
hit-vs-missed tasks from data already in `me_events`, and write two pages of
self-hosting notes (data boundary / audit / quota) to test whether B-class demand exists.

Signed-off-by: Ikalus1988 <136884451+Ikalus1988@users.noreply.github.com>
@Ikalus1988 Ikalus1988 added area:docs docs-only Only documentation files changed shape-safe labels Sep 16, 2026
@github-actions

github-actions Bot commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶

1713 - Partially compliant

Compliant requirements:

  • None

Non-compliant requirements:

  • Add a new lesson documenting alembic migration chain divergence
  • Include diagnosis commands
  • Include fix-by-scenario playbooks
  • Problem section: alembic upgrade head fails after dependency update
  • Root cause section: migration chain diverges from alembic_version table
  • Solution section: diagnose → stamp/merge/rollback per scenario
  • Prevention section: alembic check before upgrade, backup before migrate
  • Closes [Bounty][$0][Lessons] 把 intake #1553（alembic upgrade 失败）转成课程 #1652

Requires further human verification:

  • None (the PR contains none of the alembic lesson content; verification would not change the result)
⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Scope Mismatch

Ticket #1713 asks for a new lesson on alembic migration chain divergence (problem/root cause/solution/prevention, closes #1652). The PR adds a 184-line maintainer strategy review document that uses #1713 only as a case study. The actual alembic lesson content requested by the ticket is not delivered in this PR at all, so the ticket cannot be closed by this change.

 
# 蓝图与拼图完整性审视 —— AI 陌生人 / 首次用 agent / 多 agent / 商业化

> 日期：2026-09-16 · 审视者：DSH agent（维护者侧）
> 方法：只采信能在本仓复现的证据，每条结论附文件路径或命令；无法验证的显式标注 **未验证**。
> 语气：按维护者要求"挑剔"——宁可把结论写成"目前只有 0.5"，也不要写成"已完成"。

---

## 0. 结论摘要（先给判断，再给论证）

**拼图的底座三层已经成型，第四层（信任）是"声明式"而不是"可验证式"，第五层（生态/商业）只有草案。**

三个最硬的缺口，按"卡住多少条路径"排序：

1. **信任不可自动验证**：provenance 字段 90% 存在，但其中 **96% 的取值是不可核验的标签**（`community` / `external`）；只有 22% 的课程带 `evidence_level`、0.7% 带 `evidence_refs`。本轮就抓到一个 **24 项检查全绿、来源链接却指向不存在仓库** 的 PR（#1713）。CI 查结构 / DCO / 注入，查不了真伪 —— 于是**信任的瓶颈是维护者的注意力，而不是机制**。
2. **对"不熟 AI 的打工人"（PRD 目标用户）装机已接近傻瓜化，但"第一次拿到价值"仍依赖模型自律** —— 这是产品无法控制的变量，而且**目前不可测量**（没有任何埋点回答"装完之后它到底调用了吗"）。
3. **"多 agent 协同"目前不成立**：现在是"同一个知识库被多个 agent 读"，不是协同。缺任务认领/交接/冲突处理一层，且 `agent_type` / `client_id` 自声明不可验证（`AGENTS.md` §3.3 已自认）。

商业化方面：飞轮的三段（贡献→命中→声誉）都真实存在，但**有两处在漏**——"崩溃/经验→课程"靠自律，"命中→可感价值"没有回执。两个候选标签当前都只能算 **0.5/1**（"能提效"有案例无量化；"对机构有益"有潜力无落地）。

---

## 1. 拼图全景（五层 × 现状 × 证据 × 缺口）

| 层 | 已有什么 | 证据（可查） | 完成度 | 缺口 |
|---|---|---|---|---|
| ① 服务 | `https://misakanet.org/mcp`，7 个 MCP 工具，streamable-http + SSE，D1 语料，检索配额，检索响应带 `voice` / `trust_notice` / `structuredContent` | `workers/register-proxy-sw.js`、`AGENTS.md` §3、`API.md` | **高** | 无 tenant/组织概念；配额是 IP 级；无检索质量指标对外 |
| ② 接线 | npx 安装器（含 `--voice` / `--report` / `--verify` / `--uninstall`）、Python 安装器、5 个 agent 目标 + DSH 插件、Claude Code 只读工具预放行 | `packages/misakanet-setup/bin/misakanet-setup.mjs`、`integrations/agent-autostart/install_misakanet_agent.py` | **高** | 两份实现靠测试维持等价（历史上漂移过多次）；无代理/内网探测 |
| ③ 触发 | 祈使式规则块（1–6 编号，触发条件在第 1 行）、checkpoint hook（第 1 轮公告 / 第 20 轮沉淀提醒 / 失败后"先查再重试"）、14 天升级提醒、语音提示 | `PROMPT_BLOCK`、`integrations/agent-autostart/checkpoint_reminder.mjs` | **中高** | "是否真的被调用"不可观测；Codex 无用户级 hook（靠规则块自律） |
| ④ 信任 | `provenance` / `evidence_level` / `evidence_refs`、`misakanet_me_events`（E4 复用证据）、leaderboard、DCO、注入扫描四层、lesson gate | `lessons/*.md`、`scripts/lesson_gate.py`、`scripts/injection_scan.py`、`workers/*` | **低**（见 §3 数据） | 来源不可自动核验；E 级无定义文档化；复用证据只到节点级 |
| ⑤ 生态 | 节点注册（PRD ⑥）、JOIN/bounty 流程、MCP registry 元数据（`server.json` / `.well-known/mcp.json`）、intake→issue 闭环、外部报料回执 | `docs/prd/`、`JOIN.md`、`scripts/register*` | **低-中** | 零金额 bounty 的持续供给未验证；无外部采用者；无企业形态 |

**一句话**：①②③ 已经把"一个 agent 在第一次踩坑前会去查"这条最短路径修通（本轮的 macOS 两轮测试就是证据，见 §2.2），但 ④⑤ 还撑着整条叙事。

---

## 2. 四类用户的路径审查

### 2.1 对 AI 陌生的人（PRD 的目标："傻瓜式管理"）

**现状路径**：`npx @misaka-net/misakanet-setup` → 关掉重开会话 → 随便问一句带报错原文的片段 → agent 先查库。

**已经做对的**：一条命令、零依赖、不写 token 到命令行、每个文件先备份、`--uninstall` 精确回退、`--report` 可公开贴、`INSTALL_FOR_ME.md` 面向非技术人。

**断点（挑剔）**：

1. **首问示例是英文错误片段**（`switch vision model` / `context window exceeded`）。目标用户不会想到用英文片段提问；而中文自然语言问句在本语料上**命中为 0**（本轮实测，"如何切换识图模型"这类整句检索不到东西——语料是按错误文本/关键词索引的）。这条把"第一次体验"直接暴露给最不会用的人。
2. **价值不可见**。命中只多一句"我参考了别人的一条经验"，用户感觉不到"省了多少时间、避免了什么坑"。缺一条面向用户的可感回执（例如"这条经验来自 3 个节点的复用 + 2 张 helpful 票"）。
3. **出错时无法自助**。`--verify` 的措辞是开发术语（端点/握手/规则块/权限放行）；非技术用户看到 `NOT READY` 只能求助。
4. **企业内网/代理场景缺失**。语料里有 `wsl-需要代理配置` 这类教训，但安装器不探测代理、不提示镜像源——而目标用户恰恰常在受管网络里。
5. **没有 GUI**。整条路径从"打开终端"开始，这对非技术用户是硬门槛。

### 2.2 初次使用 agent 的人

**最关键的不确定性不是安装，是模型会不会用**。同一份规则块：一轮测试里 codex/mimo **没有**主动调用 MCP（#1761 Round 1 / 用户 macOS 首轮），把规则块改成祈使式并预放行工具后，Round 2 **调用了** `misakanet_search` + `misakanet_submit_intake`。也就是说"是否触发"由 **规则块文本 × 模型版本** 共同决定，仓库无法保证。

**缺口**：把"是否调用"变成可观测数字。目前 `--report` 里的 `live-call-evidence` 是**留给人手填的空白字段**——这是整份报告里唯一靠自觉的一行，而它恰好是最重要的那一行。

### 2.3 多 agent / agent 协同

**已有**：MCP 多客户端接入、节点注册、`client_id` 稳定身份、`me_events` 复用证据、intake 去重 key、排行榜。

**缺口（挑剔）**：

- 没有**任务层**语义：谁在做哪个任务、怎么交接、重复劳动如何避免。排行榜是节点级，不是任务级。
- 没有**冲突检测**：两个 agent 同时改同一文件/同一迁移，知识库层面无感知（本仓语料里已经有 `shared-json-needs-atomic-write`、`idempotent-task-claim` 这类教训，说明问题真实存在，但产品侧没接）。
- **身份不可验证**：`agent_type` / `client_id` 自声明，`AGENTS.md` §3.3 明确写了"不把它当作归属证据"。做成协同层时必须先解决"这是谁"。
- 无 A2A / agent 间协议位（RFC-280 Vision 4 提过 Federated，但没有 PRD）。

**判断**：若"多 agent 协同"是目标，缺的是一层**任务认领 + 回执 + 租约**，而不是更多检索工具。这层可以完全建立在现有 `me_events` 事件表上。

### 2.4 大公司与机构

**已有**：无。`docs/rfc-280-90-day-roadmap.md` 的 Vision 4 提到 Enterprise / Internal deployment，但**没有 PRD、没有实现、没有材料**。

机构真正会问的三件事，逐条对照：

| 机构要的 | 现状 | 雏形在哪 |
|---|---|---|
| 数据不出域（自托管/私有） | 无 | worker + D1 抽象可改造，但当前只有托管形态 |
| 可审计（谁在何时用了什么知识、谁改了什么） | 无 | `me_events` 已有事件骨架，缺 tenant/actor 维度 |
| 成本与配额可见 | 部分（IP 级限额） | 限额逻辑已有，缺按组织聚合 |

---

## 3. 信任层审计（本轮实测数据）

审计脚本扫描全部 `lessons/**/*.md` 的 frontmatter，并逐条解析外链：

| 指标 | 数值 | 含义 |
|---|---|---|
| 课程总数 | **440** | — |
| 带 `provenance` | 398（90%） | 字段覆盖率看着不错 |
| 带 `evidence_level` | **96（22%）** | 78% 的课程没有证据等级 |
| 带 `evidence_refs` | **3（0.7%）** | 几乎等于没有 |
| frontmatter 里的外链 | **32（7% 的课程）** | 93% 的课程没有任何可点的来源 |
| `provenance.source` 取值 | `community` 289 / `external` 80 / `internal` 14 / 其余零星 | **96% 的"来源"是不可核验的标签** |

32 条外链中 2 条不可解析：一条是示例用的内网代理地址（`http://172.19.128.1:7890`，属于合理用法）；另一条 `cloud.google.com/billing/...` 在本机网络不可达，**未能判定真假（未验证）**。

**本轮同时发生的三个案例，恰好说明门禁的边界**：

| 案例 | 门禁结果 | 真相 | 说明 |
|---|---|---|---|
| #1713 | 24 项**全绿** | `source:` 指向的仓库整个 404（`modelcontextprotocol/mcp-memory-service` 不存在），`provenance.issue: 1652` 是我们自己的 bounty 号 | CI 查结构、DCO、注入，**查不了真伪** |
| #1656 | gate/dco/audit 红 | 519 字节骨架 + 手改生成物 `lessons/index.md`(-146) + 无签核 | 靠门禁拦住，但也是**人**写的 review 才有意义 |
| #1646 | 4 项红 | 内容是好的，红灯纯粹因为基座落后 112 提交 | **假阳性**：更新基座后同一份内容全绿 |

**挑剔结论**：目前"可验证的失败记忆"这个叙事，实际上靠**维护者逐条读**来兑现。这在 440 篇时可行，在 4000 篇时不可行；而 4000 篇正是"飞轮"要到达的位置。**最便宜的一处结构性加固**：把 `source:` 的可解析性变成门禁（十行脚本 + 一个 CI 步骤），把"编造来源"从人工发现改成自动挡。这不解决语义真伪，但能挡住最廉价的一类污染——而廉价污染恰恰是量最大的一类。

---

## 4. 商业化：飞轮在哪，点火需要什么

### 4.1 现有飞轮（含漏点）

崩溃 → 墓碑(fatal-guard) → draft lesson → 汇入语料 → 检索命中 → 复用证据(E4) → 排行榜/声誉 → 更多贡献
↑ ↓
┌──── 漏点① ────┐ ┌── 漏点② ──┐
靠"规则块自律"提交 命中没有"可感价值"回执


- **漏点①**："经验→课程"依赖 agent 自律。规则块改了措辞才让 codex 开始提交（#1761），说明这段是**可以被文本影响的、但不稳定**。
- **漏点②**：命中之后用户/agent 拿不到"省了什么"的信号，声誉回报也停在榜单上。
- **漏点③**（顺带）：零金额 bounty（#1652 自己写着 zero-bounty）能换来 merge credit，但"投入 vs 回报"对陌生贡献者是负的——本轮 #1656 的骨架 PR 就是这个激励下的产物。

### 4.2 三个候选引爆点（附我给置信度的理由）

| 引爆点 | 机制 | 前置条件 | 置信度 | 反例/风险 |
|---|---|---|---|---|
| **A. 装机即得**（agent 首日就少踩一个坑） | 装机 → 触发 → 首次命中 | 非技术人能装 + **中文可检索** + 命中可见 | **中** | 若模型不调用，全盘失效（本轮已见过一轮失败）；示例语言不匹配目标用户 |
| **B. 组织内网失败记忆**（私有部署 + 审计 + 配额） | 团队共享"只有我们踩过的坑" | 自托管形态 + 审计事件 + 组织配额 | **中低**（需新增产品线，但没有技术天堑） | 与"公开语料"的边界会被质疑；企业采购周期长 |
| **C. 平台位**（谁定义"失败记忆"的 schema） | 被他人引用/复刻 | 外部采用者 | **低**（长期） | 目前只有自用；registry 元数据已就位但无人引用 |

### 4.3 两个标签的当前成色（逐条给证据强度）

| 标签 | 现有证据 | 缺口 | 当前成色 |
|---|---|---|---|
| **能提效** | 命中案例：cc 命中 `model-switch-script-pattern`；codex 主动检索并提交（#1761 Round 2） | **没有任何量化**：无 A/B、无"命中 vs 未命中"的耗时/轮次对比 | **0.5 / 1**（有案例，无度量） |
| **对大公司和机构有益** | 无（无试点、无合规材料、无自托管文档） | 数据不出域、审计、配额三件事都未落地 | **0.5 / 1**（有潜力，无交付物） |

**把两个 0.5 变成 1 的最便宜两步**（都不需要新工程线）：

1. **量化"命中 vs 未命中"**：`me_events` 已经记录了检索与复用事件，把"某任务是否命中课程"与"任务完成轮次/耗时"关联起来，就能给出第一个提效数字。这一步**现在就能做**，只是没人做。
2. **两页企业自托管说明**：数据不出域（哪些数据在本地、哪些必须出网）、审计（事件表能回答什么）、配额（成本如何可见）。不需要真部署，先成为**可谈判材料**，用来验证 B 类需求是否真实存在。

---

## 5. 十条最薄弱的假设（每条给证伪测试）

| # | 假设 | 证伪测试 | 现状 |
|---|---|---|---|
| 1 | 装上就会用 | 装机后 24h 内出现首次 MCP 调用的比例 | **不可测**（无埋点） |
| 2 | 语料的索引方式对目标用户可用 | 中文自然语言问句 top1 命中率 | 已知≈0（未修） |
| 3 | provenance 可信 | 外链可解析率 + 抽查来源一致性 | 96% 是不可核验标签；已有编造案例 |
| 4 | 多 agent 协同已被支持 | 两个 agent 并发使用同一知识库是否重复劳动/冲突 | 无此能力 |
| 5 | 升级无摩擦 | 用户是否需要手动重跑安装器才能拿到新行为 | 需要（#1761 已证实） |
| 6 | 匿名 5 次/天够用 | 真实用户被限流的比例 | 无数据 |
| 7 | DCO + gate + CI 足以守住质量 | 用假来源做红队测试 | **本次已被击穿**（#1713） |
| 8 | 零金额 bounty 能持续供给课程 | 近 30 天 merged lessons 的来源分布 / 认领率 | 未统计 |
| 9 | 两个安装器（JS/Python）保持等价 | 行为差异清单 | 历史多次漂移（示例文本、权限、codewhale 目标） |
| 10 | D1/Worker 能支撑机构级需求 | 是否存在 tenant 抽象 | 无 tenant 概念 |

---

## 6. 建议的下一步（按"解锁面 ÷ 成本"排序）

1. **provenance 可解析性门禁**（≈10 行脚本 + 1 个 CI 步骤）→ 把第 ④ 层从"人工可信"推向"机制可信"。**最高性价比**。
2. **中文/自然语言的检索路径**（别名索引或 FAQ 前置）→ 直接解锁 §2.1 的目标用户；否则"傻瓜式"只对会用英文错误串的人成立。
3. **首次调用可观测**（hook 记录 MCP 调用次数并写入 `--report`）→ 把"③a 模型不听话"从轶事变成数字，也让 §5 的假设 1 变得可测。
4. **两页企业自托管说明**（数据边界/审计/配额）→ 把"机构有益"从潜力变成可谈判材料，顺便验证 B 类需求真伪。
5. **多 agent 的最小协同语义**（任务认领 + 回执 + 租约，复用现有事件表）→ 补 §2.3；这一步会把产品从"知识库"变成"协作面"。
6. **非技术用户 GUI**（`docs/install/index.html` 已是落地页，可做成"复制一行命令"向导）→ **最后做**。1/2 未完成时，GUI 只会把摩擦放大到更多不会用的人身上。

---

## 7. 数据来源与复现方式

- 语料审计：扫描 `lessons/**/*.md` frontmatter（440 篇），逐条解析外链（GitHub 走 API，其余走 HEAD）：得到 §3 表格中除"案例"外的全部数字。
- 案例证据：PR #1713（24 检查全绿 + 404 来源）、#1656（骨架 + 生成物 + 无签核）、#1646（基座过期导致的假阳性）——三条 review 均在本仓可见。
- 蓝图盘点：`docs/prd/01..06`、`docs/rfc-280-90-day-roadmap.md`（Vision 1–4，其中 Vision 4 已含 Federated / Enterprise 但没有 PRD）、`JOIN.md`、`docs/maintainer/setup-value-assessment-2026-09-16.md`。
- 用户可感路径：`INSTALL_FOR_ME.md`、`packages/misakanet-setup/README.md`、`docs/install/index.html`。
- 未验证项已在文中逐条标注（如 `cloud.google.com` 外链、企业需求真伪）。
Unverifiable Audit Claims

The §3 trust-layer audit presents specific numbers (440 lessons total; 398 with provenance; 96 with evidence_level; 3 with evidence_refs; 32 with any external URL; 96% uncheckable source labels) as the empirical basis for the document's central recommendation. The audit script itself is not included in the PR nor linked from the doc, so reviewers cannot reproduce the numbers from the current corpus. Since these statistics drive the strongest recommendation (a ~10-line source: resolvability CI gate), the methodology and snapshot date should be reproducible.

 
审计脚本扫描全部 `lessons/**/*.md` 的 frontmatter，并逐条解析外链：

| 指标 | 数值 | 含义 |
|---|---|---|
| 课程总数 | **440** | — |
| 带 `provenance` | 398（90%） | 字段覆盖率看着不错 |
| 带 `evidence_level` | **96（22%）** | 78% 的课程没有证据等级 |
| 带 `evidence_refs` | **3（0.7%）** | 几乎等于没有 |
| frontmatter 里的外链 | **32（7% 的课程）** | 93% 的课程没有任何可点的来源 |
| `provenance.source` 取值 | `community` 289 / `external` 80 / `internal` 14 / 其余零星 | **96% 的"来源"是不可核验的标签** |

32 条外链中 2 条不可解析：一条是示例用的内网代理地址（`http://172.19.128.1:7890`，属于合理用法）；另一条 `cloud.google.com/billing/...` 在本机网络不可达，**未能判定真假（未验证）**。
Unsupported Public Allegation

The document publicly asserts that PR #1713 was "24/24 green" while its source: pointed at modelcontextprotocol/mcp-memory-service, "a repository that returns 404", and frames this as a fabricated-source case study. The doc does not include the relevant source: text from the PR frontmatter, the CI check-run output, or an HTTP response capture as in-doc evidence — only the assertion. Before publication, this allegation should be backed by inline evidence (CI URLs / curl output / git blame on the lesson file) so a future reader can confirm the claim rather than take it on faith from a maintainer note.

 
| #1713 | 24 项**全绿** | `source:` 指向的仓库整个 404（`modelcontextprotocol/mcp-memory-service` 不存在），`provenance.issue: 1652` 是我们自己的 bounty 号 | CI 查结构、DCO、注入，**查不了真伪** |
Ambiguous Path Reference

§7 cites docs/prd/01..06 as evidence sources. That notation is ambiguous — it could mean 01 through 06 inclusive (six files) or the literal name 01..06 — and the actual docs/prd/ directory layout is not shown in the diff. If only a subset of those PRDs exists, the link will silently mislead. Verify the path matches the real directory before merging.

 
- 蓝图盘点：`docs/prd/01..06`、`docs/rfc-280-90-day-roadmap.md`（Vision 1–4，其中 Vision 4 已含 Federated / Enterprise 但没有 PRD）、`JOIN.md`、`docs/maintainer/setup-value-assessment-2026-09-16.md`。

@github-actions

github-actions Bot commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

PR Code Suggestions ✨

No code suggestions found for the PR.

@Ikalus1988

Ikalus1988 commented Sep 16, 2026

Copy link
Copy Markdown
Owner Author

🧾 Audit Report — PR #1766 (d5622fe)

📊 Quality Score

⚠️ Quality score unavailable; continuing with hard gates.

🔏 DCO Audit

✅ All commits signed-off.

📏 PR Size

Metric Value
Files Changed 1
Lines Added 184

🔐 Secret Scan

✅ No hardcoded secrets detected.

📦 Dependency Audit

⏭️ Skipped; no Python/JS dependency files changed.

🧪 Test Suite

✅ PASS — 53% coverage

📋 Lesson Schema

✅ All lessons valid.

⚖️ Verdict

✅ All gates passed. Ready for merge.

Scope: full | Triggered by d5622fe | View run

@github-actions github-actions Bot added the ready-to-merge All checks passed, ready for maintainer label Sep 16, 2026
@Ikalus1988
Ikalus1988 merged commit e07844b into main Sep 16, 2026
24 checks passed
@github-actions

github-actions Bot commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

🎉 Merged — Thank you!

Your contribution has been merged into main.

PR: #1766 — docs(maintainer): blueprint completeness and strategy review

What's next:

  • Your code is now part of MisakaNet's failure-lesson corpus (now 393 lessons)
  • Feel free to pick up another issue labeled good first issue or status: competition
  • Questions? Ask in this thread or open a Discussion

Welcome to the MisakaNet contributor community! 🧠

@github-actions

github-actions Bot commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

✅ Merged! Thanks again, @Ikalus1988.

docs(maintainer): blueprint completeness and strategy review (+184 lines, 1 files)

Quick question — did any MisakaNet lesson help you this time?
→ Share feedback

No need to reply if nothing comes to mind. ⚡

@Ikalus1988 Ikalus1988 mentioned this pull request Sep 19, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

area:docs docs-only Only documentation files changed ready-to-merge All checks passed, ready for maintainer Review effort 3/5 shape-safe

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@Ikalus1988