---
title: 公司共享 Context 项目仓库发布方案 v1
date: 2026-08-03
type: 设计spec
status: published
content_status: confirmed
belongs_to:
  - "[[3-业务线/Gitea知识库/_context|Gitea知识库]]"
owner: Verlit
last_modified_at: 2026-08-06T18:24:55+08:00
last_modified_by: Codex
migrated_from: "0-收集箱/公司共享 Context 项目仓库发布方案 v1.md"
governance_overlay: "[[2026-08-03-v1审核开关治理模型_deepseek-v4-pro]]"
hash: "sha256:a3a33cec7dfd0441fdf12af420bfc4f3d63ee7c113d4ae298ab96d2e2e45285f"
hash_scope: "Markdown 正文（从一级标题开始至文件末尾）的 UTF-8 SHA-256"
---

# 公司共享 Context 项目仓库发布方案 v1

> **一页纸结论**
> 本方案不重新发明知识同步系统，而是以 2026\-07\-28 采集的“四人 Obsidian \+ Git \+ Nginx”分享方案为 v0，保留 Git 留痕、服务器只读和 Agent 接入，补上五个企业项目必需的差分：**按项目组织、散落来源发布、统一 current、按项目授权、发布后回读**。
> 
> v1 的核心原则是：**项目是公司共享知识的业务容器，仓库是权限容器；个人怎么创作和留历史由个人决定，经过明确发布进入公司自建 Gitea 项目仓库 ****`main/current`**** 的内容，才进入公司共享读取面并被 Agent 默认读取；其中 ****`content_status: confirmed`**** 才代表已经确定的公司口径，****`discussion`**** 只代表当前在途材料。confirmed 是否需要第二人审核由项目审核策略决定；试点固定为 `forced_off`，仍保持发布即生效。**
> 
> 

> **当前版本身份**
> 
> - 本文是 AI组织 W30“公司共享 Context 实现方案设计”的**当前设计真源**。
> 
> - 方案已经定稿，个人 `cc` Vault 的 Markdown\-only Git 基线已经建立；公司 Gitea、首个项目仓库、只读入口和发布 Skill 尚未部署。
> 
> - 当前团队共 6 人；v1 仍只选择 1 个项目试点，项目成员从 6 人中按实际权限确定。6 人是当前组织事实，**不构成所有项目必须全员加入或企业知识库永久只服务固定人群的业务硬门**。
> 
> - 外部案例和调研报告是证据，不替代本文的实施口径。
> 
> 

## 版本边界

|版本|只解决什么|暂不解决什么|
|---|---|---|
|v1：发布链|选择材料、标记 `discussion / confirmed`、按项目审核策略决定 confirmed 是否待审核、写入项目 `main/current`、导出、通知与 Agent 读回、Git 恢复|不建设通用审批平台、proposal/PR、多级会签或飞书审批；试点审核策略固定关闭|
|v2：治理增强候选|根据 v1 的真实使用摩擦，选择正式审批集成、飞书权限、跨项目治理或保持轻量开关|不预设一定同时建设，也不在 v1 前置实现|

v1 可以在发布前由发布者自行查看 diff，也可以在线下或飞书里讨论重大修改。项目策略为 `forced_off` 时，这些行为不构成第二道批准门；策略有效开启时，confirmed release 进入 `pending_review`，由 reviewer 对不可变候选 hash 作出决定。`pending_review` 是发布事务状态，不是第三种内容状态。发布前的结构、链接、附件、隐私和凭据检查是**质量检查**，不是内容审核。

## 方案全景

最终方案由五个边界组成：

1. **个人工作区**：保留每个人现有的 Obsidian、本地目录、飞书、Notion 或其他工具，不强制创建个人 Git 仓库；当前 `cc` Vault 已选择“本地 Git 留历史 \+ NAS 单向备份”。

2. **发布入口**：个人明确选择允许共享的文件、段落或多份材料，生成项目级发布物。

3. **项目仓库**：公司在空余服务器上自建 Gitea，按项目建立私有仓库并按项目成员授权；发布动作直接更新仓库 `main/current`。

4. **只读 current**：服务器只导出已发布的 current，管理层和 Agent 从统一入口读取。

5. **历史账本**：Git 保存差异和恢复点，但历史、草稿和私人来源不进入 Agent 默认读取面。

