feat: release Dever 0.1.4 with enforceable project guidance

examples/README.md

@@ -1,6 +1,6 @@
 # Dever 示例
 
-`examples/` 只保留两个入口：`cms/` 是当前维护的应用示例，`old/` 是旧语言合同和回归材料的归档。旧目录不符合当前 component/domain/role 应用布局，不应直接执行 `dever check/run/build`。
+看当前用法请用 `cms/`；`old/` 只保存历史回归材料，不是新项目模板，也不能直接按当前应用运行。
 
 CMS 同时维护 [Dever 源码](cms/dever/module/news/article/api/admin/manage.dever)和 [Markdown 源码](cms/md/module/news/article/api/admin/manage.dever.md)。两套实现使用同一目录与业务合同：
 
@@ -35,29 +35,55 @@ test/
 
 Markdown 项目使用相同的目录和 API/CMD 声明，仅把源码扩展名换成 `.dever.md` 并补齐文档合同。
 
-编译器从 API/CMD/Job 声明生成入口。平台租户、账号、成员与会话是 `global type`，保存在共享平台库；文章、分类、修订、媒体、排期和审计属于当前租户物理库。认证 verify 只读取 global Model 并建立只读用户与租户身份；接口权限由核心根据当前站点和角色自动校验，后续 API 才进入可信 tenant scope。一个职责文件可包含一组内聚方法，没有按函数拆文件。
+## 数据和权限
 
-文章通过 `/news/article/admin/manage/create` 创建，`list/detail` 查询，`remove` 删除草稿，`publish` 发布。编辑调用 `/content/revision/admin/manage/create`，传入 `selected_article_id`、`expected_version`、标题正文和可空分类/媒体 ID；版本冲突返回 409，文章更新和修订快照在同一事务内完成。文章不声明绕过这些规则的自动 REST 写接口。列表 SQL 直接返回同领域 `app.ArticleView`，不暴露私有 Model。
+平台租户、账号、成员和会话使用 `global type`，保存在平台库。文章、分类、修订、媒体、排期和审计放在各租户自己的数据库。
 
-`/publishing/schedule/admin/manage/schedule` 接收文章 ID 和 `publish_at`；创建时验证作者与草稿状态，按真实到期时间入队。每个排期有独立任务键，同刻文章不会合并。任务执行仍由核心复验身份和权限；发布、审计和排期状态一并提交或回滚，完成任务重放不会重复写入。手动重复发布返回 409。
+verify 先核实 global 身份数据。核心按站点和角色检查接口权限，成功后才访问租户数据。入口由 API、CMD、Job 声明生成，无需 main。相关方法放在同一业务主题文件里，不按函数逐个拆文件。
+
+文章接口位于 `/news/article/admin/manage/`：create 创建，list/detail 查询，remove 删除草稿，publish 发布。
+
+编辑使用 `/content/revision/admin/manage/create`，传入文章 ID、expected_version、标题正文和可空分类/媒体 ID。版本冲突返回 409，文章更新与修订快照一起提交。文章不用自动 REST 写接口，以免跳过这些规则；列表返回 `app.ArticleView`，不泄漏私有 Model。
+
+定时发布使用 `/publishing/schedule/admin/manage/schedule`，传入文章 ID 和 publish_at。创建时检查作者和草稿状态；每个排期有独立任务，不会合并同时发布的文章。
+
+执行任务前，核心再次核验身份和权限。发布、审计和排期状态一起提交或回滚，完成任务重复执行不重复写入。手动重复发布返回 409。
+
+## 先检查，再运行
 
 在仓库根目录执行：
 
 ```bash
 dever check examples/cms/dever
 dever check examples/cms/md
-dever test examples/cms/dever
-dever test examples/cms/md
+dever test examples/cms/dever --filter news.article.publish
+dever test examples/cms/md --filter news.article.publish
 dever fmt examples/cms/dever --check
 dever fmt examples/cms/md --check
-dever run examples/cms/dever -- user.account.bootstrap '{"tenant_key":"tenant-one","tenant_name":"Tenant One","email":"owner@example.com","display_name":"Owner","password":"change-me-now"}'
-dever tenant migrate examples/cms/dever 1
-dever tenant owner examples/cms/dever 1 admin 1
-dever tenant owner examples/cms/dever 1 front 1
 ```
 
-`run/build` 只读取各项目的 `config/setting.json`，运行数据写入各自 `data/`。先用 bootstrap CMD 建立平台租户、业务 Owner membership 与 Argon2 密码，再用返回的真实 `tenant_id` 执行 `tenant migrate`，并用返回的 `tenant_id/user_id` 分别 provision admin/front 核心 RBAC Owner；示例中的 `1` 只是首次空库的常见结果，不能在生产脚本里硬编码。两个站点各自通过同站点的 `user/authorization/<site>/manage` 接口管理普通角色。不带 CMD 参数时启动 admin/front HTTP API。`test` 不读取部署配置；每个涉及 Model 的测试使用独立临时 SQLite，并在结束后清理。
+这些测试使用独立临时 SQLite，不连接部署数据库，结束后清理。命令仍会读取配置与锁中的依赖信息。检查全部应用测试时再去掉 `--filter`。
 
-CMS 的五个应用测试验证分类、发布规则、账号引导/规范化和会话生命周期的正常业务输出，位于各项目根 `test/`；拒绝、过期等负向行为，以及带真实登录的 HTTP、并发编辑、上传、Job 重试/回滚验收见 [业务验收说明](../test/cms/README.md)。普通测试不伪造认证上下文。编译器和 CLI 的 Rust 回归测试仍统一位于仓库根 `test/`，两者都不混入业务 `module/`。部署前必须替换示例 JWT secret，并把两个站点的 `origin` 和 Host 改成真实 HTTPS 入口；`origin` 描述反向代理外部地址，不是 Dever 内部监听地址。
+实际部署前先替换 JWT secret，并把两个站点的 origin 和 Host 改成真实 HTTPS 入口；origin 是用户访问的外部地址，不是内部监听地址。
+
+用 bootstrap CMD 建立平台租户、Owner 成员和密码：
+
+```sh
+dever run examples/cms/dever -- user.account.bootstrap '{"tenant_key":"tenant-one","tenant_name":"Tenant One","email":"owner@example.com","display_name":"Owner","password":"change-me-now"}'
+```
+
+替换示例账号与密码，再用返回的真实 tenant_id 和 user_id 执行以下命令，不要猜测 ID 是 1：
+
+```text
+dever tenant migrate examples/cms/dever <tenant_id>
+dever tenant owner examples/cms/dever <tenant_id> admin <user_id>
+dever tenant owner examples/cms/dever <tenant_id> front <user_id>
+```
+
+这会迁移租户数据库，并建立后台、前台的核心 Owner。之后各站点通过 `user/authorization/<site>/manage` 管理普通角色。运行配置在项目的 `config/setting.json`，数据在 `data/`；`dever run examples/cms/dever` 不带 CMD 参数时启动 HTTP 服务。
+
+CMS 的五个应用测试覆盖分类、发布规则、账号引导/规范化和会话正常流程，放在各项目的 `test/`，不伪造认证上下文。
+
+拒绝、过期、真实登录、HTTP、并发编辑、上传和 Job 重试/回滚见 [业务验收说明](../test/cms/README.md)。编译器与 CLI 的 Rust 回归测试在仓库根 `test/`，都不放进业务 module。
 
 旧示例仍可供编译器维护者查阅历史语义，但不能作为新 Dever 应用的目录、可见性或调用方式范本。