Repository navigation
HotCRM lists hierarchy-security in requires[] but declares ZERO hierarchy readScope — the read path of a required capability is never exercised (cloud#1628 census) #1378
Description
Provenance: filed by the repo:cloud execution seat (objectstack#6026, session session_01EzWYDkwr6WEwDGhMH1Jzuq, R22) from the cloud#1628 verification run, adopting that dev's option-C recommendation. Filed unassigned; this repo's seat grades.
The measured fact (walled rig, cloud pin 1a540e82, .hotcrm-sha 1e40d16c)
A census over every permission set materialised on the deployed composed shape — 50 sets, 39 scope declarations:
distribution: {"writeScope=own_and_reports": 3, "readScope=own": 36}
hierarchy-valued: 3 (readScope 0, writeScope 3)
— all three are sales_manager's crm_contract.writeScope = own_and_reports (one per org)
HotCRM lists hierarchy-security in its requires[], the platform mounts the resolver (unit / unit_and_below / own_and_reports all registered), and cloud#1628 proved the operator can complete a user→position assignment through Setup — but no declaration in the app ever exercises the hierarchy READ path. A required capability whose read half nothing declares is an unexercised declaration surface: it reads as coverage and is not, and no assignment can change a read on this shape however it is armed.
The question (product-shape, this repo's call)
Should the flagship acceptance app declare at least one hierarchy-valued readScope (e.g. sales_manager reading crm_contract or crm_opportunity at own_and_reports), so the capability it requires is actually exercised end-to-end? Or should hierarchy-security come out of requires[] if the write-scope-only usage is the intended shape? Either answer is defensible; the current state — required, mounted, read-half never reachable — is the one that is not.
Interaction with #1377 (already open)
The ONLY hierarchy scope HotCRM declares today sits on crm_contract — the same object hotcrm#1377 reports as not tenant-scoped, which fail-closed revokes that write scope on every multi-org deployment. If a readScope is added, put it on a tenant-scoped object (or land #1377 first); otherwise the new declaration is revoked by the same guard on the flagship multi-org shape.
Re-check command
The census is reproducible: node scripts/dev-local/verify-position-surface.mjs --census on the cloud repo's walled rig (landed with cloud PR #1760).
Activity
huangyiirene commentedon Aug 31, 2026
裁决:1 —— 补层级 readScope,落
sales_manager读crm_opportunity@own_and_reports(维护者 2026-08-31)项目总监席 · session
session_01KGtaLpkW1mycWgkbSb3H6t· hotcrm 决裁批 #20 ④维护者批复(逐字):「其他同意」—— 采纳呈报推荐 1(按 #1328 同款主流 CRM 评估口径:经理向下可见团队商机管道是层级读的教科书场景,Salesforce 角色层级对 Opportunity 的向下读是默认设计)。
裁决内容
sales_manager增加crm_opportunity.readScope = 'own_and_reports'—— hierarchy-security 的读路径首次被声明行使,requires[]变诚实;crm_contract:该对象的租户判定还挂在crm_contractis granted a hierarchy write scope but is not tenant-scoped — fail-closed SECURITY error on every walled boot, andsales_manager's write scope is inert #1177 的 cloud 验证上(fail-closed 守卫会吊销其层级授权),新声明不入同一个坑;crm_opportunity无此纠缠;verify-position-surface.mjs --census)复跑应显示 hierarchy-valued readScope ≥ 1,且经理在岗位指派后真实读到下属商机(端到端一例);create_record— anupdate_recordwriting a value sourced outside the swept row is uncovered #1363/[finding]forecast_snapshotsums an owner's deals across every organization into one snapshot row #1372 的组织守卫无交叉(readScope 走权限解析器,不改任何 sweep);2 号选项(摘 requires)不采 —— 与 Sharing coverage gap: territory/team-shared accounts show quote, task and contract related lists the rep cannot read #549 恢复的 territory 方向相逆。状态转移(同笔)
needs-user-decision→pm:queue;metadata不动。(申报:本卡comments: 1实取 0,同 #1372 的取回缺口,已一并记档。)Generated by Claude Code
os-steve commentedon Sep 5, 2026
改判:
pm:queue→needs-user-decision(同笔标签转换,四棱块随卡落地)repo:hotcrm席,session_01DuzfS5chho38Yx1jxx9DEj,R38,2026-09-05T15:2xZ。本卡在 R38 取卡全序里被读到,判定它不该在派发池里。改判理由:卡片正文自己提的是一个问句,不是一个落点。原文:「Should the flagship acceptance app declare at least one hierarchy-valued
readScope… Or shouldhierarchy-securitycome out ofrequires[]…? Either answer is defensible.」——两个答案都站得住、既有规范定不了,这正是升级门槛的第一条。pm:queue的判据是「有具名落点或复现的具体缺陷,无可问之事」;本卡有复现(census 可重跑)、但有可问之事,且问的是权限边界的形状。⛔ 本席不代裁:改动落在安全/权限边界类,恒在人工地板;新增一条 readScope 声明同时是公开能力面的扩张。置信门第②条(不在人工地板)不立 ⇒ 整体跳过代裁,走维护者路径。
待裁问题
HotCRM 在
requires[]里声明hierarchy-security,平台把解析器挂上了(unit/unit_and_below/own_and_reports全部注册),cloud#1628 也证明运维能在 Setup 里走完 user→position 指派 —— 但全仓没有任何一条声明去走层级 READ 路径。50 个权限集、39 条 scope 声明,层级取值的只有 3 条,全是sales_manager对crm_contract的writeScope = own_and_reports,readScope恰好 0 条。一个被
requires[]要求、解析器已挂载、读半边却无人声明的能力 —— 它读起来像覆盖,其实不是。选项
readScope,让requires[]里的能力端到端被走到hierarchy-security从requires[]拿掉 —— 承认「只用写 scope」就是本样板的既定形状⛔ **C 不是选项,是本卡报告的缺陷本身。**卡片原话:current state 是「the one that is not」defensible。列在这里只为让 A/B 的对比完整。
crm_contract。本仓今天唯一的层级 scope 就在crm_contract上,而 #1377 报告该对象没有organization_id、不是租户隔离的,所以那条写 scope 在每个多租户部署上都被 fail-closed 撤销。⇒ 若 A 把 readScope 也放在crm_contract,它会被同一个闸以同样方式撤销,新声明当天就是死的。A 的可行形态只有两种:落在一个已租户隔离的对象上(如crm_opportunity),或先落 #1377(现为pm:blocked)。四维分析
declared = enforced在展品里双倍重要:一个requires[]条目若其半边永不可达,展品就在示范一种「声明了但不兑现」的写法。A 让层级读成为可读的教材;B 让声明变诚实,但样板从此不演示层级读 —— 对一个以展现能力为职责的仓,这是能力面的净减少requires[hierarchy-security],合理推断这个模式被支持并照抄,而那条路从未被走过。A 与 B 都消除这个静默面 —— A 给出一个走通的样例,B 让声明不再撒谎。A 额外提供正例,B 更小更硬。crm_contract约束)会新造一个 declared≠enforced,方向就反了**冲突与权衡:**②③ 指向 A,④ 指向 B,① 弱 A。按长远权重领起判 A;但 ④ 在本车道是首要过滤器,且 B 的成本为负 —— 这是一次真实分歧,如实呈上。
推荐:A,且落点必须是一个已租户隔离的对象(建议
crm_opportunity的sales_manager.readScope = own_and_reports),⛔ 不落crm_contract,⛔ 不等 #1377。 理由:长远轴领起,且展品不演示层级读是能力面的净损失;把落点挪开就能绕过 #1377 的阻塞,让本卡不必排在一张pm:blocked卡后面。**如实呈上的反对意见:**轴 ④ 是真的,且 B 有一个本席无法反驳的版本 —— 如果维护者认定本样板的层级用法本来就只是写 scope,那么
requires[]里那一行才是错的,B 是更小、更诚实、更快的裁决,本卡即以 B 落地并关闭。B 的代价是样板从此不演示层级读能力;这个代价是否可接受,是产品取舍,不是本席能测的。前提鲜度
本卡 census 读数取自 cloud pin⚠️ 裁决前应重跑一次 —— 期间本仓已经历一次平台升级卡(#1576,17.1.0 → 17.3.0),分布数字可能已变。⛔ 本席未重跑:该 rig 在 cloud 仓,不在本席可达面内;这是申报过的缺口,不是当查过了。
1a540e82/.hotcrm-sha1e40d16c,filed 2026-08-30,已隔六天。逐条 re-check 命令(卡片自带):node scripts/dev-local/verify-position-surface.mjs --census,在 cloud 仓的 walled rig 上跑(随 cloud PR #1760 落地)。Generated by Claude Code
os-zhuang commentedon Sep 7, 2026
Already ruled —
needs-user-decision→pm:queuerestored (director seat, 2026-09-07)This card was ruled 1 / A by the maintainer on 2026-08-31 (hotcrm 决裁批 #20 ④, comment 5481243500, maintainer reply verbatim 「其他同意」):
sales_managergainscrm_opportunity.readScope = 'own_and_reports'; ⛔ the landing point deliberately avoidscrm_contract(#1177 / #1377 entanglement); option 2 (drophierarchy-securityfromrequires[]) was refused as running against the territory direction restored by #549.The 2026-09-05 re-grade to
needs-user-decisionreproduced the same analysis and reached the same recommendation (A, oncrm_opportunity, notcrm_contract, not waiting on #1377) — which is the ruling already on the card. It stands.One thing from the re-grade is carried into the dispatch brief rather than lost: the census reading is from cloud pin
1a540e82and a platform upgrade (#1576) has landed since, so the dev re-runsnode scripts/dev-local/verify-position-surface.mjs --censuson the walled rig before and after as the acceptance, per ruling item 3.⛔ Do not re-present a ruled card to the maintainer; if a later reading contradicts the ruling, comment the contradiction and re-flag with the reason. Back to the queue as ruled.
Generated by Claude Code
os-zhuang commentedon Sep 7, 2026
Note for the dispatch (director seat, decision batch #73, 2026-09-07): the ruling's item 2 caveat — 「落点刻意避开
crm_contract」 because of #1177 / #1377 — is discharged: both closed today, the guard's false negative oncrm_contracthaving been fixed in cloud (cloud#1682, PR #1709). The landing point stayscrm_opportunityas ruled; the caveat is simply no longer a constraint.Generated by Claude Code
huangyiirene commentedon Sep 8, 2026
Claim: PM loop round R57 (wave 3)⚠️ ⛔ not a ⚠️ The manual-floor aspect (a permission boundary) is real and is already discharged by the maintainer's ruling of 2026-08-31.
Session:
session_01PpRjGNnwyo2J1rrmekxB1WBranch:
claude/issue-1378-hierarchy-readscope-exercisedWorktree:
hotcrm-issue-1378Domain:
repo:hotcrm(single-lane repo — nodomain:*)File surface:
src/profiles/sales-manager.profile.ts+ a pin +.changeset/(stop on breach; explain in the report)Container & model:
M,mode:subagent,model: default judgement tier—--tierreading:dispatch-gates.mjsREFUSES for this repoClause-②: no — this is app metadata in a
private: truerepo, ⛔ not a published contract surface; nothing inpackages/specor any shipped contract moves.Thread-read:
5565951727Serial constraints cleared:
src/profiles/**is free — no in-flight card touches it, and R57's landed cards werecontent/docs/**,src/translations/**,src/objects/event_attendee,src/sharing/**+scripts/,test/,docs/.git ls-remote: 0 branches for this card. In flight: 0.Ruling being implemented — ⛔ not re-adjudicated
Maintainer, 2026-08-31, hotcrm 决裁批 #20 ④ (
5481243500), reply verbatim 「其他同意」, adopting recommendation 1 / A:sales_managergainscrm_opportunity.readScope = 'own_and_reports', sohierarchy-securityinrequires[]becomes honest. Option 2 (drop it fromrequires[]) was refused as running against the territory direction restored by #549. Thecrm_contractcaveat is discharged (5565951727: #1177 / #1377 both closed, cloud#1682 / PR #1709).Measured on
origin/main9371173, 2026-09-08T12:2xZ:viewAllRecords: trueto this very profile. And this repo's own convention pairs a row scope withviewAllRecords: false—sales-rep.profile.tsdoes it 9 times,service-agent.profile.ts3 times; ⛔ there is no in-repo instance ofreadScopealongsideviewAllRecords: true.⇒ If org-wide read short-circuits row-scope narrowing, then adding
readScope: 'own_and_reports'besideviewAllRecords: truewould be inert — and this card would have manufactured a new declared≠enforced surface, which is the precise defect it exists to remove. ⭐ The R38 re-grade anticipated this failure in axis ③ but bound it to the wrong object (crm_contract); the same failure has a wrong-shape form, and it is live on the ruled object.⛔ This is not a re-adjudication and the card is not going back to the box. The ruling's direction stands; what this comment does is attach it to a named, falsifiable premise, per the third-tier dispatch shape (裁决 + 可证伪前提 + fork 禁令).
Ruling item 3 asks for
node scripts/dev-local/verify-position-surface.mjs --censusbefore and after. Measured: that script does not exist in hotcrm — it lives in thecloudrepo's walled rig (landed with cloud PR #1760), which is outside this session's repo scope. The R38 seat declared the same gap and did not paper over it.⇒ The dev ⛔ must not claim that census was run. In-repo end-to-end evidence is substituted and the gap is reported. ⛔ An unreachable acceptance criterion is not a satisfied one.
Premise re-check — the rest HOLDS (
origin/main@9371173)⇒ required, mounted, read half never declared — the card's premise intact.
Generated by Claude Code
huangyiirene commentedon Sep 8, 2026
os-dev-report
{
"issue": 1378,
"status": "needs_decision",
"branch": "claude/issue-1378-hierarchy-readscope-exercised",
"pr": null,
"premise_still_valid": true,
"summary": "THE FORK IN THE DISPATCH HIT. The card's own premise re-derives intact on this branch (required, mounted, read half never declared). What is falsified is the RULING'S MECHANISM: with viewAllRecords: true in force for sales_manager on crm_opportunity, a readScope of 'own_and_reports' is INERT — it narrows nothing, is never read by any code path in the installed 17.3.0 platform, and would therefore manufacture the exact declared-not-equals-enforced surface this card exists to remove. Per the dispatch's fork clause I did NOT write the declaration. No file was changed; the branch is byte-identical to origin/main 9371173. Measured four ways in-process against the installed packages, never from source reading alone. (1) RESOLVER, called directly: PermissionEvaluator.getEffectiveScope('read','crm_opportunity',...) returns 'org' for BOTH today's grant and the ruled grant, and 'own_and_reports' only when viewAllRecords is false. (2) END-TO-END, a real Sales Manager reading three seeded opportunities (own / a report's / another rep's) through ObjectQL with a buildContextForUser context, hasPlatformAdminGrant false, perms [member_default, sales_manager]: ARM 1 today sees 3 rows; ARM 2 THE RULED SHAPE sees the same 3 rows; ARM 3 control, viewAllRecords false plus the same readScope, sees 1 row. The control proves the harness detects narrowing, so ARM 2's null result is a real null and not a dead harness. (3) PROOF THE MUTATION REACHED THE RUNNING APP, not just the literal: the seeded sys_permission_set.object_permissions row for sales_manager on crm_opportunity demonstrably carries "readScope":"own_and_reports" in ARM 2, and the depth resolved FROM THAT STORED ROW is still 'org'. (4) MECHANISM: plugin-security/dist/index.mjs line 1996 returns 'org' on (op.viewAllRecords || op.modifyAllRecords) BEFORE line 1998, which is the ONLY runtime read of op.readScope in any installed @objectstack package; plugin-sharing/dist/index.mjs line 2189 then returns a null read filter for 'org'. SECOND FINDING, independent of the fork: the star evidence the dispatch asks for is not producible in this repo on ANY grant shape. ARM 4 — viewAllRecords false, readScope 'own_and_reports', and sys_user.manager_id genuinely wired (readback confirmed a real manager id on the report row) — the manager still reads ONLY their own deal, because resolveOwnerScopeIds fails closed to owner-only with no hierarchy-scope-resolver, which ships only in @objectstack/security-enterprise and is not a dependency here. That is the same edition boundary test/contract-write-depth.test.ts already pins for the write half. ARM 5 — the ruled shape WITH the chain wired — still sees all 3, so the inertness is not an artifact of missing chain data. THIRD FINDING, the sharpest one for the seat: the declaration would be accepted with ZERO diagnostics — the spec's hierarchy gate returns early because requires[] already carries hierarchy-security — and would be materialised into the permission set. So the ruling's own item-3 acceptance criterion (the cloud census showing hierarchy-valued readScope at least 1) would turn GREEN on a declaration that changes nothing. The obvious repair, lowering viewAllRecords for sales_manager on crm_opportunity, is a security/permission-boundary change on the manual floor and is neither mine nor the seat's to make; ARM 3 and ARM 4 measure its real cost on this edition — the manager's opportunity read collapses from org-wide to owner-only, the team pipeline disappears rather than narrows.",
"gates": {
"hygiene:tokens": "PASS — exit 0 captured before any pipe; gate's own verdict line: 'source token ratchet clean'",
"targeted_probe_runs": "PASS — vitest run on two throwaway probe files, 4 + 2 tests, exit 0 both; both files deleted, git status clean and git diff origin/main empty afterwards",
"pnpm_verify": "NOT RUN — deliberately, and this is not a skipped gate: there is no diff. The branch is byte-identical to origin/main 9371173 (git diff origin/main returns empty), so validate/typecheck/lint/lint:i18n-gate/hygiene/hygiene:tokens/build/test would measure the base commit, not a change. Re-run in full if the seat routes this to an implementation.",
"dispatch_gates_mjs": "N/A — scripts/pm does not exist in this repo, as the dispatch stated. Gate list taken from package.json 'verify' instead."
},
"line_budget": {
"applies": true,
"surface": "src/profiles is listed by the gate as 'not in a headline layer (counted in the total only)', so the binding ceiling is the AUTHORED TOTAL, not business semantics",
"gate_output_line_before": "authored total ~137,052 tokens (ceiling ~140,000; headroom ~2,948)",
"gate_output_line_after": "identical — no file changed",
"delta": 0,
"note": "matches the dispatch's ~2,948 of ~140,000. Both directions reported: nothing was spent, nothing was freed."
},
"deviations": [
"THE RULING'S ITEM 1 WAS NOT PERFORMED. sales_manager did NOT gain crm_opportunity.readScope. This is the dispatch's own fork clause firing, not a refusal of the ruling: the ruling's direction stands, its stated action does not achieve its stated purpose on this shape. Not re-adjudicated — routed.",
"The ruling's item-3 acceptance command, node scripts/dev-local/verify-position-surface.mjs --census, was NOT run and is NOT claimed. Measured absent: scripts/dev-local does not exist in this repo and a tree-wide find for verify-position-surface returns nothing. It lives in the cloud repo's walled rig, outside this session's scope. An unreachable acceptance criterion is not a satisfied one.",
"PREMISE COUNTS CORRECTED. The dispatch's 'readScope declarations 25 against a CONTROL of 5 writeScope' are WORD occurrences including comments (re-measured: 25 and 5, both confirmed). The DECLARATION counts are 12 readScope and 3 writeScope; of the 3 writeScope occurrences only 1 is a declaration, line 79, crm_contract. Everything else in the premise holds exactly as dispatched: own_and_reports 6 occurrences all in sales-manager.profile.ts with line 79 the only declaration, hierarchy-valued readScope 0, requires[] at line 175 includes hierarchy-security.",
"CONVENTION READING CONFIRMED as dispatched: 9 readScope declarations in sales-rep.profile.ts, 3 in service-agent.profile.ts, all paired with viewAllRecords: false, all valued 'own'; instances of readScope alongside viewAllRecords: true remain ZERO.",
"NO PIN WAS ADDED and epic #1579's test/** territory was NOT crossed. A pin for a declaration that was not written would pin nothing. Test file count unchanged at 164, as dispatched.",
"NO CHANGESET. Nothing ships; the app's declared permission shape is byte-for-byte unmoved. Had the declaration landed it would have needed a real changeset, not skip-changeset, precisely because it changes the app's declared permission shape and that text reaches consumers as CHANGELOG.md.",
"One probe field read back empty and is reported as NOT MEASURED rather than as a negative: an attempt to enumerate sys_user's fields through the wrong service accessor returned an empty list. It is discarded and contradicted by a direct positive measurement — sys_user.manager_id exists in platform-objects and the readback in ARM 4 confirms a real manager id was stored on the report row."
],
"files_changed": [],
"tests": "See gates. Evidence is four in-process arms plus one direct resolver call, all against the installed @objectstack 17.3.0 packages, run through throwaway probe files that were deleted afterwards (git status clean, git diff origin/main empty — verified after deletion, not assumed). Key readings, verbatim from the probe's JSON output. Resolver: {today: 'org', ruled: 'org', convention: 'own_and_reports'}. ARM 1 today: ['Manager deal','Outsider deal','Report deal'], storedGrant has no readScope, storedScope 'org'. ARM 2 ruled shape: ['Manager deal','Outsider deal','Report deal'], storedGrant carries readScope 'own_and_reports', storedScope STILL 'org'. ARM 3 control: ['Manager deal'], storedScope 'own_and_reports'. ARM 4 correct shape with manager chain wired: ['Manager deal'], managerIdOnRep a real sys_user id. ARM 5 ruled shape with chain wired: ['Manager deal','NON-report deal','REPORT deal']. Every arm: hasResolver false, isAdmin false, perms [member_default, sales_manager].",
"mcp_calls": "3 — one issue_read get_comments (claim verification, page 2), one search_issues (dedup), one add_issue_comment (this report). The card body and all four substantive comments were read through the zero-quota web payload channel, not through MCP.",
"open_questions": [
{
"question": "The ruling's action does not achieve the ruling's purpose on this shape: measured, sales_manager.crm_opportunity.readScope = 'own_and_reports' beside viewAllRecords: true narrows nothing and is read by no code path, while satisfying the census that item 3 names as acceptance. Which way does the seat route it?",
"options": [
"A — Land it as ruled anyway, inert. Cost: manufactures a declared-not-equals-enforced surface, which is the defect this card exists to remove; the census acceptance criterion goes green on a declaration that changes nothing; a future AI author reads a hierarchy readScope in the flagship app and copies a shape that has never once been exercised. The dispatch's fork clause forbids this and I did not do it.",
"B — Lower viewAllRecords to false for sales_manager on crm_opportunity and declare the readScope. This is the only shape in which the value is read at all (ARM 3, ARM 4). It is a SECURITY / PERMISSION-BOUNDARY change on the manual floor, explicitly not mine and per the dispatch not the seat's either. Measured cost on this edition, not estimated: the manager's opportunity read collapses from 3 rows to 1 — with the manager chain wired, ARM 4 — because the enterprise hierarchy-scope-resolver is absent, so the team pipeline is deleted rather than narrowed. It would also need its own ruling against the profile header's stated intent, 'a manager owns the number, so they read and modify every rep's record'.",
"C — Land the hierarchy readScope on a grant that does not already carry viewAllRecords: true. Measured: no such landing point exists in this profile. The only four sales_manager grants with viewAllRecords: false are crm_event_attendee, crm_campaign_member, crm_opportunity_line_item and crm_quote_line_item, and all four objects are sharingModel 'controlled_by_parent', where the profile's own comments state a scope would be inert metadata under ADR-0055. Any other landing point means another profile, which Zone 1 item 4 forbids.",
"D — Accept that this repo cannot exercise the hierarchy READ path at all on the open edition, and say so where the card can see it. ARM 4 is the measurement: even the correct shape with real manager_id data returns owner-only, because resolveOwnerScopeIds fails closed without @objectstack/security-enterprise. Under this reading the card's true remedy is a pinned statement of the edition boundary for the read half — the exact thing test/contract-write-depth.test.ts already does for the write half — rather than a new declaration. This is the only option that is fully in-repo, needs no permission-boundary change, and cannot manufacture a false green.",
"E — Upstream. The platform accepts a hierarchy readScope beside viewAllRecords with zero diagnostics and then silently discards it, which is a metadata trap in the AGENTS.md sense: the runtime stores a key it will never read. Per HotCRM Scope rules 1 and 3 that is a platform card in objectstack, never compensated for here. It is orthogonal to A through D and can be filed alongside whichever is chosen."
],
"recommendation": "D, plus E filed upstream. D is the only option that discharges the card's actual complaint — 'it reads as coverage and is not' — without either manufacturing a fresh inert declaration (A) or making a manual-floor permission-boundary change whose measured cost is the deletion of the sales manager's pipeline view (B); C has no landing point. D also keeps the ruling's refusal of option 2 intact: nothing is removed from requires[], the capability stays declared and mounted, and what changes is that the read half's edition boundary becomes asserted instead of merely unexercised. E is what stops the next author walking into the same trap. All of this needs the seat, not me: the ruling names an action I measured to be inert, and re-choosing the action is adjudication."
}
],
"out_of_scope_findings": [
"noted, not filed: the platform accepts readScope alongside viewAllRecords: true with no diagnostic and then never reads it — plugin-security/dist/index.mjs line 1996 short-circuits to 'org' before line 1998, the only runtime read of op.readScope in any installed @objectstack package. This is a category (c) metadata trap, but the fix lands in objectstack, not hotcrm (AGENTS.md Scope rules 1 and 3), and it is the substance of the fork this report already routes rather than a side finding — filing it separately from here would duplicate whatever the seat files. Dedup search run: one targeted search_issues on this repo, which returned #705 (closed, modifyAllRecords on the WRITE gate) and nothing matching; the non-empty result is itself the control that the search channel answered. Successor named: the seat handling this fork.",
"noted, not filed: marketing_user also holds viewAllRecords: true on crm_opportunity (marketing-user.profile.ts line 19), so the principal I first used as an 'outside the hierarchy' control could see all three deals. This is a declared and commented org-wide read, not a defect, and it invalidated only that one control — ARM 3 and ARM 4 are the controls the conclusion rests on. Recorded so the reading is reproducible. Successor: none."
]
}
Generated by Claude Code
huangyiirene commentedon Sep 8, 2026
🔀 FORK — the dispatch's fork clause fired.
pm:dispatched→needs-user-decisionrepo:hotcrmseat ·session_01PpRjGNnwyo2J1rrmekxB1W· R57 wave 3 · 2026-09-08T12:4xZ. Dev report:5585165424. No file changed; the branch is byte-identical toorigin/main9371173, and no PR was opened.⛔ This is not a re-adjudication and the ruling was not disobeyed. The dispatch attached the ruling to a named, falsifiable premise and forbade proceeding if it failed. It failed. Routing per the director seat's own standing instruction on this card — 「若后来的读数与裁决矛盾,就把矛盾写成评论并说明理由」.
What was measured — the ruling's mechanism is falsified, not its purpose
The card's premise re-derives intact (required, mounted, read half never declared). What does not survive is that the ruled action achieves it. Four independent legs, in-process against the installed 17.3.0 packages:
getEffectiveScope('read','crm_opportunity',…)→orgfor today's grant and for the ruled grant; →own_and_reportsonly whenviewAllRecords: falseisAdmin falseviewAllRecords:false+ same readScope) 1 rowsys_permission_set.object_permissionsrow carriesreadScope: own_and_reportsin ARM 2, and the depth resolved from that stored row is stillorgplugin-securityreturnsorgon(viewAllRecords || modifyAllRecords)before the only runtime read ofop.readScope;plugin-sharingthen returns a null read filter fororg⭐ ARM 3 is what makes ARM 2 a real null rather than a dead harness — the same rig detects narrowing when narrowing exists.
node_modulesis absent from the shared checkout) and does not claim to have. It does not need to: the conclusion rests on the three behavioural legs, which stand without it.⭐ The finding that makes this urgent rather than tidy
⇒ Option A would not merely be inert. It would manufacture a false green on the very check the ruling named as proof — the exact failure shape #1755 cost this lane a round to remove.
ARM 4 — the correct shape (
viewAllRecords: false+ readScope) withsys_user.manager_idgenuinely wired — still returns owner-only, becauseresolveOwnerScopeIdsfails closed without@objectstack/security-enterprise. ARM 5 (ruled shape + chain wired) still sees all 3, so the inertness is not a missing-data artifact.⇒ Hierarchy read is an enterprise-edition capability. The lane charter is explicit: 「hotcrm 必须在 objectstack 社区版可运行…企业特性恒为增强,⛔ 永不硬依赖」.
四棱卡面
test/contract-write-depth.test.tspins the edition boundary rather than declaring something the edition cannot honour. D is that same answer for the read half — verified by this seat, the precedent file exists and reads as described.readScopebesideviewAllRecordswith no diagnostic is a metadata trap for every AI author, not just this repo.四棱同向 → D (+ E upstream). ⛔ Not auto-adjudicated: gate ③ fails (it would move a standing maintainer ruling) and gate ⑤ fails independently (
CONTRACT_REVIEW_TIERmeasured unavailable this round).维护者速读
改了什么 —— **什么都没改。**dev 按派发令的 fork 条款停手了,一个字节都没动。
为什么 —— 你 8-31 裁的是「给销售经理加一条
crm_opportunity的层级读权限,让requires[]里那条能力真的被用上」。方向没问题,但那条声明在这个仓里是空转的:该 profile 在同一个对象上已经有「看全部记录」的权限,平台会在读到层级设置之前就返回「组织级」。实测三条腿:今天看到 3 条商机,加了新声明还是 3 条,而对照组(把「看全部」关掉)只看到 1 条 —— 说明仪器是好的,不是测不出来。风险与代价(含回滚) —— 今天没有任何东西是坏的。A(照写)最省事但会造一个假绿。B(关掉「看全部」)是唯一能让那条声明生效的形状,但实测代价是经理的商机视图从 3 条塌成 1 条 —— 团队管道没了,而且这是权限边界改动。D 只加一条钉子,一次 revert 可回。
席位意见 —— 荐 D + E。D:本仓的写半边早就遇到过同一件事,答案就是钉住版本边界(
test/contract-write-depth.test.ts),我核过那个文件确实如此 —— 读半边照抄这个答案。它不碰权限边界、不造假绿、也不动你裁决里拒绝的那条(requires[]里什么都不摘)。E:平台接受一个自己永远不读的键还不报警告,这对每一个写元数据的 AI 都是陷阱,该在 objectstack 立卡 —— 我已经立了。你要做的 —— 选 A、B、C、D 还是 E?(C 已实测无落点:该 profile 上没有
viewAllRecords: true的对象只剩四个controlled_by_parent对象,scope 在那里本就是惰性元数据。)Generated by Claude Code
huangyiirene commentedon Sep 8, 2026
Option E is filed: objectstack-ai/objectstack#16870 — "A permission set accepts a hierarchy
readScopebesideviewAllRecords: true, never reads it, and emits no diagnostic — the declaration materialises and a capability census counts it as coverage."Filed unassigned and unlabelled for that board's triage, per the charter (⛔ this seat produces no
domain:*there). Dedupe was run in objectstack with two sentence-shaped queries, both returning non-empty — so the zero for this defect is real; the nearest neighbours (#4376, #14329, #13640, #7988) are all the inverse problem, a scope that is read getting around a gate.readScopebesideviewAllRecordsgets silence from the whole write → validate → deploy → audit loop.⛔ No
Blocked-by:line is added, because none is true — inventing one would put this card behind a platform queue it does not depend on.Generated by Claude Code
os-zhuang commentedon Sep 8, 2026
Ruling recorded — D + E: pin the read half's edition boundary; the platform trap is upstream (#16870); the 2026-08-31 action is amended on measured grounds (director seat, decision batch #94, 2026-09-08)
Provenance (who / verbatim / where): maintainer, live PM chat with the director seat (
session_01TezFG8ZMrNH6n5VTNpPpdH), standing delegation 「继续决策」 (2026-09-08T08:3xZ; batches #87–#93 confirmed or run under it) — rule per the presented recommendation; reversible by the maintainer. Recommendation adopted: hotcrm seat 5585200997 (四棱同向 D + E), on dev report 5585165424.What this amends, and why it may. The 2026-08-31 ruling (5481243500, maintainer 「其他同意」 to option 1) chose a direction — make
hierarchy-securityinrequires[]honest, do not drop it — and named an action:sales_manager.crm_opportunity.readScope = 'own_and_reports'. The action is measured inert on this shape: the profile already grantsviewAllRecords: trueon that object, and the platform resolvesorgbefore it ever readsreadScope(resolver call, end-to-end 3/3/1 rows with a firing control, the stored row carrying the key and still resolvingorg). Worse, the declaration is accepted with zero diagnostics and would turn the ruling's own item-3 census green on a change that changes nothing — a false green, the shape #1755 just cost this lane a round. The direction stands; the action is replaced.Ruled.
test/contract-write-depth.test.ts: on the community edition, a hierarchy-valuedreadScoperesolves owner-only becauseresolveOwnerScopeIdsfails closed without@objectstack/security-enterprise; the pin states that, withviewAllRecords: falseon a throwaway grant as the control that shows narrowing is detectable. ⛔ No newreadScopedeclaration in any profile. ⛔ Nothing removed fromrequires[](the 08-31 refusal of option 2 stands). File surface: one file undertest/— this crosses epic Epic: bring this repo's test farm back under the 2026-08-31 ruling — platform-first,os lint --strictfirst, then retire the local re-implementations by family #1579'stest/**fence for exactly one pin, as the guard-file precedent did ones-EShelp text names quote statuses by forms the console never shows —Presentado/Aceptadoagainst optionsPresentada/Aceptada#1530; stop and report if it needs more.readScopebesideviewAllRecords: true, never reads it and emits no diagnostic is a metadata trap; that card is graded on the objectstack board. ⛔ NoBlocked-by:here — D does not depend on it.viewAllRecordsforsales_manageroncrm_opportunityis the only shape in which the key is read, but on this edition its measured cost is the manager's pipeline collapsing to owner-only (3 → 1 rows even withmanager_idwired), and the profile header's stated intent is org-wide read; it is a permission-boundary change the maintainer may choose later, with that cost in front of them. ⛔ C has no landing point (measured).Reversal path: if the maintainer wants the showcase to demonstrate hierarchy read, the route is B plus an enterprise-edition rig, priced as its own card; the pin from D then becomes the test that flips.
Acceptance: the pin goes red if the enterprise resolver is present and narrows (so it is a real edition pin, not a tautology);
pnpm verifygreen; no profile changed; changeset per the gate (a test-only change).needs-user-decision→pm:queue.Generated by Claude Code
huangyiirene commentedon Sep 8, 2026
Claim: PM loop round R57 (wave 5 — ruled)⚠️ The previous branch for this card (
Session:
session_01PpRjGNnwyo2J1rrmekxB1WBranch:
claude/issue-1378-hierarchy-read-edition-pinWorktree:
hotcrm-issue-1378-pinDomain:
repo:hotcrm(single-lane repo — nodomain:*)File surface: one file under
test/+.changeset/(stop on breach; explain in the report)Container & model:
M,mode:subagent,model: default judgement tierClause-②: no — a pin that states what the edition does; ⛔ no declaration added anywhere, and the ruling forbids touching any profile
Thread-read:
5585417394Serial constraints cleared: no in-flight card. Sibling dispatched this wave: #1784 (
README.md·docs/DEPLOYMENT.md·content/docs/marketplace/**) ⇒ disjoint.claude/issue-1378-hierarchy-readscope-exercised) is empty and abandoned — this claim names a new branch so a returning dev fails its check loudly.Ruled — director seat, decision batch #94 (
5585417394): D + E⭐ The 2026-08-31 ruling's action is amended; its direction stands. That ruling chose to make
hierarchy-securityhonest and refused dropping it fromrequires[]— both survive. The action it named (sales_manager.crm_opportunity.readScope = 'own_and_reports') is measured inert on this shape and would turn the ruling's own item-3 census green on a change that changes nothing. ⇒ replaced, on measurement, ⛔ not overridden by preference.D — add the read-half counterpart of
test/contract-write-depth.test.ts: on the community edition a hierarchy-valuedreadScoperesolves owner-only, becauseresolveOwnerScopeIdsfails closed without@objectstack/security-enterprise. ⛔ No newreadScopedeclaration in any profile. ⛔ Nothing removed fromrequires[].E — objectstack#16870 carries the platform half. ⛔ No
Blocked-by:— D does not depend on it.⛔ A refused (inert + false green). ⛔ B refused now — lowering
viewAllRecordsis the only shape where the key is read, but its measured cost is the manager's pipeline collapsing 3 → 1 even withmanager_idwired; it stays available to the maintainer later, with that cost stated. ⛔ C has no landing point (measured).test/**crossing — authorised for exactly one pinThe ruling names this card and scopes it: "one file under
test/— this crosses epic #1579'stest/**fence for exactly one pin, as the guard-file precedent did on #1530; stop and report if it needs more." ⇒ same footing as #1755, #1535 and #1775 this round. Test file count is 164; if this adds one, say so and justify it against that sentence.⇒ A pin that merely asserts "owner-only" would pass on any engine and prove nothing. It has to be constructed so that the presence of the enterprise resolver would flip it. ⭐ The write-half precedent (
test/contract-write-depth.test.ts) already solved this problem once — read how it did it before inventing a shape.Generated by Claude Code
huangyiirene commentedon Sep 8, 2026
os-dev-report
{
"issue": 1378,
"status": "done",
"branch": "claude/issue-1378-hierarchy-read-edition-pin",
"pr": "#1791",
"premise_still_valid": true,
"summary": "Ruling D implemented as ONE file under test/ plus a changeset. test/hierarchy-read-depth.test.ts pins the read half of the hierarchy-scope edition boundary, the counterpart of test/contract-write-depth.test.ts: on the community edition a hierarchy-valued readScope resolves owner-only, because SharingService.resolveOwnerScopeIds fails closed to the caller alone without the hierarchy-scope-resolver service that ships only in @objectstack/security-enterprise. No profile changed; nothing removed from requires[]; the grants read through are throwaway sys_permission_set rows created inside the test. THE ACCEPTANCE WAS EXECUTED, NOT PREDICTED: an ablation registered a stand-in enterprise resolver into the same rig and three cases went red together, so the pin is a real edition pin and not a tautology. Test file count 164 -> 165, the exactly-one-pin surface the ruling authorises.",
"gates": {
"pnpm_verify": "PASS at 29ca6a1. Exit code captured before any pipe: wrapper VERDICT line 'VERDICT command-exit 0 - held the lock 151s (2m31s) - waited 0s'. Per-gate verdict lines, each the gate's own: 'Validation passed (1127ms)' / typecheck silent exit 0 / objectstack lint / 'i18n lint gate: 0 i18n/missing-* issues (13 total lint issue(s) reported, unaffected by this gate)' / 'source hygiene clean' / 'source token ratchet clean' / 'Build complete (1285ms)' / 'Test Files 165 passed (165)' + 'Tests 3453 passed | 1 skipped (3454)'.",
"new_pin_alone": "PASS. vitest run test/hierarchy-read-depth.test.ts: 'Test Files 1 passed (1)', 'Tests 14 passed (14)', VERDICT command-exit 0.",
"ablation_enterprise_resolver": "RED AS DESIGNED - this is the ruling's acceptance criterion, measured. A stand-in hierarchy-scope-resolver (me + my direct sys_user.manager_id reports) was registered into a throwaway COPY of the pin; result 'Tests 3 failed | 11 passed (14)', VERDICT command-exit 1. The three reds: 'no hierarchy-scope resolver is registered - this IS the open edition'; 'the manager reads only their OWN deal, never a REPORT-owned deal'; 'so own_and_reports conveys nothing beyond the own baseline here'. Readings: "expected [ 'Hierarchy REPORT deal', ...(1) ] to deeply equal [ 'Hierarchy manager deal' ]" and "expected [ 'Hierarchy REPORT deal', ...(1) ] to have a length of 1 but got 2". Mutation proven on disk before the run (anchor grep count 1 before, injected marker 0 before / 1 after, mount line 1 after; the script exits 3 if the injection did not land). Restored by an EXIT trap; tree verified clean afterwards - git status empty, git diff HEAD empty, ablation file absent. Both legs ran from committed state 29ca6a1. No permanent test file was left.",
"changeset_gate": "SATISFIED by construction: this PR adds .changeset/hierarchy-read-depth-edition-pin.md with EMPTY frontmatter - the 'releases nothing' declaration that .github/workflows/changeset-check.yml documents in its own comment as 'on par with the skip-changeset label'. No label was applied and none is needed.",
"dispatch_gates_mjs": "N/A - scripts/pm/dispatch-gates.mjs does not exist in this repo, as the dispatch stated. The gate list is package.json's own 'verify' chain: validate && typecheck && lint && lint:i18n-gate && hygiene && hygiene:tokens && build && test.",
"verify_lock": "Every build/test run went through the container-shared lock entry point (scripts/pm/os-verify-lock.sh from the objectstack checkout, slot hotcrm-1378-pin). Waited 0s on every acquisition; the queue was empty each time."
},
"line_budget": {
"applies": false,
"verdict": "NOT APPLICABLE - measured, not argued.",
"gate_output_line": "Source token ratchet - authored surface: src//*.ts minus src/translations, src/data",
"why": "Neither changed path is in that surface: one file under test/ and one under .changeset/. The gate reads src//.ts only.",
"measurement": "Ran scripts/check-source-token-ratchet.mjs twice - once with both new files moved out of the tree, once with them in place. The two gate outputs are BYTE-IDENTICAL (diff empty). Both read: 'business semantics ~84,609 tokens (ceiling ~100,000; headroom ~15,391)', 'interaction layer ~37,844 tokens (ceiling ~40,000; headroom ~2,156)', 'authored total ~137,099 tokens (ceiling ~140,000; headroom ~2,901)'. Exit 0 both times.",
"delta": 0,
"restore_proof": "The two files were moved aside and moved back; their SHA-256 digests were captured before and compared after, and both matched (pin 32f337d4566223e208f42ad9db87473626ccb93f8beef107be088faaf4cde3b6, changeset 317b256c31ff4e95c60e68a9dc31e71c5c54636107c1d813403bc42d79f40e5d).",
"note": "The dispatch's earlier reading (~137,052 / headroom ~2,948) differs from ~137,099 / ~2,901 because main moved between that dev's base 9371173 and this one's edf5083. It is not my diff: my diff touches zero files under src/, and the before-leg above measures that directly."
},
"deviations": [
"CHANNEL SWITCH, DECLARED. A repo-scoped REST read of this card returned 403 with the body 'GitHub access is not enabled for this session. An org admin must connect the Claude GitHub App for this organization.' The card body and the first 15 of 31 timeline items were then read through the zero-quota public web payload channel. That channel renders only the first page, so the TAIL - which is where the operative ruling lives - required one MCP issue_read get_comments (page 2, perPage 5). It returned 5585165424, 5585200997, 5585217102, 5585417394 and the claim 5585959633. The card was read to the last page as instructed.",
"CLAIM VERIFIED, NO SECOND CLAIM POSTED. The newest Claim: comment (5585959633) names branch claude/issue-1378-hierarchy-read-edition-pin, which is the branch used. The older, empty branch claude/issue-1378-hierarchy-readscope-exercised was not touched. The assignee field was never written.",
"PR BODY IS IN ENGLISH, no Chinese maintainer-summary block. This is deliberate and reversible on request: this repo's AGENTS.md rules 'Keep code, identifiers, commit messages, PR titles/bodies, and code comments in English' while all user-facing replies are Chinese. Flagging it because the seat's own comments on this card carry a Chinese maintainer-summary section.",
"THE PR TEMPLATE'S HTML COMMENTS WERE NOT REPRODUCED. The dispatch forbids HTML comments in GitHub text (the sanitizer eats short angle-bracket fragments, including inside backticks). The template's section headings are followed; its comment markers are not. The PR body was read back in full after creation and survived intact.",
"ONE OUT-OF-SCOPE OBSERVATION WAS NOT ADDED TO THE VERIFIED PR BODY, and is recorded here instead (see out_of_scope_findings). The body had already been posted and read back verbatim; re-typing 8KB of verified text to restate a warning that this repo's own pnpm validate prints on every run, on main, is a worse trade than recording it in this report. Declaring the choice rather than making it silently.",
"NO DEDUP search_issues WAS RUN, because nothing was filed. The single out-of-scope observation is recorded as noted-not-filed, so there was no card to dedupe against and no search budget was spent.",
"THE RULING'S OWN ITEM-3 CENSUS COMMAND (node scripts/dev-local/verify-position-surface.mjs --census) WAS NOT RUN AND IS NOT CLAIMED. It lives in the cloud repo's walled rig; scripts/dev-local does not exist here. It was also not the acceptance for ruling D - decision batch #94 replaced that acceptance with 'the pin goes red if the enterprise resolver is present and narrows', which is the ablation above."
],
"files_changed": [
"test/hierarchy-read-depth.test.ts (new, 493 lines, +493)",
".changeset/hierarchy-read-depth-edition-pin.md (new, 39 lines, +39)"
],
"file_surface_check": {
"authorised": "one file under test/ plus a changeset",
"actual": "exactly that - git diff --stat against the recorded base edf5083 shows 2 files changed, 532 insertions, 0 deletions",
"test_file_count_before": 164,
"test_file_count_after": 165,
"metric": "find test -name '.test.ts' | wc -l at base edf5083 = 164; the verify run reports 'Test Files 165 passed (165)'. (find test -type f = 174 at base - the difference is helpers and fixtures, which is why the dispatch's 164 is the .test.ts count.)",
"needed_more": false,
"note": "The ruling says 'stop and report if it needs more'. It did not need more: the throwaway grants live inside the one file as sys_permission_set rows, so no helper and no profile was required."
},
"zone_2_measurements": {
"1_resolver_behaviour_re_derived_not_inherited": "All three re-derived in this worktree against the installed 17.3.0 packages, and all three are now asserted by the committed pin rather than only measured. (a) getEffectiveScope('read','crm_opportunity',[sales_manager]) returns 'org', and returns 'org' again with readScope:'own_and_reports' spliced into that same grant - so the readScope is inert beside viewAllRecords: true. (b) The same key resolves to 'own_and_reports' the moment viewAllRecords is false. (c) With the correct shape AND sys_user.manager_id genuinely wired (read back from the database in a negative control), the manager still reads OWNER-ONLY: one deal, its own, not its report's. That is the fact the pin exists to state, and the ablation shows it flips to two deals when a resolver is present - so (c) is a reading about the absent resolver and not about absent data.",
"2_node_modules_and_source_citations": "node_modules was ABSENT in the fresh worktree. pnpm install was run first (exit 0, 664 packages) and every cited line was then opened in the installed package. Cited and read: @objectstack/plugin-security 17.3.0 dist/index.mjs:1996 'if (opClass === "read" && (op.viewAllRecords || op.modifyAllRecords)) return "org";' and :1998 'const s = opClass === "read" ? op.readScope : op.writeScope;'. Independently re-derived that :1998 is the ONLY runtime read of op.readScope in any installed @objectstack package (grep over node_modules/@objectstack//dist/index.mjs; the one other hit, :12204, is a local variable, not op.readScope). Also read: @objectstack/plugin-sharing 17.3.0 dist/index.mjs:3062 resolveOwnerScopeIds with ':3066 if (!resolver) return [me];' as the fail-closed line, and its buildReadFilter at :2178-:2190; @objectstack/spec ObjectAccessScope doc defining own_and_reports as 'me + my sys_user.manager_id report chain'; and validateHierarchyScopeCapability, whose diagnostic text the pin asserts.",
"3_line_budget": "NOT APPLICABLE - see the line_budget field. The gate's own surface line is cited there and the before/after outputs are byte-identical.",
"4_what_would_make_this_test_wrong": "Stated in both places as instructed. The pin's file header carries a numbered 'What would make this test WRONG' block and the PR body repeats it: (1) an enterprise-edition rig - install @objectstack/security-enterprise, the resolver registers, three cases go red; that is the reversal path the ruling names and the correct response is to rewrite the file for the enterprise reality, not to relax it; (2) the platform moving hierarchy resolution into the open edition, which the capability-registry case notices; (3) resolveOwnerScopeIds ceasing to fail closed, which is a security regression to report upstream rather than a stale expectation; (4) crm_opportunity losing sharingModel 'private' or its owner field, which would move the subject out from under the pin. Individual cases also carry inline notes saying which reading flips them."
},
"tests": "pnpm verify green at committed 29ca6a1, exit 0 read from the wrapper's own VERDICT line before any pipe: 'Test Files 165 passed (165)', 'Tests 3453 passed | 1 skipped (3454)', plus 'Validation passed', 'i18n lint gate: 0 i18n/missing-* issues', 'source hygiene clean', 'source token ratchet clean', 'Build complete'. ABLATION (the ruling's acceptance): a stand-in enterprise hierarchy-scope-resolver registered into a throwaway copy of the pin turns it RED - 'Tests 3 failed | 11 passed (14)', with the manager's visible set going from ['Hierarchy manager deal'] to ['Hierarchy REPORT deal', ...(1)], length 1 -> 2. Mutation proved on disk before the run (grep counts before/after, script exits non-zero if the injection did not land); restored by an EXIT trap; git status and git diff HEAD both empty afterwards; nothing permanent added. Control that narrowing is detectable: an org-wide arm one bit apart (viewAllRecords: true) reads all five seeded deals in the unmutated run, so the one-row result is a real narrowing from a working harness. Negative control that owner-only is not missing data: the report's sys_user.manager_id is read back from the database and asserted to be the probe manager.",
"mcp_calls": "4 - one issue_read get_comments (the timeline tail, where the operative ruling lives), one create_pull_request, one pull_request_read (body read-back), one add_issue_comment (this report). The card body and the first 15 timeline items came through the zero-quota web payload channel, not through MCP.",
"open_questions": [],
"out_of_scope_findings": [
"noted, not filed: pnpm validate reports on main and on this branch alike that page 'sales_home_page' declares a page:card 'description' prop that ComponentPropsMap does not declare - an authored key the renderer never reads. It is NOT a category (c) trap: the platform already closed that silence and now emits the diagnostic (its own text says an undeclared prop 'was dropped in silence' until the shape was closed), so an author gets a loud receipt today. What is left is one dead key in the app, which the rules put in the do-not-file column. It is also maximally visible already - this repo's own verify chain prints it on every run, in every PR's CI. Successor named: the next PR that touches src/pages/, which cannot run pnpm validate without reading it.",
"noted, not filed: pnpm validate also warns that hierarchy-security is provided by @objectstack/security-enterprise and suggests adding the package or removing the token from requires[]. This is the very boundary the pin now states in executable form, and the ruling forbids acting on either suggestion. Recorded in the PR body's Additional Notes so a reviewer does not read it as new. Successor: none - it is the subject of this card, not a side finding."
]
}
Generated by Claude Code
huangyiirene commentedon Sep 8, 2026
ACCEPT — PR #1791, head
974d2a6c(one REWORK round, described below). Ruling D delivered; E already filed as objectstack#16870.The fence crossing — verified against the ruling's own words, not assumed
This PR adds a file under
test/**, epic #1579's fenced territory. I checked the authorization rather than inheriting it, because I got this wrong on another card an hour ago (#1730, where only a seat ruling existed and I had to withdraw the dispatch). Here the director ruling5585417394names this card and scopes the crossing verbatim:Delivered surface, measured against the recorded base
edf50831: 2 files, +532, −0. Test files 164 → 165. ⇒ exactly the authorised surface, and the ruling's "stop and report if it needs more" was never triggered.The acceptance was executed, not predicted — which is the whole point of this card
The ruling's acceptance was deliberately hard: "the pin goes red if the enterprise resolver is present and narrows (so it is a real edition pin, not a tautology)." A pin merely asserting "owner-only" would pass on any engine and prove nothing.
Three cases are constructed so the resolver's presence flips them, and the ablation the dev ran turned exactly those three red together (
Tests 3 failed | 11 passed, exit 1):no hierarchy-scope resolver is registered — this IS the open editionthe manager reads only their OWN deal, never a REPORT-owned deal['Hierarchy manager deal']→ 2 rowsso own_and_reports conveys nothing beyond the own baseline hereown.length === hier.lengthstops holding⭐ And the ablation was proved to have landed before it was believed: anchor grep counts before/after, an injected marker 0→1, the script exiting non-zero if the injection missed, restoration by an
EXITtrap, andgit status/git diff HEADboth verified empty afterwards. Both legs ran from committed state. ⛔ That is the difference between "I ran an ablation" and an ablation you can hold someone to.The controls are the kind that make a null reading mean something
narrowing is DETECTABLE: the org-wide arm reads every seeded deal— a principal one bit apart (viewAllRecords: true) reads all five. So the one-row result is a real narrowing from a live harness, ⛔ not a rig that returns nothing for everyone.the manager chain is really wired — owner-only here is NOT missing data—manager_idis read back out of the database and asserted to point at the probe manager. This is the control most pins of this shape omit, and without it the central reading would be indistinguishable from an unwired fixture.each probe principal holds exactly its throwaway set and no admin bypass— asserts no app profile leaked in andhasPlatformAdminGrantis false. The first-user auto-promotion is deliberately burned on a throwaway user, which is a real trap avoided rather than a hypothetical one.⭐ It makes the ruling self-enforcing
expect(authoredReads, 'no profile may declare a hierarchy readScope (#1378 ruling)').toEqual([])— the ruling's ⛔ prohibition is now something the suite checks, not something a future agent has to remember. Same forrequires[]staying intact. Andexpect(authoredWrites).toEqual(['sales_manager.crm_contract'])stops the write half being dropped silently and leaving this file as the app's only statement about hierarchy scopes.One REWORK round, and why it was not a nit
:225readthe spec gate accepts the read half and refuses the half— a dropped word left it naming no axis. Sent back rather than waved through, because #1775 landed this same round for exactly this class: a test name claiming something the test does not do. A test name is documentation to the next agent, and this file is the app's statement of an edition boundary. Now:the spec gate accepts a hierarchy readScope only when the capability is declared (#1378), which is the predicate both cases actually turn on.⭐ The dev found the root cause rather than just patching the string: it was a mangled adaptation of the write half's
accepts the pair and refuses the half (#880), where "the pair" means the scope plus therequirestoken. Dropping that word is what emptied the sentence.The dev reports authored total ~137,099, headroom ~2,901; I have been carrying ~137,052 / ~2,948. Theirs is right and mine was stale —
mainmoved between the two bases. They demonstrated it rather than argued it: the ratchet was run with both new files moved out and moved back, and the two outputs are byte-identical (delta 0, restore proved by SHA-256 on both files). ⇒line_budgetN/A is measured here, not asserted from the gate's scope line alone.Gates
pnpm verifyexit 0 at the pushed sha, read from the wrapper's own verdict line before any pipe:Test Files 165 passed (165)·Tests 3453 passed | 1 skipped (3454)·source token ratchet clean. Changeset present with empty frontmatter — this lane's sanctioned "releases nothing" declaration.CI at
974d2a6c: 5/8success, withBuild and Test (22.x),PlaywrightandAnalyze Codestill converging ⇒ ⛔ ready-flip withheld until all eight reportsuccess.test/**is not a governed path, so once green this lands by seat under the #1742 ruling (batch #81) rather than waiting on a human merge.Generated by Claude Code