## 一、方案来源：以外部分享为 v0，只保留真实增量

本方案的技术底座来自 2026\-07\-28 采集的飞书分享。原方案已经证明以下链路在四人小团队中可以运行：

- 每个人保留自己的 Obsidian Vault；

- 只同步指定团队内容，不默认暴露整个 Vault；

- Git 承担同步与版本历史；

- bare Git \+ `post-receive` 导出工作树；

- Nginx 提供 Markdown 只读访问；

- Agent 通过 HTTP \+ Basic Auth 读取；

- Skill/安装包封装 Git 和路径细节。

wide 调研没有发现一条完全不同、又能原生解决全部问题的新架构。它的价值是验证原方案方向成立，并给出原方案没有覆盖的真实失败模式。v1 因此只做以下差分：

|v0 外部分享|v1 公司方案|
|---|---|
|按成员汇集多个个人仓库|按公司项目建立共享仓库|
|只同步预先集中的团队子目录|允许从散落文件、段落和多份材料生成发布物|
|任意 push 后立即展示|只有显式“发布”动作能更新 current；confirmed 是否审核由项目策略决定，试点固定免审|
|Agent 读取服务器检出的内容|Agent 只读已发布的 current 快照|
|Basic Auth 粗粒度共享|项目仓库按项目成员授权，Agent 使用独立只读身份|
|Git 历史即全部版本|current 与历史读取面分离|
|协作状态未区分|v1 在 current 内增加 `discussion / confirmed` 材料状态；审核开启时只增加 release 事务状态，不增加内容状态|
|未覆盖通知与刷新确认|每次发布生成回执并做 Agent 读回|

## 二、七条最终原则

1. **项目是公司共享知识的基本对象。**

2. **仓库按权限边界建立；v1 默认每个项目一个企业私有仓库。**

3. **个人是否使用 Git、是否建立个人仓库，不做强制。**

4. **个人工作区保存私人过程材料，项目仓库保存已明确共享的当前版本。**

5. **个人材料通过单向发布进入项目仓库，不做双向同步。**

6. **本地统一使用标准 Git；个人仓库留在本地并由 NAS 单向备份，公司项目仓库以自建 Gitea 作为远端和权限层。**

7. **v1 以“明确发布”为共享生效动作；进入 ****`main/current`**** 的内容才进入公司共享读取面，其中只有 ****`confirmed`**** 能被人和 Agent 当作已经确定的公司口径；审核策略开启时，confirmed 必须先通过绑定候选 hash 的审核。**

其中需要特别澄清：

> “发布而不是复制”是权威关系的定义，不是说技术上完全不产生第二份文件。
> 
> 

发布会物理生成一份企业共享产物，但个人材料与企业产物不是两个竞争真源：

- 个人材料是原料、过程稿和个人工作上下文；

- 项目仓库 current 是公司当前共享读取面，不自动等于已经定稿；

- `current + discussion` 是正在协作的在途材料，Agent 必须显式标注状态，不能把它表述为公司结论；

- `current + confirmed` 是已经确定、可被人和 Agent 作为公司口径引用的材料；

- 个人材料发生变化，不会自动覆盖企业 current；

- 企业 current 只有经过下一次明确发布才能更新；

- 项目审核策略为 `forced_off` 时不要求第二个人批准，发布权限本身就是生效权限；策略有效开启时，confirmed 必须由 reviewer 审核不可变候选；

- 企业 current 的修改若需回到个人原稿，通过建议或人工吸收处理，不做自动反向同步。

## 三、总体架构

### 3\.1 个人边界

- 不要求统一个人目录；

- 不要求个人仓库；

- 不把整个个人 Vault 暴露给公司 Agent；

- 发布 Skill 只读取本次明确选择的来源；

- 临时构建发生在 vault 外的临时目录，不在私人源目录内生成派生文件；

- 绝不把私人仓库历史直接提升为公司共享历史。

当前 `E:/local_project/cc` 的个人实现已经确定为：

- Vault 根目录建立一个本地 Git 仓库，只纳入选定的 Markdown 与仓库规则文件；历史基线 commit 为 `ab9496768cb8df6c59b615996269e3f06dbe2290`；

- `2-代码库/` 等独立代码仓库和 `7-飞书镜像/` 不进入 Vault 根仓库；子仓库由离目标文件最近的 `.git` 独立提交；

