CCode 代码托管平台
13 项功能
F01 · 代码协作 · 4 份 PRD
仓库文件管理功能集
新建文件 / 新建文件夹 / 导入文件与文件夹 / 删除文件 / 删除文件夹五大能力，整合为统一功能集。Figma 原型 + 设计稿双轨交付，三阶段校验引擎覆盖 13 种异常场景。
- "文件夹→文件"跳转设计：文件夹不独立提交 commit，随文件提交一并完成，无需 .gitkeep 占位
- 8 大类 14 条导入校验规则：前置拦截 → 路径尺寸校验 → 上传过程校验，三阶段级联
- 7 种实时文件状态标签：待上传/上传中/成功/失败—大于25MB/重名覆盖/损坏/网络异常
- 空目录级联删除 + 页面离开保护：对齐 Git 不跟踪空目录原则
F02 · 平台基础设施 · REPO-001 + REPO-002
镜像推送与仓库推送
打通仓库与外部仓库（GitHub/GitLab/Gitee 等）之间的推送镜像能力。完整版（REPO-001）与精简版（REPO-002）双 PRD，覆盖从创建到同步的完整生命周期。
- 三种仓库来源 × 三种授权方式矩阵：OAuth / PAT / 用户名密码，每种组合对应不同交互流程
- 智能地址识别 + SSH 协议支持：协议感知动态表单切换（http ↔ ssh，令牌 ↔ 密钥对应）
- Force Push 策略 + 5 种失败原因精细化提示：同名分支覆盖、源新目标无→新建、目标有源无→保留不动
- REPO-002 新增编辑能力 + 同步 LFS 对象：最多 10 个目标仓库（对齐 GitLab 上限）
F03 · 代码协作 · V10.0 · 48 条验收条件 · 24 测试通过
Code Owner 代码所有者
通过 CODEOWNERS 文件声明路径与所有者的对应关系，MR/CR 涉及这些路径时自动纳入审批要求。对齐 GitHub 行业标准，4 入口 8 场景原型。
- 默认分支权威：仅默认分支的 CODEOWNERS 为全局权威来源，消除不同分支规则歧义
- Code Owner 作为独立评审来源：与普通/关键评审人并存，多 Owner 任一通过即满足
- 审批版本与 source-head revision 绑定：新提交时上一版本审批自动失效，精细化失效粒度控制
- 6 类安全原因码 + 8 种权威重算场景矩阵：重复事件或相同输入为 no-op
F04 · 安全合规 · V10.0（10 次迭代）
路径保护
对仓库内特定路径提供细粒度写保护，硬门禁优先于 MR/CR 评审，命中即阻断。直接满足金融合规客户的招标硬性需求。4 个活动主题板原型 + DESIGN.md 设计契约。
- 硬门禁模型：命中规则直接阻止写入，不能通过批准绕过——区别于常规"软提醒"
- 聚合规则 + 原子提交：多路径批量创建一条聚合规则，任一路径异常整个操作被拒绝
- 纯词法路径匹配：不依赖文件系统，可配置仓库中尚不存在的"未来路径"
- "创建不阻断、合并才阻断"：MR 创建阶段仅提示，合并阶段实时重算并弹出阻断对话框
F05 · 代码协作
提交人展示（Author / Committer）
规范代码提交中「作者」与「提交人」两个角色的展示逻辑，覆盖 rebase、squash、cherry-pick、Co-authored-by、CI 机器人等复杂场景。Figma 原型交付。
- 双角色明确区分 + 双头像交叠设计：作者在前、提交人在后偏移，6 种展示组合样式
- 7 种 Git 操作场景逐一推演：正常提交、--author、Rebase、Squash、Cherry-pick 等
- Co-authored-by 共同作者解析：自动解析 trailer，最多展示前 3 个头像叠放，其余 "+N" 可展开
- Committer 作为来源标识：AI 工具各有独立图标，回答"提交来自哪里"
F06 · 安全合规 · V2.0（10 次迭代）
删除用户后系统行为规范
定义用户被删除后在仓库组、提交记录、MR、议题、评论等全量场景中的展示行为。竞品分析覆盖 GitLab 6 大场景 18 子场景，系统性枚举 10 个核心模块 30+ 字段。
- 核心洞察：区分"主动操作"与"被动操作"——主动行为保留原用户名但不可点击，被动关系自动清理
- 渐进退化策略：先查原用户名，无法获取时降级为 Ghost，兼顾可追溯与容错
- 方案 A（数据隔离）优先：删除用户与新用户完全隔离，从安全/复杂度/企业匹配度四维度对比决策
F07 · 代码协作
源分支删除与恢复
MR 合并后源分支删除的交互与恢复能力。HTML 高保真原型（V2.0, 102KB），覆盖 14 种场景的完整交互流程。
- 14 场景全覆盖：从简单单 MR 删除到跨仓库 MR、多 MR 引用、超 30 天不可恢复
- 分支命名规范联动：无规范/警告模式/强制模式三档策略，恢复时名称合规校验
- 多 MR 引用风险提示：最多展示 5 个引用 MR（带状态标识），删除后 14 天内可恢复
F08 · 安全合规
提交身份校验（committor-author 一致性）
推送时校验提交身份与平台账号的一致性，防止冒名提交，满足企业合规与安全诉求。Figma 原型交付。
- 严格 / 基础两种模式：严格模式不匹配即拒绝，基础模式仅记录告警，满足不同安全等级客户
- 在 git push 环节从源头阻断：服务端校验而非前端展示，本地 git 配置不可信
- 与多邮箱管理能力闭环：基于用户全部已验证邮箱校验，而非仅主邮箱
F09 · 用户能力
多邮箱管理
支持用户管理多个邮箱，区分主邮箱 / 通知邮箱 / 已验证邮箱三种角色，为通知推送、提交身份识别提供灵活性。Figma 原型交付。
- 角色化邮箱模型：主邮箱（登录/唯一标识）、通知邮箱（消息推送）、已验证邮箱（安全校验）三种角色分离
- 验证机制：新增邮箱需验证后才能生效，防止错填/滥用
- 与通知、登录、提交身份联动：为 committor-author 校验和消息通知链路提供邮箱基础设施
流程规范与知识沉淀
F10 · 竞品调研专项
竞品调研长期跟踪体系
覆盖文件操作、镜像仓库、删除用户、Code Owner、提交人展示等 5 大主题。自创四步法 + 可复用模板，使每个产品决策有据可查。核心原则：调研要思考"为什么一个平台做了、另一个没做"。
F11 · CCode 操作手册
企业级操作手册编写
覆盖仓库、分支、权限、流水线、Webhook、IP 白名单、制品仓库等十余个模块。1828 张截图、113 个 md 文件，企业版与独立版双版本维护。
F12 · PRD 需求文档治理规范
PRD 标准化治理体系
分层治理架构（规则层+执行层），产品级与技术级边界红线，5 种状态流转，AI 协作角色边界。本工作集多份 PRD 均按此体系编号。
F13 · 需求到上线 SOP
端到端流程标准化
接收需求 → 竞品分析 → 输出 PRD（十章标准结构）→ 工具使用 → 验收上线，配套测试交接条件与状态流转规范。
