docs: sync genarrative shared skills

.hermes/skills/genarrative-admin-backoffice/SKILL.md

@@ -217,9 +217,10 @@ npm install
 3. `cargo fmt --all` 可能格式化不相关 Rust 文件；提交前用 `git status` 检查并 revert 非本任务文件。
 4. patch 工具对 Rust 单文件 lint 可能用 Rust 2015 edition 误报 `async fn is not permitted in Rust 2015`；以 `cargo test/check` 为准。
 5. `adminRoutes` 新增 route id 后，`AdminShell.routeIcons` 必须同步，否则 TypeScript 会因 `satisfies Record<AdminRouteId, ...>` 报错。
-6. 后台页面中的中文和 JSON 预览要避免整文件重写导致编码问题；修改后运行 `npm run check:encoding`。
-7. 后台数据页移动端要保证表格横向滚动，不要让整页布局撑坏。
-8. 涉及敏感配置、token、密码、连接串时，输出和文档中统一写 `[REDACTED]`。
+- 后台页面中的中文和 JSON 预览要避免整文件重写导致编码问题；修改后运行 `npm run check:encoding`。
+- 后台数据页移动端要保证表格横向滚动，不要让整页布局撑坏。
+- 若用户追问“之前不是说要把 npm run dev 修好吗”这类已承诺的 dev 启动问题，不要只解释；先复现 `npm run dev`，再按启动日志修脚本并验证到服务就绪。WSL/Linux 下 `spacetime start --root-dir=server-rs/.spacetimedb/local` 可能需要把用户级 SpacetimeDB 版本目录同步到项目 root-dir 的 `bin/<version>` 并建立 `bin/current`，详见 `references/dev-rust-stack-startup-2026-05-08.md`。
+- 涉及敏感配置、token、密码、连接串时，输出和文档中统一写 `[REDACTED]`。
 
 ## 参考资料
 
@@ -229,3 +230,4 @@ npm install
 - `references/spacetimedb-http-sql-sats-display.md`：通过 HTTP SQL 读取 private table 时，enum / Option / Timestamp 的 SATS 原始 rows 如何转换为后台列表、详情和 Excel 可读值。
 - `references/daily-login-tracking-trigger-points.md`：排查后台 `daily_login` 埋点为何不是登录接口写入，而是任务中心读取/领奖兜底写入的触发点记录。
 - `references/daily-login-auth-closure.md`：将方案A拆出的每日登录埋点入口接入真实认证成功链路时的推荐接入点、非阻断语义、测试和提交注意事项。
+- `references/dev-rust-stack-startup-2026-05-08.md`：`npm run dev` / `scripts/dev-rust-stack.sh` 在 WSL/Linux 下同步 SpacetimeDB root-dir 安装、避免 `bin/current/spacetimedb-cli` 缺失和冷编译超时的修复记录。

.hermes/skills/genarrative-admin-backoffice/references/admin-tracking-events-export-2026-05-07.md

@@ -23,7 +23,7 @@
 ## 验证命令
 
 ```bash
-cd <repo-root>/.worktrees/hermes-996d586b
+cd <repo-root>
 npm install                         # 若 node_modules 缺失
 npm run admin-web:typecheck
 npm run admin-web:build
@@ -39,7 +39,7 @@ cargo test -p api-server admin_tracking -- --nocapture
 启动命令：
 
 ```bash
-cd <repo-root>/.worktrees/hermes-996d586b
+cd <repo-root>
 npm run api-server
 npm run admin-web:dev -- --host 127.0.0.1
 ```

.hermes/skills/genarrative-admin-backoffice/references/dev-rust-stack-startup-2026-05-08.md

@@ -0,0 +1,34 @@
+# `npm run dev` / `scripts/dev-rust-stack.sh` 启动修复记录
+
+## 症状
+- `npm run dev` 在 WSL/Linux 下直接失败：
+  - `It seems like the spacetime version set as current may not exist`
+  - `exec failed for .../.spacetimedb/local/bin/current/spacetimedb-cli`
+- 失败位置通常在 `sync_local_spacetime_install` 后、等待 SpacetimeDB 就绪阶段。
+
+## 根因
+- `server-rs/.spacetimedb/local` 是空 root-dir 时，`spacetime start` 仍会尝试回调 `bin/current/spacetimedb-cli`。
+- 旧脚本只按 Windows/Git Bash 思路同步 `spacetimedb-cli.exe`，WSL/Linux 下没有把用户级安装同步到项目 root-dir。
+- `api-server` 首次冷编译时，默认 300 秒超时不够，容易在就绪前被回收。
+
+## 修复要点
+1. 同步本机 SpacetimeDB 安装到项目 root-dir
+   - 从 `spacetime --version` 解析真实 CLI 路径。
+   - 将对应版本目录复制到 `server-rs/.spacetimedb/local/bin/`。
+   - 重新建立 `bin/current` 指向版本目录。
+2. 兼容 WSL/Linux 与 Windows
+   - 不再只判断 `OSTYPE=msys*|cygwin*`。
+   - 同时检查 `spacetimedb-cli` 与 `spacetimedb-cli.exe`。
+3. 提高 api-server 就绪等待时间
+   - `API_SERVER_TIMEOUT_SECONDS` 从 300 提升到 600。
+
+## 复现 / 验证
+- 运行 `npm run dev`。
+- 观察日志：
+  - SpacetimeDB 能正常启动到 `Listening on 127.0.0.1:3101`
+  - 模块发布成功
+  - api-server 进入健康检查等待并最终可访问 `/healthz`
+
+## 相关文件
+- `scripts/dev-rust-stack.sh`
+- `server-rs/.spacetimedb/local/`