@geraldmaron/construct 1.0.0 → 1.0.1

package/rules/zh/development-workflow.md

@@ -1,49 +0,0 @@
-<!--
-rules/zh/development-workflow.md — <one-line purpose>
-
-<2–6 line summary.>
--->
-# 开发工作流
-
-> 此文件扩展 [common/git-workflow.md](./git-workflow.md)，包含 git 操作之前的完整功能开发流程。
-
-功能实现工作流描述了开发管道：研究、规划、TDD、代码审查，然后提交到 git。
-
-## 功能实现工作流
-
-0. **研究与重用** _(任何新实现前必需)_
-   - **GitHub 代码搜索优先：** 在编写任何新代码之前，运行 `gh search repos` 和 `gh search code` 查找现有实现、模板和模式。
-   - **库文档其次：** 使用 Context7 或主要供应商文档确认 API 行为、包使用和版本特定细节。
-   - **仅当前两者不足时使用 Exa：** 在 GitHub 搜索和主要文档之后，使用 Exa 进行更广泛的网络研究或发现。
-   - **检查包注册表：** 在编写工具代码之前搜索 npm、PyPI、crates.io 和其他注册表。首选久经考验的库而非手工编写的解决方案。
-   - **搜索可适配的实现：** 寻找解决问题 80%+ 且可以分支、移植或包装的开源项目。
-   - 当满足需求时，优先采用或移植经验证的方法而非从头编写新代码。
-
-1. **先规划**
-   - 使用 **planner** 代理创建实现计划
-   - 编码前生成规划文档：PRD、架构、系统设计、技术文档、任务列表
-   - 识别依赖和风险
-   - 分解为阶段
-
-2. **TDD 方法**
-   - 使用 **tdd-guide** 代理
-   - 先写测试（RED）
-   - 实现以通过测试（GREEN）
-   - 重构（IMPROVE）
-   - 验证 80%+ 覆盖率
-
-3. **代码审查**
-   - 编写代码后立即使用 **code-reviewer** 代理
-   - 解决关键和高优先级问题
-   - 尽可能修复中优先级问题
-
-4. **提交与推送**
-   - 详细的提交消息
-   - 遵循约定式提交格式
-   - 参见 [git-workflow.md](./git-workflow.md) 了解提交消息格式和 PR 流程
-
-5. **审查前检查**
-   - 验证所有自动化检查（CI/CD）已通过
-   - 解决任何合并冲突
-   - 确保分支已与目标分支同步
-   - 仅在这些检查通过后请求审查

package/rules/zh/git-workflow.md

@@ -1,29 +0,0 @@
-<!--
-rules/zh/git-workflow.md — <one-line purpose>
-
-<2–6 line summary.>
--->
-# Git 工作流
-
-## 提交消息格式
-```
-<类型>: <描述>
-
-<可选正文>
-```
-
-类型：feat, fix, refactor, docs, test, chore, perf, ci
-
-注意：通过 ~/.claude/settings.json 全局禁用归属。
-
-## Pull Request 工作流
-
-创建 PR 时：
-1. 分析完整提交历史（不仅是最新提交）
-2. 使用 `git diff [base-branch]...HEAD` 查看所有更改
-3. 起草全面的 PR 摘要
-4. 包含带有 TODO 的测试计划
-5. 如果是新分支，使用 `-u` 标志推送
-
-> 对于 git 操作之前的完整开发流程（规划、TDD、代码审查），
-> 参见 [development-workflow.md](./development-workflow.md)。

package/rules/zh/hooks.md

@@ -1,35 +0,0 @@
-<!--
-rules/zh/hooks.md — <one-line purpose>
-
-<2–6 line summary.>
--->
-# 钩子系统
-
-## 钩子类型
-
-- **PreToolUse**：工具执行前（验证、参数修改）
-- **PostToolUse**：工具执行后（自动格式化、检查）
-- **Stop**：会话结束时（最终验证）
-
-## 自动接受权限
-
-谨慎使用：
-- 为可信、定义明确的计划启用
-- 探索性工作时禁用
-- 永远不要使用 dangerously-skip-permissions 标志
-- 改为在 `~/.claude.json` 中配置 `allowedTools`
-
-## TodoWrite 最佳实践
-
-使用 TodoWrite 工具：
-- 跟踪多步骤任务的进度
-- 验证对指令的理解
-- 启用实时引导
-- 显示细粒度的实现步骤
-
-待办列表揭示：
-- 顺序错误的步骤
-- 缺失的项目
-- 多余的不必要项目
-- 错误的粒度
-- 误解的需求

package/rules/zh/patterns.md