- 一次业务变化若同时修改代码和知识文档，分别在代码仓库与 Vault 仓库提交，必要时用同一任务 ID 关联，不追求跨仓库“一个 commit”；

- Vault 到 NAS 只做单向备份，不做双向同步；NAS 必须包含 `.git` 或定期保存 `git bundle`，否则只能恢复文件现状，不能恢复 Git 历史；

- 个人 Vault 不推送到公司 Gitea。公司 Context 项目仓库应放在根仓库明确排除的位置（如 `2-代码库/<project>-context/`）或 Vault 外，避免父子仓库同时追踪同一文件。

- Claude Code 与 Codex 已接入项目本地的 session\-aware checkpoint 软提醒：只记录当前 session 通过文件写入工具明确触碰的 Markdown，在完成前提醒精确 commit；不自动暂存、不自动提交，也不把其他会话的全局脏状态归给当前 session。两端都需要新会话加载，Codex 首次加载时需通过 `/hooks` 审阅并信任项目 hook。

以上是当前 `cc` Vault 的具体落地，不是强制所有成员都采用个人 Git。对其他成员，v1 只要求能从其现有工作区明确选择材料并发布。

### 3\.2 项目仓库边界

项目是业务容器，仓库是权限容器。v1 采用一项目一仓，原因是用户已经确认需要按项目给不同人授权，而 Git 最可靠的权限边界是整个仓库。公司远端明确使用自建 Gitea：它是独立开源的 Git 托管与权限管理系统，不是 Gitee；本地仍然使用标准 Git，只是公司项目仓库统一推送到 Gitea。

未来只有在多个项目的成员、保密级别和生命周期完全一致时，才可以评估合并仓库；不能因为目录看起来方便，就在同一仓库内用文件夹模拟安全隔离。

### 3\.3 公司读取边界

- 管理层按项目获得仓库权限；

- Agent 不直接获得 Git 写权限；

- Agent 默认不获得 `.git`、构建区和私人来源；

- 服务器只导出 `main/current`；

- 每个项目使用独立 current 地址或独立挂载路径；

- 需要调查历史时，走显式历史查询，不把历史长期混入默认 Context。

## 四、权限模型

### 4\.1 角色

|角色|主要权限|明确禁止|
|---|---|---|
|个人作者|维护个人材料、选择发布来源|不能让个人修改自动覆盖 current|
|发布者|查看 diff、执行发布、获得发布回执|不能读取本次未选择的私人材料|
|项目维护者|管理 Gitea 项目成员、发布凭据、备份和恢复动作|不应静默改写 Git 历史|
|项目成员|使用独立 Gitea 账号与 SSH key，读取 current、查看被授权的项目历史|不能共享账号或访问未授权项目|
|Agent|读取 current 快照、返回版本信息|无私人源、历史和发布权限|

同一个人可以同时担任作者、发布者和项目维护者。试点 `forced_off` 不强制把“提出修改”和“内容生效”拆成两个人的动作；项目审核策略有效开启时，publisher 与 reviewer 默认必须是不同人，并由系统记录绑定候选 hash 的审核决定。

### 4\.2 权限执行位置

|权限|执行位置|
|---|---|
|谁能看私人原稿|个人工作区与设备权限|
|谁能访问某项目|Gitea 项目仓库成员或项目团队|
|谁能执行发布|发布入口身份或发布网关凭据|
|谁能更新 `main`|仅发布网关对应的 Gitea 凭据；成员不直接 push `main`|
|谁能看 current|Nginx/只读挂载的项目身份|
|Agent 能读什么|current 导出根目录与独立只读凭据|

frontmatter 或 manifest 中的 `audience` 只是权限说明，不是实际权限。真实执行必须依赖仓库成员、凭据和读取入口。

### 4\.3 权限撤回边界

Git 权限只能阻止未来访问，不能让已经 clone 到个人设备的历史自动消失。因此实施时必须同时规定：

- 公司资料和职务产出仍属公司资产；

- 离职或退出项目时移除仓库成员、吊销凭据；

- 轮换共享读取凭据；

- 不把敏感信息写入不必要的历史；

- 设备和备份按公司规则处理；

- 需要更高隔离的项目使用独立仓库，不能只删文件夹权限。

## 五、项目仓库结构

