Repository navigation
[观察] PR #762 落地的 integrations 页写「没有 Setup → 集成 菜单」，说法过宽：该分组在平台 Setup 应用里真实存在，plugin-webhooks 等会往里挂条目 #800
Description
Activity
📋 findings 分诊轮(修复线 PM):晋级 pm:queue——页面自己的操作建议(启用 webhooks)会触发自己的绝对断言破裂,一句话软化即可消除休眠矛盾,小单池待派。
Generated by Claude Code
[PM 认领 · R26] session_01VHrPAGEgFDoHjphqYG4BMa · 分支
claude/issue-800-integrations-scope-wording· 文件面:content/docs/guides/integrations.mdx×3(:19与:106附近两句)+ changeset裁定与边界(按 issue 自带建议执行,PR #762 的核心主张不动):
- 两句绝对语气收成范围语气:「没有
设置 → 集成菜单」→ 该分组在平台 Setup 九组名单中真实存在,但本应用未启用会往里挂条目的能力(webhooks/datasource/mcp 不在 requires 与平台常开清单),故今天分组为空;「没有设置 → 集成 → Webhooks页面可去」→ 本应用未启用webhooks,启用后该条目由plugin-webhooks挂进去——与同页「把 webhooks 加进 requires」的操作建议不再对撞。 - 「未落地/未启用/已移除」三态各得其所(issue 的判据):连接器是未落地,菜单分组是存在但未启用——写实时保持这个区分。
- 平台侧事实(九组名单、三个包挂条目)按 issue 证据复测(
@objectstack/platform-objects/ plugin-webhooks 等,node_modules 只读);⚠️ reports能力不在 requires 里，但 10 个报表已声明、且 crm_case 的 allowExport 授权正是靠「报表面」立论 —— 工单导出可能根本没有落地面 #798 先例:报表能力与本单无关,不顺手扩展。 - ⛔ 不动
src/**、releases/;PR docs(guides): 按实际落地能力重述 integrations 页，并校正指南索引描述行 (#756) #762 其余主张零回退;不加守卫;三语同步。
⛔ 不升级 @objectstack/*;changeset 站内路径反引号;控制字节自扫;JSON 报告按标准 schema。
Generated by Claude Code
- 两句绝对语气收成范围语气:「没有
✅ 验收通过 —— PR #908 已转 ready 并挂 auto-merge(CI 8/8 全绿)。
验收要点:
- 主前提成立并强化:dev 实测确认
SETUP_APP(@objectstack/platform-objects@17.0.0-rc.2)声明九个导航分组,group_integrations在列且条目全靠外部包贡献(plugin-webhooks / service-datasource / mcp),无第十组——issue 的核心主张(文档不应断言「不存在 设置 → 集成 菜单」)据此落实为三语各三句的范围语气改写。 - 行号偏差如实报:issue 给的
:19/:106实测为:23/:82,该页自 docs(guides): 按实际落地能力重述 integrations 页，并校正指南索引描述行 (#756) #762 后仅 feat(views): give the Cases list an Export button (#817) #843 动过一条 bullet、行号未漂移,属 issue 正文近似,不影响定位。 - issue 论据被证伪(修法不受影响):「三个能力都没加载、分组因此是空的」不成立——
serve.js:768默认补载mcp、serve.js:2277无条件挂载 DatasourceAdminServicePlugin,今天 设置 → 集成 下大概率已有 Datasources 与 Connect an Agent 两个平台条目,仅 webhooks 真未启用。dev 措辞据此绕开「分组是空的」这一未经浏览器实测的推断,按「今天没有任何厂商连接器条目」落笔,更稳。 :8导语一并纳入:issue 未引到,但承载同一句绝对断言,只改:23会造成同页自相矛盾,纳入合理;PR 已单独说明该 hunk 可独立 revert。- docs(guides): 按实际落地能力重述 integrations 页，并校正指南索引描述行 (#756) #762 核心主张零回退:src/ 无连接器元数据、平台包无连接器插件、十条悬空路径三条原文全部保留,只删「更没有菜单」从句。
越界发现处置:#909(integrations 页「已落地能力」漏 MCP 端点与 Datasources 两个默认开启的平台面,兼更正本单错误论据)已复核,静态读码证据充分、开单前已做重复检索,标 finding 入发现池——按 dogfood 流程需浏览器实测后再补文档,暂不排期。
Generated by Claude Code
- 主前提成立并强化:dev 实测确认
更正一条论据：分组不是空的（结论不受影响）
来自 #909 的实施轮。
⚠️ 本单的结论、定级与修法都不受影响，PR #908 当时已按正确事实落地；这里只更正正文里用来支撑结论的一句话，不重开本单、不改动正文。被更正的原话
在 HotCRM 当前的部署下，这三个能力一个都没加载……
webhooks/datasource/mcp都不在其中。分组因此是空的。所以今天没有用户会撞上这句话的错，本单按观察项归类。三项里只有
webhooks成立。另外两项在默认部署下是加载的，理由各不相同：mcp不需要写进requires—— CLI 自己会补。@objectstack/cli的serve.js里有一段isMcpServerEnabled() && !requires.includes('mcp')就push('mcp')；该函数在OS_MCP_SERVER_ENABLED未设置时返回true，本仓没有任何地方关掉它。条目 Connect an Agent 由@objectstack/mcp挂进group_integrations。datasource根本不是能力词条 —— 它不在PLATFORM_CAPABILITY_TOKENS里，所以不受requires约束。serve.js无条件挂载DatasourceAdminServicePlugin，注释写明是为了「a self-host runtime is a complete low-code platform out of the box」。条目 Datasources 由它注册。
（平台已从 17.0.0-rc.2 走到 17.1.0，行号搬过家；上面一律按文本定位，不引行号。）
这一次是浏览器实测，不是静态读码
#909 把「注册不等于渲染」设成了硬门。实际起了应用、以管理员身份登录、打开 Setup 应用：
- Integrations 分组默认就是展开的，底下两个条目 Datasources 与 Connect an Agent 都真实渲染，各有非零包围盒；
- 两个条目都能打开可用的页面 ——
Connect an Agent给出本环境的 MCP 端点与各客户端配置，Datasources列出部署自己的存储（Default，带Test/Sync objects）； - 两者都只受分组自身的
manage_platform_settings管辖，没有额外门控。
⇒ 分组不空，而且今天就不空。 也就是说，「没有用户会撞上这句话的错」这条兜底其实并不成立：一个管理员今天打开
设置 → 集成就会看到两个条目，而当时那句「没有设置 → 集成菜单」正是在对他说话。这让本单的修法比它自己主张的更值得做，而不是更不值得。顺带
本单当时观察到的「
plugin-webhooks会往group_integrations里挂 Webhooks 与 HTTP Deliveries」依然正确，且webhooks确实没有加载 —— 那一半原样成立，文档也确实应当继续不提它。#909 正在补的是另一件事：这两个真实存在的条目，全站文档从未解释过它们是什么。
Generated by Claude Code
发现于 #763 / PR #797（为
import-and-export.mdx核对 Setup 应用的分组构成时，顺带对上了 #756 / PR #762 刚落地的措辞）。不在 PR #797 的文件面内，单独记录。先说结论：这是观察项，不是回退请求。 PR #762 的主张（十类厂商连接器不存在、那十条
Setup → Integrations → X配置路径指向不存在的界面）完全成立，本单不触碰它。有问题的只是它用来支撑该主张的那句绝对化表述。实测
content/docs/guides/integrations.mdx:19及 zh 两页对应位置：以及
:106附近：但 Setup 应用（
SETUP_APP，来自@objectstack/platform-objects/apps）的导航分组实际是九个，Integrations就在其中：而且有三个包会往
group_integrations里挂条目：@objectstack/plugin-webhooks（条目 Webhooks 与 HTTP Deliveries）、@objectstack/service-datasource、@objectstack/mcp。为什么今天还看不出问题
在 HotCRM 当前的部署下，这三个能力一个都没加载：
requires是automation, triggers, analytics, auth, ui, approvals, sharing，平台常开的是queue, job, cache, settings, email, storage, sms, sharing, messaging, analytics——webhooks/datasource/mcp都不在其中。分组因此是空的。所以今天没有用户会撞上这句话的错，本单按观察项归类。但它会在一个特定时刻变错
同一页的 webhooks 小节明确建议读者：
读者一照做，
设置 → 集成 → Webhooks就出现了——而页面刚刚告诉他「没有这样一个页面可去」。这一处是页面自己给出的操作，与页面自己的绝对断言，会在同一次部署里对撞。建议
把绝对语气收成范围语气，两处各改一句即可（三语同改）：
设置 → 集成菜单」→「设置 → 集成分组存在，但今天它下面没有任何厂商连接器条目——本应用没有启用会往里挂条目的那几项能力」；设置 → 集成 → Webhooks这样一个页面可去」→「本应用未启用webhooks，所以该条目不出现；一旦在部署里启用，它会由plugin-webhooks挂进设置 → 集成」。这恰好与 PR #762 自己最受认可的那一点同构——「未落地」「未启用」「已移除」三种状态各得其所。连接器是「未落地」，而这个菜单分组是「存在但本应用未启用」，两者被混写成了同一句「不存在」。
关联
import-and-export只断言「Setup 里没有 Data 分组、没有 Privacy 分组」——那两个分组在九组名单里确实不存在，是可证伪且成立的说法，不依赖「某能力有没有启用」。