@@ -1,36 +0,0 @@
-<!--
-rules/zh/patterns.md — <one-line purpose>
-
-<2–6 line summary.>
--->
-# 常用模式
-
-## 骨架项目
-
-实现新功能时：
-1. 搜索久经考验的骨架项目
-2. 使用并行代理评估选项：
-   - 安全性评估
-   - 可扩展性分析
-   - 相关性评分
-   - 实现规划
-3. 克隆最佳匹配作为基础
-4. 在经验证的结构内迭代
-
-## 设计模式
-
-### 仓储模式
-
-将数据访问封装在一致的接口后面：
-- 定义标准操作：findAll、findById、create、update、delete
-- 具体实现处理存储细节（数据库、API、文件等）
-- 业务逻辑依赖抽象接口，而非存储机制
-- 便于轻松切换数据源，并简化使用模拟的测试
-
-### API 响应格式
-
-对所有 API 响应使用一致的信封：
-- 包含成功/状态指示器
-- 包含数据负载（错误时可为空）
-- 包含错误消息字段（成功时可为空）
-- 包含分页响应的元数据（total、page、limit）

package/rules/zh/performance.md

@@ -1,60 +0,0 @@
-<!--
-rules/zh/performance.md — <one-line purpose>
-
-<2–6 line summary.>
--->
-# 性能优化
-
-## 模型选择策略
-
-**Haiku 4.5**（Sonnet 90% 的能力，3 倍成本节省）：
-- 频繁调用的轻量级代理
-- 结对编程和代码生成
-- 多代理系统中的工作者代理
-
-**Sonnet 4.6**（最佳编码模型）：
-- 主要开发工作
-- 编排多代理工作流
-- 复杂编码任务
-
-**Opus 4.5**（最深度推理）：
-- 复杂架构决策
-- 最大推理需求
-- 研究和分析任务
-
-## 上下文窗口管理
-
-避免在上下文窗口的最后 20% 进行以下操作：
-- 大规模重构
-- 跨多个文件的功能实现
-- 调试复杂交互
-
-上下文敏感度较低的任务：
-- 单文件编辑
-- 独立工具创建
-- 文档更新
-- 简单 bug 修复
-
-## 扩展思考 + 规划模式
-
-扩展思考默认启用，为内部推理保留最多 31,999 个 token。
-
-通过以下方式控制扩展思考：
-- **切换**：Option+T（macOS）/ Alt+T（Windows/Linux）
-- **配置**：在 `~/.claude/settings.json` 中设置 `alwaysThinkingEnabled`
-- **预算上限**：`export MAX_THINKING_TOKENS=10000`
-- **详细模式**：Ctrl+O 查看思考输出
-
-对于需要深度推理的复杂任务：
-1. 确保扩展思考已启用（默认开启）
-2. 启用**规划模式**进行结构化方法
-3. 使用多轮审查进行彻底分析
-4. 使用分角色子代理获得多样化视角
-
-## 构建排查
-
-如果构建失败：
-1. 使用 **build-error-resolver** 代理
-2. 分析错误消息
-3. 增量修复
-4. 每次修复后验证

package/rules/zh/security.md

@@ -1,34 +0,0 @@
-<!--
-rules/zh/security.md — <one-line purpose>
-
-<2–6 line summary.>
--->
-# 安全指南
-
-## 强制安全检查
-
-在任何提交之前：
-- [ ] 无硬编码密钥（API 密钥、密码、令牌）
-- [ ] 所有用户输入已验证
-- [ ] SQL 注入防护（参数化查询）
-- [ ] XSS 防护（净化 HTML）
-- [ ] CSRF 保护已启用
-- [ ] 认证/授权已验证
-- [ ] 所有端点启用速率限制
-- [ ] 错误消息不泄露敏感数据
-
-## 密钥管理
-
-- 永远不要在源代码中硬编码密钥
-- 始终使用环境变量或密钥管理器
-- 启动时验证所需的密钥是否存在
-- 轮换任何可能已暴露的密钥
-
-## 安全响应协议
-
-如果发现安全问题：
-1. 立即停止
-2. 使用 **security-reviewer** 代理
-3. 在继续之前修复关键问题
-4. 轮换任何已暴露的密钥
-5. 审查整个代码库中的类似问题

package/rules/zh/testing.md

@@ -1,34 +0,0 @@
-<!--
-rules/zh/testing.md — <one-line purpose>
-
-<2–6 line summary.>
--->
-# 测试要求
-
-## 最低测试覆盖率：80%
-
-测试类型（全部必需）：
-1. **单元测试** - 单个函数、工具、组件
-2. **集成测试** - API 端点、数据库操作
-3. **E2E 测试** - 关键用户流程（框架根据语言选择）
-
-## 测试驱动开发
-
-强制工作流：
-1. 先写测试（RED）
-2. 运行测试 - 应该失败
-3. 编写最小实现（GREEN）
-4. 运行测试 - 应该通过
-5. 重构（IMPROVE）
-6. 验证覆盖率（80%+）
-
-## 测试失败排查
-
-1. 使用 **tdd-guide** 代理
-2. 检查测试隔离
-3. 验证模拟是否正确
-4. 修复实现，而非测试（除非测试有误）
-
-## 代理支持
-
-- **tdd-guide** - 主动用于新功能，强制先写测试