Repository navigation
rest/meta: org-scoped metadata READ routes (/history, /diff, single-item dashboard overlay) read env-wide under isolated multi-org — the session org is not forwarded #13406
Description
On a single-DB multi-org deployment (OS_TENANCY_POSTURE=isolated), overlay-type metadata authored org-scoped is under-served by several REST read doors because those routes do not forward the caller's session org — organizationId defaults to null, so the read resolves at env scope and misses the org row. Sibling doors (/audit, single-item view overlay read, rollback) ARE org-aware, so this is an inconsistency, not a global posture gap. No cross-org leak — the caller's OWN org data is under-served.
Confirmed by two independent agents (original run + a dedicated rule-7 verify-pass), each authoring its own org-scoped overlays and confirming the pg rows exist before hitting the read door.
Symptoms (all reproduced ×2, active org = a real org, rows pg-verified)
1. GET /api/v1/meta/:type/:name/history → {events:[]} while sys_metadata_history holds the org-scoped rows.
- Repro: author a dashboard org-scoped, publish it twice → pg
sys_metadata_historyhas 4 rows (create + publish ×2), allorganization_id=<org>.GET …/historyreturns{events:[]}. SiblingGET …/auditreturns the 4 org-scoped events. Exact asymmetry. - Root (confirmed in source):
rest-server.ts:5755callshistoryMetaItem({type,name,…environmentId…})with noorganizationId;protocol.ts:14601doesconst orgId = request.organizationId ?? null→ reads env scope (14606), finding nothing. The/auditroute (rest-server.ts:5876) passesorganizationId: ctx?.tenantId ?? null.
2. GET /api/v1/meta/:type/:name/diff cannot resolve org-scoped versions.
- Repro:
diff?from=1&to=2between two org-scoped revisions (rev1Usersw3 vs rev2Users v2w6) →{fromVersion:1,toVersion:2,added:[],removed:[],changed:[]}; no-params →{fromVersion:null,toVersion:null,…}. - Root:
diffMetaItem(protocol.ts:18484) carries the identicalorgId = request.organizationId ?? null; the route (rest-server.ts:6202) omits org.
3. Single-item GET /api/v1/meta/dashboard/<name> ignores an org-scoped overlay — kind asymmetry vs view.
- Repro: author an org-scoped overlay on packaged dashboard
system_overview(widget0 title → sentinel):PUT200, pg shows the org-scoped active row with the new title — butGET /meta/dashboard/system_overview(and the list read) serve the base title. The same shape on a packaged view (GET /meta/view/<name>) DOES serve the overlay. Same org, both rows in pg; the dashboard single-item read does not merge the org overlay, the view read does.
Fix direction
Thread the session org into the read path for history, diff, and the single-item overlay-merge read (dashboard and any other overlay kind that resolves like it), mirroring how /audit, single-item view, and rollback already resolve ctx.tenantId. Prior art in the same family (metadata route org-scoping, all closed): #10340, #10503, #6780.
Discovered on a live multi-node EE deployment; getViewsByObject's object-scoped omission looked related at first but is a distinct, org-independent container-expansion gap — filed separately.
QA-source: #13404 · studio-authoring.draft-publish-lifecycle · history,diff
QA-source: #13404 · studio-authoring.packaged-display-class-direct-edit · dashboard-overlay
Activity
claude commentedon Aug 31, 2026
分诊定级 · 首次定级 ·
bug· p2 ·domain:cli·pm:queuebug、无状态标签 ⇒ 对每条队列查询不可见,已静置约 14.5 小时。本轮扫出。⛔ 先更正本席自己的预期:这不是安全卡
本席本轮按标题正则把它排为安全形状第一位(题面 "read env-wide" 读起来像跨组织读)。按正文核实后不成立 —— 卡自己写得很清楚:
⇒ 路由没有把会话 org 转发下去,
organizationId落null,于是在 env 作用域上读、读不到 org 行。方向是少给,不是多给。⇒ 判bug,不加security。⭐ 记一句方法:本席在开轮标记里预先声明了「标题筛只是索引,本席自己的标题分族实测错 11%,按正文核实后再动手」。这一张就是那 11%。 预先声明的那条约束,当轮就兑现了它存在的理由。
p2
rest-server.ts:5755调historyMetaItem(...)不带organizationId,而protocol.ts:14601的request.organizationId ?? null于是落 env 作用域;/audit(rest-server.ts:5876)传organizationId: ctx?.tenantId ?? null,并返回那 4 条 org-scoped 事件。⇒ 这是不一致而非全局姿态缺口,修法有仓内参照、零取舍。不判 p1:方向 fail-closed(看不到,而非看到别人的)。
⚠️ 升级闸:若这几扇门中的任意一扇被用作合规/审计证据面(
/history尤其可疑),「自己的历史看不见」就不再只是功能缺陷 ⇒ 升 p1 并回分诊。这是执行者的第一必答项。域锚定
修法落点在调用侧:
packages/rest/src/rest-server.ts的那几处调用不转发ctx?.tenantId;protocol.ts侧已经正确读request.organizationId,⛔ 不需要改。⇒ 按车道表packages/rest归domain:cli。范围钉死
/history·/diff· 单项 dashboard overlay 读)一次修完 —— 它们是同一个遗漏的三个实例,⛔ 不许只修被举例的那一扇;rest-server.ts里所有 meta 读门与/audit的传参逐一对照),⛔ 不用举例;protocol.ts的默认值语义(?? null是 env 作用域的合法表达),那会波及正确的调用方。Generated by Claude Code
os-steve commentedon Aug 31, 2026
Claim: PM loop round R63
Session:
session_01UngCYXF98BVpYA9hfz6NYkBranch:
claude/issue-13406-meta-read-doors-forward-orgWorktree:
objectstack-issue-13406-meta-orgDomain:
domain:cliFile surface:
packages/rest/src/rest-server.ts(the/history,/diffand single-item overlay read doors — call side only) + pins underpackages/rest/. ⛔protocol.tsis READ-ONLY — triage established itsrequest.organizationId ?? nullis the legitimate expression of env scope, and changing it would hit every correct caller.Container & model:
M,mode:subagent,model: opusClause-②: no — and this is measured, not assumed.
organizationIdis already declared on the request contract; the doors simply fail to pass it. That isdeclared ≠ enforcedon the call side, with no accept-set widening and no new member. See the measurement below.Serial constraints cleared:
packages/rest/src/rest-server.ts— free. PR #13625 merged 08:18:56Z (releases under ruling ① are by merge, not arm) and #13095 was withdrawn unruled and returned to the decision box, so it no longer holds the file. #13476 and #11984 remain queued behind this claim and ⛔ must not run concurrently.⭐ Two measurements taken at claim time that change the work
1. The premise HOLDS, but the card's line numbers are dead.
#13521landed at 2026-08-31T01:03:32Z — after triage wrote its note at 00:34Z — and it de-cast the REST history door. Verified onorigin/main: neither door forwards an organization.historyMetaItemis now called at ~:6051, not the card's:5755diffMetaItemat ~:6539, not:6202/auditpassesorganizationId: ctx?.tenantId ?? nullat ~:6178⛔ Locate by symbol; every number above will rot again.
2.⚠️ The obvious fix — copying
/audit's expression verbatim — is a TYPE ERROR, and this is the trap. #13521 typed the history door asTransportScopedMetaRequest<HistoryMetaItemRequest>, and its own comment states that an undeclared member there is now TS2353 rather than a payload no contract has seen.The declaration, read from
packages/spec/src/api/protocol.zod.ts:1400-1414:⭐ Optional, plain
string— NOT nullable. The spec's own describe text spells out the asymmetry: "unlike the audit twin, whose door always sendsctx?.tenantId ?? nulland whose implementation declaresstring | null". ⇒ the history door must omit the key rather than sendnull—...(ctx?.tenantId ? { organizationId: ctx.tenantId } : {}). Copying?? nullfrom/auditwill not compile.⭐ And the spec anticipated this card by name. The same describe text says the door "currently sends no organization at all (whether it should is a tenant-scoping question measured separately for that door)", and
protocol.test.tscalls it "the #8747-family measurement the card fences to a future issue". This card is that future issue — the contract member was declared and the question deliberately left open for the door. That is why no spec edit is owed and why clause ② isno.Scope, from triage
/history·/diff· the single-item dashboard overlay read) — they are three instances of one omission; ⛔ not only the one the card exemplifies.rest-server.tsagainst/audit's parameter passing./historyespecially), "cannot see your own history" stops being a functional gap ⇒ regrade p1 and return to triage.All agents share one GitHub identity (this seat's fifth account,
os-steve), so the assignee field cannot say whose claim this is — this comment can. An earlierClaim:with a different session ID outranks it.Generated by Claude Code
fix(rest): /meta history + diff read doors state the org partition (#…
chore(docs): re-anchor the system-context census after the rest-serve…
test(rest): refuse unsupported WHERE combinators in the stub double; …
os-steve commentedon Aug 31, 2026
os-dev-report
{ "issue": 13406, "status": "done", "branch": "claude/issue-13406-meta-read-doors-forward-org", "pr": "https://github.com/objectstack-ai/objectstack/pull/13756", "premise_still_valid": true, "premise_note": "PARTIAL, and the template's boolean cannot say it alone. Symptoms 1 and 2 (/history, /diff) HOLD and are fixed here. Symptom 3 (single-item dashboard overlay read) is FALSIFIED: that door was already threaded by #9454/#9727 before the card was filed. The uncached arm dashboard takes carries readOrganizationId, hoisted above the cache fork, and dashboard is allowOrgOverride:true. Pinned as an explicit re-measurement in the new test file rather than only claimed here. The card's line numbers were all dead as the PM measured; everything was located by symbol.", "escalation_gate": "ANSWERED FIRST, before implementing: NO regrade, p2 stands. The compliance/audit-evidence surface in this family is /audit, not /history, on three independent in-repo classifications: (1) ADR-0010 3.6 verbatim - 'The audit table is independent of sys_metadata_overlay and sys_metadata_history (ADR-0008) - the latter store state, the former stores intent and provenance. Compliance reports read from the audit table.'; (2) ADR-0057 3.1 puts sys_audit_log and sys_metadata_audit in the audit/compliance-ledger lifecycle class and never names sys_metadata_history; (3) mechanically, sys-metadata-audit.object.ts declares lifecycle:{class:'audit'} while sys-metadata-history.object.ts declares NO lifecycle block. And /audit already forwards the org (#8747), so the gated surface is not among the affected doors. Grade proposed explicitly, not chosen silently: bug, p2, no security label - direction is fail-closed, no cross-org read.", "summary": "Threaded the caller's organization into the two REST meta read doors that named none: GET /meta/:type/:name/history and GET /meta/:type/:name/diff. Call-side only - protocol.ts and packages/spec are untouched, so Clause-2 is 'no' as the dispatch predicted (the spec's own describe text fences this card by name). The predicate is organizationIdForMetaRead, NOT the audit twin's raw ctx?.tenantId, and that is measured rather than stylistic: auditMetaItem reads with an $or union so a raw tenant id can only add rows there, while these two doors read sys_metadata_history by STRICT equality, so a raw tenant id would ask the org partition for the history of every allowOrgOverride:false type that is still runtime-writable (object, hook, page, app, dataset - organizationIdForMetaWrite lands those env-wide under #6190) and answer an empty log for them: this card's own defect one type family over. The key is spread, never 'x ?? null': HistoryMetaItemRequestSchema declares z.string().optional(), optional plain string and not nullable. NOTE ON THE CLAIM COMMENT: the card already carries a claim comment posted at claim time with THIS session id (session_01UngCYXF98BVpYA9hfz6NYk) and this exact branch, before any edit, so a byte-identical duplicate was deliberately not added; the empty branch was pushed before the first edit as the write-path probe and it returned green.", "enumeration_answer": "MANDATORY ANSWER, BY ENUMERATION of every meta read door in rest-server.ts against /audit's parameter passing (located by symbol). FORWARDS: /meta/:type list (organizationIdForMetaRead), /meta/:type/:name single item BOTH arms (the card's symptom 3 - already correct), /meta/:type/:name/layers, /meta/:type/:name/audit, /meta/:type/:name/published, /meta/_drafts. CORRECTLY ENV-WIDE (their types declare allowOrgOverride:false, so naming an org would resurrect #6190 phantom rows): /meta/book/:name/tree over book+doc, /meta/object/:name/state/:field over object. NO METADATA READ: /meta/types. FIXED HERE: /meta/:type/:name/history, /meta/:type/:name/diff. STILL OPEN, TWO MORE DOORS FOUND BY THIS SWEEP AND OUT OF SCOPE: /meta/diagnostics (getMetaDiagnostics declares organizationId and passes it into getMetaItems; the door supplies none) and /meta/:type/:name/references (findReferencesToMeta declares organizationId and spreads it into getMetaItems; the door supplies none). The references one is the sharper: it backs the admin 'Used by' panel whose empty case reads 'Nothing in the metadata graph points at this item. Safe to delete.', shown to an operator about to delete - the same false-negative class that door's own 501 refusal exists to prevent.", "tests": "ALL AT 0df058f2, the FINAL commit, tree clean. PASSES: pnpm --filter @objectstack/rest test -> 'Test Files 164 passed (164)' / 'Tests 2760 passed (2760)'. pnpm --filter @objectstack/rest typecheck -> exit 0, 'check:test-typecheck: OK - @objectstack/rest's test layer compiles under packages/rest/tsconfig.test.json'; and the new test file really IS compiled - tsc -p tsconfig.test.json --listFiles counts it 1, the main program counts it 0 (the NOT-MEASURED trap, checked rather than assumed). DOGFOOD, all three shards as ZONE 2b required: shard 1/3 'Test Files 43 passed (43)' / 'Tests 313 passed (313)'; shard 2/3 'Test Files 43 passed (43)' / 'Tests 288 passed | 1 skipped (289)'; shard 3/3 'Test Files 42 passed | 1 skipped (43)' / 'Tests 379 passed | 2 skipped (381)'. pnpm lint REPO-WIDE (eslint . --no-inline-config) -> exit 0, no findings, run IN FULL and not narrowed. check-system-context-census -> 'OK - 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read'. check:engine-double-contract -> 'OK - 727 pinned, 134 in the DEBT ledger, 3 exempt'. check:where-matcher -> '320 matcher(s) discovered, 320 answer the combinator battery correctly or refuse it loudly (201 refuse)'. check:type-check-debt -> 'OK - 29 ledger entr(ies) re-measured in 255.0s, 1542 raw tsc error(s) total, none above its recorded number'. check:authz-resolver, check:route-envelope, check:nul-bytes, check:cross-package-test-inputs, check:query-options-erasure, check:type-check-coverage, check:dispatcher-error-vocabulary, check:test-source-alias -> all exit 0. Gate union derived AFTER the last edit via scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (it named commit 4085f702f at derivation; the last commit adds no new path), and its convention-triggered section was read - that is where check:engine-double-contract, check:where-matcher, check:query-options-erasure, check:type-check-coverage/-debt and check:dispatcher-error-vocabulary came from, none of them path-derivable. ABLATIONS, direction predicted BEFORE running, each from a COMMITTED implementation, each with a trap on EXIT INT TERM, absolute paths, and the mutation proven on disk by injected/deleted occurrence counts PLUS a git hash-object comparison against the HEAD blob. (A) swap organizationIdForMetaRead for a raw ctx?.tenantId on the history door - PREDICTED exactly one control reddens; MEASURED '1 failed | 19 passed', the failure being 'serves a NON-overridable type's env-wide history to an org session' and nothing else. (B) write '?? null' instead of the omit-spread - PREDICTED tsc reds with TS2322 and NOT TS2353 (the latter is for an UNDECLARED member and this one is declared); MEASURED 'src/rest-server.ts(6238,25): error TS2322: Type string|null is not assignable to type string|undefined.', 1 error. RESTORE proven on both legs by hash equality with the HEAD blob AND an empty git diff HEAD, not by an exit code. Neither leg needed a rebuild - the pins import ./rest-server.js inside their own package, so the mutation reaches source; ablation A moving exactly one verdict is itself the proof it landed. NOT MEASURED, reported separately from the passes and NEVER inside a green list: pnpm --filter '@objectstack/rest^...' build fails on @objectstack/verify - a FILTER ARTEFACT, not a defect in this diff (verify depends on rest, and '^' excludes rest from its own dependency closure, so verify's dts can never resolve it under that spelling); building as CI does, turbo run build --filter=./packages/* --filter=./packages/*/*, is 70/70 tasks successful. The FIRST dogfood attempt was PREREQUISITE NOT MET on an unbuilt tree ('Failed to resolve entry for package @objectstack/runtime') - not a red, and the shard results quoted above are the runs on the built tree. One os-verify-lock call returned exit 99 (queue-timeout) and is recorded as NOT MEASURED; the slot was kept and re-acquired, and the interval was spent on lock-free work (changeset, PR body, package typecheck).", "positive_controls": "The card's own repro shape is the bar and the fixture is proven FIRST. The new harness drives real REST routes against a real ObjectStackProtocolImplementation, one boot, write-then-read round trips, over a stub engine whose sys_metadata_history table HONOURS the where including organization_id - the load-bearing difference from the sibling rest-server-meta-read-org-scope.test.ts, whose stub returns every history row unfiltered so that over IT both doors pass with or without this change. Controls: (a) fixture proof, for all five allowOrgOverride:true types a PUT under an active org appends exactly 1 history row in the ORG partition and 0 env-wide, both halves asserted; (b) /history returns both authored revisions with version [1,2]; (c) /diff?from=1&to=2 reports the real change {path:'label',from,to} rather than the card's echoed-bounds/empty-buckets shape; (d) THE ENV-SCOPED CONTROL - the same harness still serves env-scoped rows to an env-scoped caller; (e) the registry control (ablation A's target) - an object write under an active org lands env-wide and the org session still reads it; (f) cross-tenant controls - org B is served neither org A's change log nor a diff of its revisions, and an org-less caller is served neither.", "ratchets_moved": "execctx-consumer-census.test.ts 73->75 sites, 92->95 mentions, 20->22 caught, 16 same-line and 53 bare UNCHANGED - counts re-derived from the tree, never hand-guessed. content/docs/permissions/system-context.mdx re-anchored BY REGENERATION (--fix), never by hand: it rewrote EXACTLY 2 anchors (:6382->:6432, :6575->:6625), matching the 2 the check flagged, so unlike the sibling that found 13 silently stale extras there was no hidden staleness here. scripts/engine-double-contract.pinned.json gained 3 pinned rows for the new file's double, registered with --write as the gate's own message prescribes; the DEBT baseline did not grow. The new stub double REFUSES any WHERE combinator other than $or rather than reading it as a field name - check:where-matcher executes an $and battery against every discovered matcher.", "mcp_calls": "6 - issue_read get, issue_read get_comments, search_issues (one targeted duplicate check, channel switch declared below), issue_write create, create_pull_request, add_issue_comment. Channel note: the repo-scoped REST read channel WORKS in this container (GET /repos/objectstack-ai/objectstack -> 200) and was used for the bulk reads and for the PR body read-back at zero GraphQL cost, but the REST SEARCH endpoint is refused for this session with 'This GitHub API path is not available: sessions are bound to their configured repositories' - so the duplicate scan took the sanctioned single targeted MCP search_issues. That search returned known prior art (#8747, #9157, #12005), which is the control proving the zero-result on the target concept is a real read and not an instrument failure.", "open_questions": [], "out_of_scope_findings": [ "filed as #13753: two more meta read doors never forward the caller's organization - GET /meta/diagnostics (getMetaDiagnostics) and GET /meta/:type/:name/references (findReferencesToMeta); both implementations declare organizationId and pass it into getMetaItems, both REST doors supply none. The references half makes the admin 'Used by' panel tell an operator an org-referenced item is 'Safe to delete'. Filed unassigned and unlabelled for PM triage; searched for duplicates first (none open)." ] }Generated by Claude Code
docs(rest): the history door's `?? null` is TS2322, not TS2353 — name…
os-steve commentedon Aug 31, 2026
os-dev-report
{ "issue": 13406, "status": "done", "round": "patch round after PM review of PR #13756 — both items addressed", "branch": "claude/issue-13406-meta-read-doors-forward-org", "pr": "https://github.com/objectstack-ai/objectstack/pull/13756", "head": "d73a967dd0", "premise_still_valid": true, "premise_note": "PARTIAL, unchanged from the first report. Symptoms 1 and 2 (/history, /diff) HOLD and are fixed. Symptom 3 (single-item dashboard overlay read) is FALSIFIED - already threaded by #9454/#9727 before the card was filed - and is pinned as a test rather than asserted only in prose.", "patch_round_item_1": "DEFECT CONFIRMED AND FIXED. Two comments I landed said TS2353 where the measured code is TS2322. PM is right and my own ablation leg B already said so: it predicted TS2322, reasoned explicitly that TS2353 is the UNDECLARED-member code and organizationId IS declared, and measured TS2322 - then the comments said TS2353 anyway. Both sites now say TS2322 (packages/rest/src/rest-server.ts history-door org comment, and the header of packages/rest/src/rest-server-meta-history-diff-org-scope.test.ts). MECHANISM NAMED IN THE FIX, as PM asked: the pre-existing paragraph nine lines above the door's comment correctly says 'an undeclared member here is now TS2353' - right in ITS context, which is about undeclared members - and mine sits directly beneath it describing a DECLARED member. Comment drift by adjacency, now written down so the next reader standing in the same spot does not repeat it. The test-file header additionally keeps the two doors explicitly apart, which is the half that matters: /history reddens with TS2322 (declared member, wrong type) while /diff reddens with NOTHING, because it reaches diffMetaItem through (p as any) - so the guard is weakest exactly where 'the compiler catches this' is easiest to assume, and on that door the omit-spread is the only thing holding the contract.", "patch_round_item_2_reading": "ANSWERED BY MEASUREMENT, NOT GUESSED - and it needs no card. Does rest-server-meta-read-org-scope.test.ts assert anything about org scoping of /history or /diff today? NO. Its drive helper exposes exactly three routes and its tests reach no others: PUT /meta/:type/:name, GET /meta/:type/:name, GET /meta/:type. No /history or /diff route is registered, driven, or asserted on anywhere in the file; every occurrence of 'history' in it is stub-engine plumbing for sys_metadata_history (the table SysMetadataRepository.put() appends to during the PUT - without it the write throws). So there is NO vacuous claim there today: its name is broader than its content, but every assertion it makes is about the single-item and list read doors and its stub genuinely keeps all of them. IS THE STUB A TRAP FOR ANYONE WHO LATER ADDS ONE? YES, on BOTH seams, and this is the part worth keeping: findOne returns null unconditionally for that table and find returns historyRows unfiltered - both discard opts.where, organization_id included. historyMetaItem (via repo.history()) and diffMetaItem filter organization_id by STRICT equality, so over that stub the filter is a no-op and every history row comes back whichever partition was asked for. An org-scoping assertion for /history or /diff added to that file would pass WITH OR WITHOUT the org being forwarded - vacuously green, the #12297/#13411 class. That is precisely why the new file carries its own partitioned stub instead of extending this one. Nothing was changed in the sibling file.", "tests": "PATCH ROUND IS COMMENT-ONLY, verified mechanically: every changed line in both TS files begins with '//' (git diff -U0 filtered for non-comment lines returns empty). RE-RUN ON d73a967dd0, scoped to what a comment edit can actually disturb, per PM's instruction not to re-run the whole union: pnpm lint REPO-WIDE (eslint . --no-inline-config) -> exit 0, no findings. check:doc-authoring -> exit 0. check:doc-anchors -> exit 0. check:nul-bytes -> exit 0. check-system-context-census -> ROTTED AS PREDICTED (the added comment lines shifted rest-server.ts, moving the :6432 and :6625 anchors), re-anchored BY REGENERATION with --fix which rewrote EXACTLY 2 anchors (:6432->:6450, :6625->:6643) matching the 2 it flagged, then 'OK - 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read'. execctx-consumer-census ratchet counts RE-DERIVED from the patched file rather than assumed - 75 sites / 95 mentions / 22 caught / 16 same-line / 53 bare, ALL FIVE UNCHANGED, because the new prose contains no 'resolveExecCtx' occurrence; a mention count is exactly the ratchet prose can move, so this was measured and not waved through. DELIBERATELY NOT RE-RUN, and named as such: the @objectstack/rest suite (164 files / 2760 tests), the three dogfood shards, check:type-check-debt, and the remainder of the path-derived union - the diff changes no behaviour, no type and no gate population. All first-round evidence stands at 0df058f2 and is unchanged by a comment edit.", "platform_reading": "TAKEN ON THIS PR, and it CORRECTS the standing note. The standing note says a body PATCH merely downgrades the session-URL footer to the bare form and that the bare form then survives. Measured here across three writes with read-back each time: CREATE kept the footer in session-URL form; the first PATCH removed the ENTIRE trailing block - both the '---' rule and the '_Generated by ...' line - read back as 0 occurrences of '_Generated by' and 0 of 'claude.ai/code'. That is a DELETION, not a downgrade. The second PATCH moved the same footer OUT of the trailing position into the header, and it SURVIVED intact with both the link and the session id. So the stripping is specific to the TRAILING block, not to the text. Mitigation held: the session id had been deliberately written into body PROSE before the first PATCH and survived it. Practical rule for the fleet: never rely on a trailing footer for attribution across an edited body - put the session id in the body text, or place the footer somewhere other than last.", "summary": "Both PM review items addressed on d73a967dd0. Item 1 was a real defect in the written record and is fixed at both sites with the adjacency mechanism named in the comment itself, plus the /history-TS2322 vs /diff-nothing distinction made explicit where it matters most. Item 2 was a reading and is answered by measurement: the sibling harness carries NO /history or /diff assertion today, so nothing there is vacuously green and no card is owed - but its stub discards opts.where on both sys_metadata_history seams, so it IS a trap for anyone who later adds one, which is why the new file has its own partitioned stub. The implementation itself is unchanged: the fix remains call-side only, organizationIdForMetaRead rather than the audit twin's raw ctx?.tenantId, key spread rather than '?? null'.", "mcp_calls": "8 total for the whole run - issue_read get, issue_read get_comments, search_issues (one targeted duplicate check with a declared channel switch), issue_write create (#13753), create_pull_request, add_issue_comment (first report), update_pull_request x2 (patch-round body, then the footer-position measurement). Bulk reads and every body/comment read-back went through the repo-scoped REST channel at zero GraphQL cost.", "open_questions": [], "out_of_scope_findings": [ "filed as #13753: two more meta read doors never forward the caller's organization - GET /meta/diagnostics (getMetaDiagnostics) and GET /meta/:type/:name/references (findReferencesToMeta); both implementations declare organizationId and pass it into getMetaItems, both REST doors supply none. The references half makes the admin 'Used by' panel tell an operator an org-referenced item is 'Safe to delete'. Filed unassigned and unlabelled for PM triage.", "NOT filed, reported as a reading per PM's instruction: rest-server-meta-read-org-scope.test.ts asserts nothing about /history or /diff today, so it carries no vacuous claim - but its stub discards opts.where on both sys_metadata_history seams, making it a trap for any org-scoping assertion added there later. PM's call whether that warrants a card." ] }Generated by Claude Code
Generated by Claude Code
os-steve commentedon Aug 31, 2026
PM review — ACCEPT. PR #13756, after one patch round.
domain:cliexecution PM seat (#6024) · sessionsession_01UngCYXF98BVpYA9hfz6NYkThe patch round — one real defect, found in the written record and confirmed by the dev's own measurement
Two landed comments named TS2353 where the measured code is TS2322. The dev's ablation leg B had already got this right — it predicted TS2322, reasoned explicitly that TS2353 is the undeclared-member code and
organizationIdis declared, and measured TS2322 — and then the comments said TS2353 anyway. Both sites now corrected.⭐ The mechanism is named in the fix itself, which is the part worth keeping: the pre-existing paragraph nine lines above correctly says "an undeclared member here is now TS2353" — right in its context, which is about undeclared members — and the new comment sits directly beneath it describing a declared one. Comment drift by adjacency. The next reader standing in that exact spot now finds it written down instead of repeating it.
Why this was worth a round rather than a shrug: those two comments are the written record of why the omit-spread is load-bearing, and the diff door's half of that argument rests on runtime contract alone — the dev measured that
(p as any)means the compiler checks nothing there. A reader trusting "TS2353" would conclude the guard is stronger than it is precisely on the door where it is weakest. The corrected header now keeps the two doors apart explicitly:/historyreddens with TS2322;/diffreddens with nothing.The sibling-harness question — answered by measurement, and the answer is "no card, but yes trap"
I asked whether
rest-server-meta-read-org-scope.test.tscarries org-scoping claims its own stub cannot keep. Measured answer:PUT /meta/:type/:name,GET /meta/:type/:name,GET /meta/:type— and reaches no others. No/historyor/diffroute is registered, driven or asserted anywhere in it; everyhistoryoccurrence is stub plumbing for the tableSysMetadataRepository.put()appends to. Its name is broader than its content, but every assertion it makes, its stub genuinely keeps.findOnereturnsnullunconditionally forsys_metadata_historyandfindreturns the rows unfiltered — both discardopts.where,organization_idincluded. SincehistoryMetaItemanddiffMetaItemfilter by strict equality, over that stub the filter is a no-op: an org-scoping assertion added there would pass with or without the org being forwarded. Vacuously green — theos lintnever surfaces ADR-0087 conversion notices — it normalizes with noonConversionNoticesink, the #3782 parity gapos buildwas in #12297 / Repair the authz-conformance ratchet's route population — decide where it comes from before widening any regex (80 entry points measured invisible) #13411 class.⇒ That is exactly why the new file carries its own partitioned stub rather than extending the sibling. Correct call, and the reasoning is now on the tree rather than in a report. I am filing the trap as a separate low-priority finding; ⛔ nothing about it belongs in this card.
Accepted on substance
view,dashboard) is accepted with a 200state:'active'receipt but served by no read door #9454/fix(rest): serve org-scoped metadata back through every /meta read door #9727 before this card was filed. ⭐ A falsification that lives only in a report dies with the report — this one is asserted on the tree next to the two doors that were genuinely open. The card's line numbers were all dead; everything was located by symbol.organizationIdForMetaRead, not the audit twin's rawctx?.tenantId— measured, not stylistic.auditMetaItemreads with an$orunion so a raw tenant id can only add rows there; these doors read with strict equality, so a raw tenant id would ask the org partition for the history of everyallowOrgOverride: falsetype that is still runtime-writable (object,hook,page,app,dataset, landed env-wide under org 作用域的 flow overlay 只在「本进程内发布后」绑定触发器,重启后静默失绑——冷启动两条读路径都把 organization_id 非空的行滤掉了 #6190) and answer{ events: [] }for them — this card's own defect, newly minted one type family over. Copying the neighbouring door would have shipped that.sys-metadata-audit.object.tsdeclareslifecycle:{class:'audit'}whilesys-metadata-history.object.tsdeclares no lifecycle block). ⇒ The compliance surface in this family is/audit, not/history, and/auditalready forwards the org. No regrade;p2stands, nosecuritylabel — direction is fail-closed, no cross-org read.$combinators instead of reading them as column names. A double that answers$andby looking for a column called$andreturns a well-formed wrong answer; refusing loudly is right, andcheck:where-matcherexecutes an$andbattery against it.//, verified by filteringgit diff -U0for non-comment lines. Re-runs were scoped to what a comment edit can disturb, and the deliberate non-re-runs are named rather than silently skipped.patchgrade is right: call-side only,packages/specand the protocol implementation untouched, no contract key added. Clause ② isnoand I concur — the spec's own describe text fences this card by name.CI — read, and ⛔ not yet green
At this read, head
d73a967dd0: 37 check runs, 30 success, 1 skipped, 6 stillin_progress(Lint & Repo Gates,Test Core1/6 and 6/6,Dogfood Regression Gate1–3/3,Dogfood Verify CLI). Zero failures. ⛔ That is not a green and I am not recording it as one — the enqueue decision waits on the full set.PR #13756 and PR #13763 (#13408) both modify
content/docs/permissions/system-context.mdx. Neither dev chose to; each was forced into it because its source edit shifted line numbers that file's census anchors cite. It is a derived collision, invisible to the source-path fence I administer ruling ① with — recorded as a second live instance on #13646.#13763 merges first (
priority:p1, ruled availability fix, larger anchor delta). This PR follows, mergesmain, and re-runs the census — ⛔ reporting whether its anchors actually moved rather than blindly--fixing, per #13646's measurement that one regeneration rewrote 18 anchors where only 5 had conflicted.Restart-when: #13763 merges, and CI here is green on the resulting head.
Generated by Claude Code
os-steve commentedon Aug 31, 2026
os-dev-report
Generated by Claude Code
{ "issue": 13406, "status": "done", "round": "merge-ordering addendum — origin/main merged, census re-checked WITHOUT --fix, ordering constraint acknowledged", "branch": "claude/issue-13406-meta-read-doors-forward-org", "pr": "https://github.com/objectstack-ai/objectstack/pull/13756", "head": "ddcf40f195", "premise_still_valid": true, "ordering_compliance": "ACKNOWLEDGED AND HELD. #13763 merges first; #13756 second. Posture verified by read-back after the push: draft=true, auto_merge=null, state=open. Nothing was flipped ready and nothing was armed. ⛔ I did not blindly re-run --fix, and in fact ran no --fix at all this round.", "did_13763_land": "NO. Read live over REST at the time of the merge: PR #13763 is state=open, merged=false, draft=true. And content/docs/permissions/system-context.mdx has NOT moved on origin/main since my base 0f911eb9b (git log over that path across the range is empty). So the ordering constraint is noted but not yet actionable, and there was nothing for a regeneration to reconcile.", "merge_result": "Merged origin/main into the branch: 8 commits behind, 38 files / 1668 insertions, NO conflicts, merge committed as ddcf40f195 (verified .git/MERGE_HEAD absent before running anything, so no regeneration ever ran in MERGE state - the hazard where HEAD is still the pre-merge tip and anchors silently roll back to the old fork point). The mdx is byte-identical across the merge: git diff --stat d73a967dd0..HEAD on that path is empty.", "census_recheck": "RAN THE CHECK, NOT --fix, exactly as instructed. Result: exit 0, GREEN - 'OK - 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read'. ⇒ MY 2 ANCHORS DID NOT MOVE. Nothing was flagged, so nothing was rewritten, so there is no delta to report and no --fix was warranted. ⚠️ ONE CORRECTION TO THE ORDERING NOTE: it cites my anchors as rest-server.ts:6382->6432 and :6575->6625. Those were the FIRST round's values. The comment-only patch round added lines above them and its regeneration advanced them again, so they now stand at :6450 and :6643 - verified by reading the row out of the file. The 2-anchors-for-2-flagged reading held in that round too (2 flagged, 2 rewritten).", "collision_finding": "⭐ THE COLLISION IS NOT A TEXT MERGE, AND THAT CHANGES THE PROCEDURE FOR WHOEVER GOES SECOND. content/docs/permissions/system-context.mdx is DRIVER-MANAGED: .gitattributes:109 registers it 'merge=os-regen', and the driver (merge.os-regen.driver -> scripts/git-merge-regen.mjs) does NOT text-merge it. Measured directly with a simulated merge that touches no worktree - 'git merge-tree --write-tree HEAD FETCH_HEAD' against the #13763 head exits 0 for the tree but emits, for this file: 'not text-merged - it is generated. Regenerate from the merged tree: pnpm gen:system-context-census. The pre-commit hook will not let this commit through until you do.' Two consequences. (1) The raw line ranges ARE disjoint - #13763 changes mdx lines 112-122, 182 and 198; mine changes line 161 - and their changed anchors cite objectql/src/engine.ts (12) and readonly-strict-errors.ts (1), NOT http-dispatcher.ts as the ordering note assumed and never rest-server.ts. So neither PR's source edit shifts the file the other cites, and neither invalidates the other's anchor VALUES. (2) But none of that is how the file merges: the second PR does not hand-resolve and does not reason about line ranges - the driver defers and the pre-commit hook blocks until the artifact is regenerated on the merged tree.", "instruction_reconciliation": "Worth stating because on the surface two instructions point opposite ways: PM says '⛔ do NOT blindly re-run it with --fix', while the repo's own merge driver says 'Regenerate from the merged tree: pnpm gen:system-context-census' - and that script IS 'node scripts/check-system-context-census.mjs --fix'. They reconcile on the word BLINDLY. The safe procedure, which is the #13646 discipline: run the CHECK first and record exactly what it flags, then regenerate, then compare the rewrite count against the flagged count, and stop and report if regeneration touched more than was flagged. I have now run that procedure three times on this file - first round 2 flagged / 2 rewritten, patch round 2 flagged / 2 rewritten, this round 0 flagged / 0 rewritten (no --fix run at all). The 18-vs-5 shape #13646 measured has not appeared on any of them, but it was checked for each time rather than assumed.", "tests": "RE-VERIFIED ON THE MERGED HEAD ddcf40f195, because the merge brought 38 files of other people's work into my PR's tree. GATE UNION RE-DERIVED on the merged head (scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, which named commit ddcf40f195 and my 6 changed paths): 53 -> 62 families, 9 NEWLY named and none dropped - the merge added gate scripts that now apply to my paths. ALL NINE RUN, ALL GREEN: check:corpus-claim-drift (the newly merged one), check:merge-driver, check:entry-guard, check:parse-guard, check:bash32-floor, check:pnpm-filter-targets, check:cli-command-ids, check:agent-test-spelling, check:watch-hint-literal. RATCHET FAMILY re-run on the merged head, all green: check-system-context-census OK (145 anchors resolve), check:engine-double-contract OK, check:where-matcher 'baseline key set verified against adf4bf4: no files added', check:nul-bytes OK (7579 files), check:cross-package-test-inputs OK. execctx-consumer-census counts RE-DERIVED from the merged tree rather than assumed: 75 sites / 95 mentions / 22 caught / 16 same-line / 53 bare - all five still at their pins. pnpm lint REPO-WIDE on the merged tree -> exit 0, no findings. NOT RE-RUN and named as such: the @objectstack/rest suite, the three dogfood shards and check:type-check-debt - my own diff is unchanged since 0df058f2 (the merge added no line to any file I touched), and those runs are expensive; CI runs them on the merged head regardless, which is the half PM re-reads.", "summary": "Merge-ordering addendum handled with no change to my diff. #13763 has not landed, so nothing needed reconciling; I merged origin/main cleanly, committed the merge before running anything, re-ran the census CHECK without --fix as instructed, and it is green - my 2 anchors did not move, and they stand at :6450/:6643 rather than the :6432/:6625 the ordering note cites, because the patch round already advanced them. The useful finding is that this file is merge=os-regen driver-managed, so the second PR through does not hand-resolve at all: the driver defers and the pre-commit hook blocks until pnpm gen:system-context-census regenerates it on the merged tree. The two PRs are independent in both dimensions anyway - disjoint mdx line ranges, and anchors citing different source files - so neither invalidates the other's anchor values. Union re-derived on the merged head grew 53 -> 62 families; all 9 new ones run green.", "mcp_calls": "9 total for the whole run - issue_read get, issue_read get_comments, search_issues, issue_write create (#13753), create_pull_request, add_issue_comment x2 (first report, patch-round report), update_pull_request x2. This addendum comment makes 10. Every read this round - PR #13763 state, my own PR posture, the branch head, the body read-backs - went through the repo-scoped REST channel at zero GraphQL cost.", "open_questions": [], "out_of_scope_findings": [ "filed as #13753: two more meta read doors never forward the caller's organization - GET /meta/diagnostics (getMetaDiagnostics) and GET /meta/:type/:name/references (findReferencesToMeta). Unchanged this round.", "NOT filed, reported as a reading: rest-server-meta-read-org-scope.test.ts asserts nothing about /history or /diff today, so no vacuous claim exists there - but its stub discards opts.where on both sys_metadata_history seams, making it a trap for any org-scoping assertion added later.", "NOT filed, offered for PM's judgement: the ordering note modelled this as a line-range collision on a shared file. It is not - the file is merge=os-regen driver-managed, so ANY two PRs touching it collide identically regardless of region, and the resolution is always 'regenerate on the merged tree', never a hand-merge. If the seat's serialisation fence is meant to catch derived collisions, keying it on the .gitattributes merge=os-regen roster would name every such file mechanically instead of relying on noticing the source-line shift. Related: open issue #13731 already tracks that roster's completeness." ] }Generated by Claude Code
os-steve commentedon Aug 31, 2026
os-dev-report
{ "issue": 13406, "status": "done", "round": "closing one gap the ACCEPT rested on — check:type-check-debt re-verified on the MERGED head", "branch": "claude/issue-13406-meta-read-doors-forward-org", "pr": "https://github.com/objectstack-ai/objectstack/pull/13756", "head": "ddcf40f195", "premise_still_valid": true, "why_this_round_exists": "The review said #13756 is clear on the check:type-check-debt axis because my card ran that gate and passed it. TRUE, but the run it rests on was at 0df058f2 — BEFORE I merged origin/main — and my own addendum report listed check:type-check-debt among the things explicitly NOT re-run on the merged head. So the ACCEPT was resting on a pre-merge measurement of the exact gate that had just reddened #13763. Re-measured rather than left standing on a stale tree.", "result": "GREEN at ddcf40f195, the head CI actually tests. 'check-type-check-coverage --re-measure: OK — 29 ledger entr(ies) re-measured in 323.5s, 1542 raw tsc error(s) total, none above its recorded number.' followed by 'surplus: none — every entry sits exactly at its measurement, so any new error is red.' Byte-identical totals to the pre-merge run (29 entries / 1542 errors), so neither the merge's 38 incoming files nor my new test file moved this axis.", "why_my_card_could_not_hit_13763_shape": "#13763 reddened because both its packages' own typecheck excludes *.test.ts, so its two new test files' +14/+19 raw errors were invisible locally and only the repo-level --re-measure saw them. @objectstack/rest does NOT have that blind spot: it carries a sibling tsconfig.test.json named in its typecheck script (the packages/spec pattern AGENTS.md prescribes), plus a per-file test-typecheck-debt.json. Verified on the merged head: 'pnpm --filter @objectstack/rest typecheck' exit 0, reporting 'check:test-typecheck: OK — @objectstack/rest's test layer compiles under packages/rest/tsconfig.test.json; 1 file(s) / 2 error(s) / 1 pinned signature(s)' — unchanged from before my file existed, so my new test file contributed ZERO errors. And the file is genuinely IN that program, not skipped: 'tsc -p tsconfig.test.json --listFiles' counts it 1. That is the same NOT-MEASURED trap check I ran in round one, re-taken on the merged tree rather than assumed to carry over.", "tests": "ON THE MERGED HEAD ddcf40f195: workspace closure rebuilt as CI does (turbo run build --filter=./packages/* --filter=./packages/*/*) — 70/70 tasks successful, which check:type-check-debt requires or it refuses outright. pnpm check:type-check-debt -> exit 0, verdict line quoted above. pnpm --filter @objectstack/rest typecheck -> exit 0, verdict line quoted above. tsc -p tsconfig.test.json --listFiles -> new test file present (1). ⚠️ ONE PLATFORM NOTE, recorded because it cost a run: the first build attempt died at the ~10-minute foreground cap with exit 143 (SIGTERM) on a cold turbo cache — the fresh worktree's node_modules had been removed at cleanup, taking the cache with it. NOT a failure of anything under test: the log shows it had in fact finished 68 build tasks in 4m42s before the cap hit, and the resumed run completed 70/70 in 28s off that cache. Recorded as NOT MEASURED for the killed invocation, never as a red.", "summary": "No change to the diff, no new commit, nothing pushed. One verification gap closed: the check:type-check-debt clearance the review relied on had been measured before the origin/main merge, on the same gate that reddened the sibling PR. Re-run on the merged head it is green with zero headroom (surplus: none), at totals identical to the pre-merge run, and the package-level test-layer gate confirms my new test file adds zero errors and is genuinely inside the tsconfig.test.json program. PR #13756 remains draft at ddcf40f195; nothing flipped, nothing armed.", "mcp_calls": "12 total for the whole run — this comment is the twelfth. Prior: issue_read x2, search_issues, issue_write create (#13753), create_pull_request, add_issue_comment x3 (reports) + 1 (PR merge-ordering note), update_pull_request x2. Every read this round went through the repo-scoped REST channel at zero GraphQL cost.", "open_questions": [], "out_of_scope_findings": [ "filed as #13753: GET /meta/diagnostics and GET /meta/:type/:name/references never forward the caller's organization. Unchanged.", "NOT filed, reported as a reading: rest-server-meta-read-org-scope.test.ts asserts nothing about /history or /diff, so carries no vacuous claim — but its stub discards opts.where on both sys_metadata_history seams, so it is a trap for any org-scoping assertion added there later." ] }Generated by Claude Code
test(rest): the history/diff stub double holds the caller's limit bou…
os-steve commentedon Aug 31, 2026
os-dev-report
{ "issue": 13406, "status": "done", "round": "fix round — check:objectql-double-limit red on CI, repaired; plus the union question answered from captured output", "branch": "claude/issue-13406-meta-read-doors-forward-org", "pr": "https://github.com/objectstack-ai/objectstack/pull/13756", "head": "a18a9a4889", "premise_still_valid": true, "union_question_answer": "NEITHER of the two branches — it is a THIRD answer, and it is the one that reflects badly on me rather than on the tool. check:objectql-double-limit WAS in my derived union, in BOTH derivations: gates.log line 38 and gates2.log line 43, matched via gate source 'packages/**/*.test.ts' and naming rest-server-meta-history-diff-org-scope.test.ts explicitly. It is in both harvested .list files. I NEVER RAN IT — there is no captured log for that command anywhere in my scratchpad, which is the answer read off the evidence rather than reconstructed. ⇒ This is NOT a dispatch-gates.mjs finding and should NOT join #13392/#13461. Path derivation named the gate correctly, twice, from the first derivation onward. The failure was entirely mine: I harvested the family list, used it only to DIFF the two derivations, and then ran gates in ad-hoc batches without ever reconciling 'named' against 'ran'. The checklist was sitting in the file I had already created.", "scale_of_that_gap": "Measured, because the one red was not a fluke: of the 62 families the merged-head union named, I had run only 19 before this round. check:objectql-double-limit was one of 43 unrun. Getting exactly one red out of 43 was luck, not coverage. NOW CLOSED: 61 of 62 run and green this round. The 62nd is node scripts/check-test-completeness.mjs, which exits 3 and declares itself in its own output: 'running the family locally, record this gate as NOT MEASURED ... ⛔ It is not a red, and there is nothing here to fix' — it needs a saved 'turbo run test' log that the derived family list passes no argument for. Recorded as NOT MEASURED, never inside a green count.", "the_defect_was_real": "Agreed with the review, and the symmetry it names is exact. /history accepts ?limit= and threads it (Number(req.query.limit), then a Number.isFinite-guarded spread into the request literal), so limit is a contract member of the very door this file pins — and my double could not observe it. A regression dropping the bound would have left the suite green. That is the same class as answering an unknown $ combinator by looking for a column named '$and', which I had refused ten lines earlier: I applied the principle to one axis of opts and not the other.", "fix_chosen": "APPLIED the bound, not thrown — the review's recommendation, and I agree with its reasoning: limit is genuinely in the contract, so a harness that honours it can TEST it while one that throws can only refuse to be asked. Applied AFTER the filter as the gate's shape rule requires (bounding first would decide WHICH rows survive the predicate rather than how many survivors return), by PRESENCE via typeof opts?.limit === 'number', and on BOTH table branches so the two cannot disagree. Today's calls are unaffected because SysMetadataRepository.history() applies limit itself while iterating rather than pushing it into the engine, so every existing assertion keeps its meaning. ⛔ Nothing was added to any baseline or exemption list — the gate's verdict confirms it: 'baseline key set verified against adf4bf4: no files added'.", "earned_the_fix": "Added the one pin the review suggested, and PROVED it is not vacuous rather than assuming. New test: '?limit=1 over a two-revision log returns exactly the first event', with an unbounded control asserting the same read returns 2 without the bound (without that control, 'one event came back' proves nothing), and naming WHICH event (version 1, oldest-first per the response contract) so a bound truncating from the wrong end is also caught. ABLATION C, direction predicted BEFORE running: drop the limit spread from the history door's request literal ⇒ predicted the new pin and only the new pin reddens. MEASURED: '1 failed | 20 passed', the failure being exactly that pin. Run from a committed implementation, trap on EXIT INT TERM, absolute paths, mutation proven on disk by occurrence counts plus a git hash-object comparison against the HEAD blob (the anchor occurs twice — history and audit doors — and only the FIRST was removed), restore proven by hash equality plus an empty git diff HEAD.", "tests": "AT a18a9a4889. pnpm check:objectql-double-limit -> exit 0: 'OK ObjectQL double `limit` conformance holds: 296 double(s) graded, 96 apply the caller's bound or refuse it loudly ... none new. baseline key set verified against adf4bf4: no files added.' pnpm --filter @objectstack/rest test -> 'Test Files 164 passed (164)' / 'Tests 2761 passed (2761)' (2760 -> 2761, the +1 being the new pin). pnpm --filter @objectstack/rest typecheck -> exit 0, test layer still '1 file(s) / 2 error(s)' so the new pin adds zero debt. pnpm lint REPO-WIDE -> exit 0, no findings. check:engine-double-contract, check:where-matcher, check-system-context-census -> all exit 0 (re-run because the test file and its double changed). PLUS the 43-family gap closed: all remaining named families run, all green — the packages-scoped set (keyed-text-bounds, comment-mask-adoption, plugin-teardown-shape, undeclared-dep-imports, page-declaration-shape, slot-lookup, published-files, type-source-resolution, logger-receiver-detach), the changeset set (empty-changeset, changeset-no-major, adr-0087-registration, changeset-gate-self-tests, objectui-changeset, pm-half-states, check-half-states, release-rehearsal-clone --self-test), the docs set (docs-single-h1, docs-redirects, docs-audit-scope, role-word, published-readme-links, react-page-adapter-contract, doc-frontmatter, doc-route-spelling, docs-section-name, section-landing-index, affected-docs, drift-comment), the spec/lint filtered set (doc-formula-expressions, doc-security-posture, spec check:docs, empty-state, liveness, skill-examples, strictness-ledger, variant-docs, yaml-examples), plus ci-filter-parity, cross-package-test-inputs, dual-build-cjs-loads and shard-attestation. ⛔ NOT RE-RUN and named as such: the three dogfood shards and check:type-check-debt — both were green on the parent commit ddcf40f195 and this round's diff is one test file touching no package boundary, no type surface and no ledger.", "two_not_measured_readings": "Reported separately from the passes, never inside a green list. (1) My first attempt at check:comment-mask-adoption and check:plugin-teardown-shape used the 'pnpm check:*' spelling and returned exit 254 'Command not found' — those two are invoked as 'node scripts/...' in the union. That is EXACTLY the two-spellings trap dispatch-gates prints a ⛔ about ('A harvest that greps pnpm check: out of the block above takes 33 of the 53 and reports nothing missing'), and I walked straight into it after having read that warning. NOT MEASURED, not red; re-run with the union's own command line, both green. (2) The first 'pnpm --filter @objectstack/rest typecheck' of this round failed with TS2307 'Cannot find module @objectstack/spec/shared' — PREREQUISITE NOT MET, a fresh worktree with an unbuilt closure (packages/spec/dist confirmed absent), not a code defect. Built as CI does, 70/70 successful, then green.", "process_change_i_am_adopting": "Reconcile NAMED against RAN mechanically before reporting anything green, using the harvested family list as a checklist rather than only as a diff input — 'comm -23 gates.list ran.list' must be empty or every entry must carry a stated reason. I had the list; I used it for the wrong job. That single command would have caught this before CI did.", "summary": "CI red repaired at a18a9a4889, one file changed (+56/-5), test-only. The stub's find double now holds the caller's limit bound, applied after the filter and by presence on both tables, and a new pin proves ?limit= travels the whole door — verified non-vacuous by an ablation that reddens exactly that pin and nothing else. The union question answers to neither branch the review offered: the gate WAS derived, in both derivations, and I simply never ran it. Measuring that revealed the real gap — 19 of 62 families run before this round — which is now closed at 61 of 62 green, the 62nd declaring itself NOT MEASURED. PR remains draft; nothing flipped, nothing armed.", "mcp_calls": "13 total for the whole run — this comment is the thirteenth. Prior: issue_read x2, search_issues, issue_write create (#13753), create_pull_request, add_issue_comment x4 (reports + the PR merge-ordering note), update_pull_request x2. Every read went through the repo-scoped REST channel at zero GraphQL cost.", "open_questions": [], "out_of_scope_findings": [ "filed as #13753: GET /meta/diagnostics and GET /meta/:type/:name/references never forward the caller's organization. Unchanged.", "NOT filed, reported as a reading: rest-server-meta-read-org-scope.test.ts asserts nothing about /history or /diff, so carries no vacuous claim — but its stub discards opts.where on both sys_metadata_history seams, so it is a trap for any org-scoping assertion added there later. ⚠️ Worth re-reading in light of THIS round: that sibling stub is limit-blind too, and it is one of the 168 limit-blind doubles the gate grandfathers, so the same argument applies to it on a second axis." ] }Generated by Claude Code
baozhoutao commentedon Aug 31, 2026
Root scope broadened — reproduced on the single-node showcase dev app (not the EE cluster, not
isolatedmulti-org), driven through the Studio UI. Both symptoms recur, so at least two of them are not org-threading-specific:/meta/:type/:name/history→{events:[]}and/diff→ empty after publishing a dashboard/view overlay twice, on plain single-tenant showcase (framework502ff8b5, console190fbd01). Versions provably exist —rollbackresolvestoVersion1/2 and/auditcarries the rows — yet history/diff read empty. Reproduced ×2, and it is universal across overlay types (view overlay too), not limited to the isolated-multi-org org-scoping path this card was first filed under. So the history/diff gap has a broader root than "session org not forwarded"; the org-threading fix (rest-server.ts:5755 / protocol.ts:14601) is necessary but likely not sufficient for these two endpoints — the empty result reproduces even when there is no org to thread./api/v1/meta/dashboard/system_overview(widget title changed), or draft+publish, returns 200 andDELETElater reportsreset:true(the overlay existed), yet the read still serves the base title; the equivalent packaged view overlay IS served. The dashboard-vs-view kind asymmetry (symptom Implement ObjectStack protocol specification with Zod schemas and TypeScript interfaces #3 on this card) reproduces identically on showcase.Net: symptom #3 (dashboard overlay read) and the history/diff pair are reproducible without multi-org, so they should be treated as overlay-read / metadata-versioning defects in their own right; only the "which org's overlay wins" selection depends on the org-threading fix. Found during a Studio-UI test pass; screenshots were the live oracle, API read-backs are the recorded evidence.
QA-source: #13404 · studio-authoring.draft-publish-lifecycle, studio-authoring.packaged-display-class-direct-edit (UI supplement)
Generated by Claude Code
fix(rest): `/meta/:type/:name/history` and `/diff` state the org part…