Feat/workflow init wiki

skills/lark-drive/SKILL.md

@@ -31,7 +31,9 @@ metadata:
 - 用户要**查询文件、文件夹或云文档自身的公开访问、分享、协作者管理、安全与评论权限设置**，优先使用 `lark-cli drive +permission-get-setting`；它只读取目标自身设置，不递归审计文件夹子文档权限。裸 token 必须显式传 `--type`。
 - 用户要**按特定主题、关键词或内容线索跨容器查找资料，并统一收集到 Drive 文件夹或 Wiki 节点**，必须先阅读 [`references/lark-drive-workflow.md`](references/lark-drive-workflow.md)，再按其中 `Workflow Registry` 进入 [`topic_move_collector`](references/lark-drive-workflow-topic-move-collector.md) workflow。该 workflow 负责搜索召回、内容验证、相关性分类、移动计划、写前确认和结果验证；禁止直接从 `drive +search` 或 `drive +move` 开始。
 - 用户要**整理云盘 / 文件夹 / 文档库 / 知识库 / 个人文档库**，或要“盘点目录结构、找出未归档/临时/重复/空目录、生成整理方案”，必须先阅读 [`references/lark-drive-workflow.md`](references/lark-drive-workflow.md)，再按其中 `Workflow Registry` 进入 [`knowledge_organize`](references/lark-drive-workflow-knowledge-organize.md) workflow。默认只生成方案；创建目录、移动资源、申请权限都必须单独确认。
-- 按主题跨范围查找并集中归档，进入 `topic_move_collector`；对已知文件夹、文档库或知识库做目录盘点和结构重组，进入 `knowledge_organize`；只移动一个已明确资源时仍使用原子移动命令。
+- 用户要**给已存在的知识库各节点写维护要求 / 维护标准 / 收录范围 / 命名规范**，或要“建立标准知识库维护方法，后续同事按标准补资料”，必须先阅读 [`references/lark-drive-workflow.md`](references/lark-drive-workflow.md)，再按其中 `Workflow Registry` 进入 [`knowledge_base_bootstrap`](references/lark-drive-workflow-knowledge-base-bootstrap.md) workflow。该 workflow 读取现有节点结构和草稿，生成规范后写前确认，把通用规范写入根节点、专属维护要求写入各子节点；不移动 / 不删除 / 不重命名节点。
+- 用户要**把本地文件 / 文件夹的资料整理入库到已有知识库**，或要“盘点这批本地资料、去重后转成知识页归位”，必须先阅读 [`references/lark-drive-workflow.md`](references/lark-drive-workflow.md)，再按其中 `Workflow Registry` 进入 [`knowledge_ingest`](references/lark-drive-workflow-knowledge-ingest.md) workflow。该 workflow 盘点本地资料（去重 / 敏感初筛）、据维护规范映射归位、转成飞书 docx 知识页写入、写后验证；只上传原文件不算完成（`drive +upload` 仅作来源附件）；目标库不存在时请用户先自建知识库或提供已有库链接再来（不从零建知识空间）。
+- 按主题跨范围查找并集中归档，进入 `topic_move_collector`；对已知文件夹、文档库或知识库做目录盘点和结构重组，进入 `knowledge_organize`；对已存在知识库各节点撰写并写入维护标准，进入 `knowledge_base_bootstrap`；把本地资料转成知识页入库，进入 `knowledge_ingest`；只移动一个已明确资源时仍使用原子移动命令。
 - 用户要**搜文档 / Wiki / 电子表格 / 多维表格 / 云空间（云盘/云存储）对象**，优先使用 `lark-cli drive +search`；按标题定位和处理重复候选时遵循 [`references/lark-drive-search.md`](references/lark-drive-search.md)。自然语言里"最近我编辑过的"、"我创建的"（→ `--created-by-me`，原始创建者语义）、"我负责/owner 的"（→ `--mine`，owner 语义）、"最近一周我打开过的 xxx"、"某人 owner 的 docx" 等直接映射到扁平 flag，避免手写嵌套 JSON。
 - 用户要对**文档评论**做任何操作（添加评论、列表 / 批量查询、回复、获取 / 更新 / 删除回复、解决 / 恢复、reaction），按下方 Shortcuts 表选择对应的 `drive +<verb>` 评论命令，执行前先阅读该命令的 ref。按评论定位文档正文位置见 [`references/lark-drive-comment-location.md`](references/lark-drive-comment-location.md)。
 - 用户给出 doubao.com 的云空间资源 URL/token，或明确提到豆包里的 file/folder/docx/sheet/bitable/wiki 资源时，仍按资源类型、URL 路径和 token 路由到本 skill；不要因为域名不是飞书而回退到 WebFetch。

