sql-optimization

写码 agent 的行为纪律——读再写、想再做、最小改动、调试不靠猜、依赖不乱加、持续推进、说明白做了什么。10 条规则 + 4 个常见失败模式 + 9 项 pre-submit 自检。任何 implementer/explorer/verifier 在写或评码前先吃这份。

改动 HTTP/RPC 接口时强制同步更新接口文档——落点见项目 AGENTS.md「目录结构」节，记录路径、方法、入参/出参、错误码、鉴权要求。

给一个服务加一个新 HTTP 端点的标准做法——契约/鉴权/结构化日志/错误形态/特性开关/集成测试/Sentry/AGENTS.md 校验全一条龙。implementer agent 写新端点时必走。

把一个粗粒度的功能想法写成结构化任务 prompt——含目标、上下文、范围、可测验收、约束、特性开关、灰度计划。架构师把任务交给 implementer agent 前用这个,作为新功能路径的第 1 步。

任意功能变更、bug修复、接口改动完成后，生成PR前必须在对应服务的变更记录文件追加条目——keep-a-changelog格式，落点见项目 AGENTS.md「目录结构」节。

给一个新功能加一个完整的特性开关——更新 @app/flags 的 FLAGS 登记表、设保守默认值、配 .env.*.example 灰度规则、文档化 kill switch 操作。每个新功能上线前必走。

主 session 拿到 task-decomposer 的 DAG 后,执行 fan-out → fan-in → 整合回路。使用 Codex 可用的并行子 agent 或多 worktree 调度方式。

审查与编写代码时的性能、韧性与可观测性判断——外部调用必须有超时/重试退避/熔断降级/幂等、接口限流与分页、缓存正确性、并发安全与资源释放、结构化日志与异常埋点。

对一张由 triage 引擎自动建的 Linear/Issue 工单做根因调查——读样本日志、相关代码、最近 PR,产出"3~5 条可执行的下一步"。triage cron 跑完后给每个新工单触发一次。

审查与编写代码时的应用级安全判断——参数化输入、鉴权与授权分离、越权(IDOR)零容忍、密钥不入代码、日志不泄露 PII/凭证、防 SSRF/CSRF/不安全反序列化。

主 session 收到需求后第一件事——判断是否可并行分解。输出 DAG(JSON),节点=子任务,边=强依赖。判定保守:有疑虑就串行。

给一个错误簇按九个维度打 0~1 分,再用权重合成严重度。triage 引擎的核心评分器,被 triage_engine.py 自动调用;也可被 architect 手动调用复核某张工单的分数。