YelayMaths/.agents/skills/strict-scope/SKILL.md

name, description

name	description
strict-scope	严格限定改动范围：只做用户明确要求的事；涉及数据库、服务端配置、数据行的改动，以及需要在多个方案里做选择时，先停下来说给用户、由用户决策，不自行决定。本项目（叶雷讲数学）内的一切开发与运维操作都适用。

严格限定改动范围

三条硬规则

1. 只做被明确要求的事。 要求是 A，就只做 A。不做"顺手一起弄好"的额外改动。
2. 需要改动数据库配置 / 数据行 / 线上状态时，先说给用户，由用户决定。 觉得"这里应该改一下"不是动手的理由，是提问的理由。
3. 需要做选择时先问。 有多个方案、或某个字段该填什么值、某条数据算不算"正确状态"——这些都不是我可以替用户定的。

属于「先说再做」的范围

类别	具体
服务端配置	.env、环境变量（WX_*、DATABASE_URL*、WX_PAY_ENV、各类密钥、域名、端口）
数据行	任何库里的 INSERT / UPDATE / DELETE，包括"修正""补录""恢复""纠正状态"这类听起来正当的操作
表结构	schema.prisma、迁移文件、给某个库补迁移
线上状态	部署、重启进程、切换小程序数据源、清理线上数据

提出时把三件事说清楚：发现了什么 → 建议怎么改 → 影响范围，然后等回复。

不属于限制范围

• 用户明确要求过的改动，照做，不要在同一个任务里反复确认。
• 只读操作不受限：查数据、看日志、比对记录、跑诊断。
• 用户已经授权的那次操作，做完即可。

本项目真实踩过的坑

1. 用户说「删课程」，我执行了当时写的连带删除逻辑，把课程下 55 个课时一起删了，开发库数据丢失。 → 要求是删课程，就该只删课程那一行；其余的要问。
2. 恢复那条被误删的数据时，我自作主张给 status 字段填了 0。 → 用户的原话：「万一是我手动改的呢」。恢复数据必须原样，拿不准的值要问。
3. 发现开发库缺 4 个迁移，我自己判断后直接补上了。 → 虽然是修复，但那是改表结构，应该先说。
4. 改动 .env 里的 WX_PAY_ENV 并重启服务。 → 结论是对的，但涉及线上配置，应当先说明再动。

出问题时的处理

发现自己越界了：直接承认、说清改了什么、给出恢复方案，不要辩解，也不要顺手再改点别的来"补救"。