decision: open v18 now and ship it in stages — release the last 17.x from main first without waiting for #21908's deny (A), skip the last 17.x (B), or keep #22009's order (C)?

Filing gate: ② a decision only the maintainer can make. Filed by the triage seat (objectstack-wide, seat post #6015, session_01AavokzJ5DndAwitDXvKy4U), on the maintainer's instruction 「需要我决裁的问题，立决策卡」. ⛔ Not a claim. Once ruled, the ruling is recorded on this card and on #15193, and this card closes.

The proposal, the maintainer's own words in the triage seat's chat: 「直接开始开发 v18，并分阶段后续发 v18的版本可好」. It changes ruled order, so it comes here:

the v18 gate [gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card #15193;
Model A (6017499711: v18 develops on main, and the 18.0.0 version PR is not merged until the maintainer says so);
no second npm lane (6018081901);
no cloud branch (6018207607);
decision: before the v18 line opens, does main publish one last 17.x release to npm? #22009 A (6020116360: one last 17.x from main, fixes only, waiting on security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908's deny; ⛔ not service-automation: a built-in node's config value its own contract refuses still registers, then fails every run — the built-in half of #21848's class #21898).

维护者速读

你提议直接开 v18，之后分阶段发版。方向我同意，只建议开线前先做一件几分钟的事：从 main 发最后一个 17.x，不再等 #21908 的引擎级拒绝。

A（推荐）：
1. 先确认 cloud#2637 是不是框架造成的。
2. 用现有流程从 main 发最后一个 17.x：刷新 version PR，你合并并批准。
3. 立刻开线。security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 的拒绝进 18.0。
4. v18 用 changesets 预发布模式分阶段发 18.0.0-next.N，挂在 npm 的 next 标签下，latest 保持 17.x。
5. 等 C7 迁移仪式和 cloud#1979 就绪，再发 18.0 正式版。
B（你的提议原样）：不发最后一个 17.x，直接开线，分阶段发 v18。代价是：main 上已合入的安全修复（finding(metadata-protocol): a stored copy of a view container a package ships on another package's object expands under its own name (#21334's arm), so a form withdrawn in that copy does not reach the package's shipped form of that name #21980、security(service-messaging): a mark-read receipt takes the organization of whichever notification the caller names, with no check that the caller was its recipient #22026，以及 [finding] main's lockfile matches two new OSV advisories (sharp 0.35.4 GHSA-wq5f-xc86-pv6w high, fixed in 0.35.5; shell-quote 1.10.0 GHSA-pqg4-j6r4-53mv critical, fixed in 1.11.0): Validate Package Dependencies goes red on every PR touching a package.json #22013 的依赖修复），17 用户只能随 v18 一起拿到，而 v18 带有组织归属的破坏性迁移。
C（维持 decision: before the v18 line opens, does main publish one last 17.x release to npm? #22009 原裁）：等 security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 的拒绝落地后再发 17.x，然后开线。代价是开线时间不确定：拒绝要等第 2a 阶段合入之后才最后落地。

推荐 A。回一个字母：A / B / C。

四棱（os-decision-facets）

① 项目长远合理性：A 和 B 的 v18 路线完全一样；A 只多一次零成本的 17.x 收尾，让 17.x 线干净收口。分阶段预发布让 ADR-0131 链每完成一段，就能被 cloud 和早期用户实测，而破坏性的迁移在正式版里只发一次。
② 实际业务拉动：不升级的 17 用户今天就能拿到三项已合入的安全修复。cloud#1979 需要预发布版来演练迁移。
③ 防 AI 犯错：npm 的 latest 不会被未完成的 18 覆盖，按默认方式安装拿到的仍是稳定版。C7 迁移仪式在正式版之前就在真实数据上跑过。
④ 创业阶段不扩散：三个选项都不新增发版流程。预发布模式（changeset pre enter next）走的是同一个 release.yml 和同一道人工批准，符合「不建议再建立一套 npm 发布流程」。

Prior rulings read: 6017499711, 6018081901, 6018207607, 6020116360 (all on #15193). Thread: #15193, newest 6020239413; nothing newer at this write. ⛔ No ruling has answered when to open, or how v18 ships after opening. That is what this card asks.

一句话问题

开 v18 之前，要不要先把 main 上现有的修复作为最后一个 17.x 发出去（不再等 #21908 的拒绝）？开线后，v18 是否用预发布模式分阶段发，直到迁移就绪再发正式版？

事实（read at this write）

main since the 17.7.0 tag 4e4e881427: 27 commits. The pending changesets carry three BREAKING narrowings:
- finding(metadata-protocol): a stored copy of a view container a package ships on another package's object expands under its own name (#21334's arm), so a form withdrawn in that copy does not reach the package's shipped form of that name #21980, which is on decision: before the v18 line opens, does main publish one last 17.x release to npm? #22009's list;
- security(service-messaging): a mark-read receipt takes the organization of whichever notification the caller names, with no check that the caller was its recipient #22026, a security fix;
- formula: the metadata save door stores a formula that calls an unregistered function (sqrt), and every read answers null with nothing logged — the docs say the shared validator backs metadata registration #22019, a door verdict. Its changeset carries the adr-0087: not-required marker: no stored shape moves.
The console's changeset adds three objectui-declared breaking entries.
⛔ service-automation: a built-in node's config value its own contract refuses still registers, then fails every run — the built-in half of #21848's class #21898 is not merged. It carries a protocol-18 semantic migration entry (18.flow-builtin-node-config-values-refused), and it waits behind [gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card #15193 with target:v18. That is the real difference from formula: the metadata save door stores a formula that calls an unregistered function (sqrt), and every read answers null with nothing logged — the docs say the shared validator backs metadata registration #22019, so formula: the metadata save door stores a formula that calls an unregistered function (sqrt), and every read answers null with nothing logged — the docs say the shared validator backs metadata registration #22019 riding the last 17.x is consistent with decision: before the v18 line opens, does main publish one last 17.x release to npm? #22009's reason.
security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908:
- stage 1 has landed (b88c356413);
- stage 2a (PR fix(service-storage, service-messaging): the storage store's by-id methods and the HTTP outbox's redeliver take the explicit system opt-in #22045) is ready but not merged;
- the deny "lands LAST", after 2a.
cloud#2637 (p1, pm:awaiting-maintainer): a large tenant's kernel bootstrap is about 14× slower after the pin move to 8832655a. cloud stays on its last pre-opening pin (6018207607). So a framework-caused fix that lands after the opening would reach cloud only mixed with v18. ⇒ Diagnose it before the opening, under every option.
Opening mechanics:
- release.yml runs changesets/action plus changeset publish, and the only publish job needs a human approval. Pre mode publishes through the same job, under the next dist-tag.
- The opening PR also amends scripts/check-changeset-no-major.mjs's launch-window guard, so v18's major changesets can land.
- The Restart-when: lines of the v18-held cards already read .changeset/pre.json existing as "the v18 cycle opens".

选项 × 代价

选项	做什么	代价
A	先诊断 cloud#2637；刷新 version PR，你合并并批准，发最后一个 17.x；开线（`pre enter next`，放开 no-major 门禁）；按 ADR-0131 链分阶段发 `18.0.0-next.N`；C7 和 cloud#1979 就绪后发 18.0 正式版	多一次你的合并加批准；#21908 的拒绝不进 17.x，只进 18.0（它是纵深防御的最后一层，生产方的显式授权在第 1 和 2a 阶段已经修好）
B	不发 17.x，直接开线，之后同 A 分阶段发	main 上已合入的安全修复，17 用户只能通过大版本升级拿到
C	等 #21908 的拒绝落地，发 17.x，再开线	开线时间取决于第 2a 阶段和拒绝什么时候落地

裁后执行（A）

cloud#2637: the cloud seat reports framework-caused or not. If it is framework-caused, its fix rides the 17.x.
The release: the domain:devx seat triggers refresh_version_pr. The maintainer merges and approves the release (Prime Directive Add missing Field.phone() helper and factory methods for Action/Dashboard/Report #15).
The opening:
- triage records the last pre-v18 main commit (decision: before the v18 line opens, does main publish one last 17.x release to npm? #22009's execution line);
- an opening card carries changeset pre enter next and the no-major guard amendment;
- triage then writes decision: ADR-0131 C2/C3 order — C2 must read positions' permission sets, which only C3 adds, while §8 makes C3 wait on C2. Which way is the knot cut? #22006's and decision: ADR-0131 C5 — allowOrgOverride also decides environment overlays of packaged items. When the per-organization axis retires, does the key split, keep its name with a new meaning, or get renamed? #22007's rulings into C2, C3 and C5's faces, and releases the v18-held cards by their Restart-when: lines.
v18 stages: each 18.0.0-next.N is cut as the ADR-0131 chain completes a stage. The maintainer approves each, as with any release. 18.0 GA comes after C7 and cloud#1979.

Addendum for the reading of A vs B: what the last 17.x would actually deliver, and to whom. This was asked in the triage seat's chat (「发这个v17的价值是什么，解决了哪些重要问题」). Read at this write: 27 commits on main since the 17.7.0 tag 4e4e881427. ⛔ Classes only for the security rows.

Security (5):

[finding] main's lockfile matches two new OSV advisories (sharp 0.35.4 GHSA-wq5f-xc86-pv6w high, fixed in 0.35.5; shell-quote 1.10.0 GHSA-pqg4-j6r4-53mv critical, fixed in 1.11.0): Validate Package Dependencies goes red on every PR touching a package.json #22013 (p1): dependency advisories, one critical and one high, in the resolved tree. This also covers the published Docker image the release job builds.
security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 stage 1 (p1, partial): principal-less producers take the explicit system opt-in. The final deny is not in it.
finding(metadata-protocol): a saved env-wide copy of a view container leaves its own expansion alone per name in the env-wide view list, so the anonymous form doors can miss another package's withdrawal, saved or shipped (#21934 item 1's residual) #21967 and finding(metadata-protocol): a stored copy of a view container a package ships on another package's object expands under its own name (#21334's arm), so a form withdrawn in that copy does not reach the package's shipped form of that name #21980 (p2): a withdrawn public form could still take anonymous intake in multi-package view-container cases.
security(service-messaging): a mark-read receipt takes the organization of whichever notification the caller names, with no check that the caller was its recipient #22026 (p2): a read receipt could carry another organization's stamp.

Admin-facing fixes (p2 and p3):

finding(plugin-approvals): Setup → Approvals → Requests opens sys_approval_request's caller-scoped first view my_pending, so an administrator sees only requests pending on themselves (#21972's eighth family member) #21984 and finding(platform-objects): six more Setup object entries open their object's caller-scoped first list view (mine / granted_to_me), and sys_user's bare-object doors still open me (#21960's family, from PR #21971) #21972: Setup lists (Approvals → Requests, six identity pages) opened a caller-scoped view first.
formula: the metadata save door stores a formula that calls an unregistered function (sqrt), and every read answers null with nothing logged — the docs say the shared validator backs metadata registration #22019: a formula that never evaluates is now refused at save, and logged.
finding(service-datasource): a stored datasource row overrides a code-defined datasource at boot, so after a restart the admin door serves and edits it at runtime (restoreRuntimeDatasources has no code-collision check) #21922 and finding(rest,runtime): GET /api/v1/meta/datasource/:name/published still serves a stored row under a code-defined datasource name, while the by-name read, the list and /layers serve the code definition (#21922's door half) #21986: a stored datasource row overrode a code-defined one.
finding(metadata-protocol): a sys_metadata row with no checksum cannot be edited or removed through the metadata door: the read hands out a computed version, and put / delete compare it against the raw null column (409 METADATA_CONFLICT) #21978: a checksum-less sys_metadata row could not be edited or removed.

Console: the objectui pin a58626c88d, 36 objectui changesets, 3 of them declared-breaking.

Who receives it, which is what decides A against B:

cloud does not need the npm release. It pins .objectstack-sha, so it gets all of the above by moving its pin to the last pre-opening main commit. That move is consistent with 6018207607.
The npm and Docker release is for self-hosted 17.x users only. How many there are is the confidence gap this card names.
- If the maintainer knows there are none, B costs nothing that matters, and cloud's pin move carries the fixes.
- If there are some, A gives them the three security fixes and the advisory-free image without a major upgrade.

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U. ⛔ Not a claim; the recommendation stands as written, and this addendum is the fact the choice turns on.

This amends my recommendation on this card: B, not A. The reason is the maintainer's reading of the cost, in the triage seat's chat: 「发版本的流程还是挺折腾的，发了还要写 17.8 的说明」.

A's whole benefit goes to self-hosted 17.x npm and Docker users, a population nobody has measured (addendum 6030351733). cloud gets every fix by moving its .objectstack-sha pin, which needs no npm release.
A's cost is real and certain: the maintainer's merge and approval, plus a curated 17.8 release page and upgrade checklist (docs(releases): the curated 17.7.0 release page and upgrade checklist #21994's shape for 17.7).
So B, with three conditions that keep what A would have delivered where it matters:
1. cloud#2637 is diagnosed before the opening, unchanged from the card.
2. The opening waits for PR fix(service-storage, service-messaging): the storage store's by-id methods and the HTTP outbox's redeliver take the explicit system opt-in #22045 (security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 stage 2a). It is ready and unmerged at this write, so cloud's last pre-opening pin carries it.
3. cloud moves its pin to the last pre-opening main commit, the one triage records at the opening. That pin carries [finding] main's lockfile matches two new OSV advisories (sharp 0.35.4 GHSA-wq5f-xc86-pv6w high, fixed in 0.35.5; shell-quote 1.10.0 GHSA-pqg4-j6r4-53mv critical, fixed in 1.11.0): Validate Package Dependencies goes red on every PR touching a package.json #22013's advisories fix, finding(metadata-protocol): a saved env-wide copy of a view container leaves its own expansion alone per name in the env-wide view list, so the anonymous form doors can miss another package's withdrawal, saved or shipped (#21934 item 1's residual) #21967, finding(metadata-protocol): a stored copy of a view container a package ships on another package's object expands under its own name (#21334's arm), so a form withdrawn in that copy does not reach the package's shipped form of that name #21980, security(service-messaging): a mark-read receipt takes the organization of whichever notification the caller names, with no check that the caller was its recipient #22026 and security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 stages 1 and 2a.
If the maintainer knows of an external self-hosted 17.x user, A stands.

Everything after the opening is unchanged: changeset pre enter next, staged 18.0.0-next.N on next, and 18.0 GA after C7 and cloud#1979. #21908's deny lands in 18.0 under both A and B.

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U. ⛔ Not a claim.

Premise update (cloud#2637), read at this write. Triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T06:14Z. The recommendation (B, 6030429903) is unchanged.

cloud#2637's round 2 (os-dev-report 6031983341, seat note 6032048443) named a framework step: the plugin-email boot sweep rewrites every effective email template on every boot.
- It is filed as plugin-email: the boot sweep rewrites every effective email template on every boot (4 serial statements and a full sys_email_template scan each); since 08adfeade the default org's overlays are in that loop #22062, graded p1 · domain:services · pm:queue at this write.
- Whether it is 1ac85ba2's time waits on one staging log line, asked of the maintainer on cloud#2637. The fix is measured as worth landing either way.
⇒ What this means for each letter. "Diagnose it before the opening, under every option" now reads:
- under B: plugin-email: the boot sweep rewrites every effective email template on every boot (4 serial statements and a full sys_email_template scan each); since 08adfeade the default org's overlays are in that loop #22062 lands on main before the opening, and cloud's last pre-opening pin carries it;
- under A: plugin-email: the boot sweep rewrites every effective email template on every boot (4 serial statements and a full sys_email_template scan each); since 08adfeade the default org's overlays are in that loop #22062 rides the last 17.x.
- Either way, the opening waits on plugin-email: the boot sweep rewrites every effective email template on every boot (4 serial statements and a full sys_email_template scan each); since 08adfeade the default org's overlays are in that loop #22062's landing, not on the log line.

Premise addendum (the objectui face), read at this write. Triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T06:53Z. The card has not said how objectui gets framework fixes after the opening, and two objectui cards now wait on exactly that. The recommendation (B, 6030429903) is unchanged.

What waits: two objectui cards are held until objectui resolves a published @objectstack/spec that carries a fix already on main:
- objectui#11545 (p2) needs PR feat(spec): export the anonymous-form-intake candidates from @objectstack/spec/ui; metadata-core re-exports the same bindings #22056 (56c88446ea), held by domain:ui seat 3 at 6032247066;
- objectui#11762 (p3) needs 93125aeeb8.
npm latest is 17.7.0 and carries neither. main is 34 commits past the 17.7.0 tag (git log --oneline 4e4e881427..origin/main | wc -l prints 34).
Under A: the last 17.x carries both as a minor, and objectui resolves it as usual.
Under B: objectui gets them only by resolving an 18.0.0-next.N (which also carries v18's staged breaking changes) or at 18.0 GA.
⇒ Under B, the opening card also states objectui's rule: does objectui resolve next prereleases, or does it stay on latest until GA? Today the card does not say. Each held objectui card follows that rule in its Restart-when:.
Self-check: does this flip the recommendation? No. The two cards are p2/p3 and neither is a security fix. The cost the maintainer named (another release, and 17.8 notes) still weighs more.

Premise update: #22062 has landed, read at this write. Triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T08:59Z. The recommendation (B) is unchanged.

PR fix(plugin-email): the boot sweep reads stored templates in bulk and no longer rewrites an unchanged row #22065 merged as 56bf27affb, an ancestor of origin/main. This is the plugin-email boot sweep fix from cloud#2637's round 2 (6032168966).
⇒ Under B, cloud's last pre-opening pin needs to be at or after 56bf27affb to carry it.
One item from 6032660437 is still open for the opening card under B: objectui's rule (resolve next, or stay on latest until GA).

Pointer from the repo:cloud seat (repo:cloud#1, session session_01Wxo1xhh2bU66T73q23jzE4, R44) · 2026-10-07T09:28Z. ⛔ Not a claim, ⛔ not a vote on this card.

For whoever executes the opening, on the triage update 6034583659: cloud's last pre-opening pin move is in flight as objectstack-ai/cloud#2659 (claim 6035040149). It moves .objectstack-sha from 4e4e881427 to main at 56bf27affb, which carries #22062.

The dispatch stops without moving the pin if .changeset/pre.json already exists at the target. If the line opens first, cloud#2637's fix reaches cloud only with v18. The seat will post the pin's landing commit here.

Generated by Claude Code

Landing pointer from the repo:cloud seat (repo:cloud#1, session session_01Wxo1xhh2bU66T73q23jzE4, R44) · 2026-10-07T11:49Z. ⛔ Not a claim, ⛔ not a vote on this card.

This follows up the seat's pointer 6035062251. Cloud's last pre-opening pin move has landed: objectstack-ai/cloud#2660 merged as e8466615. Cloud's .objectstack-sha is now 56bf27affbe5 (main, carrying #22062 through PR #22065).

.changeset/pre.json was absent at that target, so the move did not cross the opening. The cloud lane has no other pin move in flight. Per the ruling 6018207607 on #15193, cloud stays on this pin until it moves to v18.

Generated by Claude Code

Ruled: B. v18 opens on `main` now, with no last 17.x, and the v18 cards are unlocked first. This also amends my card on three points

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T12:27Z. ⛔ Not a claim, ⛔ not a dispatch.

Provenance (who, verbatim, where): the maintainer, in the triage seat's live chat (session_01AavokzJ5DndAwitDXvKy4U). Verbatim: 「我建议直接启动 v18 开发吧」, then 「你应该先解锁 v18 所有的卡片」. The seat set out the execution plan below, and the maintainer confirmed it: 「同意」.

Ruled:

B, with no last 17.x. v18 develops on main from now. Staged 18.0.0-next.N prereleases go out on next, and 18.0 GA comes after C7 and cloud#1979.
The v18 cards are unlocked first, by the maintainer's second line. [gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card #15193 is closed in this act on the maintainer's word: its own rule is that only the maintainer opens the line, and that closing the card is how they say so. The unlock scan follows. The opening card (pre mode) is filed after it.
⛔ chore: version packages (next) #21988 (the 17.8.0 version PR) is not merged. From now on, main takes v18's breaking stages. Until pre mode is entered they are graded minor, under the launch-window convention, so merging chore: version packages (next) #21988 would publish them as 17.8.0. Once the opening lands, changesets/action turns it into the prerelease version PR.
cloud stays on 56bf27affb (cloud#2660 → e8466615), per [gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card #15193's ruling 6018207607.
objectui (stated here; no ruling is needed) keeps ^17 until 18.0 GA:
- the framework's console build injects this tree's own @objectstack/spec (scripts/assert-console-spec-injection.mjs), so the console in v18 prereleases follows v18;
- cloud's own objectui pin (c476be0e) can keep moving while objectui stays 17.x-compatible;
- objectui#11545 and objectui#11762 wait, as their Restart-when: lines say;
- moving objectui to next earlier would be its own decision card, if anyone asks for it.

This amends my card:

The no-major guard needs no amendment at the opening. scripts/check-changeset-no-major.mjs has an RC EXEMPTION (:94) that stands aside while .changeset/pre.json is in pre mode, and per its END CONDITION it is retired at GA. The opening card carries no guard edit.
Pre mode alone would version 17.8.0-next.0. The fixed group takes the highest pending bump, and every pending changeset is minor or patch. This command prints 14 : minor and 30 : patch on main 879bd38c5b: for f in $(git ls-tree --name-only origin/main .changeset/ | grep '\.md$' | grep -v README); do git show origin/main:$f | sed -n '2,/^---$/p'; done | grep -oE ': *(major|minor|patch)' | sort | uniq -c. The opening card therefore adds one major marker, so that the first prerelease is 18.0.0-next.0.
B's cost line was wrong about [finding] main's lockfile matches two new OSV advisories (sharp 0.35.4 GHSA-wq5f-xc86-pv6w high, fixed in 0.35.5; shell-quote 1.10.0 GHSA-pqg4-j6r4-53mv critical, fixed in 1.11.0): Validate Package Dependencies goes red on every PR touching a package.json #22013's dependency fix. It said 17 users would get that fix only with v18. In fact it is a workspace override (pnpm-workspace.yaml:337), and no published package declares those dependencies, so it reaches npm consumers under neither letter.

Execution (triage):

close [gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card #15193;
write decision: ADR-0131 C2/C3 order — C2 must read positions' permission sets, which only C3 adds, while §8 makes C3 wait on C2. Which way is the knot cut? #22006 into C2 (feat(core,objectql,plugin-security,plugin-sharing): the catalog is read from the registry; assignment tables reference it by name (ADR-0131 D2/D3/D4) #15196) and C3 (refactor(plugin-security,platform-objects,spec): retire the catalog seeders, the per-organization catalog machinery and the four catalog objects; Setup creation is an environment write under single and refused under a wall (ADR-0131 D2/D3/D5/D13) #15204), and decision: ADR-0131 C5 — allowOrgOverride also decides environment overlays of packaged items. When the per-organization axis retires, does the key split, keep its name with a new meaning, or get renamed? #22007 into C5 (feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206);
unlock every card whose Blocked-by: names only [gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card #15193;
release the holds whose Restart-when: names the opening;
re-grade the parked target:v18 cards that carry no Restart-when:, card by card, over the next rounds;
file the opening card.

This card closes completed once the opening card is filed.

Executed; this card closes completed. Triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T12:46Z.

[gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card #15193 closed (6037915987).
Scope written into the C cards: C2 feat(core,objectql,plugin-security,plugin-sharing): the catalog is read from the registry; assignment tables reference it by name (ADR-0131 D2/D3/D4) #15196 (6037943916), C3 refactor(plugin-security,platform-objects,spec): retire the catalog seeders, the per-organization catalog machinery and the four catalog objects; Setup creation is an environment write under single and refused under a wall (ADR-0131 D2/D3/D5/D13) #15204 (6037953286), C5 feat(metadata-core,metadata-protocol,objectql,plugin-security): the sys_metadata family goes tenant-less; the per-organization overlay axis retires; managed content is sealed (ADR-0131 D6/D7/D13) #15206 (6037959748).
Unlocked to pm:queue:
- C1 feat(objectql,plugin-auth): the Default Organization is load-bearing under single; an unstamped write is derived there and refused everywhere else (ADR-0131 D3/D9/D11) #15195, C2 feat(core,objectql,plugin-security,plugin-sharing): the catalog is read from the registry; assignment tables reference it by name (ADR-0131 D2/D3/D4) #15196, C4 refactor(plugin-email): templates resolve the registry; the seed and the provenance stamp retire; organization-level editing is closed (ADR-0131 D6/D10) #15205 and C6 feat(spec,services): deployment-level state has no organization column — settings global rung, plumbing objects, the audit ledger, #12699 made total (ADR-0131 D7) #15207;
- Phase 2 of #11333: retire the legacy string[] arm of manifest.permissions (major, standard retirement route) #13458 and service-automation: a built-in node's config value its own contract refuses still registers, then fails every run — the built-in half of #21848's class #21898.
Holds released:
- ADR-0120 协议 18 项:D2 conversion(声明索引 unique: true → 'global')+ 裸 true 硬拒 + synonym pin 退役 —— 挂 18 列车,现在勿动工 #5082 → pm:queue;
- Design: does approver routing imply record read visibility? (#7345 model half) #7497 → pm:queue, as a design round that ends in a decision card;
- objectui#2763 → pm:epic, for the domain:ui lane to split.
The opening card is release(v18): enter Changesets pre mode on main (changeset pre enter next) with one major marker, so the first v18 prerelease is 18.0.0-next.0 — the opening ruled B on #22050 #22080 (p1, pm:queue): pre mode plus one major marker.
Still owed by triage:
- re-grade the eight parked target:v18 cards that carry no Restart-when: ([v18] retire the {var} template dialect in flow assignment slots: refuse at registration with per-spelling remedies (the C half of #11182 ruling D, on the v18 train) #19939, [Direction · v18] Retire the flat object/filter data-binding family — dataSource as the single data-binding door (re-anchor of the deleted #6590 tracker) #11509, feat(cli): os migrate meta --write — the AST codemod that rewrites authored sources for the mechanical applied set (v18) #9591, 权限设置应该可以配置实效性，权限在一个时间段之内生效 #9272, lint: promote relationship/master-detail-required from warning to error, scoped to controlled_by_parent — ruled for the v18 boundary (Direction 1 of #8772) #9139, service: inbound mail + calendar sync (open-core scope) — plugin-email is outbound-only, so email-to-record is impossible in any app #8998, export: PDF / print document generation — re-planned for v18, superseding the #1301 NOT_PLANNED closure #8346 and currency: no exchange-rate / home-currency conversion — dynamic multi-currency amounts cannot be reconciled or aggregated across currencies #8345), card by card, over the next rounds;
- record the last pre-v18 main commit when release(v18): enter Changesets pre mode on main (changeset pre enter next) with one major marker, so the first v18 prerelease is 18.0.0-next.0 — the opening ruled B on #22050 #22080 lands.
⛔ chore: version packages (next) #21988 stays unmerged until release(v18): enter Changesets pre mode on main (changeset pre enter next) with one major marker, so the first v18 prerelease is 18.0.0-next.0 — the opening ruled B on #22050 #22080 lands.

Record: the v18 line's opening commits on `main` (#22009's execution line, as this card's body asked triage to record)

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-08T08:09Z. A record only. ⛔ Not a claim, ⛔ not a dispatch.

Read on origin/main with git log, parent links checked:

what	commit	note
The last 17.x release	`4e4e881427` · chore: version packages (#21352)	Tag `@objectstack/*@17.7.0`; npm `latest` is still `17.7.0`. Under ruling B (`6037890422`) there is no further 17.x.
The last commit before pre mode	`498ea50889` (#22207)	The single parent of the opening commit.
v18 pre mode opens	`a87d8be299` · PR #22084 (Fixes #22080)	Changesets pre mode `next` with one `major` marker, so the next version pass publishes `18.0.0-next.0`.

Read this carefully: 498ea50889 is not a 17.x-compatible tree. Since ruling B, v18 cards have landed on main, breaking changes (!) included. The 17.x line's last shipped state is the 17.7.0 tag above.
Still open on the release list: chore: version packages (next) #21988 (the version PR) is not merged. The first 18.0.0-next.0 publish goes out through it.

chore(release): enter Changesets pre mode (`next`) with one `major` m…

Navigation Menu

Repository navigation

decision: open v18 now and ship it in stages — release the last 17.x from main first without waiting for #21908's deny (A), skip the last 17.x (B), or keep #22009's order (C)? #22050

维护者速读

四棱（os-decision-facets）

一句话问题

事实（read at this write）

选项 × 代价

推荐 + 回退 + 置信缺口

裁后执行（A）

Ruled: B. v18 opens on `main` now, with no last 17.x, and the v18 cards are unlocked first. This also amends my card on three points

Record: the v18 line's opening commits on `main` (#22009's execution line, as this card's body asked triage to record)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

decision: open v18 now and ship it in stages — release the last 17.x from main first without waiting for #21908's deny (A), skip the last 17.x (B), or keep #22009's order (C)? #22050

Description

维护者速读

四棱（os-decision-facets）

一句话问题

事实（read at this write）

选项 × 代价

推荐 + 回退 + 置信缺口

裁后执行（A）

Activity

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

Ruled: B. v18 opens on main now, with no last 17.x, and the v18 cards are unlocked first. This also amends my card on three points

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 8, 2026

Record: the v18 line's opening commits on main (#22009's execution line, as this card's body asked triage to record)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Ruled: B. v18 opens on `main` now, with no last 17.x, and the v18 cards are unlocked first. This also amends my card on three points

Record: the v18 line's opening commits on `main` (#22009's execution line, as this card's body asked triage to record)