@pzy560117/codex-harness 0.1.2 → 0.1.4

package/package-source/docs/codex-harness-engineering/templates/config/global-AGENTS.md

@@ -1,40 +0,0 @@
-# Global AGENTS.md
-
-## 通用工作原则
-
-- 默认使用简体中文输出。
-- 在没有验证证据前，不要声称任务已完成。
-- 先阅读代码和文档，再修改文件。
-- 开始实现前，先确认验收标准、测试入口和完成证据路径。
-- 尽量保持改动范围小且可审计。
-
-## 工具与命令规则
-
-- 先用 `Get-Command` 检查命令是否存在。
-- 命令不存在时优先使用已知绝对路径，不盲目重装工具。
-- 搜索文件优先使用 `rg` 或 `rg --files`。
-- 不要用内联脚本绕过正常文件和脚本结构。
-
-## Git 规则
-
-- dirty workspace 默认视为阻塞，除非用户明确说明哪些改动属于当前任务。
-- 禁止在未确认时使用破坏性命令，如 `git reset --hard`、`git checkout --`、递归删除。
-- 提交前必须有 fresh verification evidence。
-
-## 安全规则
-
-- 不把 token、cookie、私钥、密码写入仓库、trace 或文档。
-- 不在不可信环境使用高权限 sandbox。
-- 对外部输入保持最小权限原则。
-
-## 分层规则
-
-- 跨项目稳定习惯放全局 `~/.codex/AGENTS.md`。
-- 当前仓库规则放项目根 `AGENTS.md`。
-- 长文档放项目 `docs/`，不要把所有细节塞进入口文件。
-
-## 不应放在全局的内容
-
-- `task.json`、`progress.txt`、`tools/harness/codex-loop.ps1` 的项目 workflow。
-- 某个仓库专属的提交规则、目录结构、接口名称。
-- 某个产品专属业务规则。

package/package-source/docs/codex-harness-engineering/templates/config/global-config.toml

@@ -1,19 +0,0 @@
-model = "gpt-5.4"
-model_reasoning_effort = "medium"
-personality = "pragmatic"
-sandbox_mode = "workspace-write"
-approvals_reviewer = "user"
-
-[approvals]
-approval_policy = "on-request"
-
-[shell_environment_policy]
-inherit = "all"
-ignore_default_excludes = true
-
-[features]
-# 默认启用 hooks 作为 stop-gate 增强层；driver 仍是主链路。
-codex_hooks = true
-
-# 在这里放跨项目稳定设置，不放项目特有 MCP、env 或 trust。
-# 项目特有内容建议放到 `<repo>/.codex/config.toml`。

package/package-source/docs/codex-harness-engineering/templates/config/mcp-config.toml

@@ -1,38 +0,0 @@
-# Codex MCP 配置模板
-# 按需复制到 `.codex/config.toml` 或 `~/.codex/config.toml`。
-
-[mcp_servers.context7]
-command = "npx"
-args = ["-y", "@upstash/context7-mcp"]
-startup_timeout_sec = 20
-tool_timeout_sec = 60
-enabled = true
-required = false
-
-[mcp_servers.openai_docs]
-url = "https://developers.openai.com/mcp"
-startup_timeout_sec = 20
-tool_timeout_sec = 60
-enabled = true
-required = false
-
-[mcp_servers.anysearch]
-# 匿名模式可用；需要更高额度时设置 ANYSEARCH_API_KEY 并启用 bearer_token_env_var。
-url = "https://api.anysearch.com/mcp"
-# bearer_token_env_var = "ANYSEARCH_API_KEY"
-startup_timeout_sec = 20
-tool_timeout_sec = 60
-enabled = true
-required = false
-
-[mcp_servers.chrome_devtools]
-url = "http://localhost:3000/mcp"
-enabled_tools = ["open", "screenshot"]
-startup_timeout_sec = 20
-tool_timeout_sec = 45
-enabled = false
-
-[mcp_servers.figma]
-url = "https://mcp.figma.com/mcp"
-bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
-enabled = false

package/package-source/docs/codex-harness-engineering/templates/config/rules/agents.md