```text
<project-id>-context/
├─ README.md
├─ current/
│  ├─ context.md
│  ├─ decisions/
│  ├─ assets/
│  └─ _release.yaml
├─ schema/
│  └─ context.schema.yaml
└─ .gitignore
```

### 5\.1 `current/`

这是人和 Agent 的默认读取根，只放已经发布、当前仍然有效的内容。

- `context.md`：能够独立理解的完整项目 Context；

- `decisions/`：仍然生效、需要单独引用的重要决定；

- `assets/`：current 实际依赖的附件；

- `_release.yaml`：当前版本、材料状态、发布者、发布时间、来源谱系和替代关系。

### 5\.2 历史与发布构建

- 发布构建在 vault 外临时目录完成，成功发布或失败退出后均不进入 Agent 读取面；

- v1 不要求 proposal 分支、PR/MR 或通用审批平台；仅当项目审核策略有效开启时保存精确 release 审核记录；

- 被替代版本首先由 Git commit/tag 承担，不默认复制到 `current/archive/`；

- 如业务确需保留归档正文，必须放在 Agent 默认读取根之外，并明确 `archived`；

- 恢复旧版时不是让成员长期 checkout 旧 commit，而是重新发布一个新的 current commit。

### 5\.3 最小发布元数据

```yaml
project_id: "<稳定项目ID>"
artifact_id: "<稳定Context ID>"
maintainer: "<项目维护者>"
content_status: "discussion | confirmed"
published_revision: "<commit或hash>"
published_by: "<发布者>"
published_at: "<发布时间>"
source_refs:
  - source_id: "<来源标识>"
    selection: "<文件/章节/片段>"
supersedes: "<被替代版本>"
audience: "<项目成员组>"
```

这些字段记录来源和生效关系，不公开个人设备上的绝对路径，也不把私人目录结构变成公司契约。`content_status` 按 `artifact_id` 记录；若一次发布中同时包含讨论态与已确定内容，应拆成不同 artifact，不允许用一个总状态掩盖混合语义。项目审核策略开启且 release 含任一 confirmed artifact 时，整个原子 release 等待审核，避免部分内容先行生效。

## 六、发布流程

### 6\.1 选择来源

发布者明确给出：

- 目标项目；

- 来源文件或对象；

- 选择整个文件、指定章节还是指定片段；

- 是否需要合并多份材料；

- 本次发布物的 `content_status` 是 `discussion` 还是 `confirmed`；

- 哪些内容明确不得进入共享区。

v1 不自动监听私人文件变化。私人源更新只产生“可能需要再发布”的信号，不自动覆盖 current。

### 6\.2 生成发布物

发布 Skill 在临时构建区生成一份干净发布物，并执行：

- 只复制明确 allowlist 的正文；

- 收集候选真正依赖的附件；

- 把可发布的内部链接改写为项目链接；

- 对未发布链接做删除、摘要替换或显式缺口标记；

- 检查敏感信息、私人绝对路径和凭据；

- 记录 `source_refs` 与内容 hash；

- 生成 current 与本次发布物的 diff。

### 6\.3 发布

自动质量检查通过后，发布者确认目标项目和 diff，执行一次明确的“发布”动作。v1 的生效规则是：

- 发布权限由项目发布身份或发布网关凭据控制；

- 依据项目审核策略决定 confirmed 是否需要第二人审核；审核状态只存在于 release 事务，不创建第三种内容状态；

- 发布者必须明确选择 `content_status`；改变材料状态也通过一次新的明确发布完成；

- 自动检查失败时阻止写入，并保留上一版 current；

- 发布网关校验本次构建所基于的 current hash，避免覆盖别人刚刚发布的新版本；

- 发布成功后直接形成新的 `main/current` commit。

人工查看 diff、口头确认或飞书讨论可以存在。是否进入系统审核门由项目策略唯一决定；v1 只实现最小条件分支，不建设通用审批产品。飞书审批、复杂会签等产品化能力留给 v2 根据真实使用情况决定。

### 6\.4 生效与读回

发布物进入 `main/current` 后，该次更新完成一个版本切换：

- 上一 current 在切换前持续服务；

- 新 current 原子生效；

- 旧版本退出默认读取面；

- 发布回执记录替代关系；

- current 导出完成后才进入读回和通知。

## 七、状态机

### 7\.1 两条状态轴

v1 把两件事分开：

- **技术状态**回答“这是不是当前共享版本”：`current / superseded / retired`；

