Skip to content

packages: an admin cannot disable a type:module sub-package of an installed app (422 WRITABLE_PACKAGE_REQUIRED), and a disabled package's nav contributions stay in the app #28117

Open
Open
packages: an admin cannot disable a type:module sub-package of an installed app (422 WRITABLE_PACKAGE_REQUIRED), and a disabled package's nav contributions stay in the app#28117
Labels
area:devpathThe road — create, dev, verify, publish/install, connect an agent, iteratedomain:serverDomain lane — seat card indexed by label:pm:seatenhancementNew feature or requestneeds-user-decisionpriority:p2Medium: important, M3

Description

@objectstack-fleet
objectstack-fleet
bot
opened on Oct 30, 2026

coordinator#1 · os-sales · session_01L6bhgV5XwfXsVDMWfbUvBv

Filing gate: ③ ordered by the maintainer. Ruling thread, 2026-10-30, quoted verbatim (not translated):

2026-10-29 14:48Z: 暂时不考虑夸仓的这种。大包 + 设置里启用模块 你继续帮我调研分析。
2026-10-30 13:05Z: 同意
2026-10-30 13:07Z (on the optional organization-scope step): 可选第三步：组织级范围。不需要

The 13:05Z 「同意」 answers the analysis "the customer always installs one suite, and enables modules in settings" (project analysis of 2026-10-29, read on origin/main eef83734): plan A (platform-level hard switch), with the three defaults: (1) the customer's own admin switches modules on and off; (2) scope stays per environment, as today; (3) "disabled" has exactly ONE meaning = hidden + refused on the data plane + data kept. Organization-level scope: ruled not needed (13:07Z) — no card, no backlog entry.

