Claude/translate to chinese pn ktt

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,49 +1,49 @@
-## Thinking Path
+## 思路路径
 
 <!--
-  Required. Trace your reasoning from the top of the project down to this
-  specific change. Start with what Paperclip is, then narrow through the
-  subsystem, the problem, and why this PR exists. Use blockquote style.
-  Aim for 5–8 steps. See CONTRIBUTING.md for full examples.
+  必填。从项目顶层到本次具体变更，追溯你的推理过程。
+  从 Paperclip 是什么开始，然后逐步缩小到子系统、问题，
+  以及为什么需要这个 PR。使用引用块格式。
+  目标为 5-8 个步骤。完整示例参见 CONTRIBUTING.md。
 -->
 
-> - Paperclip orchestrates AI agents for zero-human companies
-> - [Which subsystem or capability is involved]
-> - [What problem or gap exists]
-> - [Why it needs to be addressed]
-> - This pull request ...
-> - The benefit is ...
+> - Paperclip 为零人力公司编排 AI 智能体
+> - [涉及哪个子系统或能力]
+> - [存在什么问题或缺口]
+> - [为什么需要解决]
+> - 本 Pull Request ...
+> - 带来的好处是 ...
 
-## What Changed
+## 变更内容
 
-<!-- Bullet list of concrete changes. One bullet per logical unit. -->
+<!-- 具体变更的要点列表。每个逻辑单元一条。 -->
 
 -
 
-## Verification
+## 验证方式
 
 <!--
-  How can a reviewer confirm this works? Include test commands, manual
-  steps, or both. For UI changes, include before/after screenshots.
+  审查者如何确认这些改动是有效的？包括测试命令、手动步骤，
+  或两者兼有。对于 UI 变更，请附上修改前/修改后的截图。
 -->
 
 -
 
-## Risks
+## 风险
 
 <!--
-  What could go wrong? Mention migration safety, breaking changes,
-  behavioral shifts, or "Low risk" if genuinely minor.
+  可能出现什么问题？说明迁移安全性、破坏性变更、
+  行为变化，或者如果确实影响很小则写"低风险"。
 -->
 
 -
 
-## Checklist
+## 检查清单
 
-- [ ] I have included a thinking path that traces from project context to this change
-- [ ] I have run tests locally and they pass
-- [ ] I have added or updated tests where applicable
-- [ ] If this change affects the UI, I have included before/after screenshots
-- [ ] I have updated relevant documentation to reflect my changes
-- [ ] I have considered and documented any risks above
-- [ ] I will address all Greptile and reviewer comments before requesting merge
+- [ ] 我已包含从项目上下文到本次变更的思路路径
+- [ ] 我已在本地运行测试并且通过
+- [ ] 我已在适用的地方添加或更新了测试
+- [ ] 如果此变更影响 UI，我已附上修改前/修改后的截图
+- [ ] 我已更新相关文档以反映我的变更
+- [ ] 我已考虑并在上方记录了所有风险
+- [ ] 我将在请求合并之前处理所有 Greptile 和审查者的评论

AGENTS.md

@@ -1,148 +1,148 @@
 # AGENTS.md
 
-Guidance for human and AI contributors working in this repository.
+为在本仓库工作的人类和 AI 贡献者提供的指导。
 
-## 1. Purpose
+## 1. 项目目的
 
-Paperclip is a control plane for AI-agent companies.
-The current implementation target is V1 and is defined in `doc/SPEC-implementation.md`.
+Paperclip 是面向 AI 智能体公司的控制平面。
+当前实现目标为 V1，定义在 `doc/SPEC-implementation.md` 中。
 
-## 2. Read This First
+## 2. 请先阅读以下内容
 
-Before making changes, read in this order:
+在进行修改之前，请按以下顺序阅读：
 
 1. `doc/GOAL.md`
 2. `doc/PRODUCT.md`
 3. `doc/SPEC-implementation.md`
 4. `doc/DEVELOPING.md`
 5. `doc/DATABASE.md`
 
-`doc/SPEC.md` is long-horizon product context.
-`doc/SPEC-implementation.md` is the concrete V1 build contract.
+`doc/SPEC.md` 是长期产品背景。
+`doc/SPEC-implementation.md` 是具体的 V1 构建合约。
 
-## 3. Repo Map
+## 3. 仓库结构
 
-- `server/`: Express REST API and orchestration services
-- `ui/`: React + Vite board UI
-- `packages/db/`: Drizzle schema, migrations, DB clients
-- `packages/shared/`: shared types, constants, validators, API path constants
-- `packages/adapters/`: agent adapter implementations (Claude, Codex, Cursor, etc.)
-- `packages/adapter-utils/`: shared adapter utilities
-- `packages/plugins/`: plugin system packages
-- `doc/`: operational and product docs
+- `server/`：Express REST API 和编排服务
+- `ui/`：React + Vite 面板 UI
+- `packages/db/`：Drizzle schema、迁移、数据库客户端
+- `packages/shared/`：共享类型、常量、验证器、API 路径常量
+- `packages/adapters/`：智能体适配器实现（Claude、Codex、Cursor 等）
+- `packages/adapter-utils/`：共享适配器工具
+- `packages/plugins/`：插件系统包
+- `doc/`：运维和产品文档
 
-## 4. Dev Setup (Auto DB)
+## 4. 开发环境搭建（自动数据库）
 
-Use embedded PGlite in dev by leaving `DATABASE_URL` unset.
+在开发环境中使用内嵌的 PGlite，不设置 `DATABASE_URL` 即可。
 
 ```sh
 pnpm install
 pnpm dev
 ```
 
-This starts:
+启动后包含：
 
