边界——它不是什么

上级：product

StandMeet 不是一个求职工具。 招聘显然是它的一种应用场景（招聘者先预读，再问出更好的追问），但创始人自己的使用排在第一位——外部大脑、起草、表达、综合、筛选。（founder-product-fit）

它也绝不能滑向：

• 个人 AI 助理（那太通用了）
• 公开广播 / 博客（那是表演）
• 内容自动化工具（那是营销）
• 和 Sijie 的实时聊天（这违背了初衷）
• 任何人都能预约会议的服务（与选择性接触的定位不符）

核心边界：StandMeet 是一个"为选择性接触而生的思想领导力过滤器"，而不是一个通用的 AI SaaS 功能。

其中两条已经被上线的代码跨过去了 —— 这里只标注，不裁决

记下来，是因为一条悄悄跟代码对不上的边界，比一条被有意挪动的边界更糟。两条都要 owner 拍板；两条都不是 bug。

• "不是求职工具"。 后端里有一整条对外的 job loop（internal/owner/jobs：从 18 种来源——Greenhouse / Lever / Ashby / RemoteOK / WWR / HN 再加十二种，直到通用的 schema.org JSON-LD 摄入器和通用 RSS 适配器（fetch/jobfetch.go:36-63；7dd19527b 2026-09-02、d235f9817 2026-09-04）——拉进一个 1 天 TTL 的 Redis 池子，resume.draft → owner 在预发页上过目，2026-09-07 起是一个可视化的 Puck composer（756c0eb1d）→ applications.commit，同时写 application 行、自动签发一张访问码、渲染一份 ATS 友好的 PDF——由 composer 里同一份 Puck 配置绘制，gotenberg 的 Chromium 打印 /print/application/<id>（1b1ebed2b，backend/cmd/server/boot_pdf.go）——右上角的 QR 指向 <public_url>/?code=…（jobsuc/applications.go:317））。这已经不是"招聘只是语料的一个应用场景"了 —— 它是第二个产品方向，有自己的表、自己的 MCP 动词、和一个 PDF 渲染器，而且它把整件事的方向反过来了：语料不再等着被读，它主动出去找读者。
• "不是谁都能约会议的服务"。 booker 能力已经上线（mcp-servers/booker，calendar 契约背后是 Google Calendar（openapi）+ CalDAV（protocol）连接器，幂等订会）。但这条边界在真正要紧的意义上仍然成立 —— 订会是按能力授予的，只对"他那张码授予了这个能力"的访客出现，而那恰恰就是"选择性接触"，不是"谁都能"。与其留着那句一刀切的否认，不如按这个说法重述。

活的是第一条：一条对外的 loop，跟一个对内的过滤器，不是显然的同一个产品，而这篇笔记应该说清它到底是哪一个。