[gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card

This card is a gate, not work. It exists so that ADR-0131's execution cards cannot be dispatched before the maintainer opens the v18 development line.

Why a card and not a label

target:v18 does not stop anyone. A lane seat's candidate query is pm:queue + domain:* + no assignee; target:* is a release-board view and appears nowhere in dispatch selection. The only state a lane seat is required to skip is pm:blocked with a Blocked-by: line, and the only thing that releases such a card is the unlock scan when its upstream closes. So the upstream has to exist. It is this card.

The rule

Every ADR-0131 execution card carries pm:blocked and names this card in its Blocked-by: line. While this card is open:

⛔ No ADR-0131 card is dispatched, claimed, or assigned — by any seat, in any repository, whatever its domain:*, priority:* or target:* labels say.
⛔ No seat cuts a new card from ADR-0131 in pm:queue. New cards derived from the record are filed pm:blocked behind this one.
⛔ This card is not closed by a seat. Not by triage, not by a lane PM, not by the director seat, not on the argument that "the upstream looks done". Only the maintainer decides that the v18 line is open, and closing this card is how they say so.

Maintainer, 2026-09-04, on ADR-0131: 「我发 17.3，然后后续这么大的改动应该放到 v18」 and, approving the record, 「要 v18 才开发」.

What happens when it closes

The unlock scan returns every card naming it to pm:queue, in the dependency order their own Blocked-by: lines already encode (C1/C2/C4/C6 become dispatchable first; C3 waits on C1+C2; C7 waits on C2–C6; C8 waits on C7; C9 on C2; C10 on C6 then C8; C11 on C8+C10; C12 on C5). Each returning card's file surface is re-verified against the then-current main before it is dispatched — the usual unlock discipline, and unusually load-bearing here because the record's premises were measured in 2026-09.

Already landed, and deliberately not behind this gate

ADR-0131 D14 puts exactly two things before the 17.3 tag, and both are done:

fix(platform-objects,core): sys_metadata_activation ships tenant-less — drop the reserved organization_id before 17.3 is cut (ADR-0126 amended by ADR-0131 D6/D7) #15024 — sys_metadata_activation ships tenant-less (PR fix(platform-objects,core): sys_metadata_activation ships tenant-less — drop the reserved organization_id (#15024) #15155, merged 2026-09-04).
revert(plugin-sharing): drop the NULL-inclusive business-unit screen added by #14949 before 17.3 is cut; keep the strict member screen (ADR-0131 D8) #15030 — the NULL-inclusive business-unit screen of fix(plugin-sharing): a seeded business unit is a usable sharing-rule recipient, and its members are tenant-screened #14949 reverted (PR revert(plugin-sharing): drop the NULL-inclusive business-unit screen before 17.3; keep the strict member screen #15078, merged 2026-09-03).

⛔ Nothing else of ADR-0131 ships in 17.x. A card that would land "just the harmless half" of any of D1–D13 in a 17.x release is out of order regardless of this gate.

The record

ADR-0131 — docs/adr/0131-total-organization-ownership-no-null-organization-id.md, merged to main via #14976, approved by the maintainer 2026-09-04. Its §8 is the execution table these cards are cut from; D14 is the staging decision this gate enforces.

docs(adr): ADR-0131 Status is Accepted — the merge that landed it on …

docs(adr-0131): amend D13's reach — the legacy-anchor retirement leav…

docs(adr): ADR-0132 / ADR-0133 Status moves to Accepted — each record…

feat(security): record platform-admin standing on the audit ledger at…

Ruling recorded: the v18 branch model is A. v18 develops on `main`, and 17.x continues on a `release/17.x` maintenance line. ⛔ This does not open the line: this card stays open until the maintainer closes it

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

Provenance (who / verbatim / where): the maintainer, in the triage seat's live chat (session_01AavokzJ5DndAwitDXvKy4U), verbatim: 「同意分支模型」. It answers the seat's recommendation to the maintainer's question 「是否建议开始处理 v18 的任务」, which offered two models and recommended A:

A: v18 on main, with a release/17.x maintenance line;
B: v18 on a long-lived next branch, with main staying 17.x.

B was not taken because main moved about 100 commits a day over the last week (3,228 since 2026-09-04), and ADR-0131 rewrites organization_id handling across the engine and services. A side branch would rot within days.

Ruled (A):

v18 develops on main. Once this card closes, ADR-0131's cards land there, in §8's order.
17.x continues on release/17.x, for security and release-blocking fixes only. There is no 17.8 feature release. A fix that must reach 17.x is a backport PR to that branch.
main's next release is 18.0.0. Its version PR is not merged until the maintainer declares 18.0 ready.
- An 18.0.0-next.N prerelease channel is optional. It is not ruled here. By default it is not opened until C7's migration ceremony is ready to rehearse on cloud and hotcrm.
cloud's .objectstack-sha follows release/17.x until cloud's v18 ceremony (cloud#1979) is ready. cloud#2654's move to the 17.7.0 tag is consistent with this.

Triage's refinement (an execution detail, overturnable by the maintainer): the recommendation said to cut at the 17.7.0 tag. The cut is instead taken from main immediately before the first ADR-0131 merge. That point contains the tag 4e4e881427, plus every 17.x fix landed after it, which would otherwise each need a backport. main is already at aa09db58c9.

Not ruled, still the maintainer's:

When the line opens. Closing this card is still the maintainer's act alone. The seat's recommended preconditions are:
- the 17.7 tail lands (objectui#11717, cloud#2654, docs(releases): write the curated 17.7.0 release page — 17.7.0 is published (2026-10-06) and content/docs/releases/v17/17-7.mdx does not exist #21989);
- 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 is answered;
- the 17.x maintenance line can publish (release: cut a release/17.x branch for cloud's pin at the v18 opening, with the backport rule — no 17.x npm publish lane (ruled; precondition for closing #15193) #21993).
target:v18 in objectui and cloud. It is still in the decision box.

The precondition card is #21993 (domain:devx, p1): the release/17.x branch, its version PR and publish lane, the dist-tag policy, and the backport rule. The line should not open before it can publish a 17.x patch.

Generated by Claude Code

Ruling recorded: no 17.x npm publish lane. `release/17.x` is a branch that cloud pins, and nothing publishes from it. This amends the record `6017499711`

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-06T14:08Z. ⛔ Not a claim, ⛔ not a dispatch. This card stays open until the maintainer closes it.

Provenance (who / verbatim / where): the maintainer, in the triage seat's live chat (session_01AavokzJ5DndAwitDXvKy4U), verbatim: 「不建议再建立一套 npm 发布流程，我运维太麻烦」. It answers the seat's question of whether 17.x needs an npm publish lane at all (choice 2: the branch for cloud's pin only).

Ruled:

release/17.x exists only so that cloud's .objectstack-sha can take security and release-blocking fixes until cloud's v18 ceremony (cloud#1979) is ready.
⛔ Nothing publishes from it: no version PR, no publish lane, no 17.x dist-tag. npm's 17.x line ends at what main publishes before the cut. Self-hosters and npm consumers get their next release as 18.0, with its manual migration.
A backport PR to the branch carries no changeset.

This amends 6017499711: that record said 17.x "continues on release/17.x" without saying how it ships. Shipping is now settled: to cloud by commit pin, never to npm.

What it changes:

release: cut a release/17.x branch for cloud's pin at the v18 opening, with the backport rule — no 17.x npm publish lane (ruled; precondition for closing #15193) #21993 is narrowed (title and body edited 14:05:32Z). It is now the cut at the opening, a proof that nothing publishes from the branch, a branch-settings list, and the backport rule.
- The edit crossed os-justin's claim (14:05:08Z). The claimant was told on the card (6018035139) and on its seat post.
The opening's hard precondition is now small: creating a branch at the opening, and writing the rule down.
A choice now open to the maintainer: a last 17.x npm release from main before the cut, through the normal release lane. It would carry whatever 17.x fixes land before the opening, for example 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 if its open question 1 is answered first. It needs nothing new.

Generated by Claude Code

Ruling recorded: no `release/17.x` at all. Cloud does not pin a maintenance branch either. This amends the records `6017499711` and `6018081901`

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-06T14:14Z. ⛔ Not a claim, ⛔ not a dispatch. This card stays open until the maintainer closes it.

Provenance (who / verbatim / where): the maintainer, in the triage seat's live chat (session_01AavokzJ5DndAwitDXvKy4U), verbatim: 「cloud 也不需要钉分支」. It follows 「不建议再建立一套 npm 发布流程，我运维太麻烦」 (6018081901).

Ruled:

v18 develops on main (unchanged), and there is no 17.x maintenance line of any kind: no branch, no npm lane, no backport rule.
npm's 17.x line ends at what main publishes before the opening.
cloud stays on its last pre-opening framework pin (the 17.7.0 tag, once cloud#2654 lands) until cloud's own v18 ceremony (cloud#1979) is ready.

What it changes:

release: cut a release/17.x branch for cloud's pin at the v18 opening, with the backport rule — no 17.x npm publish lane (ruled; precondition for closing #15193) #21993's whole scope is withdrawn. It was claimed at 14:05:08Z (os-justin), with no branch and no PR as of this record. Triage does not touch claims, so closing it not_planned is the holder's act. Told on the card and on the seat post.
The opening has no remaining precondition beyond the maintainer's word.
- At the opening, triage records the last pre-v18 main commit in its round record. A branch can always be cut from it later if an emergency ever needs one. That is an option, not a plan.
⚠️ Everything 17.x users or cloud need must land on main before the opening. After it, a fix reaches them only through 18.0 and its manual migration. Named now:
- 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 (p1 security), which waits on its open question 1;
- any framework-side fix for cloud's open p1s, for example cloud#2637 if its bisect names a framework commit;
- the decision whether to publish a last 17.x to npm from main before the opening.

Generated by Claude Code

Ruling pointers: batch #282 items 2 and 6 (decision cards #22009 and #22010) · maintainer 「同意」 2026-10-06T16:00Z

Director seat, summon #35, session_01VYToj6PQehTEKNrjGM9akg (via the relay). Records: 6020116360 on #22009 and 6020197009 on #22010, both closed. ⛔ This gate card stays open: only the maintainer closes it. Thread-read: 6018207607.

decision: before the v18 line opens, does main publish one last 17.x release to npm? #22009 → A: one last 17.x release from main before the opening, through the existing lane, fixes only. List: 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 engine-level deny (batch 🔗 Broken links detected in documentation #281), 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 / decision: #21980 OQ1 — the unscoped kernel's bare-name registration lets one package's stored copy answer another package's by-name read: fix it in #21980, split it out, or fix it first? #22004 (batch 🔗 Broken links detected in documentation #282 item 1), any framework-side fix cloud's open p1s name (cloud#2637 if its bisect names a framework commit), plus the 5 fixes already on main since the 17.7.0 version commit (fix(plugin-approvals): Setup → Approvals → Requests opens the tenant-wide list, and a merged-app pin closes the caller-scoped first-view family #21991, fix(metadata-protocol): put and delete accept the version a checksum-less sys_metadata row is served as #21990, fix(metadata-protocol): the metadata door serves a code-defined datasource's code definition while a stored row exists #21985, fix(platform-objects): Setup identity pages open on the tenant-wide list; a caller-scoped list view is never first #21983, fix(metadata-protocol): another package's withdrawal of a form holds at the anonymous form endpoints, whatever packages' copies of a view container are saved #21979). ⛔ 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 (feat(spec)!, PR feat(spec)!: the build doors refuse a builtin node config value its executor contract refuses, with its location #21974) is not on the list; it lands in 18.0. No deadline was set; A′ (publish without waiting for 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) is the fallback if the maintainer sets one 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 misses it. Readings corrected: npm latest is 17.7.0, published 2026-10-06T12:22Z; main carries 9 commits since the version commit, not dozens.
- Execution: the domain:devx seat triggers refresh_version_pr once the listed fixes are on main; the maintainer merges the version PR and approves the release (Prime Directive Add missing Field.phone() helper and factory methods for Action/Dashboard/Report #15); triage records the last pre-v18 main commit at the opening; the maintainer closes this card after the release is out.
decision: create the target:v18 label in objectui and cloud and tag their v18-gated cards (objectui#2763, objectui#7611, cloud#1979)? #22010 → A: target:v18 is created in objectui and cloud and applied to objectui#2763, objectui#7611 and cloud#1979 (triage, next round, one sentence per card). The label is a board view; the gate stays this card's Blocked-by: lines.

Generated by Claude Code

Pointer: decision card #22050 is in the box. It covers the maintainer's proposal 「直接开始开发 v18，并分阶段后续发 v18的版本可好」: when to open, and how v18 ships after opening.

A, recommended: cut the last 17.x from main now, without waiting for 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, after cloud#2637 is diagnosed. Then open with changeset pre enter next, ship staged 18.0.0-next.N under the next dist-tag, and cut 18.0 GA after C7 and cloud#1979.
B: skip the last 17.x.
C: keep decision: before the v18 line opens, does main publish one last 17.x release to npm? #22009's order.

Nothing on this card changes until the ruling is recorded. This card still closes only by the maintainer.

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

docs(qa): record A1 of crud-permission-matrix as a known v18 gap (obj…

The v18 line is open: this gate closes on the maintainer's word

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T12:28Z. ⛔ 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 所有的卡片」, then 「同意」 to the seat's execution plan. The ruling record is #22050 6037890422 (B: v18 opens on main, with no last 17.x).

This card's own rule is that only the maintainer decides the v18 line is open, and that closing this card is how they say so. The seat closes it on their word, through the relay, in this act.

What follows, in this order:

The scope comments first: 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 is written 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).
The unlock scan. Every card whose Blocked-by: names only this card returns to pm:queue. Every other ADR-0131 card stays pm:blocked in the order its own Blocked-by: line encodes:
- C3 waits on C1 and C2;
- C5 waits on C1;
- C7 waits on C2 to C6;
- C8 waits on C7;
- C12 waits on C5;
- C11 waits on C8 and cloud#1979;
- C9 (objectui#7611) waits on C3 and C5;
- C10 (cloud#1979) waits on C6.
Each returning card's file surface is re-verified against the then-current main at claim, as this card says.
The opening card (Changesets pre mode) is filed after the unlock.
⛔ chore: version packages #21988 is not merged. From here, main takes breaking stages.
The last pre-v18 main commit is recorded when the opening card's PR lands.

cloud stays on 56bf27affb until its own v18 ceremony (cloud#1979), per 6018207607.

feat(spec)!: the build doors refuse a builtin node config value its e…

Navigation Menu

Repository navigation

[gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card #15193

Why a card and not a label

The rule

What happens when it closes

Already landed, and deliberately not behind this gate

The record

Ruling recorded: the v18 branch model is A. v18 develops on `main`, and 17.x continues on a `release/17.x` maintenance line. ⛔ This does not open the line: this card stays open until the maintainer closes it

Ruling recorded: no 17.x npm publish lane. `release/17.x` is a branch that cloud pins, and nothing publishes from it. This amends the record `6017499711`

Ruling recorded: no `release/17.x` at all. Cloud does not pin a maintenance branch either. This amends the records `6017499711` and `6018081901`

The v18 line is open: this gate closes on the maintainer's word

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[gate] the v18 development line is not open — ADR-0131 execution cards are blocked on this card #15193

Description

Why a card and not a label

The rule

What happens when it closes

Already landed, and deliberately not behind this gate

The record

Activity

objectstack-fleet commented on Oct 6, 2026

Ruling recorded: the v18 branch model is A. v18 develops on main, and 17.x continues on a release/17.x maintenance line. ⛔ This does not open the line: this card stays open until the maintainer closes it

objectstack-fleet commented on Oct 6, 2026

Ruling recorded: no 17.x npm publish lane. release/17.x is a branch that cloud pins, and nothing publishes from it. This amends the record 6017499711

objectstack-fleet commented on Oct 6, 2026

Ruling recorded: no release/17.x at all. Cloud does not pin a maintenance branch either. This amends the records 6017499711 and 6018081901

objectstack-fleet commented on Oct 6, 2026

objectstack-fleet commented on Oct 7, 2026

objectstack-fleet commented on Oct 7, 2026

The v18 line is open: this gate closes on the maintainer's word

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Ruling recorded: the v18 branch model is A. v18 develops on `main`, and 17.x continues on a `release/17.x` maintenance line. ⛔ This does not open the line: this card stays open until the maintainer closes it

Ruling recorded: no 17.x npm publish lane. `release/17.x` is a branch that cloud pins, and nothing publishes from it. This amends the record `6017499711`

Ruling recorded: no `release/17.x` at all. Cloud does not pin a maintenance branch either. This amends the records `6017499711` and `6018081901`