-
company-service.js:company.json 加 ownerId(无 SQL 表,纯 JSON 字段);create() 接收 ownerId;list({ user }) 按传入用户过滤,不传就不过滤(company-heartbeat-service.js 等 系统内部巡检要看全部公司);新增 canAccessCompany(company, user) 作为全仓库唯一一份 归属判据(admin 不过滤,判负一律 404 不是 403,不暴露"这个 id 存在只是不是你的")。 company.js 用 router.param('companyId', ...) 统一收口(约 50 条路由,含 okrPath() 系列 动态路由)。graph-run.js 的两个挂载点参数形状不一样,设计阶段的描述不准确,实现时才 发现:companyRouter 唯一路由是 /:companyId/graph-runs 直接查;主 router 全部路由是 /:id/...,:id 指的是 run 不是公司,改成先查 run 的 company_id 再判断,run 不存在或 公司不是你的统一回"run 不存在"。devloop.js 用 :pid 反查 company_id;POST /projects 单独校验 body 里的 company_id(放在基本字段校验之后,避免归属检查打乱输入校验的错误 优先级);GET /projects 按归属过滤列表。 okr.js 最终没有按原计划接入 companyId 归属校验——实现前查证发现 OkrDashboard.vue 挂载的 /okr 页面全站没有任何导航入口指向它,是个孤儿页面,给访问不到的页面建"选公司" 前端交互不划算,改成 requireAdmin(跟 dream.js 同款),先堵住直接拼 URL 看到跨公司 聚合数据的口子。真正在用的公司级 OKR(company.js 的 /:id/okr)已随 company.js 一起隔离。 存量数据迁移:scripts/backfill-company-owner.js(npm run backfill:company-owner), 两家存量公司已划给种子账号,幂等验证过。 8 个既有测试文件用的公司 id 都是从没真正建过的字符串标签,挂锁后集体 404——新增共享 helper server/tests/helpers/ensure-test-company.js 修复;两处原有的"跳过已有 company.json 的目录,那是真公司"防御逻辑,判据从"有没有 company.json"改成"ownerId 是不是 -1 这个测试专用标记",否则新出现的测试夹具会被误判成真公司永远不清理。 验证:真实 curl 走过(admin 看到全部存量公司、新用户看到空列表、新用户拼 URL 访问 别人的公司 404、新建公司 ownerId 精确落在创建者、admin 和创建者都看得到其他人看不到); 全量 vitest 1427 passed,3 个无关既有失败不受影响。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
## 为什么加 「输入输出」tab 把产物的绝对路径摆出来了,但那是服务器本地路径 —— 浏览器里点不开, 走查时只能靠肉眼确认「路径长得对」,而真正要确认的是「这份 brd.md 里写了什么、 下游读到的是不是它」。 ## 前端 新增 web/src/components/graph-console/FilePreviewModal.vue,输入/输出两处路径 改成可点按钮。渲染三档:.md 走 marked(已是既有依赖,没新增包)、.json 重新缩进、 其它原文。两处刻意的选择: - .json 解析失败时**退回原文**并说明,不替它藏起来 —— 产物 json 写坏了本身就是要看的信息 - 超过 512KB 时后端回 truncated,界面如实说「不是完整内容」,不装作读全了 output_ref 那一行不做成可点:它是目录不是文件。 后端没有新造端点:复用现成的 GET /api/company/:cid/files/content,它的根目录正是 data/companies/<cid>,而 graph_files.rel_path 本来就是相对公司根的,正好对上。 ## 修掉六处路径越界(真漏洞) company.js 里 3 个 GET + 3 个 PUT(templates / company / workspace)用的是同一个写法: if (!absPath.startsWith(safeBoundary)) → 403 「一个目录名是另一个的前缀」时它会放行: cid = co-a,path = ../co-a-evil/company.json → abs = .../data/companies/co-a-evil/company.json → startsWith('.../data/companies/co-a') === true → 放行 于是公司 co-a 能读 co-a-evil 的文件;PUT 那三处是同一缝隙上的跨公司**写**。 抽 resolveInside() 用 path.relative 判断,六处共用一份(复制六份判据迟早会漂)。 新增 7 条用例走真 HTTP 验,PUT 那条断言的是**文件没被改**而不只是响应码。 ## 顺带修掉一个被你的实际使用触发的 bug 跑全套时 graph-seed-service 的对账用例红了,报 `org_graph_nodes WHERE company_id='mycompany' expected 10 / actual 9`。 不是并发偶发 —— 单跑也红。原因:seedCompanyAgents 对 type='meta-bootstrap' 的角色 是 continue(既不落 org_graph_nodes 也不落 system_agents),而 verifyCounts 复算期望值时把 agents[] 全算进去。mycompany 的 10 个角色里 orggraph-planning 正是 meta-bootstrap → 差 1。 也就是说:**界面上点一遍新建公司就会踩到**。这条缺陷上一轮就被预告过 (当时那个 agent 说「不在我的独占文件里」没修),今天被真实使用兑现了。 修法是让 verifyCounts 复用同一个 isMetaBootstrap 判据,不复制那个 type 判断。 新增独立测试文件(不并进 graph-seed-service.test.js —— 往它的 hermetic 夹具里 加角色会连带改既有断言),用 GRAPH_SEED_ROOT 自建最小夹具。 那个文件里第二条用例是刻意的:只断言「对账干净」时,seed 一个都没种也会“通过”, 两种原因症状相同。第一版就是这么错的 —— 我误以为 runStartupSeed 会种公司角色 (它只做 reconcile + 全局 agent + 模板),是第二条断言把「夹具没种」和 「过滤没生效」分开的。 ## 验证 871 全绿(87 文件)。3 处变异精确变红后逐字还原 (startsWith 回退 → 精确打红跨公司读/写两条;verifyCounts 去掉过滤 → 打红对账条)。 拿运行中的实例 + 用户真实公司 mycompany 走查过:读到真实 brd.md 内容, `../idearun/company.json` 与 `/etc/hosts` 均 403。web:build 通过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>