需求 → 设计（这座桥）
父级：standmeet
目的
product 与 architecture 之间缺失的中间层——产品表面如何拆解为七根支柱，双向可溯：每条承诺追到它的工程实现，每根支柱也能追回它据以成立的那条承诺。同时记录 2026 年 6 月转向之后，哪些产品文档仍然具有权威性。
链条（愿景 → 承诺 → 旅程 → 设计 → 代码 → 验证）
每个子页面都把一条承诺从头走到底，每一层都带着具体的标识符：
- chain-interpretation — 访客提问；得到有声音、有依据、带角色框架的回答。(抓取面落地后已全程兑现——
corpus_links沿 owner 自己打的链接走。) - chain-explicit-push — AI 对话 → 经由 MCP 与 vault 路径，汇入一个经过整理的语料库。
- chain-selective-access — 谁能看到什么，在发放的那一刻就被冻结。(最深的一条链：设计已定稿，测试也最重。)
- chain-owner-first — 先做外部大脑，再谈受众。(在结构上是成立的；检索这一层单薄。)
- chain-machine-readable — 当提问的一方是一个 agent 时。(愿景强，工程薄。)
- chain-hiring — 第一个应用场景，还不是产品本身。(盯住这条边界。)
- chain-sovereignty — 你的基础设施、你的密钥、你的信任边界。(对抗性验证最薄弱的一环；平台迁移那个没挑明的理由，也藏在这里。)
哪些产品文档仍然有效
| 文档 | 结论 |
|---|---|
docs/features-and-journeys.md（最近改动 2026-09-06，7037a434e） | LIVE — 记录在案的产品表面：Owner / Visitor / Cross-actor 三种角色（按编号分组的旅程集合）；每个功能都带一个 e2e spec 标签；现在也收录了 vault 旅程（A12 同步、A33 抓取）、microsites、以及按 microsite 设的 SEO |
docs/design/project/IDEAS.md（5 月 30 日） | LIVE backlog — resume=git 模型（git 相关措辞已按 2026-05-28 的决定从界面里去掉）、应用打包、agentic-chat 能力这一批构想；目前都还没有构建 |
docs/product-vision.md（5 月 16 日） | HISTORICAL — 早于 2026 年 6 月的转向，立足于一个此后已被放弃的方向；不要再用。只有"数字分身应用 = 现有代码"这条映射还站得住 |
docs/growth.md（5 月 16 日） | MISFILED — 其实是一篇 OpenClaw 传播理论的案例研究，不是 StandMeet 的增长文档；其五条楞子原则可以迁移使用，只是目前没有接到任何东西上 |
这个仓库实际在用的流水线
需求到设计的转换机制，实际运作起来是这样的：features-and-journeys.md 里的每条旅程/功能都带一个e2e spec 标签（[✓ gate-access]，[ ] 表示未覆盖；有一个 gap 小节负责给这些优先级排序）→ 承重的决策会落到一份带固定标记（P.x / D-x / §x / A.x）的设计文档里 → 决策在写代码之前先被红色契约测试冻结 → roadmap 区块排定构建的顺序。用 harness 的话说：spec 标签就是关卡清单；红测试冻结那道切分线；roadmap 就是预算表。
旅程集群 → 支柱
| 旅程集群 | 旅程 | 支柱 | 关键设计 |
|---|---|---|---|
| Owner 的设置与认证 | 设置向导 · 登录 · 重置 | access-control + structure | setup-token 认领，owner-keypair-auth |
| Owner 整理语料库 | raw→wiki→output 的晋升旅程 | corpus | three-tier-corpus-promotion、writings-import-export、derived-path-corpus-as-filesystem |
| 邀请码与邀请 | 邀请码管理 · 关卡进入 · 配额 | access-control | acl-and-quota-granularity、role-snapshot-frozen |
| 访客聊天与公开页面 | 访客旅程集合 | agent-core + corpus（渲染面） | entry-agnostic-agent、ui-cards、corpus-retrieval、unbuffered-sse-passthrough |
| 求职循环（对外） | 职位 · 简历 · 申请 · QR 循环 | backend/internal/owner/jobs/ 域模块（fetch / jobsuc / jobsmcp / jobsadmin / printsess）+ connector | job-loop 设计文档 |
| Connector 管理 | connector 管理旅程 | connector | connector-plugins、connector-deps |
| Skills 与对话 | skills 管理 · 对话审阅 | capabilities + agent-core | skills-progressive-disclosure |
| API·MCP（机器可读的出口） | 管理端 API·MCP 表面 | capabilities | as-mcp-facade、owner-keypair-auth |
| SEO / sitemap / microsites | 公开表面 · robots + sitemap · /p/ 下的 microsites（2026-09-05 由"custom pages"改名，e7fe80e91；SEO 自 7037a434e 起按 microsite 设） | corpus + structure | landing/reader、builder |
孤儿审计（双向）
有承诺却没有工程的（大多数没问题）：转向之前 product-vision.md 那一整摆（HISTORICAL——随转向一起作废，不值得逐条列出）；IDEAS 里的 agentic-chat 能力（现行 backlog，尚未构建）；growth.md 的五条楞子原则（没有接上线——目前不存在任何分发功能）。
有工程却没有产品旅程的（当初查出的可动手补的缺口）：corpus-as-vault 方向——基于 wiki_refs 的图检索、文件夹折叠、callout/TikZ/widget 渲染、CSS 片段同步——曾是 roadmap 里 corpus-as-vault 的核心承诺，却在 features-and-journeys 里没有任何旅程；平台化（MCP 外部化、ui://、注册表）同样是架构驱动、没有旅程；sysroutes/captcha/RSS 仍标着未覆盖的 [ ]，也没有旅程。当时的结论：features-and-journeys.md 需要一个 vNext，把 vault 相关的旅程补上（owner 侧：在 Obsidian 里写作 → 同步 → 验证渲染；visitor 侧：浏览链接起来的 wiki / 沿反向链接走）——否则 roadmap 里最大的一个赌注，就没有产品侧的验收标准——你只能检查你能检查的东西。之后已补上： 文档现在有 A12（vault 同步，十个 sync-* spec）和 A33（抓取面，retrieval-links）；到 7037a434e 还标着 [ ] 的只剩 LockedView、microsite 回滚、Turnstile 验证码和登录节流——RSS 从未上线（robots + sitemap 上线了，e2e/test/seo-feeds.spec.ts）。
结语
**这座桥是以一种实践的形式存在的（spec 标签 → 设计文档 → 红测试 → 区块）；这一页让它变得可检视——第一次检视，就发现旗舰承诺缺了它的旅程，而那条旅程之后已经写上了。