feat: add domain core and verification harness

docs/quality-gates.md

@@ -1,6 +1,6 @@
 # 质量门禁与验证策略
 
-> 状态：测试策略已定义；命令在 Android 骨架初始化后启用
+> 状态：JVM/harness 门禁已启用；Android lint、构建、UI 与设备门禁等待 Android application 壳
 > 原则：完成必须有可重复证据，不能以“代码看起来正确”代替验证
 
 ## 1. 反馈循环
@@ -17,7 +17,18 @@
 
 ## 2. 预期本地命令
 
-工程创建后，Windows 环境至少提供以下稳定入口：
+当前可重复的 Windows 快速门禁：
+
+```powershell
+.\gradlew.bat spotlessCheck --offline
+.\gradlew.bat :app:test --offline
+.\gradlew.bat verifyContentContract --offline
+.\gradlew.bat verifyLocal --offline
+```
+
+`verifyLocal` 当前聚合无依赖格式检查、10 个领域测试、3 个内容 repository 测试、domain 依赖边界、内容契约与负向夹具、文档链接、高置信 secret scan 和原型 JavaScript 语法检查。CI 执行同一个聚合任务。
+
+Android application 插件配置后，Windows 环境还必须提供：
 
 ```powershell
 .\gradlew.bat spotlessCheck
@@ -29,15 +40,7 @@
 
 若采用不同格式化插件，命令可以调整，但必须在本文件和 CI 同步更新。`connectedDebugAndroidTest` 需要模拟器或设备，应与纯 JVM 快速门禁分开。
 
-建议再提供聚合任务：
-
-```powershell
-.\gradlew.bat verifyLocal
-```
-
-它至少依赖格式、lint、JVM 单元测试和 debug 构建，使代理不必猜测正确验证组合。
-
-当前仓库没有 Gradle Wrapper，所以上述命令尚未运行，也不能报告为通过。
+到那时必须把 Android lint 和 debug build 加入现有 `verifyLocal`，使代理仍不必猜测验证组合。在完成这一步之前，`verifyLocal` 通过只证明 JVM 与仓库门禁，不代表 APK 已构建或真机测试已通过。
 
 ## 3. 测试层次
 
@@ -148,6 +151,8 @@
 
 可以使用现有静态工具、架构测试库或小型自定义 Gradle 任务；具体选型写入[决策记录](decisions.md)。规则的错误消息应告诉代理如何修复，而不只报告失败。
 
+当前由无外部依赖的 Node 脚本与 Gradle 任务执行上述已落地规则，见 ADR-013。引入 Android 源码后应扩展同一入口，不应建立一套互不相干的新命令。
+
 ## 6. 发布门禁
 
 发布候选必须满足：