# 需求:员工对齐基准-机器清单上卡与飞书投影与能力索引

状态: accepted(2026-10-20 boss 10-19 拍板以 NAS git 为基准,spec 已出,进实施队列)
归属: 公司基建(员工入职分发)
来源: boss 直投(会话)
日期: 2026-10-19
建议: 做,boss 10-19 拍板以 NAS git 为基准:入职卡缺「哪些是公司服务器/哪些只在内网成立」这一格;远程员工看不到卡用飞书投影解决而不开公网入口;能力索引承接谁做过什么的原诉求

## 现状

boss 10-19 把「跨 agent 协作总线」推翻重定口径：以 NAS 的 git 为唯一基准，只补员工入职真正缺的三格。实测对账：

- 入职卡四段（账号 / 本机环境 / 连通性 / 必读）都有承载，**唯独「哪些是公司服务器、哪些地址只在内网成立」零结构化承载**：`ops/onboard.json` 顶层键实测 = `version/comment/nas/rules/baseline/checks/accounts/readings/redlines/first_day`，没有 machines；「Mac 构建机」只活在 `ops/data/events.json` 与 `ops/patrol-log.md` 的散文里。公司实际四台：NAS、Mac 构建机、腾讯云服务器、老板开发机（口径详见 spec §3 登记表，逐台带来源）。
- **公司没有独立测试机**：开发/测试库都按库隔离在 NAS 的 MySQL 13306 上——这句话现在没有任何机器可读的载体，新员工只能靠问。
- 远程员工看不到卡：卡的载体是老板本机 `.runtime/`，而 NAS 只有内网地址（`192.168.31.192`）。已否决的三条路：给 NAS 开公网入口（红线，spec §2）、常驻消息服务（本仓无承载，且 `ops/ceo-cadence.md:20` 明写白天不设定时任务）、自建寻址总线（同一承载已有 git + 需求票 + 每晚 00:00 一场日循环）。
- 曾按「总线」出过一版 2 人日五组件设计，被 boss 判「实在太复杂」并全撤。撤回依据实测两条：① `ops/cli_scan.py:59` 按 `r["path"].exists()` 过滤，而 34 个 `ops/products/*.yaml` 写的是 `repo: D:/code/work/lin/...` ⇒ 换机器同步会静默互回滚；② 记录里跨人重复劳动事故 = 0 起（口径：`ops/worklog/` 与 `ops/data/events.json` 全量人读，认领协议已在拦）。
- M2 不需要新建飞书应用：本机 `lark-cli` v1.0.79 已配 app、`identity: bot` 且 `verified: true`（appSecret 在系统钥匙串，`~/.lark-cli/config.json` 记 `appSecret.source=keychain`）。**风险点**：现渲染的入职卡把本人口令渲进第一节（既有测试即断言 `"S3cret-123" in card`），直推公网文档=凭据上飞书，必须先有去密投影。

spec：`docs/superpowers/specs/2026-10-19-employee-alignment-basis-git-feishu-design.md`
计划：`docs/superpowers/plans/2026-10-19-employee-alignment-basis-git-feishu.md`

## 方案

三步，合计 0.7 人日，M1 独立可用先做，M3 可押后。

- **M1（0.2 人日）机器清单上卡**：`ops/onboard.json` 顶层加 `machines` 段（4 台，逐台 `id/name/role/addr/reach/owner/writable/note`）；判定收在 `validate_spec()` 单一函数（`card`/`verify` 两入口天然共用，不抄第二份），缺项或 `reach` 写了 `lan-only|public|ssh-bastion` 之外的值 ⇒ 退 2；卡面第一节内以 `### 公司机器清单` 出表，可达性标注由 `reach_label()` 按 `reach` 生成（人不手写，缺标注=渲染器缺陷，才可机检）。
- **M2（0.3 人日）去密投影进飞书**：`render_card(..., mask_secrets=True)` 先把口令换成「已线下发放」；`card --publish feishu` 只调现成 `lark-cli`（`--content @file`，中文不过 shell 管道），首行打源指纹（正本版本 @ 本地 HEAD sha）；document_id 落进成员档案 `feishu_doc`，第二次走 `overwrite`——投影不留历史，历史在 git；推送失败退 1 且回显「未上线」，判据只认回包 `document_id`，不信退出码。需 boss 人工的只剩「员工怎么拿到那篇文档」（bot 出链接由 boss 转发，或 `auth login` 恢复 user 身份再分享）。
- **M3（0.2 人日）能力索引**：`ops/capabilities.md` 一行=一个真跑通过的能力（5 列，「在哪个仓」用 `ops/cli_registry.json` 的 `repos[].id`，禁本机绝对路径），派生自 `cli_scan.py gen`，人只补示例命令与验证日期；`ops/capabilities.py check` 只判三种坏形态（缺格 / repo id 查无 / 超 90 天）⇒ 退 1；本仓 `AGENTS.md` 留一行指针。**不声称挂日报**（本仓无该承载，要挂得同时改 `run_daily.py`+`report.py` 并动 `nodes.json` 链登记，另开一票）。

非目标：成员登记表、协作线程协议、轮次状态机、唤醒层、常驻消息服务、NAS 公网入口/mesh、跨机远程执行、云效 Codeup 换正本（boss 10-19 明确「还是老方案」）。

## 验收标准

- [ ] `python ops/onboard.py card <成员>` 出的卡含「公司机器清单」节，四台机器逐台带 `role` 与 `owner`，`lan-only` 地址旁有可达性说明。
- [ ] `machines` 缺 `role`/`owner`，或 `reach` 写三值之外的值 ⇒ 负向用例并退 2，且 `card` 与 `verify` 两个入口都拦住、回显点名缺哪一条（先红后绿，不只断言「失败就行」）。
- [ ] 卡推到飞书一篇真文档，首行源指纹与本机 `rules check` 读数一致；在飞书里手改正文后重推，改动被覆盖回正本形态（证明它不是第二正本）。
- [ ] 一名远程员工在自己手机（不在内网、不装软件）打开飞书链接看到完整卡，读数写进 worklog；员工未到位则本条标 pending，不当已完成。
- [ ] 凭证不落盘进 git、不进对话、不进日志：`git grep` 与卡面/投影正文双处查 `app_secret` 与哨兵口令零命中。
- [ ] 推送失败（临时 `LARK_CLI_BIN` 指向不存在的二进制）⇒ `card --publish` 退非 0 + 回显「未上线」，不许静默成功；负向用例覆盖。
- [ ] `python ops/demand.py check` 与 `python -m pytest ops -q` 无新增红（现存 1 处硬伤是他人 2026-10-10 票来源锚点轮转、2 处 `test_system_health` 人因表周刷新红为既有挂账）。
- [ ] `ops/capabilities.md` 每行「在哪个仓」能在 `ops/cli_registry.json` 的 `repos[].id` 查到；`capabilities.py check` 两态各验：全新鲜退 0，某行日期改成 120 天前 ⇒ 退 1 且点名那一行。
- [ ] 卡面与飞书文档不出现任何老板本机绝对路径（沿用 `test_employee_facing_carriers_carry_no_boss_checkout_path`，`machines` 新增行同样过闸）。