- **材料状态**回答“内容是否已经确定”：`discussion / confirmed`。

两种材料状态都可以进入 current。发布者选择状态，系统记录并展示；discussion 永远免内容审核，confirmed 按项目策略决定是否需要 reviewer。状态变化必须形成新的发布记录，不能只在读取端口头改称呼。

需要区分四件事：

- **私人材料存在**：不代表公司知道；

- **发布物已经生成**：不代表已经进入公司 current；

- **内容进入 current**：不代表已经定稿，仍要看 `content_status`；

- **发布动作成功**：不代表导出和 Agent 已刷新；

- **Agent 已读回**：只证明交付链正确，不证明业务判断永远正确。

## 八、通知与读回

每次发布生成一张发布回执，至少包含：

- 项目与 current 地址；

- 新 commit/hash；

- 发布人和发布时间；

- 变更摘要；

- 被替代版本；

- 需要关注的关键变化；

- `content_status`；

- Agent 读回结果。

v1 不依赖飞书 API 自动通知。第一期可以由发布者把回执和 current 链接人工发到现有协作群；待基础链路真实被使用后，再选择通知适配器。

发布完成必须验证：

1. Git `main` 指向本次发布 hash；

2. current 导出目录与 `main/current` 一致；

3. Nginx/挂载入口能读到新版本；

4. Agent 能返回正确 `artifact_id`、commit/hash、`content_status` 和关键结论；遇到 `discussion` 必须标注“在讨论中”，不能把它表述为已确定公司口径；

5. Agent 默认读取不到发布构建区、历史和未授权项目。

任何一步失败，都不能报告“发布完成”。

## 九、恢复与冲突

### 9\.1 恢复

恢复不是让每个人各自停在一个旧版本，而是：

1. 项目维护者或发布者选择一个历史 commit；

2. 生成恢复发布物；

3. 说明恢复原因和影响；

4. 按正常发布流程形成一个新的 current commit；

5. 导出并完成 Agent 读回。

这样公司始终只有一个 current，同时保留“为什么恢复”的谱系。

### 9\.2 冲突

|冲突类型|处理方式|
|---|---|
|两人同时执行发布|发布网关比较 `base_current`；后到且基线过期的发布失败，基于最新 current 重新构建|
|新内容补充旧内容|合入现有章节或新增章节，不必升级全部定义|
|新口径替代旧定义|形成完整新 current，旧版由 Git 历史保留|
|发布构建期间 current 变化|阻止覆盖，重新基于最新 current 生成 diff 后发布|
|私人源与企业 current 不一致|企业使用 current；私人源变化需再次发布|
|企业 current 需要反哺个人源|形成建议，由个人决定吸收，不自动回写|

## 十、实现选择

公司实现已经明确选择**在现有空余服务器上自建 Gitea**，不再把 Git 品牌留作实施时待选项：

1. Gitea 作为公司 Git 远端和权限层，管理 6 名成员的独立账号、SSH key、项目团队和私有仓库；每个项目只授权实际参与成员；

2. 所有电脑仍使用标准 Git。个人 Vault 不设置公司远端，只由 NAS 单向备份，不上传公司 Gitea；公司 Context 项目仓库才推送到 Gitea；

3. Gitee 免费团队方案在当前 6 人规模下不适合作为长期基础设施；自建 Gitea 不受托管平台套餐人数限制，但公司自行承担运维；

4. 外部分享中的 bare Git \+ hook \+ Nginx 继续作为 v0 证据，不作为公司的长期权限管理层；裸仓库缺少用户、项目成员、密钥撤销和审计管理界面；

5. 不选择 GitLab：对当前 6 人、Markdown 为主的负载过重；也不先部署重型 Wiki、Redis、对象存储或复杂页面权限系统；

6. 所有项目采用单一发布网关：成员执行发布，只有网关的 Gitea 凭据能更新 `main`；网关同时执行项目审核策略，但不扩展为通用审批平台；

7. Gitea 的仓库数据、数据库和配置必须做异机备份并至少验证一次恢复；NAS 是候选备份目标，但服务器到 NAS 的实际路径和 `.git` 纳入情况仍需现场确认；

8. 生产服务器的实现修改必须先查明部署路径，通过开发环境 → Gitea 远端真源 → 服务器部署，不直接改生产工作树。

最小运行组件：