Business reason: a suite (HotCRM) ships as ONE artifact with several type: module packages (ADR-0019 D3, ADR-0130 D2/D6). A customer who does not use a module wants it gone from their apps, and today nobody can do that: the disable door refuses every installed or code-booted package, so a suite module can never be switched off. Without this, "enable modules in settings" has no platform mechanism, and suites are pushed back toward separate artifacts (cross-repo dependencies, ruled deferred on #25805).
Reader who acts: the server lane (runtime + objectql), one PR; the docs/adr/** line is Tier H (maintainer approves).
Dedupe (open AND closed): semantic searches "disable module sub-package installed app WRITABLE_PACKAGE_REQUIRED", "suite module enable disable nav contributions disabled package": 3 hits (#24813, #24062, #24030), all closed and about OTHER doors of the same gate; #7560 is the gate this card narrows. 0 open duplicates.

Back-link: #7560 (the gate), #25805 (ruled D) · ⛔ Not a claim.

Today (origin/main b6c2ed9c)

Expected

  1. Disable door. A package may be disabled by an admin with manage_metadata when it is manifest.type: 'module' AND it belongs to an installed type: 'app' package (same artifact / same namespace — the dev MEASURES which tie the registry actually carries for a suite installed both ways, marketplace install and code boot, and pins both). Everything else keeps answering 422 WRITABLE_PACKAGE_REQUIRED exactly as today: the app package itself, platform packages, plugin / driver / other types, and a module whose app is not installed. The exemption covers DISABLE only: edit, publish, revert, delete, overwrite stay refused on the module (it is still read-only for authoring, ADR-0070 D2).
  2. Nav. applyNavContributions drops contributions whose packageId is disabled, on every read path that folds them (registry helpers and the protocol app read). Re-enable restores them.
  3. Flows. Record-change triggers bound to a disabled package's objects: the dev measures first; if they still fire, they stop while the package is disabled and resume on enable, in this PR. If they already stop, a pin only.
  4. Served verdict. The Console must not re-derive the rule ([Decision] OS_METADATA_WRITABLE unlocks a write on a read-only package while Studio renders a "Read-only" badge — which one is telling the truth? #8146: one answer to the question). The row carries the server's answer to "may this package be disabled here?" next to writable. If that needs a new key in package-api-assembled.zod.ts, that key is a spec-lane edit: report it as a fork / Seam before writing it, ⛔ do not overload writable (it means "may author into", and stays false for a module).
  5. Red tests first: module of an installed app disables (200) and its objects 404 OBJECT_PACKAGE_DISABLED, its nav items gone; re-enable restores both; app package, platform package, plugin, and an orphan module still 422; disable survives restart (state file).
  6. ADR-0070 D2: one addendum line — "a type: module sub-package of an installed app may be disabled (not authored into) by an admin; ruling 2026-10-30". docs/adr/** is Tier H: governed PR, the maintainer approves.

Not in scope (ruled)

Linked

  • Console half: the ui card filed alongside this one (the existing Packages page gets the toggle for these rows), Blocked-by: this card.
  • HotCRM: hotcrm#2270 (modules organised inside ONE artifact, each a type: module package) is still the premise on the app side; hotcrm#2271 (revenue as a standalone artifact) is shelved by this direction. Neither card is edited here.

Generated by Claude Code

Activity

  1. objectstack-fleet
    added
    enhancementNew feature or request
    priority:p2Medium: important, M3
    pm:queue
    area:devpathThe road — create, dev, verify, publish/install, connect an agent, iterate
    domain:serverDomain lane — seat card indexed by label:pm:seat
    on Oct 30, 2026

  2. objectstack-fleet commented on Oct 30, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Oct 30, 2026
    ContributorAuthor

    coordinator#1 · os-sales · session_01L6bhgV5XwfXsVDMWfbUvBv

    Scope addendum (part of the ruling record above; the dispatch order repeats it).

    1. App-side references to a disabled module are the app's to tolerate. When a module is disabled, the app package's hooks, actions and dashboard tiles that read or write that module's objects meet the platform's existing refusal. The platform keeps answering 404 OBJECT_PACKAGE_DISABLED on the data plane and the by-name read. ⛔ This PR does not soften that answer (no empty result, no silent skip, no fallback) for any caller, app code included.
    2. Measure and document one path. In the PR, measure what an app hook gets when it reads a disabled module's object through api.object() (the error shape and code a hook's try sees), pin it in a test, and write it into the package-lifecycle docs, so an app author knows what to catch.

    Why: the HotCRM read (objectstack-ai/hotcrm main a598256, read-only) shows the real dependency picture. The suite is ONE artifact with four packages: app.objectstack.hotcrm (type: app, namespace crm) and three type: module packages (…hotcrm.service, …hotcrm.revenue, …hotcrm.marketing). Each module declares dependencies: { 'app.objectstack.hotcrm': '^6.0.0' } and contributes its nav through navigationContributions. That manifest dependency on the installed app package is a measured candidate for this card's "belongs to an installed app" tie; the dev still measures both install paths. The app package ALSO references module objects in code: 3 lookups, 4 hooks (for example event.hook.ts writes crm_case, contact.hook.ts counts crm_quote), 3 actions that call module flows, 1 dashboard tile on a revenue dataset. Making those tolerate a disabled module is a separate HotCRM-lane card. It will be filed once the maintainer agrees, and it is not this card's work.

    Generated by Claude Code

  3. objectstack-fleet
    added
    pm:dispatched
    and removed
    pm:queue
    on Oct 31, 2026
  4. objectstack-fleet
    assigned
    os-project-manager
    on Oct 31, 2026

  5. objectstack-fleet commented on Oct 31, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Oct 31, 2026
    ContributorAuthor

    domain:server#2 · os-project-manager · session_0186vfjHHMsRXC9EUT9hTFMo

    Claim: PM loop round 1 · card thread · 2026-10-31T03:03Z
    Session: session_0186vfjHHMsRXC9EUT9hTFMo (the seat); the card thread is session_01FEkQ5otJRNvRGLG91cCJr7
    Account: os-project-manager (the seat's linked user; the card's assignee)
    Branch: claude/project-thread-omgm6f (the card thread's harness-pinned branch; it names no issue, so this claim is the identity record)
    Worktree: the card thread's own container checkout
    Domain: domain:server
    Seat: domain:server#2
    Ruling-ref: the maintainer's words quoted in this card's body (「大包 + 设置里启用模块」, 「同意」, 「…组织级范围。不需要」: plan A, one meaning of "disabled") and the scope addendum 6523684730; filing gate ③ (ordered by the maintainer).
    File surface:

    State: pm:queue → pm:dispatched, assigned to os-project-manager (label write at 02:59Z), recorded by this claim.

    Generated by Claude Code

  6. os-project-manager
    added a commit that references this issue on Oct 31, 2026

    test(trigger-record-change): type the #28117 block's slot lookups (ch…

    c403c6b

  7. objectstack-fleet commented on Oct 31, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Oct 31, 2026
    ContributorAuthor

    domain:server#2 · os-project-manager · session_01FEkQ5otJRNvRGLG91cCJr7
    os-dev-report
    {
    "issue": 28117,
    "status": "done",
    "branch": "claude/project-thread-omgm6f",
    "pr": "#28308",
    "session": "session_01FEkQ5otJRNvRGLG91cCJr7 — this card thread (harness Claude-Session line); dispatching seat session_0186vfjHHMsRXC9EUT9hTFMo",
    "premise_still_valid": true,
    "summary": "Premise held on origin/main 69ce01d: the disable door asked requireWritablePackage alone (422 for every suite module, measured on both install paths) and applyNavContributions folded disabled packages' contributions. Item 1: PATCH /packages/:id/disable now reads isDisableableAppModule first (runtime packages.ts): manifest.type 'module', manifest.dependencies DIRECTLY naming an installed package of manifest.type 'app', own scope not system/cloud. isWritablePackage is unchanged, so writable stays false and edit/publish/delete still 422 (pinned). The tie, measured: code boot (AppPlugin) and marketplace install (manifest.register source marketplace) leave the same row keys (type, dependencies, namespace); ArtifactInstallScope.packageIds is not persisted, so the declared dependency is the carried tie. Item 2: applyNavContributions skips a disabled package's contributions before the group lookup; one fold serves getApp, getAllApps and the protocol app list/by-name reads; enable restores with nothing cached. Item 3: measured first, a record-change flow on a disabled package's object DID fire for an in-process write (base red: stamp 'done'); RecordChangeTrigger now withholds dispatch when engine.registry.isObjectPackageDisabled(object), the write itself untouched. Item 4: the served verdict needs a new SERVED_ROW_VERDICTS key in package-api-assembled.zod.ts: NOT written, reported as Seam (see out_of_scope_findings); writable not overloaded. Addendum: an app hook's ctx.api.object(moduleObject).find({}) on a disabled module is SERVED the kept rows, no error (engine ScopedContext, not the data plane); pinned and written into the marketplace handbook; this contradicts the addendum's expectation that app code meets the refusal, so it is open_questions[0]. Item 6 (docs/adr) untouched, seat follow-up #28285. Clause-2: yes (widening), Metadata-protocol: none, one patch changeset for runtime, objectql, trigger-record-change.",
    "tests": "Red first on base 69ce01d, then green at HEAD. (1) packages/runtime/src/domains/packages-disable-app-module.test.ts (new; real ObjectKernel + MetadataPlugin + ObjectQLPlugin + AppPlugin + SqlDriver better-sqlite3 :memory:, through HttpDispatcher.dispatch; suite composed with composeStacks manifest preserve; booted per install path code and marketplace): base 6 failed / 20 passed (both 'disables the module (200)' answered 422; restart and hook measurement fail at their disable step), HEAD 26/26 passed. Cases: row tie, enabled control, disable 200 + GET /data/qs_order 404 OBJECT_PACKAGE_DISABLED + nav gone on GET /meta/app/qs_app and registry.getApp, edit/publish/delete 422 WRITABLE_PACKAGE_REQUIRED, enable restores data (kept record) and nav, seven still-422 packages (app, plugin, module of a plugin, orphan module, module of an absent app, system-scoped module of the app, system-scoped plugin), restart over the state file (disabled after reboot, enabled after enable + reboot), addendum hook measurement ([{ rows: 1 }] in-process vs 404 on the data plane). (2) packages/objectql/src/registry-nav-contribution-disabled-package.test.ts (new, real SchemaRegistry): base 4 failed / 7 passed, HEAD 11/11. (3) trigger-record-change record-change-integration.test.ts new [#28117] block (real kernel ObjectQL + automation + trigger + SQLite): base 1 failed ('a flow on a disabled package's object fired: expected done to be null') / 1 passed, HEAD 2/2. | Ablations via scripts/ablation-replace.mjs under the lock, each suite reads the mutated file from src (no build between): door 'const readOnly = isDisableableAppModule(qlService, id)' -> 'false && ...' blob 53825564f8bb -> e14712be2677: 4 failed / 22 passed; nav --delete 'if (this.isPackageDisabled(c.packageId)) continue;' blob 0d8ee0e6b325 -> 4629981b5d26: 4 failed / 7 passed; trigger 'if (written && ...' -> 'if (written && false && ...' blob 9ce4a4d903d3 -> a08bcd2662b8: 1 failed / 1 passed; every restore blob == HEAD, git diff HEAD empty. | Package suites at 9808a8f (lock VERDICT command-exit 0): objectql 501 files / 9761 passed; trigger-record-change 11 files / 116 passed; runtime 488 files / 7932 passed, 19 skipped. Trigger file again at c403c6b: 11/11. typecheck on the three packages exit 0 (tsc + test programs). eslint --no-inline-config on the six touched files exit 0.",
    "gates": "Final head c403c6b: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 93 commands; all 93 run, all exit 0, captured before any pipe (check-plugin-teardown-shape --self-test after git fetch --depth=1 origin 621a487). --ran: '93 derived famil(ies) accounted for — 93 run, 0 NOT-MEASURED'. At the first head 9808a8f check:slot-lookup was exit 1 (new trigger test block, erasure count 11 -> 13); c403c6b types the lookups and it holds. Scoped lint exit 0. CI check-runs on PR #28308 at report time: 23 listed, 3 completed (skipped: packed-tarball smoke, schedule gate, 18.x upgrade harness), 19 in_progress, 1 queued; left to the seat.",
    "dogfood_battery": "n/a — no ! in the PR title and no (narrowing) arm",
    "mcp_calls": "3 — mcp__github__issue_read (get #28117; get_comments #28117 twice). No MCP write tool.",
    "api_writes": "2 — relay pr_create (fleet-write run 41167267388, PR #28308, read-back identical, assignees none, labels none: a changeset ships so no skip-changeset); relay comment of this report on #28117 (post-stamped). git push x2 to claude/project-thread-omgm6f is not a REST write. Reads only: gh api pulls?state=open and each PR's /files twice for the overlap check (21 open PRs, none touch packages.ts, registry.ts, package-writability.ts, record-change-trigger.ts or the handbook).",
    "open_questions": [
    {
    "question": "status: needs_decision — An app's own hook reading or writing a DISABLED module's object in-process (ctx.api.object(name), measured: find returns the kept rows, a write lands) is not refused; only the data plane and the by-name reads refuse with 404 OBJECT_PACKAGE_DISABLED. Scope addendum 6523684730 item 1 expected app code to meet that refusal. Should the in-process path be refused too? This PR keeps today's answer (addendum: no softening, and adding a refusal is not on the card), pins it, and documents it.",
    "options": [
    "A — Keep as shipped here: disabled = hidden + refused on the data plane (REST/MCP/by-name) + data kept; in-process engine access is served; record-change flows on the module's objects are withheld (this PR). Cost: none. The HotCRM tolerance card shrinks to UI-side reads (dashboard tile, lookups through the data plane).",
    "B — Refuse app-authored in-process access (a hook's ctx.api, app automation) to a disabled package's object with the same 404 OBJECT_PACKAGE_DISABLED, platform/system code still served. Cost: a new engine-side gate on ScopedContext (medium, objectql), and HotCRM's 4 hooks that touch module objects (e.g. event.hook writes crm_case) then throw while a module is off, so disabling Service breaks event writes until the HotCRM card lands.",
    "C — Refuse at the engine for every caller. Cost: large; reaches seeds, cascade walks, migrations and platform services that resolve a disabled package's objects (package-disable-enforcement.test.ts keeps resolution readers serving on purpose)."
    ],
    "recommendation": "A. Real business need: the measured consumer is HotCRM, whose app hooks write and count module objects; under B or C switching off a module the customer does not use breaks the app's own writes, the opposite of the ruling's goal. Long-term soundness: the ruling's one meaning names the data plane, and A keeps one refusal in one place (the protocol) rather than a second copy in the engine. AI-error axis: A is quieter for an app author (no error in-process), mitigated by the handbook section that says exactly what a hook meets; B is louder but would make an AI-written suite fail at runtime on a switch an admin flips later. Startup focus: A adds no gate (new gates default no); B/C add one with no maintainer naming it. Related, read from source and not measured: a disabled module's own code hooks still run on an in-process write, and its record-change flows bound to an ENABLED package's object still fire; if the maintainer wants a disabled module fully inert in-process, that is one engine/automation card covering all three, not this PR. If this question is routed onto #28117, the PR's 'Fixes #28117' should become 'Part of #28117' before landing."
    }
    ],
    "out_of_scope_findings": [
    "class: b · reach: maintainer (card item 4) · Seam: spec:SERVED_ROW_VERDICTS (packages/spec/src/api/package-api-assembled.zod.ts L155-166, a new served key beside writable, e.g. a may-disable verdict) → runtime:withWritableVerdict (packages/runtime/src/domains/packages.ts, would read isDisableableAppModule) | renderer:PackagesPage.tsx L1054 (writable || !enabled) · evidence: the Console offers Disable only when writable, which stays false for a module, so the server accepts a disable the Console cannot offer · carrier: seat (spec-lane card; the Console card is Blocked-by #28117) · dedupe words: served verdict disable module, SERVED_ROW_VERDICTS disableable, Packages page disable module",
    "carrier: none · noted, not filed (read from source, not measured): a disabled module's own code hooks run on in-process writes to its objects, and its record-change flows on an enabled package's object still fire; recorded in the PR's Acceptance notes and in open_questions[0]"
    ],
    "deviations": "Commit trailers are model-free (Co-authored-by: Claude) per os-dev.md and the pre-push hook, not the harness's model-named line. PR opened without assignees per the order."
    }

    Generated by Claude Code

  8. objectstack-fleet commented on Oct 31, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Oct 31, 2026
    ContributorAuthor

    domain:server#2 · os-project-manager · session_0186vfjHHMsRXC9EUT9hTFMo

    待裁：模块被停用后，应用自己的 hook 在进程内读写它的对象 —— 要不要也拒绝

    domain:server 席位 2 · 2026-10-31T04:21Z · 来源：dev 报告 6538834934（needs_decision，前提成立）· PR #28308（head c403c6bd，在飞草稿，席位准备以 Part of #28117 落地）。

    一句话问题： 客户管理员把套件里一个不用的模块关掉后，浏览器、API、MCP 读它的对象都答 404（模块“不存在”），但套件自己的代码（应用包的 hook）在服务器内部照样读得到、写得进这个模块的数据。补充说明 6523684730 第 1 条原以为应用代码也会撞上同一个拒绝；实测没有。要定的是：“停用”对套件自己的代码算不算数。

    背景与 Governing text

    Governing text: 本卡正文引用的裁决记录（方案 A，三条默认，「"disabled" has exactly ONE meaning = hidden + refused on the data plane + data kept」）；补充说明 6523684730 第 1、2 条；packages/objectql/src/package-disable-enforcement.test.ts 文件头（#7557 (A) 的两类读者）；ADR-0016 §9.5；SKILL.md〈升级与决策〉「新增门禁默认否」。

    前提（实测于 PR #28308 head c403c6bd，真实内核 + SQLite；HotCRM 读于 main 94646738，只读）

    1. 模块经门停用后，应用包的 afterInsert hook 里 ctx.api.object('qs_order').find({}) 拿到保留的记录（[{ rows: 1 }]，无错误）；同一窗口 GET /data/qs_order 答 404 OBJECT_PACKAGE_DISABLED。re-check：pnpm --filter @objectstack/runtime exec vitest run src/domains/packages-disable-app-module.test.ts -t "addendum"；grep -n "isObjectPackageDisabled\|PackageDisabled" packages/objectql/src/engine.ts（预期 0 行）。
    2. “进程内写入落地”是在触发器集成测试里以引擎直接 insert 实测的（记录写入、流程不盖章），不是经 hook 的 ctx.api 写；按代码 ObjectRepository 直转 engine.update/insert，同一条路。re-check：pnpm --filter @objectstack/trigger-record-change exec vitest run src/record-change-integration.test.ts -t "28117"；sed -n 21775,21777p packages/objectql/src/engine.ts。
    3. HotCRM 应用包（src/sales，type: 'app'）里触碰模块对象的 hook 是 6 个文件，不是补充说明与 dev 所说的 4 个：event.hook.ts、task.hook.ts（crm_case，service 模块）；contact.hook.ts、account.hook.ts（crm_quote / crm_contract，revenue 模块）；opportunity.campaign-metrics.hook.ts、lead.campaign-metrics.hook.ts（crm_campaign / crm_campaign_member，marketing 模块）。其中 event.hook.ts 与 task.hook.ts 的 crm_case 读写都包在 try/catch 里（注释「never break the event write」）；contact.hook.ts 的 beforeDelete 计数、account.hook.ts 的 beforeDelete 计数、两个 campaign-metrics hook 的读写没有 try/catch。re-check：grep -n "crm_case\|crm_quote\|crm_contract\|crm_campaign" /home/claude/hotcrm/src/sales/objects/*.hook.ts；grep -rln "name: 'crm_case'" /home/claude/hotcrm/src --include=*.object.ts（预期 src/service/...）；sed -n 240,262p /home/claude/hotcrm/src/sales/objects/event.hook.ts。
    4. ScopedContext 已有 appAuthored 标记（engine.ts L21762，Security: a runAs system hook or an action script body reaches the four identity-assignment objects past the delegated-administration gate (the #25251 refusal requires flowRunId) #25653 用于 sudo() 的来源标记），B 的“只拒应用代码”在结构上可做，但今天没有任何读取按这个标记拒绝。re-check：grep -n "private appAuthored\|appAutomationElevationOf" packages/objectql/src/engine.ts。
    5. Package disable and uninstall never reach the metadata/data layer: a disabled package's objects still serve rows, and uninstall leaves 7 orphaned sys_metadata rows #7557 (A) 的控制组仍在：解析读者对停用包的对象继续服务，测试名「after disable: API readers stop, resolution readers keep serving」。re-check：grep -n "resolution readers keep serving" packages/objectql/src/package-disable-enforcement.test.ts。

    选项 × 真实代价 × 工作量

    选项 做什么 客户可感知后果 工作量
    A 维持 PR #28308 所钉：停用 = 隐藏 + 数据面/按名读取/MCP 拒绝 + 数据保留；进程内（应用 hook 的 ctx.api、服务、级联）照常服务；停用模块对象上的记录触发流程不派发（本 PR）；手册已写明 hook 不会撞到 OBJECT_PACKAGE_DISABLED 关掉模块后套件自己的代码不报错；已知的奇怪处：联系人若在已隐藏的 Revenue 里有未结报价，删除仍被 hook 以“有 1 张未结报价”拒绝，用户看不到那张报价（数据保留的诚实后果，启用即恢复） 平台 0 · HotCRM 容错卡缩到界面侧读取（仪表盘 revenue 数据集一块、经数据面的 3 个 lookup）
    B 引擎加一道门：带 appAuthored 标记的 ScopedContext 读写停用包的对象，答同一个 404 OBJECT_PACKAGE_DISABLED；平台/系统代码仍服务；手册改写，本 PR 的钉子翻转 实测代码下：关 Revenue 后删除联系人、删除客户在 beforeDelete 里抛 404（无 try/catch）；关 Marketing 后带活动的线索/商机保存抛 404；关 Service 后事件、任务不坏（有 try/catch）。HotCRM 的 6 个 hook 改完前，关模块等于把应用自己的删除与保存弄坏 objectql 车道 · 1 PR · M · 最近先例：本 PR 的触发器判断（record-change-trigger.ts +21 行，按包状态停手）；HotCRM 车道 · 1 PR · 6 个 hook · 无先例
    C 引擎对所有调用方拒绝停用包的对象 关 Revenue 后删除客户时级联到 crm_contract（主从级联）失败；迁移、种子、跨包解析都撞 404；推翻 #7557 (A) 已钉的控制组 objectql 车道 · 1–2 PR · L · 无先例（#7557 走的是反方向）

    业务含义直译

    • A： 把一个部门的门牌摘了、对外不接待，但公司内部的流程还能进去取档案、存档案，档案一张不丢。
    • B： 门牌摘了之后，连本公司的员工也不许进；没改流程之前，涉及那个部门的审批会在半路报错。
    • C： 整层楼封死，连物业、搬家、消防检查也进不去。

    四维分析（业务立场）

    • ① 长远合理性（领起）： 两年后，“停用”的平台样子应当是：对客户的用户和任何外部客户端，模块不存在；对套件自己的代码，模块是一份仍在、仍可用、只是不对外的系统资源 —— 因为裁决定的是“数据保留”，而不是“数据冻结”。主流平台正是这样建模：Salesforce 的 Apex 以系统模式运行，不受把对象从界面与 API 上藏起来的对象权限约束；Odoo 没有“停用”，只有卸载且连数据一起删。A 维持“一个拒绝、一个落点”（协议数据面），复用 Package disable and uninstall never reach the metadata/data layer: a disabled package's objects still serve rows, and uninstall leaves 7 orphaned sys_metadata rows #7557 (A) 的两类读者划分，不增特例。B 在引擎里引入第三类读者“应用写的进程内代码”，让引擎按调用方来源给不同答案，这是一条新的、只为停用而生的特例，而且与 Package disable and uninstall never reach the metadata/data layer: a disabled package's objects still serve rows, and uninstall leaves 7 orphaned sys_metadata rows #7557 (A) 把解析读者当控制组的裁决相背。C 直接推翻那条控制组，把级联、迁移、种子一并拖进去。
    • ② 业务拉动： 今天谁会撞上？唯一实测的消费者是 HotCRM：应用包 6 个 hook 文件读写模块对象（前提 3）。A 下一个也不坏；补充说明预告的 HotCRM 容错卡缩到界面侧。B 下按实测代码：关 Revenue，联系人与客户的删除在 beforeDelete 计数处抛 404；关 Marketing，带活动的线索/商机保存抛 404；dev 举的例子「event.hook writes crm_case … disabling Service breaks event writes」不成立，那段在 try/catch 里。没有任何客户或维护者要求“套件自己的代码也要被拒”；补充说明第 1 条是一个被实测推翻的假定，不是一条拉动。
    • ③ 防 AI 犯错： 出错时谁看到什么。A：AI 写的 hook 在模块停用时不会收到任何信号，继续读写被隐藏的数据 —— 静默，但后果有界：数据保留、流程不派发（本 PR）、启用即恢复；手册“What your app's own code meets”一段写明了这一点，作者有处可查。B：响亮，但响在错误的读者面前 —— 不是 hook 的作者，而是半年后被管理员一个开关弄坏删除功能的终端用户，看到的是 beforeDelete 里冒出来的 404 OBJECT_PACKAGE_DISABLED；AI 写的套件在测试里全绿，上线后才坏。C 同 B 且范围更大。防错轴在这里不翻字母：响亮拒绝优于静默容忍的前提是拒绝落在作者的编译/发布时或请求的门口，B 落在运行期的客户侧。
    • ④ 不扩散： A 不加门禁。B、C 各加一道引擎门禁，没有维护者点名（裁决原话只有「hidden + refused on the data plane + data kept」；补充说明是 Sales 席位写的范围说明），按「新增门禁默认否」荐不加。B 还多出一个 HotCRM 车道的 6 处改动才能让客户安全地关模块。

    推荐：A。 只看①选 A；②③④ 是否翻转：否。不取 B：为停用在引擎里新增一类按调用方来源的拒绝，和 #7557 (A) 钉住的“解析读者继续服务”相背，且在 HotCRM 的 6 个 hook 改完之前，关一个模块会弄坏应用自己的删除与保存，与裁决“客户不用的模块可以关掉”的目的相反。不取 C：范围更大，级联删除、迁移、种子一并失败，推翻已钉的控制组。需要明知的代价：A 下应用代码仍会向被隐藏的模块写数据（如 event.hook 给 crm_case 盖 first_response_date），这些写入没有流程、没有界面，只在启用后可见；联系人删除可能被一张看不见的报价挡住。置信缺口：其一，停用模块自己的代码 hook 在进程内写入时仍运行、它绑在已启用包对象上的记录触发流程仍派发（dev 读自源码，未实测）—— 若维护者要“停用模块在进程内完全静止”，那是一张覆盖这三处的引擎/自动化卡，不在本问题里；其二，HotCRM 3 个调用模块流程的 action 在模块停用后撞到什么，未测，归 HotCRM 容错卡。

    裁后执行

    os-decision-facets
    ① 长远：停用 = 对外不存在、对套件自己的代码仍是系统资源（Salesforce Apex 系统模式类比）；A 一个拒绝一个落点，复用 #7557 (A) 两类读者；B 加第三类“按调用方来源”的读者，C 推翻已钉控制组
    ② 拉动：唯一实测消费者 HotCRM，应用包 6 个 hook 读写模块对象；A 零破坏；B 下关 Revenue 删联系人/客户抛 404、关 Marketing 带活动的保存抛 404；无人要求套件自己的代码被拒
    ③ 防错：A 静默但有界（数据保留、流程不派发、手册写明）；B 响亮在错误的读者面前 —— 终端用户在运行期撞 404，AI 写的套件测试全绿上线才坏
    ④ 不扩散：A 不加门禁；B/C 各加一道引擎门禁且无维护者点名，B 再加 HotCRM 6 处改动
    Prior rulings read: disabled package object in-process hook ctx.api engine served refused OBJECT_PACKAGE_DISABLED → 11 hits (nearest #25296, #25308: /actions 门拒绝停用包的动作，落在公开门；#7557 (A) 两类读者，钉在 package-disable-enforcement.test.ts；#24097/#24210 按名读取；none rules the in-process path); disabled package flows actions hooks still run in-process engine automation inert → 38 hits (nearest #27395 卸载后流程仍可触发、#20677 账本停用流程重启再武装，皆为自动化账本侧，none rules the engine read path); ADR-0016 §9.5, ADR-0141 open item 4; thread: 6523684730

    Analysis-tier: fable

    Generated by Claude Code

  9. objectstack-fleet commented on Oct 31, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Oct 31, 2026
    ContributorAuthor

    domain:server#2 · os-project-manager · session_0186vfjHHMsRXC9EUT9hTFMo

    Landing record · #28117 · PR #28308

    domain:server seat 2 · session_0186vfjHHMsRXC9EUT9hTFMo · 2026-10-31T05:24Z

    Reading Probe Result
    Queue membership git ls-remote origin 'refs/heads/gh-readonly-queue/main/pr-28308-*' 0 refs (released)
    Ancestry git merge-base --is-ancestor 7abe151b origin/main yes
    Content git grep -c isDisableableAppModule origin/main -- packages/runtime/src/domains/packages.ts 4 hits

    Release: claim 6538161407 (session_0186vfjHHMsRXC9EUT9hTFMo, card thread session_01FEkQ5otJRNvRGLG91cCJr7, branch claude/project-thread-omgm6f) · into the decision box.

    • State: pm:dispatched → needs-user-decision, assignee cleared. Under letter A the card closes with a ruling record. Under B or C a fresh claim and order follow.
    • Resume-from: main at 7abe151b or later.

    Generated by Claude Code

  10. objectstack-fleet
    added
    needs-user-decision
    and removed
    pm:dispatched
    on Oct 31, 2026
  11. objectstack-fleet
    unassigned
    os-project-manager
    on Oct 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:devpathThe road — create, dev, verify, publish/install, connect an agent, iteratedomain:serverDomain lane — seat card indexed by label:pm:seatenhancementNew feature or requestneeds-user-decisionpriority:p2Medium: important, M3

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions