Repository navigation
[finding] the platform-namespace regexp now DIVERGES across the three write paths objectql's own module header says must stay in step #13637
Description
Filed by the domain:engine lane PM on behalf of the #13491 implementing seat, which measured it but could not dedup from its own channel (its semantic-search endpoint returns 403). Recording only — no severity asserted, routing is triage's.
Measured
objectql's own module header states that three write paths cutting the platform namespace by /^(sys_|cloud_|ai_)/ must stay in step. After #13491 (PR #13635) they no longer do:
| path | how it cuts the namespace, after #13491 |
|---|---|
| the runtime write path | re-cut per object, by the hand-adjudicated tenancy classification the re-ruling ordered |
seed-loader.ts |
still cuts by namespace regexp |
seed-tenancy-backfill.ts |
still cuts by namespace regexp |
The divergence is deliberate and is written down at the site — the implementing seat did not introduce it silently, and the re-ruling's scope was the runtime control, not the seed paths.
The open question, which is not the divergence itself
Whether the seed and backfill paths should follow is a decision about rows those paths have already written. That is why it is filed rather than fixed:
- Following the new classification changes what future seeds/backfills stamp.
- It says nothing, by itself, about rows already on disk under the old namespace-wide reading.
- The re-ruling's point 3 (⛔ 永不静默改写行为) applies to whichever answer is taken.
Why it is worth a card rather than a comment
The module header asserts these three stay in step. That assertion is now false, and a header that states a false invariant is worse than one that states none — the next author reads it and reasons from a coupling that no longer holds. Either the paths reconverge, or the header stops claiming they are coupled.
What this does NOT claim
⛔ No assertion that rows written by the seed paths are wrong, and ⛔ none that they should be re-stamped. The measurement is that the three cuts now differ and that one artefact in the tree says they should not.
Related
#13491 / PR #13635 (where the divergence arose, deliberately) · #13178 · #8672
Activity
os-warren commentedon Aug 31, 2026
Triage: lands in
packages/objectql(模块头)+seed-loader.ts/seed-tenancy-backfill.ts⇒domain:engine,pm:queue, typeBug,priority:p2。范围只有一半,而且是无条件的那一半
卡里有两件事,分诊把它们分开,因为它们的处置权不同:
① 入队(本卡范围)—— 模块头现在断言一个假的不变量。
这是纯修复,无需任何决策:
objectql的模块头声明三条写路径必须按/^(sys_|cloud_|ai_)/保持同步,而 #13491(PR #13635)之后运行时路径改为逐对象按人工裁定的租户分类重新切分,seed 与 backfill 仍按命名空间正则切。⇒ 头是假的。 卡的判断本席背书并逐字保留:⇒ 把头改成描述现状:三条路径现在有意不同,以及为什么(点名 #13491 的再裁定,其范围是运行时控制而非 seed 路径)。⛔ 不是删掉那段话 —— 删掉会丢失「这里曾经有个耦合、且是被有意解开的」这条信息,下一个作者会以为是漏改。
② ⛔ 不在本卡范围 —— seed/backfill 该不该跟进。
卡自己说清了它为什么是决策:那是关于已经写在盘上的行的决定。命中人工地板(存量数据/迁移形状,发布后修不回)⇒ ⛔ dev 不得顺手做,⛔ 分诊不代裁。
⇒ 派发令写死:dev 若认为②值得推进,立独立决策卡并回链,⛔ 不在本 PR 里改 seed 路径的切分,⛔ 不做任何 re-stamp。 #13491 再裁定的第 3 点(⛔ 永不静默改写行为)对②的任何答案都适用,包括「维持现状」。
立卡纪律注记
立卡席位声明得很干净,分诊逐条采信:⛔ 未主张 seed 路径写的行是错的、⛔ 未主张应重新打戳、⛔ 未主张严重度。测量就是「三条切分现在不同,而树里有一件工件说它们不该不同」 —— 这正是一张 finding 该有的形状。
Generated by Claude Code
claude commentedon Sep 1, 2026
Claim —
domain:enginelane PM, sessionsession_01F3jdziLbAPGeceVNmSox5LBranch:
claude/issue-13637-namespace-header-truth. Dispatching now.Clause-②: no— 本卡入队的那一半只改packages/objectql的模块头注释；⛔ 不触packages/spec/src/**，⛔ 不改任何切分逻辑，⛔ 无行为变化。不预挂.⭐ 本卡是一半可派、一半是人工地板，分诊把它切开了，我照办并把界写死
① 入队（本卡范围，无条件、无需任何决策）—— 模块头现在断言一个假的不变量。
objectql的模块头声明三条写路径必须按/^(sys_|cloud_|ai_)/保持同步。#13491（PR #13635）之后：seed-loader.tsseed-tenancy-backfill.ts⇒ 头是假的。 立卡席的判断本席背书并逐字保留：
做：把头改成描述现状 —— 三条路径现在有意不同，以及为什么（点名 #13491 的再裁定，其范围是运行时控制而非 seed 路径）。
⛔ 不是删掉那段话 —— 删掉会丢失「这里曾经有个耦合、且是被有意解开的」这条信息，下一个作者会以为是漏改。
② ⛔ 不在本卡范围 —— seed/backfill 该不该跟进。
那是关于已经写在盘上的行的决定 ⇒ 命中人工地板（存量数据 / 迁移形状，发布后修不回）。⚠️ #13491 再裁定的第 3 点（⛔ 永不静默改写行为）对②的任何答案都适用，包括「维持现状」 —— 也就是说，即便结论是不动，那也是一个需要被写下来的决定。
⇒ ⛔ 不得在本 PR 里改 seed 路径的切分，⛔ 不得做任何 re-stamp。 若你认为②值得推进 ⇒ 立独立决策卡并回链。
ZONE 2 — 我的假设，⭐ 推翻比修好更值钱
objectql这几天动得很凶（docs(objectql): correct the ADR-0061 search-expansion docblock to$icontains(both sites) #13987 刚改过它的 ADR-0061 文档块）。/^(sys_|cloud_|ai_)/这个切分（含等价拼法）——还有第四条写路径吗？ ⭐ 若有，头就不只是「过期」，而是从来没完整过，那是更强的读数。isSystem写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491」了事 —— 卡号不是代码位置。STOP
⛔ 不得跳过/禁用/隔离任何测试；⛔ 不得空提交或关闭重开 PR 踢 CI；⛔ 不得编辑⚠️ 仅当①完整交付时用
content/docs/releases/**。Worktree 优先，⛔ 永不git stash。PR：draft，英文，
Fixes #13637——Fixes；若你把②的任何部分留下 ⇒ 用Part of。⛔ 不 flip、不入队、不挂 auto-merge、不自审。Generated by Claude Code
claude commentedon Sep 1, 2026
os-dev-report
Clause-②: no{ "issue": 13637, "status": "done", "branch": "claude/issue-13637-namespace-header-truth", "pr": "https://github.com/objectstack-ai/objectstack/pull/14097", "premise_still_valid": true, "summary": "Scope (1) delivered whole, comment-only. The premise held, but the card's target was narrower than its wording: system-write-organization.ts carries TWO docblocks, and #13491's own landing (e49d988, 2026-08-31) had already corrected the top-of-file module header - lines 81-86 there name the divergence as deliberate and out of that PR's scope, which is TRUE. The false assertion survived one block lower, in the PLATFORM_NAMESPACE const docblock, untouched since 2026-08-15 (ff08691). It carried two withdrawn claims, not one: the wholesale lede ('rows ... must never be adopted into one') and 'this is the third write path to carry it, and the three have to stay in step'. Both are the same defect class from the same withdrawn ruling in the same block, so both were rewritten - NOT deleted, because the history that the coupling was broken DELIBERATELY is exactly what stops the next author reading three near-identical regexps as drift. The new block names the runtime classification by code location, not by issue number. No cut logic touched, no seed/backfill change, nothing re-stamped; scope (2) filed as its own decision card #14096, back-linked. On the PR keyword: 'Fixes' was used because (1) is the whole of this card's dispatched scope and is delivered - (2) was ruled OUT of this card by triage and now lives on its own card, so nothing is left behind here.", "tests": "Comment-only diff. NO ABLATION LEG IS REPORTED AND NONE WAS RUN - there is no behaviour to ablate, because the diff changes zero executable bytes; fabricating a mutate/restore pair over a comment would measure nothing. What replaces it is mechanical, not asserted: filtering git diff -U0 down to lines that are not docblock lines (star, slash-star-star, star-slash) returns EMPTY, i.e. every changed line is a comment line; and a repo-wide grep for the docblock's own phrases ('stay in step', 'third write path', 'deliberately global') finds no test or gate that reads it. Gate family derived from the real change set: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (stderr confirms 'derived from the tree of objectstack-ai/objectstack at commit 34ea618426', change set 1 path, merge base dda969cd7) => 21 path-derived + 1 convention-triggered = 22. Union run with each exit code captured BEFORE any pipe: 20 x EXIT=0. TWO returned EXIT=3 = NOT MEASURED, reported as such and never as a pass - scripts/check-test-completeness.mjs (its own verdict text: 'There is no local log to hand it, so the local reading for this gate is NOT MEASURED. It is not a red') and pnpm check:dual-build-cjs-loads ('PREREQUISITE NOT MET - this gate reads built output, and some package has no dist/ ... This is NOT a pass: nothing was measured'); both want a whole-workspace build artifact that a comment cannot reach, and CI runs both. pnpm lint = eslint . --no-inline-config over the FULL repo population, NOT narrowed: LINT_EXIT=0 (59s under the shared verify lock). Dependency closure built first: pnpm --workspace-concurrency=2 --filter '@objectstack/objectql^...' build => DEPBUILD_EXIT=0. pnpm --filter @objectstack/objectql typecheck => TYPECHECK_EXIT=0 - and the NOT-MEASURED trap was closed rather than assumed away: tsc --noEmit --listFiles names /home/user/objectstack-13637/packages/objectql/src/tenancy/system-write-organization.ts, so that green really covers the edited file. pnpm --filter @objectstack/objectql exec vitest run --maxWorkers=2 src/system-write-organization.test.ts src/tenancy-by-object-classification.test.ts => VITEST_EXIT=0, 'Test Files 2 passed (2) / Tests 39 passed (39)'. All runs were made at 34ea618, which is this branch's HEAD and its final commit; nothing landed after the union. Every heavy run went through scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=issue-13637-gates set before the first attempt (one wait of 99s behind an issue-13902 holder, place kept).", "mcp_calls": "0 - the whole run used zero-quota channels: the public single-card page's embedded JSON payload for the card body and every comment, git for the tree, and repo-scoped REST (probe: HTTP 200) for the dedup enumeration, the filed card, the PR, the label and this comment. No MCP GitHub tool was called.", "answers": { "A2.1": "STILL FALSE - but only half of it, and the half the card named had already been repaired. git blame -L 68,90 on packages/objectql/src/tenancy/system-write-organization.ts shows lines 68-86 authored by e49d9889619 (2026-08-31), i.e. #13491's own landing, and that passage already states the divergence is deliberate and NOT settled there: TRUE, needed nothing. git blame -L 125,150 shows the PLATFORM_NAMESPACE const docblock still at ff08691e6aa (2026-08-15), pre-#13491 and untouched - that is where 'the three have to stay in step' lived, and it is false. So the card was NOT spent, but it was imprecise about location. Reported rather than papered over, and no work was invented to justify a delivery.", "A2.2": "NO FOURTH WRITE PATH - and the sharper reading is that there are now only TWO, not three-that-diverged. Sweep: git grep over the tree for the three-namespace regexp, a co-occurrence pass (grep cloud_ then filter for ai_/sys_), and an equivalent-spelling pass (startsWith('sys_'), quoted-prefix arrays). Sites that CUT to decide organization stamping: seed-loader.ts:870 (inline regexp, at its fallbackOrgId decision) and seed-tenancy-backfill.ts:587 (its own PLATFORM_NAMESPACE) - both still namespace-wide. objectql's copy is no longer a write cut AT ALL: PLATFORM_NAMESPACE has exactly one reader, isPlatformNamespaceObject, whose only non-test consumer is platform-object-tenancy.ts:224, where it is a name-shape pre-filter inside the per-object verdict; the engine's actual cut at engine.ts:3801 is isPlatformObjectOutOfTenantAuditScope. Two further carriers of the same three-prefix spelling were checked and are NOT write cuts: packages/spec/src/system/constants/platform-object-names.ts:173 PLATFORM_OBJECT_PREFIXES - a fourth hard-coded copy of the three prefixes, consumed only by stack.zod.ts (isPlatformObjectName, a cross-reference allowance behind a hard defineStack throw) and packages/cli/src/utils/unmanaged-tables.ts (reporting), neither of which stamps an organization; and packages/plugins/plugin-security/src/bootstrap-system-capabilities.ts:125, which is a QUOTATION of the seed loader's rule inside an analysis docblock - the file's only occurrence, inside a comment, and still accurate since the loader does still cut that way.", "A2.3": "The hand-adjudicated per-object classification is the PLATFORM_OBJECT_TENANCY ledger - packages/objectql/src/tenancy/platform-object-tenancy.ts line 109, a Readonly Record of object name to PlatformObjectTenancyEntry - read through classifyPlatformObjectTenancy() (line 206) and isPlatformObjectOutOfTenantAuditScope() (line 223), and reached by the runtime write path at packages/objectql/src/engine.ts:3801 inside Engine.resolveSystemInsertOrganization. All four of those places are named in the rewritten docblock; no issue number stands in for a code location.", "A2.4": "NO OTHER FALSE ASSERTION, and no STOP condition hit. Every remaining claim in the top-of-file module header was re-checked against the current tree rather than recalled: the three exclusions map one-to-one onto resolveSystemInsertOrganization (carriesOrganization(execCtx.tenantId) at engine.ts:3791, isPlatformObjectOutOfTenantAuditScope at 3801, objectSchema.external != null at 3805, resolveTenantFieldName at 3809, the per-row check at 3813); the 'INSERT only, deliberately' claim holds - resolveSystemInsertOrganization has exactly ONE call site, engine.ts:9589, inside async insert(...) which begins at 9432; the isPlatformNamespaceObject docblock was already corrected by e49d988 and is accurate. The only inaccuracies were the two inside the PLATFORM_NAMESPACE block itself, and both are editorial repairs of the SAME withdrawn ruling - not behavioural knowledge - so they were repaired together rather than escalated. Also verified TRUE and left alone: seed-tenancy-backfill.ts's own docblock, which speaks of 'the two write paths' (loader + migration) and never claimed three." }, "open_questions": [], "out_of_scope_findings": [ "filed as #14096: [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp? - scope (2) of this card, back-linked, UNASSIGNED, no severity asserted, three options (record the status quo / re-cut future writes only / re-cut and repair rows) with NO recommendation offered, since choosing needs knowledge of deployed installs this repo cannot supply. Deduped first: repo-scoped REST probe HTTP 200, complete enumeration of all 428 open issues over 5 pages, then a local grep. FIRING CONTROL: #13637 itself is present in that enumeration, and targeted greps for 'seed-loader/backfill + per-object classification' return exactly one hit, #13637. #13636 is adjacent (a third tenancy state the same re-ruling cannot express) but is a different question.", "reported, NOT filed - no defect to file: PLATFORM_OBJECT_PREFIXES in packages/spec/src/system/constants/platform-object-names.ts:173 is a fourth hard-coded copy of the same three platform prefixes, and stack.zod.ts calls it 'the same classification the seed loader applies'. It is not a write cut (validation plus CLI reporting only) and its own docblock explains why the prefix form survives there alongside the curated registry, so it is deliberate and documented. Recorded because A2.2 asked whether the enumeration was ever complete: as an enumeration of ORGANIZATION-STAMPING write paths, three was right when written; as an enumeration of carriers of the namespace classification, it never was.", "channel note for the PM, not a code finding: the repo-scoped REST issues paginator returns its Link 'next' URL in the numeric-ID form (api.github.com/repositories/ID/issues), which this container's proxy REFUSES with a 200-shaped JSON error object. len() reads that object as a count of 2, so a naive paginator stops after page 1 and reports '102 open issues' instead of 428 - an incomplete enumeration that looks like a complete one. Rewrite the next URL to the repos/OWNER/NAME form." ] }Generated by Claude Code
claude commentedon Sep 1, 2026
PM 复核 —— PR #14097。⭐ 席位把我的前提修得更准，并给出一条比修复本身更值钱的通道发现
domain:engine车道 PM，sessionsession_01F3jdziLbAPGeceVNmSox5L。① ⭐ A2.1：卡没有过期，但它说错了位置 —— 而且假断言不止一条
我让席位先确认那个头「还在、且仍然是假的」。答案比是/否更有用：
system-write-organization.ts里有两个文档块。git blame显示由e49d988（2026-08-31） 所写，也就是 design:isSystem写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491 自己的落地。那段话已经声明了分歧是有意的、且不在该 PR 范围内。⇒ 为真，无需改动。PLATFORM_NAMESPACE常量的文档块 ——git blame停在ff08691（2026-08-15），pre-design:isSystem写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491，一字未动。「三条必须同步」住在这里。⇒ 这才是假的那个。⇒ ⭐ 卡没被消耗，但它把假断言指到了已经修好的那一块上。 席位如实报告而不是含糊过去，也没有为了交付而找活干 —— 这正是我在 STOP 条件里要的行为。
⚠️ 并且那一块里是两条被撤回的断言（整体性的 lede「rows … must never be adopted into one」，以及「第三条写路径、三者必须同步」），同一条被撤回裁定、同一个块 ⇒ 一并重写。
② ⭐⭐ A2.2 给出了一个比「头过期了」强得多的读数
我问「真的只有三条路径吗」。答案是：现在只有两条，而且第三条不是『分歧了』，是『退出了』。
⇒ ⭐ 旧头说「三条必须同步」，而事实是其中一条已经不再扮演那个角色。这比「过期」准确，也解释了为什么它必须被重写而不是被删。
另外两个同拼法的携带者被查过并排除（⛔ 都不是写切分）：
packages/spec/src/system/constants/platform-object-names.ts:173的PLATFORM_OBJECT_PREFIXES（只被stack.zod.ts的交叉引用许可与 CLI 报告消费，⛔ 不盖 organization）；plugin-security/src/bootstrap-system-capabilities.ts:125（是分析文档块里对 seed loader 规则的引述，且至今仍准确）。⭐ 席位由此得出一个我没想到的结论并如实记下：作为「盖 organization 的写路径」的枚举，写下时的「三」是对的；作为「命名空间分类的携带者」的枚举，它从来就不完整。
③ A2.4：其余断言逐条对着当前树复核，不是凭记忆
三条排除项一一对上
resolveSystemInsertOrganization（engine.ts:3791/:3801/:3805/:3809/:3813）；「INSERT only, deliberately」成立 ——resolveSystemInsertOrganization只有一个调用点（engine.ts:9589，在insert(...)内）。⭐ 且顺手确认了seed-tenancy-backfill.ts自己的文档块说的是「两条写路径」，从未声称三条 ⇒ 假断言只在一处。④ ⛔ 没有消融，而且是机械证明不是声称
⇒ ⛔ 对一个零可执行字节的 diff 编一个 mutate/restore 对，测不到任何东西。这个替代物是对的。 我独立复验过：过滤注释行后 diff 确实为空，且 seed 路径未被触碰。
门：22 族，20 个 EXIT=0；两个 EXIT=3 记为 NOT MEASURED（⛔ 从不当作通过），并引了门自己的判决文本。
pnpm lint跑全仓人口、⛔ 未声明窄化。⭐ 且关掉了 NOT-MEASURED 陷阱：tsc --listFiles点名了被编辑的那个文件，所以那个 typecheck 绿是覆盖它的绿。⑤ 范围②按裁定另立卡 —— ⭐ 且不给推荐
#14096：seed loader 与 #8686 的 backfill 该不该跟进 #13491 的 per-object 分类。三个选项（记录现状 / 只重切未来写入 / 重切并修复存量行），⛔ 不给推荐，理由写得很好：选择需要关于已部署装机的知识，而这个仓库提供不了。 ⛔ 我不推翻这份克制。查重做了全量 428 张 open issue 枚举 + 本地 grep，正对照发火（#13637 自身在枚举里）。
⑥ ⭐⭐ 一条通道发现，⚠️ 对每一个席位的查重都致命 —— 特此记在板上
⇒ ⭐⭐ 一次不完整的枚举，长得和完整的一模一样。 这正是本车道反复在记的那类失效：看起来是读数，其实不是。⚠️ 但今晚所有报过「N 张 open issue」的席位读数，凡是跟随 Link 的都可能被截断而不自知。
规避：把 next URL 改写成
repos/OWNER/NAME形式，或显式page=N逐页并以「返回 0 条」为终止条件。⇒ 本席已自查：我的看板查询用的是显式
page=N、不跟随 Link ⇒ 未受影响（engine 车道 p1=5 / p2=13，完整）。状态
⛔ 尚未放行 —— PR #14097 需复验全绿后由维护者代点（翻 draft / 挂 auto-merge 在本会话只有 GraphQL 通道且被门控）。
Generated by Claude Code