-- API: `http://localhost:3100`
-- UI: `http://localhost:3100` (served by API server in dev middleware mode)
+- API：`http://localhost:3100`
+- UI：`http://localhost:3100`（在开发中间件模式下由 API 服务器提供）
 
-Quick checks:
+快速检查：
 
 ```sh
 curl http://localhost:3100/api/health
 curl http://localhost:3100/api/companies
 ```
 
-Reset local dev DB:
+重置本地开发数据库：
 
 ```sh
 rm -rf data/pglite
 pnpm dev
 ```
 
-## 5. Core Engineering Rules
+## 5. 核心工程规则
 
-1. Keep changes company-scoped.
-Every domain entity should be scoped to a company and company boundaries must be enforced in routes/services.
+1. 保持变更限定在公司范围内。
+每个领域实体都应限定在公司范围内，路由/服务中必须强制执行公司边界。
 
-2. Keep contracts synchronized.
-If you change schema/API behavior, update all impacted layers:
-- `packages/db` schema and exports
-- `packages/shared` types/constants/validators
-- `server` routes/services
-- `ui` API clients and pages
+2. 保持合约同步。
+如果你更改了 schema/API 行为，需更新所有受影响的层：
+- `packages/db` schema 和导出
+- `packages/shared` 类型/常量/验证器
+- `server` 路由/服务
+- `ui` API 客户端和页面
 
-3. Preserve control-plane invariants.
-- Single-assignee task model
-- Atomic issue checkout semantics
-- Approval gates for governed actions
-- Budget hard-stop auto-pause behavior
-- Activity logging for mutating actions
+3. 保持控制平面不变量。
+- 单一指派人任务模型
+- 原子性的 issue 检出语义
+- 受治理操作的审批门控
+- 预算硬性停止自动暂停行为
+- 变更操作的活动日志记录
 
-4. Do not replace strategic docs wholesale unless asked.
-Prefer additive updates. Keep `doc/SPEC.md` and `doc/SPEC-implementation.md` aligned.
+4. 除非被要求，不要整体替换战略文档。
+优先进行增量更新。保持 `doc/SPEC.md` 和 `doc/SPEC-implementation.md` 的一致性。
 
-5. Keep plan docs dated and centralized.
-New plan documents belong in `doc/plans/` and should use `YYYY-MM-DD-slug.md` filenames.
+5. 保持计划文档标注日期并集中管理。
+新的计划文档应放在 `doc/plans/` 中，使用 `YYYY-MM-DD-slug.md` 文件命名格式。
 
-## 6. Database Change Workflow
+## 6. 数据库变更工作流
 
-When changing data model:
+更改数据模型时：
 
-1. Edit `packages/db/src/schema/*.ts`
-2. Ensure new tables are exported from `packages/db/src/schema/index.ts`
-3. Generate migration:
+1. 编辑 `packages/db/src/schema/*.ts`
+2. 确保新表从 `packages/db/src/schema/index.ts` 导出
+3. 生成迁移：
 
 ```sh
 pnpm db:generate
 ```
 
-4. Validate compile:
+4. 验证编译：
 
 ```sh
 pnpm -r typecheck
 ```
 
-Notes:
-- `packages/db/drizzle.config.ts` reads compiled schema from `dist/schema/*.js`
-- `pnpm db:generate` compiles `packages/db` first
+注意事项：
+- `packages/db/drizzle.config.ts` 从 `dist/schema/*.js` 读取编译后的 schema
+- `pnpm db:generate` 会先编译 `packages/db`
 
-## 7. Verification Before Hand-off
+## 7. 提交前验证
 
-Run this full check before claiming done:
+在声明完成之前运行以下完整检查：
 
 ```sh
 pnpm -r typecheck
 pnpm test:run
 pnpm build
 ```
 
-If anything cannot be run, explicitly report what was not run and why.
+如果有任何检查无法运行，请明确报告哪些未运行及原因。
 
-## 8. API and Auth Expectations
+## 8. API 和认证要求
 
-- Base path: `/api`
-- Board access is treated as full-control operator context
-- Agent access uses bearer API keys (`agent_api_keys`), hashed at rest
-- Agent keys must not access other companies
+- 基础路径：`/api`
+- 面板访问视为具有完全控制权的操作员上下文
+- 智能体访问使用 Bearer API 密钥（`agent_api_keys`），静态存储时进行哈希处理
+- 智能体密钥不得访问其他公司的数据
 
-When adding endpoints:
+添加接口时：
 
-- apply company access checks
-- enforce actor permissions (board vs agent)
-- write activity log entries for mutations
-- return consistent HTTP errors (`400/401/403/404/409/422/500`)
+- 应用公司访问检查
+- 强制执行操作者权限（面板 vs 智能体）
+- 为变更操作写入活动日志条目
+- 返回一致的 HTTP 错误（`400/401/403/404/409/422/500`）
 
-## 9. UI Expectations
+## 9. UI 要求
 
-- Keep routes and nav aligned with available API surface
-- Use company selection context for company-scoped pages
-- Surface failures clearly; do not silently ignore API errors
+- 保持路由和导航与可用的 API 接口对齐
+- 在公司范围页面中使用公司选择上下文
+- 清晰地展示失败信息；不要静默忽略 API 错误
 
-## 10. Definition of Done
+## 10. 完成的定义
 
-A change is done when all are true:
+当以下条件全部满足时，变更才算完成：
 
-1. Behavior matches `doc/SPEC-implementation.md`
-2. Typecheck, tests, and build pass
-3. Contracts are synced across db/shared/server/ui
-4. Docs updated when behavior or commands change
+1. 行为符合 `doc/SPEC-implementation.md`
+2. 类型检查、测试和构建通过
+3. 合约在 db/shared/server/ui 之间保持同步
+4. 当行为或命令发生变更时，文档已更新