@@ -1,115 +0,0 @@
----
-trigger: always_on
----
-
-# 通用 Agent 编排规则
-
-## 作用范围
-
-本文件定义跨项目可复用的 agent 角色、阶段映射和派发规则。这里的 `agent` 是职责角色，不一定要求每个角色都有独立进程；主控可以通过以下三种方式执行角色：
-
-- 通过 `.codex/agents/*.toml` 调起只读辅助子代理或 scoped writer 子代理。
-- 复用现有 skill，例如 `prd-writer`、`architect`、`frontend-design`、`api-design`、`tdd-guide`、`code-reviewer`。
-- 在当前主控会话中按该角色的规则完成窄范围分析，但主控会话只做分析和路由，不直接写仓库文件。
-
-如果某个阶段没有项目专属 agent，按本文的“阶段到默认 Agent 映射”选择默认角色。
-
-## 角色清单
-
-| Agent Role | 主要职责 | 推荐技能 / Prompt | 何时使用 |
-| --- | --- | --- | --- |
-| `controller` | 主控、阶段推进、任务排序、合并决策 | `controller-loop.md` | 全流程常驻，不直接写仓库文件 |
-| `bootstrap-operator` | 新项目接入、模板复制、smoke、环境检查 | `project-setup`, `tools/install/bootstrap-codex-harness.ps1` | Stage 01 初始化 |
-| `product-analyst` | 需求分析、PRD、用户角色、业务规则、验收标准和可执行验收示例 | `prd-writer`, `business-rule-spec`, `requirements-design-template` | Stage 02 需求收敛 |
-| `requirements-trace-analyst` | 需求到页面、状态、字段、接口、测试的追溯 | `consistency-checklist`, `spec-review` | Stage 03 追溯矩阵和缺口分析 |
-| `architect` | 架构边界、数据流、模块拆分、技术风险 | `architect`, `api-design`, `data-flow-spec` | 架构、契约、跨模块影响和高风险决策 |
-| `design-lead` | 设计规范、信息架构、组件规则、视觉 token | `frontend-design`, `ui-ux-pro-max`, `brand-design-md` | Stage 04 设计规范和复杂 UI 决策 |
-| `image-prompt-writer` | AI 生图 brief、页面状态、禁止事项、参考图要求 | `ai-ui-prompts` | Stage 05 生图输入 |
-| `ui-image-reviewer` | 设计图是否满足 PRD 和 Design Brief | `frontend-design`, `spec-based-review` | Stage 07 UI Image Review |
-| `frontend-spec-writer` | 把设计图翻译成组件、状态源、状态分支、事件、测试选择器和视觉断言 | `frontend-first-workflow`, `page-spec-template` | Stage 08 Image To Frontend Spec |
-| `planner` | DEV-PLAN、任务拆分、依赖、验证顺序 | `planner`, `plan` | 实施计划和任务拆解 |
-| `harness-writer` | `AGENTS.md`、任务队列、控制面配置、hook、prompt、harness 文档等编排资产写入 | `harness-writer.md` | 主控遇到非 driver 编排写入时 |
-| `frontend-worker` | 前端页面、组件、样式、stories、前端测试 | `frontend-patterns`, `typescript`, `vue-arco` 或项目栈技能 | 前端实现 |
-| `visual-reviewer` | 浏览器截图和设计图对比、视觉还原报告 | `browser-e2e-testing`, `midscene-fix-review` | Visual Parity |
-| `contract-designer` | OpenAPI、mock、client 生成、字段和错误码契约 | `api-contract-template`, `api-design` | Contract First |
-| `backend-worker` | API、数据库、权限、异常流、后端测试 | `backend-patterns`, `database`, 项目后端技能 | 后端实现 |
-| `integration-worker` | 前后端联调、mock 切真实服务、主流程 E2E | `api-integration`, `fullstack-workflow` | Integration |
-| `test-planner` | 从需求阶段开始定义可测试需求、验收示例、追溯矩阵、测试数据、分层测试计划和证据路径 | `qa-e2e-planner`, `test-coverage`, `tdd` | 测试设计与测试左移 |
-| `test-runner` | 运行确定性验证、汇总失败、写测试报告 | `e2e-runner`, `qa-e2e-runner`, `verify` | Verify / Regression |
-| `stage1-reviewer` | 产品、设计、计划一致性审查 | `spec-based-review`, `spec-review` | Stage 1 Review |
-| `stage2-reviewer` | 代码质量、测试覆盖、回归风险审查 | `code-reviewer`, `security-reviewer` | Stage 2 Review |
-| `failure-triage` | 失败归因、owner 分类、Repair Queue | `build-error-resolver`, `failure-triage.md` | 测试、构建、视觉或 review 失败后 |
-| `repair-worker` | 按 finding 定点修复并复验 | 原开发 agent + `repair-one-finding.md` | 修复闭环 |
-| `docs-worker` | 文档、索引、使用指南、模板同步 | `doc-updater`, `update-docs` | 文档更新和交付归档 |
-| `security-reviewer` | 权限、认证、支付、密钥、敏感数据和 sandbox 风险 | `security-reviewer`, `security-review` | 高风险功能 |
-| `release-manager` | diff 检查、验证证据、提交、push、最终报告 | `auto-commit`, `git-workflow` | 合并、提交和交付 |
-
-## 阶段到默认 Agent 映射
-
-| 阶段 | 主责 Agent | 协作 Agent | 说明 |
-| --- | --- | --- | --- |
-| 01 初始化 | `bootstrap-operator` | `docs-worker` | 接入模板、检查 Git、跑 smoke |
-| 02 需求收敛 | `product-analyst` | `requirements-trace-analyst`, `test-planner` | 把聊天需求转成 PRD、页面清单、状态矩阵、验收标准和可执行验收示例；所有 P0/P1 需求必须通过需求可测试性检查 |
-| 03 追溯与难点预研 | `requirements-trace-analyst` | `test-planner`, `architect` | 建立需求到 UI/API/数据/状态/测试/证据的追溯矩阵，识别高风险路径和测试数据缺口 |
-| 04 Design Brief | `design-lead` | `product-analyst` | 把主观审美变成可编码设计规则 |
-| 05 AI Image Brief | `image-prompt-writer` | `design-lead` | 生成稳定的 AI 生图输入 |
-| 06 UI 设计图 | `design-lead` | `image-prompt-writer` | 生成或编辑页面多状态参考图 |
-| 07 UI Image Review | `ui-image-reviewer` | `product-analyst`, `design-lead` | 设计图不通过时回到上一步 |
-| 08 Image To Frontend Spec | `frontend-spec-writer` | `frontend-worker`, `test-planner`, `visual-reviewer` | 把图片元素映射到组件、数据、事件、状态源、渲染分支、测试选择器、视觉断言和 E2E 场景 |
-| 09 DEV-PLAN / 任务拆分 | `planner` | `controller`, `architect`, `test-planner` | 生成依赖、owned paths、验证顺序和真实任务；每个任务都要携带测试层级、验证命令和证据路径 |
-| 10 Frontend Build | `frontend-worker` | `test-planner` | 先对照验收示例和前端测试规格实现；每个 UI 状态必须有代码状态源、渲染分支和复验入口，不能用界面说明文案冒充状态实现 |
-| 11 Visual Parity | `visual-reviewer` | `frontend-worker` | 除视觉还原外，还检查状态覆盖和关键交互可用性；失败后由原 frontend worker 修 |
-| 12 Contract First | `contract-designer` | `architect`, `backend-worker`, `frontend-worker`, `test-planner` | 先定义 OpenAPI、错误码、mock 和契约测试，再进入后端实现 |
-| 13 Backend / API | `backend-worker` | `contract-designer`, `test-planner` | 按契约实现 API、数据和权限 |
-| 14 Integration | `integration-worker` | `frontend-worker`, `backend-worker`, `test-runner` | mock 切真实接口，跑主流程 |
-| 15 Stage 1 Review | `stage1-reviewer` | `product-analyst`, `design-lead` | 审实现是否符合产品、设计和计划 |
-| 16 Stage 2 Review | `stage2-reviewer` | `security-reviewer`, `test-planner` | 审代码质量、测试缺口和风险 |
-| 17 Verify / Regression | `test-runner` | `controller`, `test-planner` | 运行 fresh evidence、affected tests、P0 regression 和契约验证；不得在本阶段第一次补齐需求测试范围 |
-| 18 修复闭环 | `failure-triage` | `repair-worker`, 原 reviewer/tester | 归因、派修、复验 |
-| 19 合并 / 提交 / Push | `release-manager` | `controller`, `docs-worker` | 只合并本任务改动，提交前检查 diff 和证据 |
-
-## 路由规则
-
-1. 需求分析阶段默认使用 `product-analyst`，不是 `frontend-worker`、`backend-worker` 或 `test-runner`。
-2. 需求追溯阶段默认使用 `requirements-trace-analyst`，测试映射由 `test-planner` 协作。
-3. 架构、契约、数据流、权限、支付、安全、迁移等高风险问题必须加入 `architect` 或 `security-reviewer`。
-4. UI 相关链路按 `design-lead -> image-prompt-writer -> ui-image-reviewer -> frontend-spec-writer -> frontend-worker -> visual-reviewer` 顺序推进。
-5. 实现失败由原实现 agent 修复；评审或测试失败由提出 finding 的原 reviewer/tester 复验。
-6. 前端状态是行为和数据分支，不是说明文字；任何把 `loading / empty / error / disabled / permission / mobile` 只写成页面文案而没有真实状态源、触发路径和渲染分支的实现，必须路由回 `frontend-worker` 修复。
-
-## 并行规则
-
-- Stage 02-08 以真相源稳定为主，可以并行调研，但不能让多个 agent 同时改同一份 PRD、Design Brief 或视觉规格。
-- 同一时刻不要让多个角色写同一组可写路径。
-- 任何并行结论都必须回到 `task.json`、验证命令和证据路径上，不接收口头“已完成”。
-
-## 子代理前置读取规则
-
-- 任何只读辅助子代理或 writer 子代理在开始判断前，必须先读 `AGENTS.md`、`docs/harness/task-session-strategy.md` 和本文件。
-- 子代理必须再读取该角色对应的 `.agents/skills/*/SKILL.md`（如存在）、项目 truth source 和必要的深文档，再输出结论。
-- 如果当前轮次是被 stop hook / continuation gate 强制继续后的续跑，先重新阅读上面这些文档，再决定是否真的需要子代理。
-- 只读辅助子代理默认只读，不直接写业务代码，不修改 `task.json`、`progress.txt`、`traces/`。
-- writer 子代理只能修改父会话明确分配的路径；主控会话自身不直接写仓库文件。
-- `progress.txt`、`traces/` 和 Git 状态默认仍由 runtime 脚本处理；除这些脚本产物外，仓库写入必须通过匹配的 writer 子代理落盘。
-
-## 模型和思考深度
-
-- `product-analyst`、`requirements-trace-analyst`、`architect`、`design-lead`、`visual-reviewer`、`stage1-reviewer`、`stage2-reviewer` 默认使用更强模型和较高思考深度。
-- `frontend-worker`、`backend-worker`、`integration-worker` 默认使用工作型模型，中高思考深度。
-- `docs-worker`、`test-runner` 可以使用较低成本模型，但失败归因和最终验收不得只靠低强度判断。
-
-## 交接格式
-
-```markdown
-Verdict: PASS | FAIL | BLOCKED
-Role: <agent-role>
-Stage: <stage-id>
-Report: <relative/path/to/report.md>
-Changed paths:
-- <path>
-Verification:
-- <command> -> PASS | FAIL | NOT_RUN
-Open issues:
-- <issue or none>
-Next recommended stage: <stage-id>
-```

