# AI 编码入口 适用 Core `3.0.0-SNAPSHOT`。先识别任务，再按[任务路由](task-routing.md)读取规范和示例。当前任务明确约束优先；对于未说明的框架行为，以真实 API、现行规范和验证结果为依据，不猜测接口。 ## 最短执行路径 1. 确认需求、SQL、目标仓库/模块、Core 版本与技术栈一致。 2. 阅读本页及[规则索引](../standards/README.md)，加载任务相关专题。 3. 打开一个匹配技术栈的实际实现和测试，核对接口签名与依赖。 4. 实现最小完整业务行为，并保持约定的同步/响应式与数据栈范围。 5. 按[交付清单](delivery-checklist.md)运行验证，报告实际结果和限制。 ## 编码前必须掌握的约束 - `CORE-LAYOUT-001`：业务模块使用既有 Maven 分层；聚合/BOM 不生成业务源码；contract 共用，不另建 reactive-core。 - `CORE-LAYER-001`：Controller 调用 Service；Service 是用例与事务边界；多实体组合 Manager；仓储承担持久化。Service 不横向互调，不发明平行编排层。 - `CORE-CONTRACT-001`：新代码使用 `contract/*`、`converter/*`；复用已有能力接口、异常和返回体，不复制默认实现。 - `CORE-TENANT-001`：每个实体明确租户模式；读权限不能代替写校验；自定义查询、关系操作和缓存同样遵守隔离。 - `CORE-AUTH-001`：复用安全模块的身份、权限与数据范围，不因接口带有资源名就假定已完成授权。 - `CORE-TX-001`：写动作核对事务代理、事务管理器和回滚；响应式工作在订阅期发生，不在业务链中 `block/subscribe`。 - `CORE-STATE-001`：只开启需求声明的数据状态能力；通用状态位不替代业务状态机。 - `CORE-DELETE-001`：区分逻辑删除、物理删除、恢复与引用保护；钩子结束不等于事务提交。 - `CORE-CACHE-001`、`CORE-EVENT-001`：使用匹配运行时，核对租户键、失效/提交时序和事件投递边界。 - `CORE-STACK-001`：按任务确定的四栈/双 Web 范围对齐；多个运行时分别装配，不混装同包同名类型。 - `CORE-STYLE-001`：按源码风格写 Javadoc、字段、日志和局部格式保护，具体规则不在此复制。 - `CORE-TEST-001`：按行为和影响范围验证；区分内存契约测试、真实数据库、应用 HTTP 与前端端到端证据。 这些是导航摘要。完整约束、反例和验证方式以[规则索引](../standards/README.md)所指正文为准。 ## 避免凭历史样板推导规则 应用错误码必须查[全局登记](../../../../design/standards/error-code-registry.md)，不能沿用旧 Core 号段。类名、泛型、配置项和 URL 先定位源码。模板中的占位名称不是已存在的 API。 发现冲突先记录具体文件和行为；不能通过新增另一层包装绕过缺失依赖或把未验证实现描述成稳定能力。 ## 多仓库工作 本仓 `AGENTS.md` 不会自动成为并列业务仓库的规则。开始业务任务时显式提供本入口与目标仓库入口；独立获取源码时使用匹配版本的文档，不复制会长期漂移的规则正文。 工具输入见[任务模板](task-input-template.md)。只改文档时使用[维护规则](../maintenance/documentation-policy.md)，无需加载无关 ORM 细节。