- 一台现有空余服务器（已知规格高于 2 核 2 GB）；

- 自建 Gitea 与异机备份；

- 项目仓库与成员权限；

- 单一发布网关；

- current 导出 hook；

- Nginx 或本地只读挂载；

- 发布 Skill；

- current 读回检查。

## 十一、v1 试点

### 11\.1 范围

- 当前团队共 6 人，从中选择实际参与首个项目的成员，不默认 6 人全员获得每个项目权限；

- 一个正在运行、确实需要共享 Context 的项目；

- 一套公司自建 Gitea；

- 一个 Gitea 项目私有仓库；

- 一个项目维护者和至少一个发布者；

- 不迁移历史全量知识；

- 只实现按项目审核开关的最小条件分支；不建设通用审核工作流；

- 不依赖飞书 API，也不打通飞书权限。

### 11\.2 五类样本

1. 私人单文件先以 `discussion` 发布，再重新以 `confirmed` 发布；

2. 不同目录的多份材料合成；

3. 带图片或附件；

4. 相邻存在私密内容，只发布允许片段；

5. 两人基于同一 current 并发发布，后到的旧基线发布被阻止并能在最新版本上重建。

### 11\.3 通过口径

- 未选择的私人内容和私人仓库历史未进入项目仓库；

- 人和 Agent 都能识别同一个 current hash；

- 人和 Agent 都能识别每个 artifact 的 `content_status`，且不会把 `discussion` 当成已确定结论；

- 发布者能够在不处理 Git 分支和 PR/MR 的情况下完成发布；

- 项目成员使用独立 Gitea 账号和 SSH key；移除成员后能够阻止其未来访问；

- 发布构建与失败结果不进入默认读取面；

- 附件、链接和项目内引用完整；

- 能完成一次恢复发布并保持单一 current；

- 项目成员不需要亲自处理复杂 Git 冲突；

- 至少有真实发布、读取、纠错和恢复行为，而不是只完成安装；

- 从空环境能够恢复正文、附件、历史和读取入口；

- Gitea 仓库、数据库和配置完成异机备份，并至少验证一次恢复。

### 11\.4 止损信号

- 同一项目出现两个被人或 Agent 当作 current 的入口；

- 私人内容进入共享历史且无法确认影响范围；

- 每次发布都要手工修链接、附件或 merge；

- 实际发布仍只有技术维护者使用，其他成员不参与；

- Agent 必须扫描私人 Vault 或历史分支才能回答；

- 发布权限和项目维护责任不清，却开始增加复杂服务和自动化；

- 多人共享同一个 Gitea 账号或 SSH key，导致访问和撤权无法归人；

- Gitea 只有同机数据、没有可验证的异机备份，或升级后无法恢复；

- 方案的维护成本明显高于当前共享问题本身。

## 十二、实施阶段

|阶段|目标|主要产物|进入下一阶段的条件|
|---|---|---|---|
|0\. 方案冻结|确认本文和首个试点|当前方案、试点项目、维护者、发布者、成员|用户确认实施范围|
|1\. Gitea 基础层|建立公司远端与权限边界|Gitea、独立账号/SSH key、项目私有仓库、异机备份|权限撤回和备份恢复可验证|
|2\. 基础链路|跑通项目仓库到 current|受保护 `main`、导出、只读入口|人和 Agent 能读取同一 hash|
|3\. 发布入口|隐藏 Git 操作|发布 Skill、diff、发布网关、回执|发布者能一步更新 current|
|4\. 真实试点|验证协作而非安装|五类样本、发布回执、恢复记录|无止损信号，成员真实使用|
|5\. v2 判决|判断是否需要治理增强|正式审批集成、飞书权限需求、成本与收益证据|用户决定扩展正式治理、飞书集成或保持轻量开关|

v2 不是默认的“完整版本”，而是一个由 v1 真实摩擦触发的选择：可能接入正式审批，可能只打通飞书权限，可能两者都做，也可能保持 v1 的轻量审核开关。manifest、自动编译、自动通知和更多项目仓库同样只由真实摩擦拉动。

## 十三、明确不做

- 不同步整个私人 Vault；

- 不强制个人建立 Git 仓库；

- 不把个人 Vault 推送到公司 Gitea；

- 不用 submodule 拼接多个私人仓库；

- 不做私人源与企业 current 的双向同步；