package/package-source/docs/codex-harness-engineering/templates/config/rules/coding-style.md

@@ -1,74 +0,0 @@
----
-trigger: always_on
----
-
-# Coding Style
-
-## Immutability (CRITICAL)
-
-ALWAYS create new objects, NEVER mutate:
-
-```javascript
-// WRONG: Mutation
-function updateUser(user, name) {
-  user.name = name  // MUTATION!
-  return user
-}
-
-// CORRECT: Immutability
-function updateUser(user, name) {
-  return {
-    ...user,
-    name
-  }
-}
-```
-
-## File Organization
-
-MANY SMALL FILES > FEW LARGE FILES:
-- High cohesion, low coupling
-- 200-400 lines typical, 800 max
-- Extract utilities from large components
-- Organize by feature/domain, not by type
-
-## Error Handling
-
-ALWAYS handle errors comprehensively:
-
-```typescript
-try {
-  const result = await riskyOperation()
-  return result
-} catch (error) {
-  console.error('Operation failed:', error)
-  throw new Error('Detailed user-friendly message')
-}
-```
-
-## Input Validation
-
-ALWAYS validate user input:
-
-```typescript
-import { z } from 'zod'
-
-const schema = z.object({
-  email: z.string().email(),
-  age: z.number().int().min(0).max(150)
-})
-
-const validated = schema.parse(input)
-```
-
-## Code Quality Checklist
-
-Before marking work complete:
-- [ ] Code is readable and well-named
-- [ ] Functions are small (<50 lines)
-- [ ] Files are focused (<800 lines)
-- [ ] No deep nesting (>4 levels)
-- [ ] Proper error handling
-- [ ] No console.log statements
-- [ ] No hardcoded values
-- [ ] No mutation (immutable patterns used)

package/package-source/docs/codex-harness-engineering/templates/config/rules/constitution.md

@@ -1,290 +0,0 @@
----
-trigger: always_on
----
-
-<!--
-Sync Impact Report:
-Version change: 1.2.0 -> 2.0.0
-Scope change: domain-specific constitution -> generic agent engineering constitution
-Modified principles:
-  - Replaced domain-specific technology mandates with generic project-first engineering rules
-  - Added multi-agent orchestration, workspace isolation, visual verification, repair loop, and model assignment rules
-Removed sections:
-  - Mahjong/OCR/RL/Android automation specific technology constraints
-Templates requiring updates:
-  - None for this document-only change
-Follow-up TODOs:
-  - If new projects should load this automatically, reference it from AGENTS.md, bootstrap output, or task-run profiles
-Rationale for version bump (MAJOR):
-  - Governance scope changed from one project domain to reusable cross-project agent workflow
--->
-
-# 通用智能体工程宪章
-
-## 定位
-
-本宪章用于多智能体工程流程、Codex Harness、项目导入包和长期稳定规则。它不绑定具体业务域、技术栈或产品形态。
-
-具体项目的业务规则、目录结构、提交规范、性能指标和部署细节应写入项目根 `AGENTS.md`、`docs/`、`specs/` 或 `.specify/memory/constitution.md`。本宪章只保留跨项目长期成立的工程约束。
-
----
-
-## 核心原则
-
-### I. 需求先行与可验收目标
-
-**原则声明**:
-
-- 开始实现前必须明确用户目标、输入、输出、约束、非目标和验收标准。
-- 对会影响架构、安全、数据、成本或交付结果的问题，必须先澄清或显式记录假设。
-- 需求评审完成后，应能让下一个 agent 不依赖隐含上下文即可继续执行。
-- 任何阶段发现需求和实现不一致，必须回到需求或设计文档补齐，再继续编码。
-
-**理由**:
-多智能体并行时，模糊需求会被快速放大。先定义可验收目标，可以减少返工并让自动化修复有明确终点。
-
----
-
-### II. 项目优先的胶水编程
-
-**原则声明**:
-
-- 新增功能必须优先复用当前项目已有模式，其次复用成熟库或参考完整开源项目，最后才做最小自定义实现。
-- 引入第三方项目、模板或库时，必须记录来源、许可证、版本或 commit、边界和替换策略。
-- 项目代码应以薄封装和轻组合为主，将外部能力隔离在 Adapter、Connector、Service 或 Integration 层。
-- 不允许业务代码散落直接调用复杂第三方 API；必须通过项目内稳定接口收敛。
-
-**理由**:
-工程价值通常来自正确组合现有能力，而不是重复实现基础设施。项目优先可以保持风格一致，降低维护成本。
-
----
-
-### III. 最小自定义实现
-
-**原则声明**:
-
-- 禁止在已有成熟方案可用时自行实现框架、协议解析器、测试基础设施、认证流程、队列系统、状态管理内核或复杂算法。
-- 只有在现有方案不满足需求、许可证不可接受、性能或部署约束不匹配时，才允许自定义实现。
-- 自定义实现必须附带调研结论、取舍说明、测试覆盖和后续替换边界。
-- 复杂逻辑必须集中在少量清晰模块中，避免跨文件隐式耦合。
-
-**理由**:
-最小实现降低长期维护风险，让 agent 把精力放在业务差异和集成正确性上。
-
----
-
-### IV. 多智能体编排与工作区隔离
-
-**原则声明**:
-
-- 主控 agent 负责任务拆解、上下文分发、路径所有权、闸门判断、结果合并和最终交付。
-- Worker agent 必须拥有清晰的职责边界，例如前端、后端、测试、文档、评审、修复或发布。
-- 并发执行时，不同 agent 应使用独立目录或明确互斥的写入路径。
-- Worker 结束时必须报告变更文件、验证命令、证据路径、未解决问题和需要主控合并的事项。
-- 主控不得盲目合并并行结果；必须检查冲突、重复实现、接口不一致和测试缺口。
-
-**理由**:
-多 agent 的核心风险不是并发本身，而是写入边界不清。路径所有权和主控合并可以避免脏文件、覆盖和上下文漂移。
-
----
-
-### V. 测试驱动与持续验证
-
-**原则声明**:
-
-- 对边界清晰的功能，优先采用 TDD: 先写失败测试，再实现，再重构。
-- 对既有系统修改，至少在改动前确认可运行的基线验证命令。
-- 每次声称完成前必须有 fresh verification evidence，不能只依赖推测。
-- 验证范围应匹配风险: 文档改动跑文档检查，纯 UI 改动跑截图和交互检查，后端合同改动跑单元、集成和契约测试。
-- 验证失败必须进入修复队列，直到通过、降级说明被接受，或形成明确阻塞。
-
-**理由**:
-自动化流程只有在可验证时才可靠。没有证据的完成声明无法支撑持续并行开发。
-
----
-
-### VI. 模块化、契约和可替换性
-
-**原则声明**:
-
-- 系统应按职责划分模块，例如 UI、API、Domain、Data、Worker、Integration、Test Harness。
-- 跨模块通信必须通过稳定契约: 类型、接口、schema、事件、API 文档或测试夹具。
-- Adapter 负责封装外部系统，Connector 负责组合多个能力，业务层不得直接依赖外部系统细节。
-- 数据流、错误流和状态流必须能被追踪，不能依赖隐式全局状态。
-- 公共模块变更必须评估影响面并补充回归测试。
-
-**理由**:
-清晰契约可以让多个 agent 并行实现不同层，并在集成阶段快速定位不一致。
-
----
-
-### VII. 可观测性与调试性
-
-**原则声明**:
-
-- 关键流程必须记录结构化日志、命令输出摘要、输入输出位置和失败原因。
-- 日志不得包含 token、cookie、私钥、密码、个人敏感信息或生产数据样本。
-- 自动化运行应保存 trace，包括任务、agent、目录、命令、退出码、截图、报告和修复记录。
-- 错误处理必须包含可恢复策略或清晰失败信息，不能静默吞错。
-
-**理由**:
-长时间自动运行必然会遇到网络、环境和依赖波动。可观测性是持续修复和断点恢复的基础。
-
----
-
-### VIII. UI 设计还原与视觉验证
-
-**原则声明**:
-
-- UI 实现前应有明确设计来源: 设计图、AI 生成图、页面规格、组件规范或参考截图。
-- 前端完成后必须通过浏览器截图保存实际界面证据，截图应放入项目约定的 artifacts 或 evidence 目录。
-- Review 时必须对比设计图和实际截图，记录布局、颜色、字体、间距、状态、响应式和交互差异。
-- 视觉差异必须进入修复队列；如果无法一比一还原，必须说明原因和接受标准。
-- UI 不能只通过代码审查完成，必须至少验证关键页面在目标视口下真实渲染。
-
-**理由**:
-前端质量最终体现在真实界面。截图对比让 agent 能把设计意图转化为可验证证据。
-
----
-
-### IX. 自动修复闭环
-
-**原则声明**:
-
-- 每个失败项必须转成结构化 Repair Queue，包含严重级别、复现步骤、期望结果、实际结果、负责人和验证命令。
-- 自动修复应按阻塞级别排序: 构建失败、测试失败、关键功能失败、视觉偏差、文档缺口。
-- 修复后必须重新运行与失败项直接对应的验证命令。
-- 当连续修复无法推进时，agent 必须输出阻塞原因、已尝试方案、当前证据和建议的人工决策点。
-
-**理由**:
-全自动实现不是无限循环，而是有证据、有优先级、有退出条件的持续修复。
-
----
-
-### X. 安全、隐私和依赖治理
-
-**原则声明**:
-
-- 禁止把 token、cookie、私钥、密码、账号凭据写入仓库、日志、trace、截图或文档。
-- 环境变量必须通过 `.env.example`、配置模板或密钥管理说明表达，不提交真实值。
-- 引入依赖前必须关注许可证、维护状态、版本锁定、供应链风险和替代方案。
-- 涉及认证、支付、权限、数据删除、生产配置的改动必须提高评审和验证等级。
-
-**理由**:
-自动化 agent 会放大一次错误操作的影响。安全边界必须优先于交付速度。
-
----
-
-### XI. 文档与上下文同步
-
-**原则声明**:
-
-- 改变行为、接口、目录、命令、部署、测试或工作流时，必须同步更新相关文档。
-- 文档应说明当前事实、操作命令、验证方式和已知限制，避免只写愿景。
-- 长文档放 `docs/`，项目规则放项目根 `AGENTS.md`，跨项目语义规则放 `.codex/rules/*.md` 或全局规则；`.codex/rules/*.rules` 只放 Codex 命令执行策略。
-- 文档改动至少运行格式或空白检查，例如 `git diff --check`。
-
-**理由**:
-多 agent 依赖文档传递上下文。过期文档会直接导致错误实现和错误验证。
-
----
-
-### XII. Git 与交付治理
-
-**原则声明**:
-
-- Dirty workspace 默认视为风险，必须区分当前任务改动和用户已有改动。
-- 禁止未经确认回滚、覆盖、重置或删除用户改动。
-- 提交前必须查看 diff，并运行与交付声明直接相关的验证。
-- 提交应保持主题清晰，避免把无关文件混入同一提交。
-- 推送前必须确认当前分支、远程状态和本地未提交风险。
-
-**理由**:
-Git 是多 agent 协作的事实边界。清晰提交和保守操作可以保护用户已有工作。
-
----
-
-### XIII. 模型与思考深度匹配
-
-**原则声明**:
-
-- 不同 agent 可以使用不同模型和思考深度，但必须与任务风险匹配。
-- 架构设计、需求评审、复杂修复、安全评审、跨模块集成和最终验收应使用更强模型或更高思考深度。
-- 机械整理、简单文档同步、格式修复、窄范围查询可以使用较低成本模型。
-- 任务配置应记录 agent 角色、模型、思考深度、上下文来源和允许写入路径。
-
-**理由**:
-统一使用最高配置会浪费资源，统一使用最低配置会降低质量。按风险分配模型是可持续自动化的基础。
-
----
-
-## 通用架构约束
-
-每个项目必须明确以下内容，不能依赖 agent 猜测:
-
-- 技术栈和运行时版本
-- 包管理器和安装命令
-- 本地开发、构建、测试、格式化、类型检查命令
-- 环境变量模板和密钥获取方式
-- 目录所有权和多 agent 写入边界
-- artifacts、screenshots、logs、reports、trace 的保存位置
-- API、数据模型、UI 页面和后台任务的契约来源
-- 发布、回滚和故障处理方式
-
----
-
-## 通用工作流
-
-1. **需求接收**: 明确目标、范围、非目标、验收标准和风险。
-2. **上下文收集**: 阅读项目规则、现有代码、文档、测试和历史决策。
-3. **方案设计**: 输出架构、接口、任务拆分、验证计划和路径所有权。
-4. **任务分发**: 主控为每个 agent 分配独立职责、目录和输出格式。
-5. **实现执行**: Worker 在自己的边界内完成实现，不覆盖他人改动。
-6. **阶段验证**: 运行对应测试、构建、截图、契约检查和文档检查。
-7. **自动修复**: 将失败项转为 Repair Queue 并持续修复。
-8. **主控合并**: 检查 diff、冲突、接口一致性、重复实现和证据完整性。
-9. **最终验收**: 对照需求和验收标准确认完成度。
-10. **交付归档**: 记录变更、验证证据、剩余风险和后续建议。
-
----
-
-## 治理
-
-### 宪章地位
-
-本宪章是通用 agent 工程规则。项目专属规则可以补充或收紧本宪章，但不能削弱安全、验证、Git 保护和用户改动保护要求。
-
-发生冲突时按以下顺序处理:
-
-1. 用户当前明确指令
-2. 项目根 `AGENTS.md`
-3. 项目 `docs/`、`specs/`、`.specify/` 中的已批准规则
-4. 本宪章和 `.codex/rules/*.md`
-5. 通用默认实践
-
-### 修订程序
-
-1. 提出修订理由和影响范围。
-2. 更新本文件和分发快照中的对应副本。
-3. 检查是否需要同步 bootstrap、prompt 模板、doctor 检查或项目导入文档。
-4. 运行文档检查。
-5. 按语义化版本递增版本号。
-
-### 版本控制
-
-**Version**: 2.0.0 | **Ratified**: 2026-04-27 | **Last Amended**: 2026-04-27
-
----
-
-## 附录: 通用验收清单
-
-- [ ] 需求、非目标和验收标准已记录。
-- [ ] 现有代码、成熟库或参考项目已优先调研。
-- [ ] 多 agent 写入路径和职责边界已明确。
-- [ ] 核心接口、数据模型和错误处理已定义。
-- [ ] 单元、集成、契约、E2E 或视觉验证已按风险选择。
-- [ ] UI 页面已保存实际浏览器截图，并与设计来源对比。
-- [ ] 失败项已进入 Repair Queue 并重新验证。
-- [ ] 文档、命令和示例与当前实现一致。
-- [ ] 日志、trace 和截图不包含敏感信息。
-- [ ] 提交前已检查 diff，并有 fresh verification evidence。

