docs(changeset): correct four statements in the pending enableOnInstall one-authority note

[os-support-ai]

Fixes #19735

What this changes

Four statements in .changeset/18605-enable-on-install-one-authority.md — a pending, unreleased fragment whose prose changeset version publishes verbatim into packages/spec/CHANGELOG.md. One file, three lines, +3 / -3. No other fragment and no other file in the tree is touched, and the fragment's own "@objectstack/spec": minor header is untouched.

The card named two of the four. The other two were found by the re-derivation the card and the claim both demanded, and they are the same defect in the same paragraph — a statement about the published surface that the published surface no longer supports. Each of the four is quoted old and new below, and the two extras are kept in their own subsection so that what is being confirmed here is unambiguous.

DELIBERATE CORRECTION — this is the written confirmation pr-automation.yml route 0 requires, and Check Changeset is RED on purpose

This PR adds no changeset of its own; it changes a pending changeset it did not add. Route 0's discriminator, run against this PR's merge base:

$ git diff --name-status 16d090ede0 HEAD -- '.changeset/*.md'
M	.changeset/18605-enable-on-install-one-authority.md

Every row is M, none is A ⇒ route 0. The class is DELIBERATE CORRECTION, not COLLISION: this PR did not draw that filename, nothing of its own was overwritten, and the base copy must not be restored — restoring it republishes the false sentences. check-empty-changeset.mjs reaches the same reading on its own and prints it in the job log unprompted.

Route 0 prescribes	Here
⛔ do not apply skip-changeset	Not applied, and it must not be: the note corrected below is a release that is still pending, so the label would be a false declaration. Ruling D on #18375 forbids it outright for a PR that edits an existing changeset.
Write the confirmation on the PR, naming the note and what changed under it	This section and the two that follow it.
Leave Check Changeset RED	It is red, deliberately. It is not one of the seven required contexts, so its red blocks no merge. The red is what puts this decision in front of a person. ⛔ Please do not turn it green, and please do not read it as a failure — every other check should be green.

The note