- 不自动监听并发布私人文件变化；

- 不在父仓库已追踪的路径中嵌套公司项目仓库，除非父仓库已明确排除；

- 不在同一仓库内用文件夹模拟保密权限；

- 不使用共享 Gitea 账号或共享 SSH key；

- 不把 Gitee 免费版作为 6 人团队的长期权限层；

- 不用纯 bare Git 长期承担公司用户与项目权限管理；

- 不让 Agent 获得 Git 写权限或默认读取全部历史；

- 不把“已进入 current”自动解释成“已经定稿”；

- 不在 v1 建设 proposal、PR/MR、通用审批平台或多级会签；项目开关开启时仅保留 reviewer 和 release 审核状态；

- 不在第一期部署重型企业 Wiki；

- 不把飞书 API 或飞书权限打通作为首轮运行依赖；

- 不一次覆盖所有项目。

## 十四、决策记录

|日期|已确认决定|来源|
|---|---|---|
|2026\-07\-24|项目立项即建立公司共享 Context；AI 默认只读 current；旧版可追溯恢复|项目知识库会议|
|2026\-07\-28|外部四人 Git/Nginx 方案作为轻量传输与读取 v0，不直接等同完整治理|外部方案评估案例|
|2026\-07\-28|wide 调研未发现完整一体化替代方案；Git 适合发布账本，不适合同步整个私人库|wide 调研报告|
|2026\-07\-29|项目作为业务对象；按项目授权时一项目一仓；个人仓库不强制；个人材料通过发布而非双向复制进入企业仓库|当前 Codex 会话|
|2026\-07\-29|用户批准把方案落到正式文档并整合 Mermaid 示意图|用户原话：“可以，你先把方案落到文档中，注意增加一些mermaid 示意图便于理解，然后整合最终文档”|
|2026\-07\-29|分版本推进：v1 淡化审核、只保留发布；v2 再考虑审核或打通飞书权限|用户原话：“分版本吧，第一个版本先淡化审核，只保留发布，下一个版本再考虑审核或者打通飞书权限”|
|2026\-07\-29|v1 增加材料状态：`current` 只表示当前共享版本，`discussion / confirmed` 区分在途内容与已确定口径；当时决定不增加审核|用户原话：“材料状态我同意，可以按照那个修改方案。”；该治理决定已被 2026-08-03 审核开关基线局部替代|
|2026\-08\-03|采用按项目审核开关；试点 `forced_off`，保留原 v1 免审行为，同时允许项目后续受控启用|用户要求基于 DeepSeek 审核开关治理模型核实、修正并最终收敛全部执行设计|
|2026\-07\-29|当前 `cc` Vault 建立 Markdown\-only 本地 Git 基线，`2-代码库/` 子仓库独立提交；Vault 到 NAS 只做单向备份|Vault 基线 commit `ab9496768cb8df6c59b615996269e3f06dbe2290`|
|2026\-07\-29|当前团队 6 人；公司远端选用空余服务器自建 Gitea，一项目一仓并按项目授权；个人 Vault 不上传公司 Gitea|用户原话：“好，我认可这个方案，现在更新方案文档吧”|

## 十五、进入实施前仍需拍板

以下不是方案缺口，而是实际开工必须由用户给出的项目字段：

1. 首个试点项目是什么；

2. 6 人中哪些是首个项目的成员；

3. 项目维护者与允许执行发布的人；

4. 空余服务器的操作系统、网络入口、域名/HTTPS、磁盘和服务器到 NAS 的备份路径；

5. 实施是否建立“驾驶舱”页面，用于显示阶段、信号灯、待拍板和止损状态。

在这些字段确认前，可以做环境盘点和实施清单，但不应替用户默认项目、人员或权限。

---

> **最终收口：个人怎么写由个人决定；当前 ****`cc`**** Vault 用本地 Git 留 Markdown 历史并单向备份到 NAS，个人 Vault 不上传公司远端；公司在空余服务器自建 Gitea，按项目建立私有仓库并授权，一次明确发布把选定材料送入 ****`main/current`****。Git 记录历史，Agent 只读取已发布的 current，并根据 ****`discussion / confirmed`**** 区分在途材料与已确定口径。confirmed 审核由项目策略控制，试点固定免审；正式审批平台和飞书权限仍属于 v2 候选，不阻塞 v1。**
> 
>