package/package-source/docs/codex-harness-engineering/templates/config/rules/git.rules

@@ -1,41 +0,0 @@
-prefix_rule(
-    pattern = ["git", "status"],
-    decision = "allow",
-    justification = "Read-only git status is required for harness workspace checks.",
-)
-
-prefix_rule(
-    pattern = ["git", "diff"],
-    decision = "allow",
-    justification = "Read-only diff inspection is required before verification and delivery.",
-)
-
-prefix_rule(
-    pattern = ["git", "log"],
-    decision = "allow",
-    justification = "Read-only commit history inspection is safe for context gathering.",
-)
-
-prefix_rule(
-    pattern = ["git", "show"],
-    decision = "allow",
-    justification = "Read-only object inspection is safe for review and evidence gathering.",
-)
-
-prefix_rule(
-    pattern = ["git", "add"],
-    decision = "prompt",
-    justification = "Staging changes must be scoped to the current harness task.",
-)
-
-prefix_rule(
-    pattern = ["git", "commit"],
-    decision = "prompt",
-    justification = "Commits require fresh verification and ownership checks.",
-)
-
-prefix_rule(
-    pattern = ["git", "push"],
-    decision = "prompt",
-    justification = "Pushing changes affects a remote repository and requires explicit intent.",
-)

package/package-source/docs/codex-harness-engineering/templates/config/rules/harness.rules

