治理规则
文件系统会腐化：临时文件夹变成永久文件夹，副本变成事实分叉，根目录长出第十一、十二个"先放着"的目录。十条治理规则的目标只有一个——让 C-suite 文件系统 在长期使用中保持一目录一 Agent 的双射不被侵蚀。
所有权映射回答"现在谁拥有什么"，治理规则回答"系统如何增长而不破坏所有权"。前者是一张静态的表，后者是一组动态的约束——没有后者，前者会在六个月内失效。
十条治理规则
每条规则给出原文、设立原因，以及违反后的典型后果。所有后果均为示例场景，用于说明规则保护的边界。
-
根目录只包含十个 C-suite 文件夹和仓库元数据
原文：Root directory contains only the 10 C-suite folders and repo metadata.
为什么：根目录是组织结构的最高层视图。任何不属于十个职能的根级条目，都是没有 owner 的资产——它不会被任何 Agent 维护、复盘或授权。
违反后果（示例场景）：有人在根目录建了
temp/放客户演示材料。三个月后没人记得里面是什么、能否删除、是否含敏感信息；任何 Agent 被授权读根目录时都会连带读到它，权限审计直接失真。 -
每个根目录必须包含声明唯一所有者的 AGENT.md
原文：Every root folder must contain an
AGENT.mdthat states its single owner.为什么：所有权必须是显式的、机器可读的声明，而不是团队默契。
AGENT.md让任何人、任何 Agent 进入目录的第一秒就知道：谁拥有这里、边界在哪、出问题找谁。违反后果（示例场景）：一个目录没有
AGENT.md，新接入的 Agent 无法判断自己对它是只读还是可写，只能保守地全部不碰，或者危险地全部都碰——两种结果都让这个目录退出了组织系统。 -
新增根目录必须对应新的 C-suite 职能
原文：No root-level folder can be added unless it represents a new C-suite function.
为什么：新根目录 = 新 C-suite Agent = 新的常设职责。这是一项组织结构决策，需要回答"公司是否需要一个新高管"，而不是"我把文件放哪"。把建目录的成本抬高到组织决策的高度，才能阻止根目录无序增长。
违反后果（示例场景）：团队为一个大客户项目建了根级
project_x/。项目同时涉及交付、合同和收款，三个职能的文件混在其中，COO、CLO、CFO 三个 Agent 都声称部分所有权——双射被打破，该目录成为权限和审计的盲区。正确做法是项目材料按职能拆入06_operations/、08_legal/、03_finance/，用引用互联。 -
公司与战略归 01_executive/
原文：Company and strategy belong to
01_executive/.为什么：定位、战略、目标、优先级和决策记录必须有单一事实来源，且由 CEO Agent 统一维护。战略一旦散落在各职能目录，各 Agent 就会基于不同版本的"公司方向"工作。
违反后果（示例场景）：CMO Agent 在
09_marketing/里自存了一份"公司定位 v2"用于写文案。两个月后 CEO Agent 更新了正式定位，市场内容仍引用旧版，对外叙事与公司战略脱节。 -
后端数据与信息循环归 02_information/
原文：Backend data and information loops belong to
02_information/.为什么：外部调研、来源地图、信息缺口和 backend data loop 是全公司决策的输入层，必须由 CIO Agent 统一保证来源可追溯、时效可标注。输入层分散，下游所有判断的可信度都无法评估。
违反后果（示例场景）：一份竞品分析被直接存进
10_sales/供谈单使用，没有来源和日期标注。半年后它仍被引用，而竞品早已改版定价——销售基于过期情报承诺了错误的差异化卖点。 -
服务定义归 04_products/，交付执行归 06_operations/
原文：Service definitions belong to
04_products/; delivery execution belongs to06_operations/.为什么："我们卖什么"和"我们怎么交付"是两类生命周期不同的资产：服务包定义由 CPO Agent 迭代，追求可复制；交付记录由 COO Agent 维护，追求过程留痕。混在一起，产品定义会被一次性客户定制污染。
违反后果（示例场景）：交付团队直接在服务包定义文件里改出"客户 A 特别版"。下一个销售引用该文件报价时，把为客户 A 定制的范围当成了标准服务承诺，交付成本估算全部失真。
-
归档统一进 06_operations/archive/
原文：Archive belongs to
06_operations/archive/.为什么：归档是一种运营动作：什么时候归档、保留多久、如何检索，都是 COO Agent 的流程职责。每个目录各自留
old/、backup/，等于在每个职能里埋一个不被治理的暗区。违反后果（示例场景）：各目录散落着
v1/、final_old/等历史残留，Agent 检索时把废弃方案当成现行方案纳入上下文，输出建立在已被推翻的决策之上。 -
Agent、角色与培训归 07_human_resources/
原文：Agents, roles, and training belong to
07_human_resources/.为什么：在 AIDC 的组织设计里，Agent 是组织成员，不是技术组件。Agent 的档案、职责模板、训练材料与人类岗位定义一样，由 CHO Agent 统一管理——这保证"哪些工作给人、哪些给 Agent"始终有一个负责的判断者。
违反后果（示例场景）：CTO 团队把 Agent 定义文件放进
05_technology/当作代码配置管理。Agent 的职责变更从此绕过组织视角，没人评估它与人类岗位的边界，出现同一职责人和 Agent 互相等待的真空。 -
品牌资产归 09_marketing/
原文：Brand assets belong to
09_marketing/.为什么：logo、视觉规范、品牌叙事必须单一来源，由 CMO Agent 维护版本。品牌资产的副本一旦扩散，对外材料会同时存在多套过期视觉。
违反后果（示例场景）：销售在
10_sales/存了一版旧 logo 的提案模板，品牌更新后继续沿用，客户在同一周收到两套视觉完全不同的"同一家公司"材料。 -
客户合作与客户上下文归 10_sales/
原文：Customer partnerships and account context belong to
10_sales/.为什么：客户是公司最敏感的上下文之一：决策人、预算、谈判历史、合作伙伴关系必须集中在 CSO Agent 名下，才能做到按客户授权、按客户审计。客户上下文一旦散落，泄露面无法估算。
违反后果（示例场景）：客户的预算与决策链信息被复制进多个职能目录。某个只该看产品文档的 Agent 被授权时连带读到客户机密；当客户要求删除其数据时，没人能列出完整的存储位置清单。
新增根目录的决策流程
规则三把新增根目录定义为组织决策。当某类工作持续溢出现有十个职能的边界时，按以下流程处理：
- 提出动议 — 由感受到溢出的 owner Agent（或人类负责人）整理证据：哪些工作、持续多久、为什么现有职能装不下。
- CEO Agent 评估 — 判断这是临时峰值还是常设职能。判断标准：这项工作是否需要独立的职责边界、独立的产出节奏和独立的升级路径。
- 形成决策记录 — 无论通过与否，结论写入
01_executive/的决策记录，注明触发证据与复议条件。 - 初始化目录 — 通过后，创建带编号的新根目录，第一份文件必须是
AGENT.md，声明新 C-suite Agent 的所有权与边界。 - 迁移与引用更新 — 把散落在其他目录的相关文件迁入新目录，原位置保留引用路径，更新所有权映射表。
不要随意新增根目录。一个新的根目录意味着公司需要一个新的 C-suite Agent——在动手建文件夹之前，先回答组织问题：这个职能是否值得一个常设的高管席位？答案为否，就把文件放进现有 owner 的目录；答案为是，就走完整的决策流程并留下决策记录。
未来 C-suite 演化
十个职能不是终点。当公司规模和业务复杂度越过特定阈值，部分职责会从现有职能中独立出来。以下是已识别的四个候选方向，每个都定义了明确的触发条件——触发条件未满足之前，相应工作仍归现有 owner 管理：
| 未来目录 | 未来 Agent | 触发条件 | 当前归属 |
|---|---|---|---|
11_customer_success/ |
CCO Agent | 客户留存、续约、增购和客户成功工作量超出 COO 与 CSO 的职责范围 | 06_operations/ 与 10_sales/ |
12_security/ |
CISO Agent | 安全审计、访问控制、客户生产系统与合规成为独立的风险面 | 05_technology/ 与 08_legal/ |
13_ai/ |
CAIO Agent | AI Agent 治理与 AI 能力建设从技术实现中独立出来 | 05_technology/ 与 07_human_resources/ |
14_data/ |
CDO Agent | 数据治理、指标体系和数据产品超出 CIO 的信息所有权范围 | 02_information/ |
演化表的价值在于把"未来可能的混乱"提前变成"已定义的扩展点"：当触发条件出现时，组织不需要争论目录该怎么建，只需要确认条件满足、走决策流程、初始化第十一个目录。
规则如何被执行
治理规则在不同部署阶段有不同的执行强度，与 C-suite 文件系统 的升级路径一致：
- 声明层 — 仓库根
README.md记录全部规则，每个目录的AGENT.md声明本目录边界；人和 Agent 的第一道约束是读到这些声明。 - 流程层 — owner Agent 的 Operating Rules 中内置了对应约束（如 COO Agent 不能跳过 CFO 的定价复核），违规会在每周 / 每月的 review cadence 中被复盘暴露。
- 平台层 — 部署到 AIDC 平台后，规则升级为 权限模型 的策略校验：越权写入在动作提交时被拒绝，全部动作进入 Action Log 供审计与复盘。
相关阅读
- C-suite 文件系统 — 这些规则保护的核心结构
- C-suite Agent 参考 — 各 owner Agent 的 Operating Rules 全文
- Company Harness — 治理规则在 Harness 中的位置
- Evolution Loop — 平台阶段规则本身如何被提案与演化