@arcships/morula-runtime 0.1.0-alpha.14 → 0.1.0-alpha.16

package/dist/morula.js

@@ -704,8 +704,8 @@ function page(ok, message) {
 }
 
 // ../morula-cli-core/dist/build-env.js
-var BUILD_VERSION = "0.1.0-alpha.14";
-var BUILD_ID = "20260923140226.31d77ab2";
+var BUILD_VERSION = "0.1.0-alpha.16";
+var BUILD_ID = "20260929103157.019b0b1c";
 var BUILD_CONTEXTS = {
   "local": "http://localhost:8080/api",
   "test": "https://morula.basecastle.com/api",

package/dist/plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morula-cli",
-  "version": "0.1.0-alpha.14",
+  "version": "0.1.0-alpha.16",
   "description": "Use Morula CLI task management from DimCode.",
   "interface": {
     "displayName": "Morula CLI",

package/dist/plugin/skills/morula-working-on-issues/SKILL.md

@@ -60,15 +60,20 @@ allowed-tools: Bash(morula *), Bash(git *), Bash(gh *)
 > 纯问答、调研、分析、本地起服务类任务：**不建分支、不提 PR、最终评论不出现 PR 章节**，直接回答用户问题。
 
 - 本任务的对外编号（在任务看板 URL / 列表可见）可能形如 `STR-101` 或 `AGENT-463963`。
-- **PR 关联**：PR 的 title / branch / body 中出现任务编号 → 服务端自动把 PR 关联到任务。
-- **关单**：只有 `Closes` / `Fixes` / `Resolves` 后**紧邻**任务编号（如 `Closes STR-101`）→ 该 PR merge 时服务端自动把任务流转到完成状态。
-- **编号用对外编号（code，如 AGENT-463963 / STR-101），不要用 UUID**：MR/分支里的任务编号必须用对外编号——服务端的关单/关联扫描（`Closes` 通道）只识别对外编号，UUID 只用于业务对象（Object），agent 任务（AgentTask）不会被 UUID 关单识别（那会把 MR 关联失败）。
-- 若任务详情只有 UUID 没有对外编号，把任务编号写进 PR 描述前先确认是否存在对外编号；确无再用 UUID 作为兜底。
+- **PR 关联只由平台通道产生**（2026-09-24 定案）：**只有经平台通道建出来的 PR 会自动关联到任务**——
+  `morula repo mr create`（推荐）或 `gh pr create` 后调 `report_pr` 工具上报。平台按自己的事实（哪个任务、
+  哪条分支、哪个 workContext）认领，**不读 PR 文本**。
+- **不要在 PR 标题/正文里靠任务编号「标记归属」**：服务端**不再扫描** title/branch/body 找任务编号。
+  人工在 GitLab/GitHub 上手工建的 PR 平台**不关联**（不进关联区、不触发自动评审、不驱动任务状态）。
+- **关单**：关联上的 PR 合并后，服务端按既有流程自动推进任务状态（全部 MR 合并 → 已合并；这些提交进入生产分支 → 已发布）。
+  不需要 `Closes` 之类关键字——**关联本身就是授权**。
+- 仍然建议 PR 标题以「`<任务编号>: 描述`」开头、正文写一句 `Closes <任务编号>`：**这是给人看的可读性**（平台不再依赖它），
+  且是任务与 PR 之间最省事的对照线索。
 
 ## 0.3 分支命名：由你（Agent）取名并上报
 
 - **任务 ID 获取**：本任务的 AgentTask ID（UUID）在系统提示「基本信息」段（也是 `morula task get`（无参）返回的 `id`，`.agent_context/task-context.md` 开头亦有）。需要调用 `morula task branch` 时用它作为 taskId。
-  - **重要区分**：`morula task branch <taskId>` 的 taskId 用**本任务 UUID**（机器协议）；但 **MR / PR 里的任务编号用对外编号 code**（如 `AGENT-958201`，用于服务端关联/关单）——**不要用 UUID 标记 MR**（UUID 关单只认业务对象，AgentTask 不会被识别，会导致 MR 关联失败）。
+  - **重要区分**：`morula task branch <taskId>` 的 taskId 用**本任务 UUID**（机器协议）；MR 标题里的任务编号用**对外编号 code**（如 `AGENT-958201`）——但注意**编号只影响可读性，不再影响关联**（服务端不读 PR 文本，见第 0.2 / 2 条）。
 - **只有需要改代码并推分支的任务才取名**；纯问答/只读调研/本地起服务不建分支（见第 3 条决策树）。
 - **先检查当前分支**：若仓库已有 feature 分支（同任务/同一改动闭环的后续轮次复用），**直接继续用当前分支，不要新建**（在仓库目录内执行）：
   ```bash
@@ -130,8 +135,9 @@ allowed-tools: Bash(morula *), Bash(git *), Bash(gh *)
 - **git / gh 命令一律在对应仓库目录内执行**（`cd <工作区根>/<仓库目录>`，或 `git -C <仓库目录> ...`）：
   工作区根不是 git 仓库，在根目录跑 git 命令必然失败。`morula` CLI 可在工作区根或其任意子目录执行（见 0.4）。
 - **主仓库**：平台已解析出的仓库在**工作区根下就绪**（目录名 = 仓库全名把 `/` 换成 `-`，如 `human-resources/xxx` → `human-resources-xxx`）；`ls` 工作区根即可看到，直接在该目录内建分支/提交/推分支/提 PR。**需要空间绑定了哪些仓库时自己查**：`morula repo list --space <spaceId>`（spaceId 见系统提示「基本信息」段）。
-- **⚠️ `morula repo checkout` 的语义 = 「声明/切换本任务的**主仓库**」**（服务端 generation+1 + daemon 物化工作区）：
-  **它决定后续开发阶段在哪个仓库干活**。因此只在**判定出主仓库之后**调用，**一次任务只声明一次**（判错要纠正时才再调一次）。
+- **⚠️ `morula repo checkout` 的语义 = 「声明/切换本任务的主仓库」**（服务端 generation+1 + daemon 物化工作区）：
+  声明只作用于当前任务（当前阶段的执行者）；**开发阶段任务不继承分析阶段的声明**——需要改代码时由你自己
+  按任务描述/分析结论 checkout。因此只在**判定出主仓库之后**调用，**一次任务只声明一次**（判错要纠正时才再调一次）。
   不要用它「把空间里的仓库逐个逛一遍」——每调一次主仓库就跟着换一次（真机踩到：分析阶段为查证 checkout 了 3 个仓库，
   主仓库最终停在最后那个「只看了一眼」的仓库上）。
 - **若任务需要了解仓库内容/代码/提交状态（读场景，含纯问答）**：
@@ -150,7 +156,7 @@ allowed-tools: Bash(morula *), Bash(git *), Bash(gh *)
 - **若任务涉及多个仓库（多仓库任务）**：涉及哪些仓库由**你**结合任务描述判断（任务描述里的「涉及仓库」是管家的初始判断；空间绑定了哪些仓库用 `morula repo list --space <spaceId>` 查；执行中发现还需改动其他仓库时，自行 prepare 拉取），**不需要向用户逐个确认**：
   1. 主仓库：在它的子目录内直接 git 操作（工作区根不是仓库）；
   2. 其他仓库用 `morula repo prepare <taskId> <repoFullName>` 物化到任务工作区根下（**与主仓库同级的子目录**，本地 daemon 端点，本轮立即物化并返回路径；git 协议拉取，不走平台 API）；
-  3. 在哪个仓库改动，就在哪个仓库内建分支（第 0.3 条命名规范）、推分支并建 PR/MR（title/description 带任务编号）；每个仓库的 PR 服务端都会自动关联到本任务。**分支名逐仓上报**：主仓库（其子目录）用 `morula task branch <taskId> --name <分支名>`；次仓库（同级子目录）用 `morula task branch <taskId> --name <分支名> --repo <owner/name>` —— 服务端据此把分支名写到该仓库的工作上下文（平台侧逐仓建 MR 兜底、交付清单都依赖它；不报则一直停在占位分支名 `morula/tmp-*`，平台找不到你的分支）；
+  3. 在哪个仓库改动，就在哪个仓库内建分支（第 0.3 条命名规范）、推分支并**经平台通道建 PR/MR**（`morula repo mr create` 优先；标题带任务编号仅为可读性）。**只有经平台通道建的 PR 才会关联到本任务**（服务端不读 PR 文本，见第 2 条）。**分支名逐仓上报**：主仓库（其子目录）用 `morula task branch <taskId> --name <分支名>`；次仓库（同级子目录）用 `morula task branch <taskId> --name <分支名> --repo <owner/name>` —— 服务端据此把分支名写到该仓库的工作上下文（平台侧逐仓建 MR 兜底、交付清单都依赖它；不报则一直停在占位分支名 `morula/tmp-*`，平台找不到你的分支）；
   4. prepare 目录二次调用会 fetch 更新但**不动工作区**——跨轮复用时先 `git status` 确认现场。
 - **安全边界**：只在本任务的任务工作区根（及其仓库子目录）内操作；禁止探索/修改工作区根之外的路径（尤其 daemon 根目录下其他任务的 `repos/`、`worktrees/`、`scratch/`）。
 - **本地验证服务端口隔离**（issues/local-backend-watch-instability.md）：若任务需要启动本地服务验证（如 `npm run dev` / `nest start` 等），**必须使用非平台占用端口**——绑定 `127.0.0.1` 的高位随机端口（如 127.0.0.1:18080+），**禁止**使用 `8080`（平台后端）及 `15173`（平台前端）等平台占用端口，也不要依赖终端会话存活（后台进程方式启动，用 `nohup`/`disown` 或 `&!` 脱离）；启动后自测可用即可，不需要（也不应）让平台侧访问。云端沙箱化后由沙箱网络策略兜底。
@@ -250,13 +256,15 @@ morula task inbox --peek     # 只看不取（确认有没有新意见，不标
 
 > 为什么是这四个时机：检查是**工具调用**，有 token 与延迟开销；「无消息立即继续」是为了不让检查点把主线带偏。
 
-## 2. PR 链接与关单意图是两套不同的契约
+## 2. PR 关联：只走平台通道
 
-- **链接通道**：PR 的 title / body 中出现任务编号 → 服务端自动关联 PR 到任务。
-  推荐写法：title 以「STR-101: 描述」开头，或 body 写「Closes STR-101」（分支名不含任务编号，见 0.3；平台通道建的 MR 会自动把编号写进 title/body）。
-- **关单通道**：只有 `Closes` / `Fixes` / `Resolves` 后**紧邻**任务编号（如「Closes STR-101」）→ 该 PR
-  merge 时服务端自动把任务流转到完成状态。title 前缀或 branch 引用只会关联 PR，不会在 merge 时关单。
-- body 中松散的提及（如「Related to STR-101」）会被标记为纯引用，不展示在任务的 PR 列表中。
+- **关联的唯一来源是平台通道**（2026-09-24 定案）：`morula repo mr create`（推荐）建 PR 时服务端当场落关联；
+  或 `gh pr create` 之后调 `report_pr` 工具上报。**服务端不读 PR 文本**——title/branch/body 里写什么任务编号都不会关联。
+- **人工在 GitLab/GitHub 上手工建的 PR，平台不关联**：不进任务关联区、不触发自动评审、不驱动任务状态。
+  如果你希望一条 PR 关联到本任务，就必须走上面两条平台通道之一。
+- **关单不需要关键字**：关联上的 PR 合并后，服务端按既有流程推进任务状态
+  （全部 MR 合并 → 已合并；这些提交进入生产分支 → 已发布）。**关联本身就是授权**。
+- 推荐（可读性，不是关联手段）：title 以「STR-101: 描述」开头、body 写一句 `Closes STR-101`——便于人和平台日志对照。
 
 ## 3. 什么时候推分支、提 PR（决策树）
 

package/dist/plugin/skills/morula-working-on-issues/references/working-on-issues-source-map.md

@@ -5,10 +5,10 @@
 
 | 契约 | 服务端实现 | 位置 |
 |------|-----------|------|
-| 任务 key 匹配（`SPW299-30`） | `VcsLinkService.TASK_KEY_RE`（扫描 title/branch/body；正则 `[A-Z][A-Z0-9]{1,9}-数字`，大小写敏感 → **MR title/body 中的编号须原样大写**；分支名已不含编号（契约 0.3 定案），编号由平台通道自动写入 title/body） | `src/modules/vcs-integration/link/vcs-link.service.ts:30,435` |
-| Close intent 单独扫描（title/body，`Closes|Fixes|Resolves` 紧跟 key） | `CLOSE_INTENT_RE` | `vcs-link.service.ts:29` |
-| reference-only 隐藏（松散 body 提及不入 PR 列表） | `resolveTargets` 与 closeIntent 分支 | `vcs-link.service.ts:60-80, 184-186` |
-| merge 关单幂等 | merged → closeIntent 链接对应任务 | `vcs-link.service.ts:19-20`（文件头注释） |
+| PR 关联**只由平台通道产生**（服务端不读 PR 文本） | 平台通道建链（`reportPrLinkByAgent`）+ webhook 按 `(租户, 仓库, PR 号)` 定位**已存在**的链接 → 只更新状态 | `src/modules/vcs-integration/link/vcs-link.service.ts`（`findLinkedRows` / `handlePullRequest`） |
+| 未关联的 PR（人工手工建）→ 不建链、不流转、留痕 | 同上（定位不到即返回，写「未关联任何任务」日志） | 同上 |
+| merge 关单：**链接存在即授权**（无需 `Closes` 关键字） | merged/closed → 多仓库汇总 → `closeObject` | `vcs-link.service.ts`（`closeObject`） |
+| 终态不可被降级（`released` 不被 `closed`/`merged` 覆盖；`merged → released` 放行） | `isTerminalDowngrade`（领域层唯一定义）+ `ObjectService.update` 不变量 | `domain/lifecycle-state.ts`、`object.service.ts` |
 
 ## 2. 与平台交互只能走 morula CLI
 
@@ -38,7 +38,7 @@
 
 | 契约 | 实现 | 位置 |
 |------|------|------|
-| merge 自动关单（服务端驱动状态） | webhook merged → closeIntent → Object 完成 | `src/modules/vcs-integration/webhook/vcs-event.service.ts` |
+| merge 自动关单（服务端驱动状态） | webhook merged → 按平台事实定位已关联链接 → 汇总 → Object 完成 | `src/modules/vcs-integration/webhook/vcs-event.service.ts`、`link/vcs-link.service.ts` |
 | agent 不调 CLI 改状态 | 协作契约第 4 条。**注意：CLI 有 `morula task state <id> --state <code>`**（机器协议 `POST /agent-tasks/:id/state`，供平台/自流转使用）——是**契约要求 agent 不调用**它，不是「CLI 没有这个命令」 | `packages/morula-cli/src/commands/task.ts`（action `state`）、`src/modules/agent-task/agent-task.controller.ts`（端点） |
 
 ## 4.1 评审任务结论回传（morula review submit）

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@arcships/morula-runtime",
   "type": "module",
-  "version": "0.1.0-alpha.14",
+  "version": "0.1.0-alpha.16",
   "description": "Device-level CLI for the Morula local agent runtime (daemon/portal/models/auth) and the Morula business CLI (morula), distributed via npm",
   "bin": {
     "morula-runtime": "./bin/morula-runtime.js",