@@ -1,29 +0,0 @@
-prefix_rule(
-    pattern = ["powershell", "-NoProfile", "-ExecutionPolicy", "Bypass", "-File", ".\\verify.ps1"],
-    decision = "allow",
-    justification = "verify.ps1 is the project harness verification entrypoint.",
-)
-
-prefix_rule(
-    pattern = ["powershell", "-NoProfile", "-ExecutionPolicy", "Bypass", "-File", ".\\env-check.ps1"],
-    decision = "allow",
-    justification = "env-check.ps1 is a harness environment readiness check.",
-)
-
-prefix_rule(
-    pattern = ["powershell", "-NoProfile", "-ExecutionPolicy", "Bypass", "-File", ".\\codex-loop.ps1"],
-    decision = "prompt",
-    justification = "codex-loop.ps1 may edit files, update task state, write traces, and commit.",
-)
-
-prefix_rule(
-    pattern = ["pwsh", "-NoProfile", "-Command"],
-    decision = "prompt",
-    justification = "Inline PowerShell can hide arbitrary operations; require review unless a narrower rule matches first.",
-)
-
-prefix_rule(
-    pattern = ["powershell", "-NoProfile", "-Command"],
-    decision = "prompt",
-    justification = "Inline PowerShell can hide arbitrary operations; require review unless a narrower rule matches first.",
-)