Merge remote-tracking branch 'origin/main' into claude/issue-24321-resume-as-decider

Author: claude

.changeset/24472-bound-action-collision-report.md

@@ -0,0 +1,14 @@
+---
+'@objectstack/objectql': patch
+---
+
+fix(objectql): a bound action named like an action its target object already lists, with a different declaration, is reported at boot naming both packages; `registerAction` reports replacing another owner's handler
+
+Clause-②: no (a warning only: no accept set narrows, no door answer moves, and no published surface gains a key; owes the seat's review of record before the queue)
+
+- **The listing.** A top-level action bound by `objectName` to an object that already lists an action of the same name is still not attached: the object keeps serving its own declaration, as the action router does. When the two declarations differ, the boot now warns once per pair, at `kernel:ready`, naming the object, the action, the package whose declaration is served and the package whose declaration is not listed. Two packages binding different declarations of one name to a third package's object are reported the same way (the first one attached is served).
+- **Not a collision.** One declaration carried twice is compared without its provenance stamps (`_packageId`, `_provenance`, the `_lock` envelope, `protection`) and without `objectName`, and is not reported: a same-stack bound action merged onto its object, or the same declaration shipped by two packages.
+- **Later artifacts.** An artifact registered after the boot (a marketplace install, a ledger rehydrate) is judged once it has registered, for the pairs naming one of its packages; a pair the boot already reported is not reported again.
+- **The handler.** `ObjectQL.registerAction` keys handlers by `OBJECT:ACTION`. A registration under a key another owner holds still replaces it (the last registration runs), and now warns, naming both owners: the action door runs the new owner's handler whichever declaration the object lists, and withdrawing that owner leaves the action with no handler. The same owner re-registering is silent, and so is the authored-action resync, which tears its set down first. A registration with no package is its own owner.
+- **Unchanged.** Nothing is refused and no boot fails on it; the served `actions`, the router's precedence and which handler runs are as before. Measured on stock CRM, showcase and todo boots: no new warning.
+- **Fix.** Rename one of the two actions, or drop the duplicate declaration.

.changeset/pre.json

@@ -1,4 +1,4 @@
 {
-  "mode": "pre",
+  "mode": "exit",
   "tag": "next"
 }

.claude/skills/pm-dispatch/references/decision-analysis.md

@@ -6,7 +6,7 @@
 
 - 每批恰好 5 张,末批不足照呈;呈完即停等回批,⛔ 永不一条消息投多批。
 - 批序:在飞被阻塞 > 运营阻塞 > 用户可见 > 结构性;卡面分析只一层 = 立卡席六项 + 四棱。
-- 总监批前卡评论是增量:命令复核前提,逐棱同异,推荐/回退/口径;不同意字母才展开四维。
+- 总监批前卡评论是增量:命令复核前提,逐棱同异,推荐/口径;不同意字母才展开四维。
 - 回批一行式逐卡对应字母选项;带的附加条件随执行落地,⛔ 不为它另起请示轮。
 - 呈递详解 = 逐卡散文按正文六项;⛔ 表格行、判词、栅格不构成详解,压缩批次是违规。
 - 受管草稿批例外:一 PR 一行(改了什么/为什么/席位意见/一个动作),⛔ 不套六项;速读住 PR。
@@ -23,7 +23,7 @@
 - 业务含义直译:每选项配一句业务上等于什么,允许行业类比。
 - 四轴从业务立场论证(含四棱行):论据是客户、产品或事故后果,机制名词只作括号补充。
 - 防 AI 犯错轴写清出错时谁看到什么:响亮拒绝,还是静默泄露。
-- 推荐 + 回退 + 置信缺口:荐一项、给回退项、明说看不见什么;⛔ 不沿用他席推荐。
+- 推荐 + 置信缺口:只荐一,余各一句不取理由;盲区明说,⛔ 不因此另荐;⛔ 不沿用他席推荐。
 - 推荐先只按①得出:终态句写两年后该能力的平台样子与主流平台建模,点名参照。
 - ②③④ 与工作量只调时序分期 ⛔ 不翻字母;契约迁就实现、分期半量 ⛔ 不作推荐。
 - ①读数相近而工作量差 ≥3× 推荐须点名;翻字母只凭维护者卡上另裁,唯④新增门禁例外。

.claude/skills/pm-dispatch/references/lanes/hotcrm.md

@@ -5,7 +5,7 @@
 ## 形态
 
 - 本席为姊妹仓执行座位:在 hotcrm 仓认领、派发、复核、落地。
-- ⛔ 不产 `domain:*`、type 与定级,纪律全文在 SKILL.md 多仓协调规则 4。
+- ⛔ 不产 `domain:*`;机械三务(含首触定级)按 cross-repo-coordination.md 单车道仓条自理。
 
 ## 范围
 
@@ -30,7 +30,7 @@
 - 发现 declared 不等于 enforced 先问生产者在哪;生产者在平台 ⇒ 上游卡。
 - 不扩散需求:创业阶段聚焦原则全额适用,四维框架的不扩散那一轴是本车道首要过滤器。
 - 框架单源在 SKILL.md 〈升级与决策〉,⛔ 不另抄。
-- 投机功能形状不入队:走决策箱或关 not planned;定级归分诊或维护者,本席只供证据。
+- 投机功能形状不入队:走决策箱或关 not planned;定级按 filing-gate.md,理由落卡,维护者可否决。
 - 双版本兼容:hotcrm 必须在 objectstack 社区版可运行,部署到 objectos 企业版时获得企业能力。
 - 操作判据:hotcrm 元数据只可依赖社区能力面,企业特性恒为增强,⛔ 永不硬依赖。
 - 会 break 社区版运行的卡定义上是错范围,回分诊。

content/docs/protocol/backward-compatibility.mdx

@@ -17,7 +17,7 @@ ObjectStack follows strict backward compatibility guarantees to ensure predictab
 <Callout type="warn">
 **The 17.x minors ran under a launch-window override: a breaking change shipped as a MINOR release, not a MAJOR one.** Every published `@objectstack/*` package versions in lockstep, so the version number alone is not an upgrade-safety signal; read [Launch Window](#launch-window-minor-releases-can-contain-breaking-changes) at the end of this page before you upgrade across 17.x.
 
-**The v18 line is a major in prerelease.** Changesets is in pre mode with the tag `next`, and `scripts/check-changeset-no-major.mjs` stands aside in pre mode, so a pull request may declare a major bump. Every release cut from `main` is the next `18.0.0-next.N` on npm's `next` tag, while `latest` stays on 17.x. See [how a breaking stage lands on the v18 line](/docs/releases/v18#how-a-breaking-stage-lands-on-this-line).
+**The v18 line has exited prerelease mode.** While Changesets was in pre mode with the tag `next`, every release cut from `main` was the next `18.0.0-next.N` on npm's `next` tag, and `scripts/check-changeset-no-major.mjs` stood aside in pre mode, so a pull request could declare a major bump. Changesets has exited pre mode, so the line's GA version is `18.0.0`, which publishes to npm's `latest` tag, and the guard again fails a pull request that declares a `major` bump. See [how a breaking stage lands on the v18 line](/docs/releases/v18#how-a-breaking-stage-lands-on-this-line).
 </Callout>
 
 ObjectStack follows [Semantic Versioning 2.0.0](https://semver.org/) (`MAJOR.MINOR.PATCH`). The table below describes what each component means; which version a breaking change ships in depends on the line, as the callout above says.
@@ -65,7 +65,7 @@ When a feature, schema property, or API is deprecated, ObjectStack follows a str
 - Code examples are updated to use the replacement
 - CLI tooling may provide automated migration commands
 
-### Phase 3: Removal (MINOR release in 17.x, the next `18.0.0-next.N` on the v18 line)
+### Phase 3: Removal (MINOR release in 17.x, the next `18.0.0-next.N` during the v18 prerelease)
 
 - Deprecated feature is removed from the schema
 - TypeScript types no longer include the property
@@ -79,11 +79,11 @@ Shipped examples: `17.2.0` retired `http_request_errors_total` and `sys_position
 ```mermaid
 flowchart TD
     A["Deprecation notice — feature marked deprecated (warning emitted)"] --> B["Migration period — deprecated feature keeps working, no behavior change"]
-    B --> C["Removal — retired at the boundary the ADR-0087 registry records (MINOR release in 17.x, the next 18.0.0-next.N on the v18 line)"]
+    B --> C["Removal — retired at the boundary the ADR-0087 registry records (MINOR release in 17.x, the next 18.0.0-next.N during the v18 prerelease)"]
 ```
 
 <Callout type="warn">
-**No minimum survival window.** ObjectStack does not guarantee a deprecated feature survives for a fixed number of releases — [ADR-0049](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0049-no-unenforced-security-properties.md)'s dispositions for a flagged property are enforce, `experimental`, or remove, and none of them carries a dwell time. A deprecated feature is retired at the boundary the ADR-0087 registry records for it; in the 17.x minors that removal itself landed in a MINOR release, so a MINOR bump was where to expect a removal to arrive. On the v18 line it lands in the next `18.0.0-next.N`.
+**No minimum survival window.** ObjectStack does not guarantee a deprecated feature survives for a fixed number of releases — [ADR-0049](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0049-no-unenforced-security-properties.md)'s dispositions for a flagged property are enforce, `experimental`, or remove, and none of them carries a dwell time. A deprecated feature is retired at the boundary the ADR-0087 registry records for it; in the 17.x minors that removal itself landed in a MINOR release, so a MINOR bump was where to expect a removal to arrive. During the v18 prerelease it landed in the next `18.0.0-next.N`.
 </Callout>
 
 ---
@@ -92,7 +92,7 @@ flowchart TD
 
 ### What Constitutes a Breaking Change
 
-Read the **Breaking?** column, not the version number: in the 17.x minors every row below — breaking or not — shipped in a MINOR or PATCH release, and on the v18 line every row ships in the next `18.0.0-next.N`, so on neither line does the bump size tell you whether you have work to do.
+Read the **Breaking?** column, not the version number: in the 17.x minors every row below — breaking or not — shipped in a MINOR or PATCH release, and during the v18 prerelease every row shipped in the next `18.0.0-next.N`, so in neither case does the bump size tell you whether you have work to do.
 
 | Change Type | Breaking? | Version Impact (17.x minors) |
 |:---|:---|:---|
@@ -114,7 +114,7 @@ Read the **Breaking?** column, not the version number: in the 17.x minors every
 1. **RFC (Request for Comments)** — Breaking changes are proposed as GitHub issues with the `protocol:breaking` label.
 2. **Deprecation** — The old behavior is deprecated in a MINOR release (see timeline above).
 3. **Migration Guide** — A detailed migration guide is published before the removal lands, in the release notes for the version that carries it.
-4. **Release** — In the 17.x minors the breaking change shipped in the next **MINOR** version, carrying a changeset entry marked `**BREAKING**`, and `scripts/check-changeset-no-major.mjs` failed a pull request that declared a `major` bump, because under lockstep one `major` would promote all 73 published packages. On the v18 line it ships in the next `18.0.0-next.N`: the guard stands aside in pre mode, so a pull request may declare a major bump. See [how a breaking stage lands on the v18 line](/docs/releases/v18#how-a-breaking-stage-lands-on-this-line).
+4. **Release** — In the 17.x minors the breaking change shipped in the next **MINOR** version, carrying a changeset entry marked `**BREAKING**`, and `scripts/check-changeset-no-major.mjs` failed a pull request that declared a `major` bump, because under lockstep one `major` would promote all 73 published packages. During the v18 prerelease it shipped in the next `18.0.0-next.N`, because the guard stood aside in pre mode and a pull request could declare a major bump. Changesets has exited pre mode, so the guard fails a `major` bump again. See [how a breaking stage lands on the v18 line](/docs/releases/v18#how-a-breaking-stage-lands-on-this-line).
 
 ---
 
@@ -173,7 +173,7 @@ The `@objectstack/spec` package provides additional stability guarantees:
 ### Export Stability
 
 - All public exports are listed in the package's `index.ts` barrel files
-- Removing an export is always a breaking change; the 17.x minors shipped it in a MINOR release, and on the v18 line it ships in the next `18.0.0-next.N`
+- Removing an export is always a breaking change; the 17.x minors shipped it in a MINOR release, and during the v18 prerelease it shipped in the next `18.0.0-next.N`
 - Internal modules (prefixed with `_` or in `internal/` directories) are not covered by SemVer guarantees
 
 ### Runtime Behavior
@@ -187,26 +187,26 @@ The `@objectstack/spec` package provides additional stability guarantees:
 ## Launch Window: MINOR Releases Can Contain Breaking Changes
 
 <Callout type="warn">
-**The 17.x minors ran under this exception — read it before you upgrade across them.** Every published `@objectstack/*` package versions in **lockstep**, and in the 17.x minors a breaking change shipped as a **MINOR** release rather than burning a MAJOR, so those minors contain documented breaking changes. The v18 line is a major in prerelease: every release cut from `main` is the next `18.0.0-next.N` on npm's `next` tag, while `latest` stays on 17.x. See [how a breaking stage lands on the v18 line](/docs/releases/v18#how-a-breaking-stage-lands-on-this-line).
+**The 17.x minors ran under this exception — read it before you upgrade across them.** Every published `@objectstack/*` package versions in **lockstep**, and in the 17.x minors a breaking change shipped as a **MINOR** release rather than burning a MAJOR, so those minors contain documented breaking changes. During the v18 prerelease every release cut from `main` was the next `18.0.0-next.N` on npm's `next` tag; Changesets has exited pre mode, so the line's GA version is `18.0.0`, which publishes to npm's `latest` tag. See [how a breaking stage lands on the v18 line](/docs/releases/v18#how-a-breaking-stage-lands-on-this-line).
 </Callout>
 
 ### Which surfaces this covers
 
 **All of them.** It was not scoped to an experimental corner or a pre-release channel: all **73** packages published from this repository belong to a single Changesets `fixed` group, so they share one version number and one policy. No published surface was exempt.
 
-The convention was enforced rather than informal — `scripts/check-changeset-no-major.mjs` failed a pull request that introduced a `major` bump, because under lockstep a single `major` on one package would promote the entire stack. Changesets is now in pre mode with the tag `next`, and the guard stands aside in pre mode, so a pull request on the v18 line may declare a major bump.
+The convention was enforced rather than informal — `scripts/check-changeset-no-major.mjs` failed a pull request that introduced a `major` bump, because under lockstep a single `major` on one package would promote the entire stack. During the v18 prerelease Changesets was in pre mode with the tag `next` and the guard stood aside, so a pull request on the v18 line could declare a major bump. Changesets has exited pre mode, and the guard fails a `major` bump again.
 
 ### What this means for an upgrade
 
 - **Do not read a MINOR bump as safe to take unattended.** Read the [release notes](/docs/releases) for the version you are moving to: they lead with breaking changes and carry the migration steps.
 - **Pin exact versions** instead of caret ranges if you cannot review each MINOR before it lands.
 - **Diff your own metadata** across the upgrade with `os diff <before> <after> --breaking-only`.
 
-MAJOR releases do still happen — 17.0.0 was cut precisely because its breaking density was too high to carry `^16.x` consumers across on a caret range, and the v18 line is a major in prerelease — but in the 17.x minors an individual breaking change did not, on its own, force one.
+MAJOR releases do still happen — 17.0.0 was cut precisely because its breaking density was too high to carry `^16.x` consumers across on a caret range, and the v18 line is the next one — but in the 17.x minors an individual breaking change did not, on its own, force one.
 
 ### When it stops applying
 
-The tables and deprecation timeline above state this rule for the 17.x minors directly, beside what the v18 line does. Classic SemVer — where a breaking change once again requires a MAJOR — is the settled form the project returns to once the launch window closes: the window closes at GA, and strict SemVer resumes from that point. **For the 17.x minors, this section was the operative rule wherever any part of this page disagreed.** For the `18.0.0-next.N` prereleases, the operative rule is [how a breaking stage lands on the v18 line](/docs/releases/v18#how-a-breaking-stage-lands-on-this-line).
+The tables and deprecation timeline above state this rule for the 17.x minors directly, beside what the v18 prerelease did. Classic SemVer — where a breaking change once again requires a MAJOR — is the settled form the project returns to once the launch window closes: the window closes at GA, and strict SemVer resumes from that point. **For the 17.x minors, this section was the operative rule wherever any part of this page disagreed.** For the `18.0.0-next.N` prereleases, the operative rule is [how a breaking stage lands on the v18 line](/docs/releases/v18#how-a-breaking-stage-lands-on-this-line).
 
 ---