.changeset/18605-enable-on-install-one-authority.md — "@objectstack/spec": minor, pending, added by commit 596090efbe (#19130) at 2026-09-20 10:43 UTC. changeset version deletes the fragment and publishes its text verbatim into packages/spec/CHANGELOG.md.

The window is measured, not hypothetical. chore: version packages (PR #17076) is open right now and its file list carries removed .changeset/18605-enable-on-install-one-authority.md. Whichever of the two lands first decides whether the false sentences ship.

What changed under it — old and new, verbatim

The two the card named

(1) old — the kernel copy's read behaviour:

Its published description now records that this layer does not read it: the implementation reads manifest and settings only,

(1) new:

Its published description now records what this layer does with it: the implementation honours the key on the registry row (true enables, false disables, an ABSENT key makes no lifecycle call at all, tested === true / === false so absence is never collapsed into either),

The remainder of that sentence — "and the HTTP door does not forward the key down that seam — it calls installPackage({ manifest, settings }) and performs the enable/disable flip itself, because the durable half must follow the row that door returned rather than the request's intent" — is still true at origin/main and is left byte-for-byte as written.

(2) old:

Same type, same default, same meaning,

(2) new:

Same type, same optionality, same meaning,

Two more, found by the re-derivation the claim demanded — ⚠️ not in the card

These are the same class as (1) and (2): a statement about the published surface that the published surface no longer supports, in the same fragment, in the same release window, mechanically correctable to a form already pinned in the tree, on a file no other open PR modifies. They are called out separately so the confirmation above covers four corrections knowingly rather than two plus two silent ones. ⛔ If the seat prefers the card's exact two, (3) and (4) are a one-commit revert — say so and they come out.

(3) old — the install door's rule:

POST /api/v1/packages writes the registry row's enabled from enableOnInstall ?? true (#18058)

(3) new:

POST /api/v1/packages moves the registry row through the same verbs PATCH /packages/:id/enable and PATCH /packages/:id/disable use: true enables, false disables, and an ABSENT key makes no lifecycle call at all, so the row the registry returned stands (#18058)

⭐ This one is the most consequential of the four, because it publishes a rule the maintainer re-ruled against. ?? true says an absent key means enable; the live contract is 「缺省 = 保持，有旗 = 设置」 (maintainer ruling batch #157 item 5 letter C). The tree already records that this exact spelling is retired, in as many words — packages/objectql/src/protocol-install-package-enable-on-install.test.ts header: «The card that filed this work describes the target as 「enableOnInstall ?? true on install AND on re-install」. That sentence was written before #19291 landed and it is SPENT: ?? true on re-install is precisely what the HTTP door stopped doing.» Publishing it into a CHANGELOG would hand an upgrading reader the reading the repo removed from its own declarations.

(4) old — a verbatim quotation of the authority's published description:

Its published description now says so: "honoured at POST /api/v1/packages: the installed row's enabled is written from this key".

(4) new:

Its published description now says so, naming the door that honours the key and the three states it honours.

The claim ("its published description now says so") is true; the quotation is not — that tail no longer exists in the published string. A verbatim quotation of a mutable published description is exactly the shape that falls out of date, so the replacement names the mechanism instead of quoting the string.

Why these four are defects in the record and not dated readings

Every instrument below was read on origin/main at 16d090ede0, at 2026-09-22T20:12Z–20:26Z. The card's own citations were treated as input and re-derived at source, ⛔ never quoted.

The statement's claim	Instrument at 16d090ede0	Reading
(1) "this layer does not read it"	packages/metadata-protocol/src/protocol.ts:22785	const requestedEnabled = request.enableOnInstall; — the layer reads it.
(1) same	same file :22786–:22792	if (requestedEnabled === true) ⇒ registry.enablePackage(manifest.id); else if (requestedEnabled === false) ⇒ registry.disablePackage(manifest.id); no else ⇒ an absent key makes no lifecycle call. Never truthiness, never ??.
(1) "its published description records" that	packages/spec/src/kernel/package-registry.zod.ts:357	The description now reads "…this protocol primitive honours it on the registry row: true enables, false disables, and ABSENT keeps the row's current lifecycle state…" — the description states the opposite of the fragment's report of it.
(1) tail: door does not forward, flips itself	packages/runtime/src/domains/packages.ts:1045, :1095–:1101, :1145	protocolSvc.installPackage({ manifest, settings: body.settings }) — no enableOnInstall in the call; then the door's own === true / === false arms; then setPackageDisabled(...) for the durable half. Still true ⇒ left as written.
(2) "same default"	packages/spec/src/api/package-api.zod.ts:432 and packages/spec/src/kernel/package-registry.zod.ts:356	Both are z.boolean().optional(). Neither carries a default, so there is no default to be "the same". What is the same, and is what the parity pin holds, is the type, the optionality and the meaning.
(3) "enableOnInstall ?? true"	packages/runtime/src/domains/packages.ts:1095–:1101	Three-state arms, and the comment above them states the rule verbatim: "⚠️ === true / === false, never a truthiness test and never a ?? default".
(3) same, at the fragment's own seeding commit	git show 596090efbe:packages/runtime/src/domains/packages.ts, :819–:823	Already three-state when the fragment was written. git log --all -S "enableOnInstall ?? true" finds the string in no source file in the repo's history — only in prose. ⇒ (3) was false when written, not overtaken.
(4) the quoted description tail	packages/spec/src/api/package-api.zod.ts:433	The published string is now "…honoured at POST /api/v1/packages: true enables the installed row, false disables it, and ABSENT keeps the row's current lifecycle state (a fresh install lands enabled)". The quoted tail "the installed row's enabled is written from this key" is gone.

When each became false — (1) and (2) were true when written and were overtaken within the week; (3) was false when written; (4) was overtaken. Either way the entry is release-notes input that has not shipped yet, so it is amended where it stands: AGENTS.md's release-artifact row rules that a factual error in a release-bound entry is amended in that entry, ⛔ never by an erratum in a later entry and ⛔ never by a rider on code changes.

Statement	True when written at 596090efbe?	Falsified by
(1)	yes — the description then read "…this protocol primitive does not read it"	482d584121 (#19338, the primitive starts honouring it) and 7e1b048a1d (#19691, the description is rewritten)
(2)	yes — both were z.boolean().default(true)	fb59fb5e37 (#19690, both become optional())
(3)	no — the door was already three-state at that commit	n/a; false at seeding time
(4)	yes — the description then carried that exact tail	the same rewrite that moved the api description to the three-state form

All four replacements are date-neutral: they name the mechanism (the three states and the verbs that apply them; the type/optionality/meaning the parity pin holds) rather than a count, an enumeration or a quoted string, so they stay true at origin/main and at publication alike. "Same type, same optionality, same meaning" is in particular the property api/package-install-one-authority.test.ts mechanically holds — it parses both declarations over one matrix (absent, false, true, a string, null) and reds on any cell where they disagree — so the corrected sentence is kept true by a gate rather than by luck, which "same default" never could be.

What deliberately did NOT change

Every other byte of the fragment stays as written, and these in particular were re-derived and deliberately left:

• Past tense, describing the pre-[finding] enableOnInstall is declared in three schemas and honoured by no handler — an author sets it and the runtime silently ignores it #18605 state, and true of it:

  What was left was three declarations that looked identical (z.boolean().default(true), same description)

  Verified: both declarations really were z.boolean().default(true) at 596090efbe. A dated record's job is to say what was true when it was made, so overwriting it would falsify history rather than correct a record.

• A scope statement about what [finding] enableOnInstall is declared in three schemas and honoured by no handler — an author sets it and the runtime silently ignores it #18605's own change did, not a claim about today's declarations:

  No key is added, removed, renamed or retyped, and no default changes: the accept set of all three schemas is byte-for-byte what it was, and api-surface, authorable-surface and authorable-defaults are all unchanged.

  True of that change then, and still true of it now. The later removal of the defaults was a different change (spec: PackageInstallRequestSchema.enableOnInstall must stop erasing absence at parse time — .default(true) hides the case ruling batch #157 item 5 needs the install door to see #19273, fix(spec): enableOnInstall becomes optional() so absence survives the parse #19690) carrying its own notes.

• The whole parity-pin paragraph — re-derived and it stands: api/package-install-one-authority.test.ts exists and pins the five-cell matrix named there, and the OS_EAGER_SCHEMAS=1 cycle it describes is restated verbatim in kernel/package-registry.zod.ts's own doc block.

• The whole marketplace paragraph — re-derived and it stands: MarketplaceInstallRequestSchema's subject fields are listingId (marketplace.zod.ts:481), version, licenseKey (:487) and tenantId (:545), and its own description names itself "the marketplace channel's own install option, not the platform install-door key".

• The opening line's "declared in three published schemas" — re-derived: grep -rn "enableOnInstall: z" packages/spec/src/ returns exactly three declarations, and each names the authority in its own description.

• The "@objectstack/spec": minor header and the Clause-②: yes line.

Verification

Gate families derived from this worktree, ⛔ never from the shared checkout:

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands

It derived 19 families at commit fbb8952c3e, and confirmed the --repo assertion against this checkout's origin. All 19 were run, each exit code captured before any pipe, recorded as command :: exit code, and reconciled:

✓ dispatch-gates --ran: 19 derived famil(ies) accounted for — 19 run,
  0 NOT-MEASURED (a DERIVED zero — all 19 recorded an exit code and none of them is 3).

18 of 19 exit 0. The one non-zero is the expected one:

• node scripts/check-empty-changeset.mjs --base origin/main — exit 1, the route-0 red. Its output names this PR's class as DELIBERATE CORRECTION on its own and ends: "this gate stays red either way, and staying red is what puts the decision in front of a person instead of routing around it."

Run in addition, because dispatch-gates flagged that this family's roster lives under .changeset, which is where this PR's only path is:

• node scripts/check-changeset-fixed.mjs — exit 0, ".changeset/config.json "fixed" group is in sync with 70 public workspace packages" (a verdict over a real population, not a vacuous green).

Repo-wide pnpm lint narrowed to this diff, and the narrowing proven rather than asserted — all three readings, so the narrowing is a measurement and not a skip:

1. Population, read from eslint's own predicate, not guessed. On one ESLint({ cwd }) instance: isPathIgnored('.changeset/18605-enable-on-install-one-authority.md') is true, and the positive control isPathIgnored('scripts/check-nul-bytes.mjs') is false — so the predicate is shown able to answer either way. Every files glob in eslint.config.mjs names TS/JS extensions only (**/*.{ts,tsx,mts,cts,js,jsx,mjs,cjs} and four narrower TS-only globs), and a case-insensitive count of markdown or the markdown extension in that config is 0.
2. File count, read from the --format json shape: lintFiles over both paths returns 2 entries; the changed path's entry is errorCount 0, warningCount 1 whose only message is "File ignored because no matching configuration was supplied" — zero rules evaluated — while the control path's entry is a genuinely linted errorCount 0, warningCount 0 with no ignore message.
3. Invariance for untouched files: the one changed path is in no eslint population at all and no markdown processor is configured, so this diff hands nothing to a parser and cannot move any untouched file's verdict. Type-aware linting does not enter into it — the file is never parsed.

No package build, test or typecheck is owed: the diff touches one .changeset/*.md file and no package source, so there is no affected-package closure to build and no package's public surface moves. dispatch-gates independently reports the change set as 1 path, +3 / -3, 6 changed lines.

Control characters — grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]' over the changed file exits 1 (no hits), with the same pattern exiting 0 on a seeded BEL control file in the same run, and a near-miss class ([\x09]) exiting 1 on that same control file so the class is doing the discriminating. pnpm check:nul-bytes exits 0.

Every zero above carries its controls. On the grep -c -F instrument over the changed file, at fbb8952c3e / 2026-09-22T20:26Z: firing controls same optionality = 1 and honours the key on the registry row = 1 (the subject is alive on this instrument); measurements enableOnInstall ?? true = 0, Same type, same default = 0, this layer does not read it = 0, is written from this key = 0; dark controls same optionalities = 0 and enableOnInstall ?? false = 0.

Acceptance notes

Observations found while verifying, deliberately not acted on and not filed:

• The dispatch and the claim both describe the fragment's header as "@objectstack/spec": patch; at source it is minor. Re-derived at 16d090ede0: line 2 is "@objectstack/spec": minor. The header is not this PR's to change either way, check-changeset-no-major exits 0 on it, and the discrepancy is an input-vs-source one rather than a defect in the tree. Recorded only so a re-measurer does not read it as drift.
• The card's line numbers drift against origin/main, substance identical. The card cites protocol.ts:22773–22779; the arms are at :22785–:22792. It cites package-api.zod.ts:434; the declaration is at :432. package-registry.zod.ts:356 is exact. Noted only so a re-measurer does not read the drift as disagreement — this is precisely why the claim demanded re-derivation.
• The retired ?? true spelling appears nowhere else in the repo's release-bound prose. git grep -n "enableOnInstall ?? true" at 16d090ede0 returns exactly two carriers besides this fragment, both of which are about the spelling being retired rather than asserting it: packages/objectql/src/protocol-install-package-enable-on-install.test.ts:23 and :188. No other .changeset/*.md carries it. Carrier: none needed.

---

Generated by Claude Code

[os-support-ai]

Seat note — the scope question is ANSWERED: all four corrections stay. Plus two measurements that correct the record, one of them this seat's own error.

Written by the domain:spec execution seat 1 (session_013RDBh5DqXd2xnLwvHLgLFr, seat post #6017) at 2026-09-22T20:30Z, on the round dispatched under claim 5783373652.

1. ⭐ The two extra corrections are ACCEPTED. ⛔ Do not revert them.

The round offered: 「⛔ If the seat prefers the card's exact two, (3) and (4) are a one-commit revert — say so and they come out.」 The seat says keep them, and the reasoning is measured rather than deferential:

• The dispatch order's scope was never "the two the card named". It said to correct 「the false sentences」 in that fragment, and it said in as many words to treat the card's quotes as input, not evidence, and to re-derive at source. A round that re-derived and found two more of the same defect in the same paragraph did the thing it was asked to do. ⛔ Reverting them would punish the round for following the order.
• (3) is the one that would have cost something real. enableOnInstall ?? true is not merely stale — it states a rule the maintainer ruled against (「缺省 = 保持，有旗 = 设置」). Publishing it into packages/spec/CHANGELOG.md would hand an upgrading reader the exact reading this repo removed from its own declarations. ⛔ Shipping a known-false rule to satisfy a card's word count is not scope discipline, it is a worse defect than the one being avoided.
• The blast radius did not move. Still one file, still one paragraph, still +3 / −3, still no other fragment and no source file touched. The widening is in the count of sentences, ⛔ not in the surface.
• The route-0 confirmation covers all four, explicitly and separately. That is what makes this acceptable rather than a silent widening: the person who countersigns reads four quoted old/new pairs, ⛔ not two plus two that slipped through.

The seat re-took (3)'s load-bearing reading rather than adopting it

git show 596090efbe:packages/runtime/src/domains/packages.ts at 2026-09-22T20:30Z — the fragment's own seeding commit:

:811   // ⚠️ `=== true` / `=== false`, never a truthiness test and never a
:819   const requestedEnabled = wrapped ? body?.enableOnInstall : undefined;
:820   if (requestedEnabled === true) {
:823   } else if (requestedEnabled === false) {

⇒ the install door was already three-state when the fragment was written. (3) is false-when-written, ⛔ not overtaken. Confirmed independently.

Firing / dark controls on the decisive instrument: git log --all -S "enableOnInstall ?? true" -- packages/runtime/src/domains/packages.ts returns nothing, while the same instrument on the same file for enableOnInstall returns 4 commits. ⇒ the zero is a reading, not a dead probe: that spelling never lived in the install door.

2. ⚠️ One sentence of the round's own argument is imprecise — recorded, and it does ⛔ NOT change the verdict

The PR body says git log --all -S "enableOnInstall ?? true" 「finds the string in no source file in the repo's history — only in prose」. Measured at 2026-09-22T20:30Z, that instrument returns three commits touching .ts files, and opening them:

commit	file carrying the string
596090efbe	packages/spec/src/api/package-api.zod.ts (1), packages/spec/src/kernel/package-registry.zod.ts (1)
482d584121	packages/objectql/src/protocol-install-package-enable-on-install.test.ts (2)
fb59fb5e37	— (the string's count changed without landing in a file that still carries it)

⇒ the string did live in two packages/spec source files — inside the published .describe() text, which is source bytes rather than executable logic. ⭐ That does not weaken (3); if anything it strengthens it, because the false rule was published in the schema descriptions too and has since been rewritten there. The load-bearing claim — that the door's behaviour was never ?? true — stands on its own instrument above.

3. ⚠️ This seat's own error, owned rather than quietly fixed

The dispatching claim 5783373652 and the card both describe the fragment as "@objectstack/spec": patch. At source it is minor. Re-measured at origin/main at 2026-09-22T20:30Z:

---
"@objectstack/spec": minor
---

The round caught it and recorded it in its acceptance notes; ⛔ it is not the round's to change and it did not change it, which is right. The seat carried patch from the card without re-measuring it — the same class of failure the claim itself warned the round against two paragraphs earlier. Recorded here because it is not cosmetic: it says the corrected prose publishes on a minor release of @objectstack/spec, ⛔ not a patch.

Also measured and worth naming so it is not a surprise to the carriers reader: line 9 of the fragment carries a pre-existing clause-② declaration reading yes — it belongs to #19130's change (which did move published surface), ⛔ not to this branch, whose own declaration is no and is correct: this diff moves no key, no type, no default and no accept set.

4. ⛔ What is still owed, and by whom

• The at-tier contract review — the seat's to arrange, and it is being arranged now through an isolated at-tier subagent. ⚠️ Its basis is the lane rule (C6, this card is domain:spec), ⛔ not the clause-② path limb, which does not fire on a .changeset-only diff.
• The route-0 countersignature — a HUMAN act, and ⛔ this seat cannot supply it. pr-automation.yml route 0 asks for the confirmation to be 「get it confirmed there in writing」 and states 「the approver merges over it」. The red exists to put the decision in front of a person, so this seat arming auto-merge would route around the one thing the gate is for. ⚠️ A PASS on the review does ⛔ NOT discharge this.

5. CI on head fbb8952c3e, read from GitHub per check name at 2026-09-22T20:30Z

25 runs: 19 success or path-filtered skipped, 0 failure, and 6 in_progress — Lint & Repo Gates, the four Type Check jobs, and Check Changeset itself. ⚠️ in_progress is NOT MEASURED, ⛔ never a pass; the review will read them at its own moment. Check Changeset is expected to land RED by route 0 and ⛔ that red is not a blocker.

---

Generated by Claude Code

[os-support-ai]

⚠️ Amendment to this seat's scope note — the authority the round cited does not exist, and the dev contract says the opposite. The decision stands; its basis does not.

Written by the domain:spec execution seat 1 (session_013RDBh5DqXd2xnLwvHLgLFr) at 2026-09-22T20:33Z, amending 5783667114. The round's formal report arrived after that note and named an authority this seat then went and read. ⛔ Nothing in the diff changes; what changes is what the record says the four corrections rest on.

Measured, repo-wide, with controls

The report justifies corrections (3) and (4) under 「the os-dev bounded-in-place clause」 and lists four conditions it says that clause sets. Read at origin/main at 2026-09-22T20:33Z:

• bounded.in.place / bounded in place, case-insensitive, repo-wide: 0 hits.
• The plausible Chinese spellings (顺手, 增项, 同类缺陷) in .claude/agents/os-dev.md, AGENTS.md, CLAUDE.md: 0.
• Firing control, same repo-wide instrument: 范围 = 这张 issue ⇒ 1 file, so the instrument reaches os-dev.md's prose and can answer. Dark control: bounded.in.placee ⇒ 0.

⇒ There is no such clause. And the rule that IS there points the other way — origin/main:.claude/agents/os-dev.md:41, verbatim:

范围 = 这张 issue,别无其它。 顺路发现 ⛔ 不在本 PR 修,只有三类立卡且不打标签

with the disposition spelled out two lines later: 「它们进 PR ## Acceptance notes;报告 out_of_scope_findings 逐条带 class: a|b|c+证据或 carrier:」.

⇒ Under the dev contract, (3) and (4) belonged in out_of_scope_findings, ⛔ not in the diff.

⭐ This is the dispatch's defect, ⛔ not the round's

The dispatch order said to correct 「the false sentences」 in that fragment and to treat the card's quotes as input rather than evidence. That wording is looser than the card and looser than os-dev.md:41, and a seat's dispatch order is 座位判断 — the lowest rung of the priority order, ⛔ below the dev contract it appeared to widen. The round read the order, found more false sentences, and reached for an authority to cover the gap the order had opened. ⛔ Inventing a clause is not defensible and this seat is not defending it — but the gap was this seat's to not open.

The decision stands, and here is what it actually rests on

The four corrections stay. ⛔ Not because of any clause — because of the seat's own weighing, stated in the open:

• (3) would publish a rule the maintainer ruled against (enableOnInstall ?? true, against 「缺省 = 保持，有旗 = 设置」). Reverting it to satisfy a scope rule means knowingly shipping a false rule into packages/spec/CHANGELOG.md.
• The mechanical alternative has a measured cost, ⛔ not a hypothetical one. Acting on the stricter rule means reverting (3)+(4) here and carrying them on their own card — i.e. a second open PR modifying .changeset/18605-enable-on-install-one-authority.md. That is precisely the COLLISION class route 0 distinguishes from DELIBERATE CORRECTION, it would trip No other open PR may claim the same single-writer path, and it would ask a person for a second countersignature on the same fragment. ⛔ A rule applied into a collision is not the stricter reading, it is a worse outcome.
• The blast radius is unchanged either way: one file, one paragraph, +3 / −3.

⛔ What the countersigner is being asked to confirm — stated plainly

Four corrections, each quoted old-and-new in the PR body, ⛔ not two. Two of them were named by card #19735; two were found by the round and are in their own subsection so nothing is silent. ⚠️ If you prefer the card's exact two, reverting (3) and (4) is one commit and the PR has not left draft — say so and it happens. ⭐ This seat recommends keeping all four, for the reasons above, and the recommendation is ⛔ not a substitute for your decision.

Recorded, ⛔ not filed

「a dispatch order can widen a round's scope past os-dev.md:41 without either side noticing, and the gap gets filled by an invented citation」 is a seat-protocol lesson, ⛔ not one of the three filing classes. It goes to this seat's round report and seat post rather than to a new card — 三类外 ⛔ 不立卡. The concrete remedy is a line in this seat's dispatch template restating 范围 = 这张 issue verbatim instead of paraphrasing it.

---

Generated by Claude Code

[os-support-ai]

Served-tier: 142/142 CONTRACT_REVIEW_TIER (seat-measured, 2026-09-22T20:52Z)
Head-sha: fbb8952

Contract-review record — PR #19747 (Fixes #19735), .changeset/18605-enable-on-install-one-authority.md

Tier control. origin/main:scripts/pm/dispatch-gates.mjs:12282 reads, verbatim: export const CONTRACT_REVIEW_TIER = 'claude-fable-5-1'; (read 2026-09-22T20:36:42Z at c120dbdf). This subagent's own model self-report is not admissible; the served-tier counts on line 1 are the seat's to take from the transcript's per-request harness model stamps. No fallback or overload notice was observed at any point in this run.

Refs (all UTC, 2026-09-22). origin/main = c120dbdfb81743a172622b7aec6d81bb9f2ed9bf (fetched 20:32:07Z). Head fbb8952c3e fetched into an owned ref refs/pr-review/19747-head. Merge base computed = 16d090ede01e8e940313364603a254a659a2355b (unchanged from the round's). Seeding commit 596090efbe7e66ae264a691e40409d0db21805a4 (#19130, 2026-09-20T10:43:07Z). Diff base..head: one row, M .changeset/18605-enable-on-install-one-authority.md, +3 / −3, one commit fbb8952c3e (20:19:00Z). The fragment blob at merge base equals the blob at origin/main (7d8f6bb501) and differs from the seeding blob (2bd6cbd7a2) only by #19627's removal of the api-surface-declarations token on line 27. The shared checkout was never edited; no worktree was registered.

Release window (measured, not repeated). PR #17076 chore: version packages file list, page 3 of the 100-per-page listing (read 20:44:56Z): "filename":".changeset/18605-enable-on-install-one-authority.md","status":"removed","deletions":27. Firing control: sibling .changeset/18058-install-door-contract-rebind.md → "status":"removed" on page 2; dark control (misspelled instal) → 0 across pages 1–3. I did not read the three 335–354 KB page dumps in full; I searched them for these rows only. Every overtaking change also has a pending fragment at origin/main in the same window (18058-…, 18877-install-preserves-lifecycle.md, 19277-in-process-install-honours-enable-on-install.md, 19339-kernel-install-request-describe-honours.md, 19339-package-api-install-door-denial.md, enableoninstall-optional-preserve.md), so this fragment's "now …" sentences publish alongside the changes they describe.

① Derived judgments

Chronology of the instruments (git log origin/main, read 20:37:00Z–20:37:36Z)

• 156792e0a0 fix(spec,runtime): bind the package-install contract to the door that serves, and honour enableOnInstall #18752 (delivers [finding] PackageInstallRequestSchema is a published, route-bound request contract that no layer parses — the install door is declared and enforced nowhere (ADR-0049) #18058), 2026-09-18T05:13Z — the door first honours the key, spelled installDisabled = wrapped && body?.enableOnInstall === false. Never ?? true.
• 4fef271b71 fix(objectql,runtime): a flag-absent install preserves the package's lifecycle state #19291 (delivers [Decision] the package boot seed set is never updated by enable/disable, so a flag-absent re-install durably reverts an operator later enable once #18752 lands — and the obvious producer fix re-opens #18058 F1 pins #18877), 2026-09-20T10:37Z — the door becomes three-state (requestedEnabled === true / === false, no else). Six minutes before seeding.
• 596090efbe spec: one authority for enableOnInstall, and a read-out of its other two declarations #19130, 2026-09-20T10:43Z — seeds the fragment and writes the ?? true wording into two spec doc blocks (package-api.zod.ts:293, package-registry.zod.ts:292) and the fragment.
• 482d584121 fix(metadata-protocol): the in-process install door honours enableOnInstall #19338 (delivers The in-process installPackage door ignores the enableOnInstall its own request schema declares — honour it the way the HTTP door does (successor of #18605, ruling batch #153 item 5 letter 1) #19277), 2026-09-20T12:39Z — MetadataProtocol.installPackage starts honouring the key.
• 7e1b048a1d docs(spec): the kernel install request's enableOnInstall says what the in-process primitive does #19691, 2026-09-22T08:48Z — kernel .describe() rewritten to "honours it on the registry row … absent makes no lifecycle call".
• fb59fb5e37 fix(spec): enableOnInstall becomes optional() so absence survives the parse #19690, 2026-09-22T10:41Z — all three declarations become .optional(); api .describe() rewritten to the three-state form; kernel .describe() rewritten again to "ABSENT keeps the row's current lifecycle state (a fresh install lands enabled)"; the parity test retitled to OPTIONALITY.
• 342808cf5e docs(spec): the api install door doc block says what the in-process primitive does with enableOnInstall #19710, 2026-09-22T14:56Z — api doc block (TSDoc, not .describe()) updated.

Correction (1) — the kernel copy's read behaviour (line 17)

• Old, at seeding: TRUE. 596090efbe:packages/metadata-protocol/src/protocol.ts installPackage (lines 22331–22400) reads request.manifest and request.settings and nothing else — zero hits for enableOnInstall / requestedEnabled in that body; firing control on the same instrument at origin/main: requestedEnabled === true at protocol.ts:22786. The kernel .describe() at seeding (package-registry.zod.ts:325) read "…this protocol primitive does not read it".
• Became false at 482d584121 (the implementation) and 7e1b048a1d (the description).
• New, at origin/main: TRUE. protocol.ts:22785–22792: const requestedEnabled = request.enableOnInstall; if (requestedEnabled === true) {…registry.enablePackage(manifest.id)…} else if (requestedEnabled === false) {…registry.disablePackage(manifest.id)…} and no else branch — === true / === false, absence makes no call. The kernel .describe() at :357 records the honouring. The retained tail of the same sentence (the HTTP door does not forward the key; calls installPackage({ manifest, settings }); flips itself; durable half follows the returned row) is TRUE at both trees: packages/runtime/src/domains/packages.ts:769 / :1045 forwards { manifest, settings: body.settings } only; :819–825 / :1095–1101 are the door's own arms; :867–869 / :1143–1145 write setPackageDisabled(_context?.environmentId, pkgId, pkg?.enabled === false).
• Not true at the seeding tree, by construction: the mechanism it names landed two hours and two days after seeding. Inherent to any correction of an overtaken "now records" sentence; it does not make the published prose false (see ③).
• Precision note, not blocking: "tested === true / === false so absence is never collapsed into either" is a fact about protocol.ts, not text the .describe() carries; the sentence's grammar ("records what this layer does with it: the implementation …") makes it a statement about the implementation, so it is not false.

Correction (2) — "same default" → "same optionality" (line 17)

• Old, at seeding: TRUE — api :320 and kernel :324 both z.boolean().default(true). False since fb59fb5e37: api :432 and kernel :356 are both z.boolean().optional(); the generated reference pages at origin/main (content/docs/references/api/package-api.mdx:498,661, kernel/package-registry.mdx:187, api/protocol.mdx:1913) list the key optional with no default. "Same default" with no default on either side reads as asserting a default that no longer exists.
• New: TRUE at both trees (at seeding both optional-with-default in the input type; at origin/main both .optional()), and mechanically held: origin/main:packages/spec/src/api/package-install-one-authority.test.ts — it('declares the key with the same type and the same OPTIONALITY, not merely the same name') asserts copyOnly is undefined and toBe(authorityOnly), then true / false carried through on the copy; the matrix loop parses exactly PackageInstallRequestSchema and InstallPackageRequestSchema over [absent, false, true, 'false', null] and asserts copy.success === authority.success and equal data. The test exists at both trees (seeding 124 lines, main 207; retitled from "same type and default" by fb59fb5e37). Optionality is the property the pin holds.

Correction (3) — the install door's rule (line 7)

• Old: FALSE WHEN WRITTEN. At 596090efbe:packages/runtime/src/domains/packages.ts:819–825 the door already read const requestedEnabled = wrapped ? body?.enableOnInstall : undefined; if (requestedEnabled === true) {…} else if (requestedEnabled === false) {…} with no else, and its own comment at :811 says "never a ?? default". Before that (fix(spec,runtime): bind the package-install contract to the door that serves, and honour enableOnInstall #18752) the spelling was === false. The ?? true spelling never lived in the door. Controls (git grep -F over packages .changeset docs, 20:38:17Z): at seeding enableOnInstall ?? true → 3 files (fragment + the two spec: one authority for enableOnInstall, and a read-out of its other two declarations #19130 doc blocks), requestedEnabled === true → 1 file (packages.ts:820), dark enableOnInstal ?? true → 0; at origin/main ?? true survives only in prose — the fragment and packages/objectql/src/protocol-install-package-enable-on-install.test.ts:23,188, both comments pinning the card's wording as SPENT (a regression pin, not a live surface).
• New: TRUE at both trees. PATCH /packages/:id/enable and /disable (seeding :878–909, main :1154–1185) call registry.enablePackage / registry.disablePackage — the same verbs the POST arms call; absent ⇒ no call ⇒ "the row the registry returned stands" is exact. The POST handler's flag arms and durable write are byte-identical between seeding and origin/main (region diff with comments stripped: only the fix(runtime): POST /api/v1/packages parses the manifest version leg instead of installing anything it is handed #19326/fix(runtime): POST /api/v1/packages parses the manifest's id leg #19473 id/version parse legs differ).
• The retained (#18058) citation now sits on a rule that [Decision] the package boot seed set is never updated by enable/disable, so a flag-absent re-install durably reverts an operator later enable once #18752 lands — and the obvious producer fix re-opens #18058 F1 pins #18877 (via fix(objectql,runtime): a flag-absent install preserves the package's lifecycle state #19291) established; a citation blemish, not a false statement, since [finding] PackageInstallRequestSchema is a published, route-bound request contract that no layer parses — the install door is declared and enforced nowhere (ADR-0049) #18058 is the change that first made the door honour the key.

Correction (4) — quoting the .describe() string (line 13)

• Old: TRUE at seeding — 596090efbe:packages/spec/src/api/package-api.zod.ts:321 carried exactly "honoured at POST /api/v1/packages: the installed row's enabled is written from this key". Overtaken at fb59fb5e37: origin/main:…:433 reads "honoured at POST /api/v1/packages: true enables the installed row, false disables it, and ABSENT keeps the row's current lifecycle state (a fresh install lands enabled)". Controls: is written from this key → seeding 2 files (fragment + api describe), main 1 file (fragment only); dark is writen from this key → 0 / 0.
• New: TRUE at origin/main — the string names the door and the three states. Not true at seeding (the string then named the door but not three states); the same construction as (1).
• Who prints it: .describe() text is published bytes — the generated JSON schema / dist, and content/docs/references/api/package-api.mdx:498,661, held equal to it by check:docs — not executable logic. Naming the mechanism instead of quoting the string is the right shape for prose that outlives the string.

"No lifecycle call at all" versus "keeps the row's current lifecycle state"

Not the same sentence; they coincide through the registry. packages/objectql/src/registry.ts installPackage lifecycle block (seeding :4203–4217, main :4272–4286, identical): an existing row keeps existing.status / enabled / statusChangedAt; a fresh id gets enabled: !seeded where seeded = this.initialDisabledPackageIds.has(manifest.id). So with no lifecycle call an existing row keeps its state and a fresh row lands enabled unless the boot seed marks it disabled. The fragment states only the code-level claim, in both line 7 and line 17, never the outcome-level one — consistent with itself, and strictly more exact than the .describe() strings' "(a fresh install lands enabled)", which is not exact for a boot-seeded id (flagged in ③; not this PR's file).

Retained passages, spot-checked at source

• Line 5 "declared in three published schemas … each one now says which of the three governs it": exactly three enableOnInstall: z. declarations in packages/spec/src at both trees (api, kernel, marketplace); api describe names the door, kernel describe "whose one authority is api/PackageInstallRequest", marketplace describe "not the platform install-door key (api/PackageInstallRequest)". TRUE at both trees.
• Line 7 past tense "(z.boolean().default(true), same description)": TRUE of seeding (all three .default(true)).
• Line 13 "Its doc block carries the map to the other two": TRUE at both trees.
• Line 19 parity pin: the test and its matrix — TRUE (above). OS_EAGER_SCHEMAS=1 on gen:schema and check:authorable-surface — TRUE (packages/spec/package.json:249,275). The import cycle — TRUE in mechanism: package-api.zod.ts:5 imports InstalledPackageSchema from ../kernel/package-registry.zod, so a PackageInstallRequestSchema.shape.… reference from that file is a cycle. FINDING — a false attribution, false when written. The sentence says the authority "is built from ManifestSchema and InstalledPackageSchema, both declared in kernel/package-registry.zod.ts". At both trees ManifestSchema is declared in kernel/manifest.zod.ts (:244 seeding, :317 main, export const ManifestSchema = strictObject({); package-api.zod.ts:9 imports it from ../kernel/manifest.zod; package-registry.zod.ts:4 merely imports it (import { ManifestSchema } from './manifest.zod'). The fragment restates the kernel doc block's own error ("both declared here", package-registry.zod.ts:313–314 seeding / :345–346 main). The PR lists this paragraph as re-derived and standing; on this clause it does not. Remedy is one clause in the same file: kernel/manifest.zod.ts for ManifestSchema, kernel/package-registry.zod.ts for InstalledPackageSchema (the edge that closes the cycle).
• Line 23 marketplace: MarketplaceInstallRequestSchema fields listingId, version, licenseKey, settings, enableOnInstall, artifactRef, tenantId at both trees; describe "the marketplace channel's own install option, not the platform install-door key" at both. The control-plane door POST /api/v1/marketplace/install is outside this repo (zero hits outside the doc block, as expected for the control plane's surface). The runtime side is packages/cloud-connection/src/marketplace-proxy-plugin.ts, which serves GET / HEAD only and return next() for every other method (:292–294) — "read-only proxy" TRUE.
• Line 27 "no default changes … api-surface, authorable-surface and authorable-defaults are all unchanged": scoped to [finding] enableOnInstall is declared in three schemas and honoured by no handler — an author sets it and the runtime silently ignores it #18605's own change; spec: one authority for enableOnInstall, and a read-out of its other two declarations #19130's file list (git show --stat 596090efbe) is describe / doc text, four generated reference pages and the new test — no baseline moved. TRUE of that change.

Internal consistency after the edit

Lines 7 (past-tense .default(true)), 17 ("same optionality") and 27 ("no default changes", scoped to #18605) read consistently as a dated record of one change plus present-tense statements of the release-time state; the two ABSENT statements (lines 7 and 17) are the same code-level claim; nothing in the four corrections contradicts a retained sentence. The one residual inconsistency in the fragment is the line-19 attribution above, which this PR did not introduce.

The clause-② reading and the lane rule

The path limb (packages/spec/src/**) does not fire: the diff is .changeset-only. This review exists by the lane rule (C6; the card is domain:spec). Line 9 of the fragment is #19130's clause-② declaration (reading yes, justified on line 27 as the conservative arm because three published descriptions' stated meaning moved); it is not this branch's. This branch's own declaration no is correct at head: no key, type, default, accept set or refusal moves — three lines of prose in one fragment.

② Semver level

Header at head line 2, at merge base and at seeding: "@objectstack/spec": minor — verified at source; the claim's and the card's patch were input errors, as the round recorded. What #19130 shipped is describe text on three keys, doc blocks, generated pages and a test — nothing additive on the public surface — so under route 1's "WHICH LEVEL" rule patch would satisfy and minor over-declares, which that rule permits ("may raise a bump but never lower it below what the act requires"). The sibling 19339-* fragments declare patch for the same class and enableoninstall-optional-preserve.md (#19690, the change that actually removed the defaults) declares minor. The four corrections describe mechanisms shipped by other fragments and change nothing about what #19130 shipped, so they move the required level in neither direction. minor stands; not a finding.

③ Boundary flags

• Check Changeset red is expected — route 0 at origin/main:.github/workflows/pr-automation.yml:714–748: every .changeset row M, none A ⇒ DELIBERATE CORRECTION; "do NOT apply 'skip-changeset' … LEAVE THIS CHECK RED". Head check-runs, newest per name, read at 20:42Z, 20:44:23Z, 20:44:56Z, 20:46:45Z and finally 20:50:09Z: at the final reading 26 runs, all completed — Check Changeset failure (completed 20:30:41Z, the route-0 red); Type Check · workspace success (completed 20:47:36Z; it was in_progress and therefore NOT MEASURED at the four earlier readings); the late-appearing TypeScript Type Check success (20:47:44Z); the other 23 success or path-filtered skipped. No check is red for any other reason, and no cell is left unmeasured. The route-0 written confirmation is on the PR; the countersignature is a human act, which the seat has already said it cannot supply.
• Retained false attribution on line 19 (the finding above) — the only item that moves the verdict; a one-clause remedy in this PR, which is the sole non-colliding carrier for the fragment in the open window (a second open PR on the same path is route 0's COLLISION class and trips No other open PR may claim the same single-writer path).
• The PR's "date-neutral" claim is narrower than "true at both trees". It says the replacements "stay true at origin/main and at publication alike" — accurate for all four. Tested against the seeding tree: (2) and (3) are true there too; (1) and (4) are not and cannot be, since they name mechanisms that landed at 482d584121 / 7e1b048a1d and fb59fb5e37. Not a defect in the published prose; recorded so no re-measurer reads it as drift.
• The PR body's history sentence was overstated ("git log --all -S finds the string in no source file") — the seat already corrected it; confirmed at source: ?? true sat in two spec doc blocks at seeding (package-api.zod.ts:293, package-registry.zod.ts:292), published bytes rather than logic. The load-bearing claim (the door never spelled it) is confirmed independently at fix(spec,runtime): bind the package-install contract to the door that serves, and honour enableOnInstall #18752 and fix(objectql,runtime): a flag-absent install preserves the package's lifecycle state #19291.
• Sibling fragment, same defect class as (4), not this PR's file: .changeset/19339-kernel-install-request-describe-honours.md:13 quotes the kernel .describe() as "…absent makes no lifecycle call", which fb59fb5e37 rewrote to "ABSENT keeps the row's current lifecycle state (a fresh install lands enabled)". A carrier is owed (a card), not this PR.
• Published .describe() nuance, not this PR's file: both live strings say "(a fresh install lands enabled)"; the registry lands a fresh id enabled: !seeded, so a boot-seeded-disabled id lands disabled. Low severity; spec-lane carrier.
• Stale source comments, out of scope: the comment above the requestedEnabled arms in both protocol.ts and packages.ts still says "The declaration's own .default(true) never reaches here" — there is no .default(true) since fb59fb5e37. Noted for the seat.
• Line-number drift the round reported is confirmed substance-identical at c120dbdf: arms protocol.ts:22785–22792, api declaration :432–433, kernel :356–357.
• One dead probe in this review is disclosed: my first control pass used the pathspec packages/*/src, which git matches against the whole path, so its zeros were unmeasured; every control above was re-taken with directory pathspecs (20:38:17Z) and the firing controls then fired.

Implemented-by: claude/issue-19735-18605-changeset-false-sentences
Reviewed-by: session_013RDBh5DqXd2xnLwvHLgLFr
VERDICT: FAIL — the four corrections are each correct at source, but the fragment as this PR leaves it still publishes one false retained sentence (line 19 attributes ManifestSchema's declaration to kernel/package-registry.zod.ts; it is declared in kernel/manifest.zod.ts at both trees), and this PR is the only non-colliding carrier that can amend it before changeset version runs.

---

Tier control — measured by the SEAT from the reviewer's transcript, ⛔ not reported by the reviewer

The reviewer declined to count itself, which is right: a self-description is not a reading, and get_session measures the dispatching session rather than the subagent. So the seat counted the harness's own per-request stamps in the subagent's transcript, ⛔ without loading the file.

• 142 assistant requests, 142 stamped claude-fable-5-1 — every per-request "message":{"model":…}, no exceptions.
• 328/328 on the superset: 186 "model" plus 142 "advisorModel", all the same value.
• Dark control: empty. Filtering every "model" / "advisorModel" occurrence for anything other than claude-fable-5-1 returns nothing.
• Fallback / overload sweep: 21 keyword hits, ⛔ none of them a notice. Read in context: tool-schema prose (get_session's own description of fallbacks, an unrelated title field), the dispatch order's sentence telling the reviewer to report a notice if it saw one, and the reviewer's own sentence saying it saw none. ⛔ No platform notice fired.
• CONTRACT_REVIEW_TIER re-read at source: origin/main:scripts/pm/dispatch-gates.mjs — export const CONTRACT_REVIEW_TIER = 'claude-fable-5-1';

⚠️ This record is adopted verbatim, FAIL and all. ⛔ A seat does not rewrite, soften or re-verdict a subagent's ruling — it adopts it whole or voids it whole. The seat's disposition of the FAIL is a separate comment and is ⛔ not part of this record.

---

Generated by Claude Code

[os-support-ai]

Seat disposition of the FAIL — the finding is CONFIRMED, and ⛔ its root is NOT on this PR's surface

Written by the domain:spec execution seat 1 (session_013RDBh5DqXd2xnLwvHLgLFr) at 2026-09-22T20:53Z, on the at-tier record 5783979248. That record is adopted whole; this comment is the seat's disposition of it and is ⛔ not part of the ruling.

The four corrections all PASS at source. The FAIL rests on one pre-existing, retained sentence the round declared it had 「re-derived and it stands」 — and it does not.

Confirmed by the seat, independently, at both trees

Line 19 of the fragment says the authority is built from ManifestSchema and InstalledPackageSchema, 「both declared in kernel/package-registry.zod.ts」. Measured at 2026-09-22T20:53Z:

reading	origin/main	seeding 596090efbe
ManifestSchema declared at	packages/spec/src/kernel/manifest.zod.ts:317	…/manifest.zod.ts:244
in package-registry.zod.ts it is	:4 — import { ManifestSchema } from './manifest.zod';	same
InstalledPackageSchema declared at	package-registry.zod.ts:55	—

⇒ 「both」 is wrong: one of the two is declared there, the other is imported. And it was wrong at the seeding tree as well, so this is false-when-written, ⛔ not overtaken. Dark control: ManifestSchemaa ⇒ 0.

⭐ But the root is a live error in SHIPPED SOURCE, and that changes what to do

The fragment did not invent the sentence — it copied one. packages/spec/src/kernel/package-registry.zod.ts, the doc block above enableOnInstall, at origin/main:

PackageInstallRequestSchema sits ABOVE this module in the import graph — it is built from ManifestSchema and InstalledPackageSchema, both
declared here — so a reference from here up to it is an import cycle.

The identical wording sits at the seeding commit (:313–:314). ⇒ the same false statement is in a packages/spec/src/** file that ships in the tarball, where an author or an AI reads it.

⚠️ The block's conclusion is NOT wrong and ⛔ must not be "fixed" away. The cycle is real through InstalledPackageSchema alone, and the block's ⛔ directive — 「Do not "fix" this into PackageInstallRequestSchema.shape.enableOnInstall」 — stands. What is wrong is one clause of the stated reason.

⛔ The seat does not widen a fifth time, and the reviewer's own premise is why

The record's remedy is 「one clause in the same file, and this PR is the only non-colliding carrier」. That premise is true of the copy and ⛔ false of the root: the root is in packages/spec/src/kernel/package-registry.zod.ts, not on any .changeset path — nothing collides there, no second route-0 PR is implied, and it is a surface where the clause-② path limb actually fires. So the collision argument that justified keeping corrections (3) and (4) does ⛔ not carry over to this one.

And twenty minutes ago this seat posted 5783702012, correcting the record because a round had widened past origin/main:.claude/agents/os-dev.md:41 (「范围 = 这张 issue,别无其它。」) on an authority that does not exist. ⛔ Widening a fifth time now, on a reviewer's recommendation, would be the same act with a better-dressed justification. The seat is not doing it on its own judgement.

⇒ What happens instead

1. A card is filed for the source doc block — its own defect, its own surface, ⛔ not a rider on this PR.
2. The fifth correction is put to the countersigner as part of the one decision already owed, rather than slipped in. ⇒ ⛔ authorized, not invented.

⛔ What the countersigner is being asked, stated plainly

This PR corrects four statements, and the at-tier review finds all four correct at source. It also finds a fifth false sentence — pre-existing, retained, measured above — which this PR does not touch, and the review's verdict is FAIL for that reason alone.

Three ways forward, and ⛔ this seat is not choosing for you:

• A — confirm the four as they stand. The fifth ships into packages/spec/CHANGELOG.md and is corrected later at its root. ⚠️ Costs: a false attribution published once.
• B — say the word and the fifth is corrected here too, one clause on line 19, same file, same commit. ⇒ five corrections confirmed knowingly, nothing ships false, and the source-side root is still fixed by its own card.
• C — revert (3) and (4) to the card's exact two. ⛔ This seat recommends against it and said why in 5783702012: (3) publishes a rule the maintainer ruled against.

⭐ This seat's recommendation is B, and the recommendation is ⛔ not a substitute for your decision. The PR has not left draft; Check Changeset stays deliberately red either way; and nothing here is armed for auto-merge.

⏱️ chore: version packages (PR #17076) is open and carries removed .changeset/18605-enable-on-install-one-authority.md. Whichever lands first decides what ships.

---

Generated by Claude Code

[os-support-ai]

Maintainer instruction — skip-changeset applied and this PR sent to the merge queue, overriding ruling D for this PR

domain:spec execution seat 1 (session_013RDBh5DqXd2xnLwvHLgLFr, seat post #6017), 2026-09-23T07:06Z. The seat acts on the maintainer's instruction, with provenance:

• Who: the maintainer, in this seat's own session.
• Words, verbatim: 「立卡更新我的决裁,这两个你直接打标签跟进合并。」
• Where: the chat of session_013RDBh5DqXd2xnLwvHLgLFr, replying to this seat's report that docs(changeset): correct two false mechanism claims in a pending connector-ledger note #19746 and docs(changeset): correct four statements in the pending enableOnInstall one-authority note #19747 were red only on Check Changeset (route 0, ruling D on [finding] the skip-changeset label suppresses the DELIBERATE-CORRECTION refusal whose own text says 「no label and no diff shape makes that safe」 — declared contract against enforced behaviour #18375).

⇒ The two PRs are #19746 and #19747. This PR gets skip-changeset despite ruling D (batch #158 item 1, which says the label is never applied to a PR that edits an existing changeset), and the seat takes it through the merge queue. The ruling itself is being updated on its own card, filed in the same act.

This lands as option A of the three-way choice at 5783988676: the four corrections as reviewed. The at-tier record at this head (5783979248) is a FAIL for one reason only: a fifth, pre-existing sentence on line 19 (「both declared in kernel/package-registry.zod.ts」 — ManifestSchema is imported there, not declared). That FAIL was the question put to the maintainer, and 「直接…跟进合并」 answers it. ⇒ the fifth sentence ships as it stands and is corrected at its root in shipped source by #19748. ⛔ No new round on this PR.

Nothing else changes: the head stays as reviewed, the queue runs every required check, and the seat verifies the landing by content on origin/main after merge.

---

Generated by Claude Code

[os-support-ai]

Confirmation of record (ruling D ② B) — replaces the label route

domain:spec execution seat 1 (session_013RDBh5DqXd2xnLwvHLgLFr), 2026-09-23T07:14Z, carrying the maintainer's words with provenance:

• Who / where: the maintainer, in the chat of session_013RDBh5DqXd2xnLwvHLgLFr.
• Words, verbatim, in order: 「立卡更新我的决裁,这两个你直接打标签跟进合并。」, then choosing the seat's option 甲 for ruling D: 「甲、维持现状。 用聊天里一句话确认,」
• What is confirmed: the pending note .changeset/18605-enable-on-install-one-authority.md, and what this PR changes under it: four statements corrected (+3 / −3), all four verified at source by the at-tier review (5783979248). This is option A of 5783988676. The fifth, pre-existing sentence on line 19 (「both declared in kernel/package-registry.zod.ts」; ManifestSchema is imported there) ships as it stands, and its root in shipped source is [finding] the shipped enableOnInstall doc block says ManifestSchema and InstalledPackageSchema are "both declared here" — ManifestSchema is declared in kernel/manifest.zod.ts, and a pending changeset already copied the error #19748.

⇒ Ruling D stands. The confirmation is this chat sentence, carried here. skip-changeset is removed from this PR: it was applied on the first instruction and is withdrawn under the second, so Check Changeset goes back to advisory red by design. It is not a required context, so it blocks nothing. The PR stays in the merge queue. The provenance comment 5790573062 is superseded on the label; everything else in it stands.

---

Generated by Claude Code