83 lines
9.0 KiB
Markdown
83 lines
9.0 KiB
Markdown
---
|
||
type: operation_log
|
||
owner: Verlit
|
||
last_updated_at: 2026-08-11
|
||
last_updated_by: Codex
|
||
hash: sha256:551318f3f4d4429cf90c56b09f8306ae0a95c9e45de9ce53642ad5a13c75bfd8
|
||
belongs_to:
|
||
- 3-业务线/Gitea知识库/_context
|
||
depends_knowledge: []
|
||
---
|
||
|
||
# Gitea知识库操作记录
|
||
|
||
## 2026-08-05
|
||
|
||
- 根据 Verlit 的明确要求创建 `3-业务线/Gitea知识库/`。
|
||
- 创建业务上下文、任务、资源、决策和操作记录五项基础文档。
|
||
- 索引现有公司共享 Context 发布方案及配套方案包。
|
||
- 明确当前仅完成业务线建档与方案索引，尚未进入实施阶段。
|
||
- 未执行 Gitea 安装、服务器连接、仓库创建、权限调整、内容迁移、远端同步或发布。
|
||
|
||
## 2026-08-06
|
||
|
||
- 清理与本业务线目标无关的跨业务线排期、边界和启动条件记录。
|
||
- 明确后续只依据 Gitea 知识库自身的试点范围、责任人、实施参数和验收条件推进。
|
||
- 对照原始 `公司共享 Context 项目仓库发布方案 v1` 完成偏移审查。
|
||
- 将主方案从 `0-收集箱/` 归位到本业务线，保留 `migrated_from`、原正文 hash 和治理补丁关系。
|
||
- 将业务线阶段调整为“方案冻结与实施参数”，不再重新选择已冻结的仓库、权限、发布、`current` 和状态模型。
|
||
- 将任务恢复为 Gitea 基础层、基础链路、发布入口、真实试点和 v2 判决五个后续阶段。
|
||
- 清理“同步器”“批量迁移”和“重新确定模型”等偏移表述；未执行任何远端操作。
|
||
|
||
## 2026-08-07
|
||
|
||
- 在业务线上下文补充企业内部 AI 的共享 Context 与权限治理底座定位。
|
||
- 明确知识库基础链路优先、只读 Agent 已属于 v1，飞书身份、动态授权和受控 Skill 为后续扩展。
|
||
- 保持现有阶段和实施任务不变；未执行任何远端操作。
|
||
- 逐份复核方案包 00～12 与执行落地手册 EXE-00～13，登记 adopted、补充、可选和已失效章节，不重新打开 v1 冻结决策。
|
||
- 形成 `v1-设计追溯与版本关系.md`、`v1-实施参数与决策清单.md`、`v1-详细实施方案.md` 和 `v1-验收与止损矩阵.md`。
|
||
- 明确当前 v1 不纳入飞书身份数据库和 Skill Registry；它们分别作为后续版本候选，不能成为 v1 实施前置。
|
||
- 清除决策记录中遗留的跨业务线排期说明；Gitea 的暂停与启动条件只依据本业务线自身参数。
|
||
- 本次只修改本地业务线文档，未连接服务器，未安装 Gitea，未创建仓库、账号或权限，未执行同步和发布。
|
||
- 根据 Verlit 明确指令，将当前阶段纠正为 `C0 工程设计构建`，把代码开发和真实实施拆为需要分别授权的 `C1` 与 `G0`。
|
||
- 将首个试点、成员、服务器、备份和 RPO/RTO 移到未来 G0，不再显示为当前推进阻塞项。
|
||
- 新建 `v1-工程构建规格.md`，补齐逻辑模块、平台代码仓库与项目 Context 仓库分离、契约所有权、状态、逻辑操作、配置与秘密边界。
|
||
- 新建 `v1-开发任务分解.md`，形成 DEV-00～14 及可选任务；全部保持 planned，未创建或修改任何代码。
|
||
- 扩充 `v1-验收与止损矩阵.md`，增加 C0/C1/G0 阶段门与 CT/UT/IT/SEC/REC/T 六层测试规格。
|
||
- 本轮仍只修改本地文档；未创建平台代码仓库，未编写或运行系统代码，未连接服务器/Gitea，未部署、未发布、未写入 `_runtime`。
|
||
|
||
## 2026-08-10
|
||
|
||
- 对照当前“全员 Agent＋MCP”目标复核 v1 的入口、身份、权限、Agent 和审计口径，确认底层仓库/发布/current 模型可继承，不需要重写完整设计。
|
||
- 新建 `公司共享 Context MCP-first 身份与审计方案 v1.1.md`，以差量覆盖方式将 MCP 唯一用户入口、无自建 Web、飞书身份绑定、内部权限＋Gitea 权限双层限制、A3/A4 受控请求和三主体强制审计纳入当前目标。
|
||
- 保持 `公司共享 Context 项目仓库发布方案 v1.md` 正文及 `sha256:a3a33cec7dfd0441fdf12af420bfc4f3d63ee7c113d4ae298ab96d2e2e45285f` 不变。
|
||
- 同步更新工程构建规格、DEV-00～14、实施参数、EXE-01～12、验收止损、版本追溯、业务入口、任务、资源和决策。
|
||
- 明确审计查询可走 MCP，但审计写入由服务端中间件自动完成；部署、迁移、备份、密钥、Gitea Admin、权限写入、SQL/SSH 和动作开关不暴露为普通 MCP 工具。
|
||
- 本轮只修改本地 Markdown 设计文档；未创建代码仓库或代码，未运行 MCP/测试，未连接飞书、Gitea、服务器或其他远端，未部署、未发布、未写入 `_runtime`。
|
||
- 根据 Verlit 要求补充 `v1.1-技术栈与详细实施设计.md`，推荐 Go 1.26.x、官方 Go MCP SDK v1.7.x、PostgreSQL 18.x、Gitea 1.26.x、`net/http`、pgx/sqlc、PostgreSQL outbox/检索和 OCI 打包。
|
||
- 设计采用模块化单体代码库、`serve/worker` 双运行角色，不引入自定义 Web、Redis、Kafka、Elasticsearch、向量数据库、微服务或 Kubernetes 前置。
|
||
- 将 Agent Host 的逐用户远程 MCP OAuth、可靠 A3/A4 确认和本地 Markdown 读取/传输定义为 C1-00 硬门；未验证前不声称真实身份和发布工具可用。
|
||
- 根据 Verlit 补充信息，将 Agent Host 硬门重构为 Agent 无关的 adapter contract：首批 Codex、Claude Code，后续客户端只新增适配器。
|
||
- 确认逐用户远程 MCP OAuth、框架人类确认和本地文件读取/传输方向成立；新增 Local Source Gate，限制允许根、明确选择、类型/大小、路径逃逸、控制文件、预检查、manifest/hash 和分块完整性。
|
||
- 明确客户端原生 tool prompt 只作为交互保护，服务端发布授权仍要求框架签发的一次性 confirmation；本轮未运行 Codex/Claude Code MCP 连接或任何代码。
|
||
- 完成闭环缺口审查：将 MCP OAuth 协议与令牌生命周期边界固定为成熟 OAuth/OIDC Authorization Server＋飞书身份联邦；将首次绑定固定为飞书稳定 ID 与 Gitea 数字 ID 的受控预配置；将中文主检索从 PostgreSQL 原生 FTS 修正为 `pg_trgm`＋元数据过滤。
|
||
- 新建 `Gitea知识库 v1.1 产品需求文档 PRD.md`，覆盖产品范围、角色、S00～S28 调用/功能/输出、MCP 工具、状态、安全默认值、异常、验收、开发/实施分段和未决 Gate。
|
||
- 新建 `Gitea知识库 v1.1 完整流程闭环.canvas`，以 Obsidian Canvas 表达登录、双层授权、读取、来源、构建、发布、current、检索、读回、审计、拒绝、撤权、重试和恢复闭环。
|
||
- 本轮仍只生成和修订本地设计产物；未安装额外能力，未编写/运行系统代码，未连接飞书/Gitea/服务器，未部署或发布。
|
||
|
||
## 2026-08-11
|
||
|
||
- Verlit 明确授权进入范围受限的 G0 基础实施，目标主机为 `120.27.248.208`、SSH 范围为 `/`；同时明确不得变动服务器上其他正在运行的代码与服务，反向代理由 Verlit 自行处理。
|
||
- 只读核对 `/www/wwwroot/gitea`，确认其为 Gitea 源码检出而非运行安装目录；本次未构建、修改或运行该源码，验收时 tracked 状态为空，HEAD 为 `7e3eeca7795db95f25c14174855c1ac12e8797e5`。
|
||
- 为 SSH MCP 增加仅限固定主机、`gitea_base` profile 和 `/www/wwwroot/gitea` 的白名单安装/检查能力；本地 9 项测试及 MCP 配置校验通过。
|
||
- 下载官方 Gitea 1.26.4 Linux amd64 二进制，使用官方签名主密钥指纹 `7C9E68152594688862D62AF62D9AE806EC1592E2` 验证二进制与校验和签名，并核对 SHA-256 `0faa36d151918f8f7d6e0f3ae67597d1c338583d695add146ac393109d0fc44a`。
|
||
- 新增独立 `git` 系统账号、`/usr/local/bin/gitea`、`/etc/gitea/app.ini`、`/var/lib/gitea` 和 `gitea.service`；服务仅监听 `127.0.0.1:3000`，systemd active，本机 HTTP 返回 200。
|
||
- 未配置数据库、正式域名、HTTPS、反向代理、备份、组织、用户、仓库或权限；`INSTALL_LOCK=false`，当前只提供本机安装页。
|
||
- 未修改宝塔/Nginx、防火墙、Redis、PHP 或其他业务。只读核对发现 `nginx.service` 的 failed 状态始于 2026-05-13，明显早于本次安装；宝塔 Nginx 进程仍监听 80/443，未对其执行任何处置。
|
||
- 脱敏验收证据写入 `_runtime/gitea-install/snapshots/2026-08-11/base-install.md`。
|
||
- Verlit 随后自行填写 Gitea 专用 MySQL 参数并设置 `INSTALL_LOCK=true`。脱敏核对确认必填项与密码均已填写，但未输出密码。
|
||
- 因 `SECRET_KEY` 与 `INTERNAL_TOKEN` 缺失，为 Gitea 生成随机安全密钥；将原配置备份到 `/etc/gitea/app.ini.pre-finalize-20260811`（root:root、0600），再仅重启 `gitea.service`。
|
||
- Gitea 完成 MySQL 自动迁移，主页与 `/api/healthz` 均返回 200；`/etc/gitea` 收紧为 0750，`app.ini` 收紧为 root:git、0640。
|
||
- 只读查询确认数据库内尚无 Gitea 用户；下一步需创建首个管理员，再配置正式 `ROOT_URL` 与反向代理。
|
||
- 根据 Verlit 指定的用户名与邮箱创建首个管理员；服务器端生成 24 位随机临时密码，设置 `--must-change-password`，未生成访问令牌。回读确认 ID=1、active=true、admin=true、2FA=false。
|