skills/lark-drive/references/lark-drive-workflow-knowledge-base-bootstrap-outputs.md

@@ -0,0 +1,158 @@
+# 知识库维护标准初始化 — 规范模板与输出模板
+
+本文件是 [`lark-drive-workflow-knowledge-base-bootstrap.md`](lark-drive-workflow-knowledge-base-bootstrap.md) 的配套引用文档，在 workflow 进入 `OUTLINE_PROPOSE`、`GEN_STANDARD` 和 `WRITE_CONFIRM` 状态时加载。
+
+本文件承载两类内容：`GEN_STANDARD` 生成维护规范时的内容模板，以及各状态用户可见输出的表格样式。所有模板是结构骨架，实际文本由 agent 结合知识库主题、节点名称和现有草稿填充。不要将本文件的模板原样照抄为死板套话。
+
+## 维护规范内容模型
+
+维护规范分两层写入：通用规范写入根节点，专属维护要求写入各子节点。通用规范只在根节点写一次，子节点不重复通用规范全文。
+
+每个节点的维护规范文档统一由两部分组成：**顶部一张 6 行治理表**（结构化元数据，供门禁校验和后续维护）+ **正文**（该节点的维护规范内容）。治理表字段名称和顺序保持一致，不因节点类型删减；字段未知时填“待确认”，并把 `page_status` 保持为“进行中”。
+
+### 6 行治理表（所有节点统一表头）
+
+| 字段 | 填写规则 | 门禁相关 |
+|------|----------|----------|
+| 来源 | 这份维护规范的制定依据：用户提供的标准、上位制度，或“据业务常识制定”。多来源逐条列出 | 不得为空 |
+| 负责人 | 本节点维护规范的负责人，优先“姓名｜团队”。未知填“待确认” | 待确认时 `page_status` 须为进行中 |
+| 版本与状态 | 写成 `v1.0｜已完成`；状态只能是 `进行中 / 已完成 / 已废弃` | 状态须合规；有“待确认”时不得为已完成 |
+| 适用与可见范围 | 适用的组织、岗位、人群和可见范围；全员适用也显式写明 | 不得为空 |
+| 生效与更新 | 写成 `生效：YYYY-MM-DD｜更新：YYYY-MM-DD｜原因：首次创建 + 说明`；无独立生效日期写“不适用（原因）” | 允许“待确认” |
+| 复核策略 | 写成 `类型：<知识类型>｜周期：<天>｜下次复核：YYYY-MM-DD` | 允许“待确认” |
+
+字段值未确定时统一填“待确认”，不得编造。含“待确认”的节点 `page_status` 保持“进行中”；只有 6 行齐备、无“待确认”的节点才可标为“已完成”。
+
+### 根节点：通用维护规范
+
+根节点文档 = 6 行治理表 + 通用规范正文。正文包含以下六个部分，缺乏来源依据的部分据知识库业务领域的通用文档管理常识补全，并保持与知识库主题一致。
+
+| 部分 | 内容要点 | 来源 |
+|------|----------|------|
+| 维护总则 | 维护的基本原则，例如及时更新时限、内容真实完整、分类存放、可追溯 | 据业务常识生成 |
+| 文件命名规范 | 统一命名格式，例如 `[资料类别]-[项目/部位]-[编制单位]-[日期]`，并约定日期格式 | 据业务常识生成，格式贴合知识库主题 |
+| 文件格式要求 | 各类资料的文件格式约定，例如图纸、报告、照片分别用什么格式 | 据业务常识生成 |
+| 维护职责分工 | 各子节点分别由谁维护、谁审核 | 结构来自节点树；具体人员留占位待用户补充 |
+| 更新与检查机制 | 日常维护、定期检查、归档锁定等机制 | 据业务常识生成 |
+| 节点导航 | 指向各子节点的导航，便于快速进入 | 结构来自节点树 |
+
+### 子节点：专属维护要求
+
+子节点文档 = 6 行治理表 + 专属维护要求正文。正文聚焦“这个节点收什么、怎么收”，不复述根节点通用规范。
+
+| 部分 | 内容要点 | 来源 |
+|------|----------|------|
+| 收录范围 | 本节点应收录的资料类别清单 | 优先从该节点现有草稿归纳；草稿缺失再据节点名称和业务常识补全 |
+| 分类细则 | 节点内资料的进一步分类或编号规则（如有必要） | 从草稿归纳或据常识补全 |
+| 命名与格式适用 | 本节点资料适用的命名与格式约定，引用根节点通用规范并给出本节点示例 | 据根节点通用规范派生 |
+| 维护与审核人 | 本节点的维护人和审核人 | 留占位待用户补充 |
+
+## 用户可见输出模板
+
+以下表格是各状态用户可见输出的样式骨架。列名使用中文；内部枚举值转为自然语言中文标签展示。
+
+### READ_STRUCTURE：结构概览
+
+```text
+知识库：<知识库名称>
+根节点：<根节点标题>
+节点总数：<N>（docx <a> / 非 docx <b> / 快捷方式 <c>）
+
+| 层级 | 节点标题 | 类型 | 现有内容 |
+|------|----------|------|----------|
+| 根   | 建材经贸大厦改造项目验收 | 文档 | 默认占位 |
+| 子   | 消防验收 | 文档 | 已有草稿 |
+| 子   | 质量验收 | 文档 | 已有草稿 |
+```
+
+类型列：文档 / 表格 / 多维表格 / 思维笔记 / 幻灯片 / 快捷方式。
+现有内容列：默认占位 / 已有草稿 / 空。
+
+### OUTLINE_PROPOSE：大纲提议表
+
+仅在结构过简（如只有根节点）时展示。基于知识库主题和根节点标题提议子节点大纲，请用户确认后新建。确认表除节点名和收录范围外，必须给出每个拟建节点的精确 `--title`、目标位置（`--parent-node-token` 指向 `root_node`，或 `--space-id` 建在空间顶层）和对象类型，以便用户逐项核对。
+
+```text
+当前知识库仅有根节点 <根节点标题>（root_node token: wikcn_ROOT），缺少承载分类的子节点。
+基于主题提议以下子节点大纲，确认后新建（新建为文档节点，可再调整）：
+
+| 拟建 --title | 目标位置（parent） | 对象类型 | 收录范围（简述） |
+|--------------|--------------------|----------|------------------|
+| 消防验收 | wikcn_ROOT | docx | 消防设计图、验收报告、现场照片 |
+| 质量验收 | wikcn_ROOT | docx | 质量检验记录、整改单、验收结论 |
+| 集团项目验收 | wikcn_ROOT | docx | 批复、招标、合同、竣工验收总结 |
+
+确认后对每个节点执行：
+  wiki +node-create --as <runtime identity> --parent-node-token wikcn_ROOT --title "<拟建标题>" --obj-type docx
+  → 记录返回的 node_token 与 obj_token，回读并入 node_inventory；obj_token 即后续 docs +update 的写入目标
+
+确认新建这些节点吗？也可增删或改名后再建；如只想为现有根节点写规范，可跳过新建。
+```
+
+新建后回读并入结构，再继续分诊与规范撰写。
+
+### TYPE_TRIAGE：分诊表
+
+```text
+| 节点标题 | 类型 | 分诊 | 处理方式 |
+|----------|------|------|----------|
+| 消防验收 | 文档 | 可写正文 | 写入维护规范 |
+| 验收台账 | 表格 | 非文档节点 | 默认跳过（可选：新建文档规范页） |
+| 外部资料 | 快捷方式 | 快捷方式 | 跳过（无自有正文） |
+```
+
+分诊列：可写正文 / 非文档节点 / 快捷方式。
+
+### WRITE_CONFIRM：写入计划
+
+R2 高风险写入。确认前必须展示每个目标节点的稳定标识（`node_token`，重名子节点靠它区分）、写入命令族、写法、`kb_gate.py` 门禁结果，以及将写入的精确内容或相对现状的 diff——不能只给标题和摘要。内容较长时，逐节点展示其完整拟写正文（可折叠为分节，但必须可供用户逐字核对）。
+
+```text
+即将写入 <M> 个节点，门禁拦截 <B> 个，状态收紧 <N> 个，跳过 <K> 个。写入为高风险操作（docs +update），确认后执行。
+
+| 节点标题 | node_token | 写法 | 命令族 | 门禁 | 写入内容 |
+|----------|------------|------|--------|------|----------|
+| 建材经贸大厦改造项目验收（根） | wikcn_ROOT | 覆盖 | docs +update overwrite | 通过 | 通用维护规范（六部分，全文见下） |
+| 消防验收 | wikcn_A | 追加 | docs +update append | 收紧为进行中：负责人待确认 | 收录范围 + 分类细则（全文见下） |
+| 质量验收 | wikcn_B | 覆盖 | docs +update overwrite | 通过 | 收录范围 + 分类细则（全文见下） |
+| 验收台账·规范页（新建） | 建后回填 | 新建文档 | wiki +node-create → docs +update | 通过 | 该节点专属维护要求（全文见下） |
+
+<逐节点展开将写入的精确正文；append 场景标明追加位置，overwrite 场景标明将替换的占位内容>
+
+新建文档（new_docx）项，须展示完整命令序列（原对象不改动）：
+  1) wiki +node-create --as <runtime identity> --parent-node-token <目标父节点，如非docx原节点同级 wikcn_T 的父> --title "<精确标题，如：验收台账·维护规范>" --obj-type docx
+  2) 记录返回的 node_token 与 obj_token
+  3) docs +update --as <runtime identity> --doc <上一步 obj_token> --command overwrite --content <规范正文>
+说明：new_docx 目标位置必须显式（--parent-node-token 或 --space-id），标题必须精确给出；node-create 返回的 obj_token 才是 docs +update 的写入目标，不得写向原非 docx 节点。
+
+门禁拦截（不写入，记入 unsupported_checks）：
+| 节点标题 | node_token | 门禁原因 |
+|----------|------------|----------|
+| 验收台账 | wikcn_T | 载体不是文档节点：obj_type=sheet |
+
+跳过节点：
+| 节点标题 | node_token | 类型 | 原因 |
+|----------|------------|------|------|
+| 外部资料 | wikcn_C | 快捷方式 | 无自有正文 |
+```
+
+门禁列：通过 / 收紧为进行中（原因） / 拦截（原因）。写法列：覆盖 / 追加 / 新建文档 / 跳过。
+
+### VERIFY：验证与汇总
+
+```text
+| 节点标题 | 写入 | 校验 |
+|----------|------|------|
+| 建材经贸大厦改造项目验收（根） | 成功 | 已确认通用规范落地 |
+| 消防验收 | 成功 | 已确认收录范围落地 |
+
+汇总：已更新 <M> 个节点，跳过 <K> 个节点。
+未写入节点（unsupported_checks）：
+| 节点标题 | 类型 | 原因 |
+|----------|------|------|
+| 验收台账 | 表格 | 非文档节点 |
+
+知识库链接：<URL>
+```
+
+校验列：已确认落地 / 未落地（需重试）/ 失败。