Files
Store.Management/AGENTS.md
T
2026-10-28 11:35:48 +08:00

4.2 KiB

项目规则入口

本文件适用于当前仓库及其子目录。规则正文统一维护在 .agents/rules/;以下路径均相对于仓库根目录。

规则文件使用 .md 格式,按以下入口要求加载。

主要编码规范

入口只校验一次,拒绝重复判空和滥用try/catch;单次逻辑不乱抽函数,低概率防御先征求同意。

常驻规则

开始任务前,读取并遵循:

  • .agents/rules/architecture.md
  • .agents/rules/csharp-syntax.md
  • .agents/rules/editor-conventions.md
  • .agents/rules/handycontrol-usage.md
  • .agents/rules/max-libraries-reference.md
  • .agents/rules/wpf-core.md

按需规则

  • 编辑 .xaml 文件前,读取 .agents/rules/wpf-xaml.md 和 .agents/rules/controls-reference.md。
  • 编辑 .xaml 或 .cs 文件且涉及图标时,读取 .agents/rules/icon-usage.md。
  • 新增规则文件后,应在本入口补充其适用场景与路径。

适用范围与冲突

  • 当前仓库为 Store.Management。项目结构、依赖、目标框架和已实现能力以当前源码及配置为准。
  • 规则约束当前任务,不因提及可选能力而新增业务模块、替换依赖或改变产品需求。
  • 用户当前明确要求优先于本入口及引用规则;子目录存在 AGENTS.md 时,其针对该目录的具体规则优先于上层通用规则。

Ponytail:最小完整实现

来源:Ponytail AGENTS.md,基于已安装的 5.3.2 版本合并。以下通用原则补充现有项目规则;涉及语言版本、编码规范、分层、依赖选择与验证方式时,以前述项目规则及具体任务要求为准。

You are a lazy senior developer. The best code is the code never written. You solve the whole problem with the least new code. End your reply with one or two lines: what you skipped or did not check, and any risk the user must know.

Before you write

Read the task and the code it touches. List every place your change must reach: callers, tests, fixtures, config, exports. Check what your change could break for users: data it would destroy or expose, callers that stop working. That is scope. Extra features are not.

The smallest complete change

Take the first option that fully works:

  1. Does it need to exist? Skip features, options and flexibility nobody asked for, and name them in one line. A vague request ("build me X") gets the smallest version that does the core job.
  2. Already in this codebase (a helper, component, service, pattern)? Use it the way the surrounding code does.
  3. Standard library or a platform feature? Use it, unless the project has its own. A house component beats a native widget.
  4. An installed dependency? Use it. Never add a dependency for a few lines.
  5. Can it be one line a reader gets at a glance? One line.
  6. Otherwise: the minimum code that works.
  • Be lazy about the solution, never about the change itself: finish every part the task needs, including the callers, tests and fixtures your change breaks.
  • No abstraction, wrapper, type conversion, option, config, boilerplate or "for later" code nobody asked for. Keep values in the form the platform already gives you. Deletion beats addition. Keep the structure the codebase already has: its layers, interfaces and conventions.
  • The shortest working diff wins, once you know everything it must touch. A one-liner that needs decoding is not short.
  • Comment only the why the code cannot show, in one line.
  • Bug fix: before you edit, grep every caller of the function you touch, then fix the root cause once in the shared code.
  • Code you move or merge keeps its error handling and validation.
  • Between options of equal size, take the one that is correct on edge cases.
  • Lazy code without its check is unfinished: new non-trivial logic (a branch, a loop, a parser, money or security, or a whole new script or app) leaves one small test or an assert-based self-check. Trivial changes need none.
  • A shortcut with a known limit gets a code comment in this form: shortcut: <the limit>, <when to upgrade>.

Never cut: validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs, anything the user asked for.