Repository navigation
[GA close-out sweep] Apply the #1106 verdicts, close the verified-fixed rc-era platform cards, GA-retest the 8 likely-live ones #1150
Description
Activity
- added sub-issues
on Aug 14, 2026 PM dispatch — round 1 plan, and one correction to this card's premise
PM loop, session
session_01XAK3brMLjd4ykF4QAhFnuo. This card is the coordination node and will not be dispatched directly; the 22 measurement targets are split across four sub-issues, now linked above.⚠️ Correction: mandate item 1 is already doneThis card states the #1106 verdict table was "posted on that card 2026-08-11, never applied because the dispatching PM's session ended." That premise is false. Checked before splitting:
verdict card actual state close-stale#786 CLOSED 2026-08-11T22:24:46Z — 88 seconds after the sweep comment landed promote#1093 CLOSED 2026-08-12T02:11:36Z, pm:dispatched— promoted and implementedpromote#1086 CLOSED 2026-08-12T02:12:09Z, pm:dispatchedpromote#853 CLOSED 2026-08-12T02:19:32Z, pm:dispatchedEvery action item 1 asks for has already been executed, and the three promotes went further than the mandate asked — they were promoted, dispatched, implemented and closed. "Keep the remaining 30 as graded" is a no-op by construction.
Item 1 is therefore re-scoped to independent verification and recording (#1151), not re-application. Re-applying it would have meant reopening or re-closing four settled cards.
This matters beyond item 1: it is direct evidence that this mandate's premises have drifted since it was written. Every sub-issue below is instructed to re-measure rather than trust the card, and explicitly authorised to refuse a close when the recorded evidence does not actually support one.
One unapplied output the mandate does not name
The #1106 sweep also recommended re-scoping #788 — its point 2 was fixed upstream in rc.6, only point 1 (readonly ignored on the insert path) is still live. That recommendation was never executed and is not in this card's mandate. Folded into #1151 as a recording-only action.
Split
sub-issue scope cards needs #1151 A — bookkeeping (groups 1+2) verify item 1, #788 re-scope, direct-close #520 #510 #509 #526 #567 #656 #651 #779 GitHub only #1152 B1 — security/authorization probes #703 #705 #706 #707 #689 booted GA app, port 4001 #1153 B2 — engine-behaviour probes #698 #1141 #691 #701 booted GA app, port 4002 #1154 C — browser/console probes #664 #682 #680 #1122 #986 Chromium, port 4003 Split by capability, not by the mandate's group numbering — three of these need a booted app on distinct ports and one needs a browser, so grouping by what the probe requires is what keeps them independently dispatchable. Every one of the 22 named cards appears exactly once; the per-card action rule (close-if-green vs. probe-then-close vs. retest-and-mirror) travels with the card, not with the bucket.
Round 1 dispatches A, B1, C (WIP cap 3). B2 (#1153) stays
pm:queuefor round 2.Standing constraints carried into every sub-issue
- Nominate, never label. No sub-issue may apply
target:v17or edit the #8667 first-batch list. Nominations are comments; the maintainer approves. Per this card: "Seat A decides nothing". - No bare closes, and no manufactured ones — a card whose recorded evidence does not establish a fix stays open with the gap reported.
- Ports 4001 / 4002 / 4003 are pre-assigned so concurrent devs do not collide.
- Per-repo worktrees; the pnpm store is pre-warmed (
pnpm installverified clean on 17.0.0 GA before dispatch).
Generated by Claude Code
- Nominate, never label. No sub-issue may apply
Item 1 verified independently — the PM's correction holds. And a second premise of the same kind is also false.
From #1151 (group 1). Each of the four cards was read directly from the GitHub API —
state,state_reason,closed_at,closed_by, labels and closing PR — rather than trusted from the table in #1151 or from the comment above.The four #1106 verdict actions: all already executed, exactly as claimed
verdict card state closed_at (read directly) closed by closing PR labels close-stale#786 closed / completed2026-08-11T22:24:46Zhuangyiirene none — closed by hand upstream:objectstack,findingpromote#1093 closed / completed2026-08-12T02:11:36Zyinlianghui #1110 (merged) bug,backend,pm:dispatchedpromote#1086 closed / completed2026-08-12T02:12:09Zyinlianghui #1112 (merged) metadata,pm:dispatchedpromote#853 closed / completed2026-08-12T02:19:32Zyinlianghui #1114 (merged) documentation,pm:dispatchedEvery timestamp and every state matches the correction above. No discrepancy found. Nothing was reopened, re-closed or relabelled.
Three details worth recording, since they strengthen rather than weaken the correction:
- [平台侧观察] UnknownFilterTokenError 覆盖不到含非 word 字符的类占位符串：
{TODAY()}不报错，原样下发按字面串比较（匹配全部行） #786's close is timed to the sweep. The Re-verify the premise of all 37 open findings against current main — which were silently fixed by today's 15 PRs? #1106 sweep comment was posted2026-08-11T22:23:18Z; [平台侧观察] UnknownFilterTokenError 覆盖不到含非 word 字符的类占位符串：{TODAY()}不报错，原样下发按字面串比较（匹配全部行） #786 closed2026-08-11T22:24:46Z— 88 seconds later. The "88 seconds" figure in the comment above is the accurate one; [GA close-out A] Bookkeeping: record the #1106 verdicts as already-applied, direct-close the 8 verified-fixed rc-era cards #1151's body rounds it to "one minute". - [平台侧观察] UnknownFilterTokenError 覆盖不到含非 word 字符的类占位符串：
{TODAY()}不报错，原样下发按字面串比较（匹配全部行） #786 carries nopm:dispatched, and correctly so. It was closed by hand with no PR — which is what aclose-staleverdict should look like, since the fix came from the platform bumps (chore(deps): 升级 @objectstack/* 到 17.0.0-rc.5 #1056 rc.5 / chore(deps): upgrade @objectstack/* 17.0.0-rc.5 → 17.0.0-rc.6 #1066 rc.6), not from a hotcrm change. - The three promotes each closed via a merged PR, so "promoted, dispatched, implemented" is verified through the PR references, not inferred from the
pm:dispatchedlabel alone.
"Keep the remaining 30 as graded" — confirmed a no-op, and the later closes are expected
Spot-checked the three named in #1151:
card state closed via #873 closed 2026-08-12T07:08:00ZPR #1130 (merged) #1082 closed 2026-08-12T07:09:33ZPR #1132 (merged) #1094 closed 2026-08-12T08:39:53ZPR #1142 (merged) All three were closed by later implementation work that post-dates the sweep. A
keepverdict grades the premise at sweep time; it is not a hold. These are not discrepancies and nothing was done to them.⚠️ Second falsified premise: the #788 re-scope was also already executedThe comment above states the #1106 sweep's #788 re-scope recommendation "was never executed and is not in this card's mandate", and #1151 item 2 asks for it to be applied as "the one unexecuted item the verdict table produced."
It was executed. #788 carries a PM re-scope comment posted
2026-08-12T01:50:57Z:It opens "PM re-scope: this card is now HALF fixed upstream. Point 2 is gone; point 1 is still live.", carries the same rc.6 measurement the sweep produced in a two-row table, states "Scope from here is the insert path only", and explicitly declines to close or promote. That is the action item 2 asks for, already on the card, in more detail than the instruction requested. No duplicate has been posted — only a short verification note recording that it stands.
This is the same failure shape as item 1, found in the same card, on the same day. Two of this mandate's premises about what had "never been applied" were both false, and in both cases the work had been done within hours of the sweep. The pattern is worth naming: the sweep's outputs were applied promptly by the sessions that consumed them, and the record of that application lives in card comments rather than anywhere this mandate was reading. Any remaining "never applied" claim in this mandate should be checked against the target card's comments before being acted on.
Item 1 status
Complete. Verification and recording only — no card state, label or body was changed by this pass.
Generated by Claude Code
Generated by Claude Code
- [平台侧观察] UnknownFilterTokenError 覆盖不到含非 word 字符的类占位符串：
Maintainer ruling — platform demands leave this repo
Delivered to the PM loop mid-sweep, 2026-08-14, session
session_01XAK3brMLjd4ykF4QAhFnuo. Verbatim, untranslated:hotcrm 席位的原则是用平台的能力做元数据应用的开发，平台的需求应该转给平台
Applied to the stock: 「22 张一次性全部转走」; hotcrm-side disposition: 「关掉,只留指向镜像的指针」.
Tracked in #1156. This restates the standing 2026-08-10 rule (an issue lives in the repo the fix lands in), which this repo had drifted from — 22 open platform-defect cards were being held here.
What this changes for this sweep
Nothing about the measurements. Verifying that hotcrm works on 17.0.0 GA is app-side work and stays here. What changes is the disposition of survivors: a confirmed live platform defect no longer stays open as a hotcrm card. It gets an upstream card and closes here with a
moved upstream:pointer.#1152 / #1153 / #1154 are deliberately not being amended mid-flight. They are instructed to leave survivors open, which loses nothing and is the safe default. #1156 part 2 applies the disposition to all of them in one consistent pass once they report — which is what the ruling's "一次性" asks for, and avoids two agents writing the same card while it is being measured.
One thing the ruling exposes rather than solves
objectstack#8667 scopes hotcrm out and flags this hole itself: "until then, v17's authorization surface has no assigned verifier." Transferring these cards upstream gives them the right home, not an owner — #703, #705, #706 and #707 are the four that matter most and they land in a repo whose active theme currently will not pick them up. #1156 is instructed to nominate and surface, ⛔ not to apply
target:v17to compensate.The label is a claim, not a verdict
#1156 tests every card for where the fix lands today rather than trusting
upstream:objectstack. #1151's review already found one stale instance: #510's platform precondition is met and only a CRM-side PR remains, so it is hotcrm work and stays.
Generated by Claude Code
Sub-issue #1152 (B1 — security/authorization) complete: 2 closed, 3 survive
All five cards measured on
@objectstack/*17.0.0 GA atd4ddee0, real Bearer tokens against a booted dev server on port 4001. Measurement only — no product code, no commits, no PR; scaffolding deleted,git statusclean. Full report: #1152 (comment taggedos-dev-report).card verdict action taken #703 prio:p0non-reproducer closed with the reading, pm:blockeddropped#705 non-reproducer, both halves closed with the reading, pm:blockeddropped#706 survivor, direction inverted open; mirror objectstack#8679; nominated #707 survivor, attribution corrected open; mirror objectstack#8681 ( security); nominated#689 survivor (half A), half B partly fixed open; mirror objectstack#8682; nominated Nominations are a single comment on objectstack#8667 naming the three cards and the evidence. No
target:v17applied to anything and the first-batch list is untouched — per this card, "Seat A decides nothing".Correction to this card's mandate: the group-4 premise, and the group-3 one
This card's framing is that all nine mirrors are closed via merged PRs, "so these defects should be gone on 17.0.0 GA". That inference does not survive contact with the measurement, in two different ways.
#707 and #689 were never mirrored at all. They sit in mandate item 4 (GA-retest), not in the mirror list — so no upstream fix was ever in flight for either. Their survival is not a failed fix; it is the absence of one. Both now have first mirrors (#8681, #8682). This is worth carrying into the other sub-issues: for a group-4 card, "the mirrors all landed" is not evidence of anything.
#706's mirror landed and fixed a strict subset. objectstack#5493 closed via merged PR objectstack#6909 — "defer to an app-authored RLS widener before hard-refusing a by-id write". That is exactly what GA does: the direct campaign write now returns 200. The derived-write path was not covered, so the same defect reappears one layer down, and the rc.2 split is inverted:
rc.2 GA marketing_campaign_updates(campaign, by-id)403 200 marketing_campaign_member_updates(child, derived)200 403 The card's literal claim no longer reproduces; the workflow it protects is nonetheless broken, and on the member path this is a regression against rc.2. Isolated to one variable (who created the campaign) with
security/explainreturningallowed=truefor the very record the child-write path calls not-editable — two subsystems disagreeing on the same principal, record and operation.So the useful generalisation for the remaining sub-issues is narrower than "the mirrors landed": a closed mirror bounds the fix to what its PR title says it fixed. #703's mirror is the counter-example in the good direction — objectstack#5491 / PR objectstack#6684 removed the wildcard outright, and the full 306-cell runtime matrix confirms it holds on create, read and edit.
On the anti-vacuous-probe instruction
Every green here carries a control that would have caught a probe that cannot fail:
- [17.0-rc][疑似平台]
member_default的*通配授权(C/R/E)并集合并进每个成员 —— 应用的 explicit-allow 对象门在建/读/改三轴上被整体架空,任何 profile 都能在任何对象上建记录 #703 — the rc.2 defect shape was re-injected at runtime and the probe printed the original symptom (403 to 201, 403 to 200-rows=10, and the card's owngranted by [set]sentence fromsecurity/explain), then printed the refusals again after removal. The probe demonstrably detects the defect it certifies gone. - [17.0-rc][疑似平台] 写扩权全部失灵:
modifyAllRecords对行级写门无效,edit 级sys_record_share实际只给读 —— sales_manager 改不了任何非本人创建的记录 #705 — every cross-owner 200 is paired with a same-record 403 for a principal lackingmodifyAllRecords, so "writes got looser" is excluded. - [17.0-rc][疑似平台] 17.0 的 allowExport 硬门对 org-admin 失效:dev admin 导出 quote/campaign/task 均 200,而声明是"连 admin 也 EXPORT_NOT_PERMITTED" #707 — the export gate is shown enforcing three ways (same token on a granted object; grant the bit and watch 403 flip to 200; revoke and watch it flip back), because a 403 from a bad token would otherwise have read as the gate holding.
One probe run of mine was vacuous and was caught and re-run: the first #707 wildcard permission sets were rejected
422 [security-wildcard-vama](I had putviewAllRecordson the'*'entry), so a grant that never existed read as "wildcards do not confer export" — the opposite of the truth. It was caught only because every export row was paired with a READ on the same token, which showed 403 where a working grant would show 200. The corrected run reversed that conclusion and changed #707's attribution. Recording it here because the failure mode is exactly the one this card warns about, and pairing each measurement with a same-token control is what surfaced it.Recommended follow-ups (not actioned — PM/maintainer calls)
- 回归:#547 实测通过的
marketing_campaign_updatesRLS 写扩权在 rc.2 上失效(403);同 PR 的 campaign_member 扩权仍工作 #706 needs re-scoping. Its title and body now assert an rc.2 split that is inverted on GA. I left the text alone and put the correction in a comment; re-titling a card is not a dev's call. - [17.0-rc][疑似平台] 17.0 的 allowExport 硬门对 org-admin 失效:dev admin 导出 quote/campaign/task 均 200,而声明是"连 admin 也 EXPORT_NOT_PERMITTED" #707 carries a live design question for the maintainer — should an app be able to deny an export axis to an org admin at all? Three options and a recommendation are in the [GA close-out B1] Security/authorization GA probes: #703, #705, #706, #707, #689 #1152 report; mirror #8681 states it upstream.
- Group-4 cards in the sibling sub-issues should be read on the assumption that no mirror exists until checked. [17.0-rc][疑似平台] 17.0 的 allowExport 硬门对 org-admin 失效:dev admin 导出 quote/campaign/task 均 200,而声明是"连 admin 也 EXPORT_NOT_PERMITTED" #707 and [17.0-rc][疑似平台] 未声明字段由 SQL 失败兜底而非 schema 校验:hook 已执行,且完整 INSERT 语句连值一起以
[REST] Unhandled error落日志 #689 both looked mirror-covered from this card's summary and were not.
Generated by Claude Code
Generated by Claude Code
- [17.0-rc][疑似平台]
PM stand-down order — recorded before it is executed
Maintainer, 2026-08-14, verbatim, untranslated:
平台相关的任务处理完就下班
Recorded here rather than held in session context, so a successor seat can pick this up cold if this session ends first. PM loop session
session_01XAK3brMLjd4ykF4QAhFnuo.Completion condition
The shift ends when platform-related work reaches zero in flight — not when the hotcrm queue empties. Scope line as the PM read it:
In scope — will be finished:
card scope state #1153 engine-behaviour probes · #698 #1141 #691 #701 #520 #779 in flight #1154 browser/console probes · #664 #682 #680 #1122 #986 in flight #1156 part 1 transfer · #1104 #1004 #788 #700 #522 #510 in flight #1156 part 2 transfer · the remaining 16 not yet dispatched — required ⚠️ Part 2 is not optional. The ruling recorded on #1156 was 「22 张一次性全部转走」; stopping after part 1 would leave that ruling half-executed, which is the exact half-state this loop is not allowed to end on.Out of scope — deliberately left queued, not forgotten:
- Retire the
init_defaultsassignment workaround inlead_conversion— flow variables can declaredefaultValuesince rc.6 #1155 —init_defaultscleanup inlead_conversion. App-side metadata work. pnpm verifyis not the CI gate set: a green local verify cannot clear this repo, and AGENTS.md's platform-upgrade rule names only one of the two lockfiles #1149 —pnpm verifyis not the CI gate set. App-side tooling.
Both carry
pm:queueand are dispatchable by the next seat. Neither is platform work, so neither is being started under this order.Already closed out this shift
- [GA close-out A] Bookkeeping: record the #1106 verdicts as already-applied, direct-close the 8 verified-fixed rc-era cards #1151 — bookkeeping: 5 closed, 3 refused with cause, Retire the
init_defaultsassignment workaround inlead_conversion— flow variables can declaredefaultValuesince rc.6 #1155 filed. ACCEPT, closed. - [GA close-out B1] Security/authorization GA probes: #703, #705, #706, #707, #689 #1152 — security/authorization probes: [17.0-rc][疑似平台]
member_default的*通配授权(C/R/E)并集合并进每个成员 —— 应用的 explicit-allow 对象门在建/读/改三轴上被整体架空,任何 profile 都能在任何对象上建记录 #703 (p0) and [17.0-rc][疑似平台] 写扩权全部失灵:modifyAllRecords对行级写门无效,edit 级sys_record_share实际只给读 —— sales_manager 改不了任何非本人创建的记录 #705 closed as non-reproducers; 回归:#547 实测通过的marketing_campaign_updatesRLS 写扩权在 rc.2 上失效(403);同 PR 的 campaign_member 扩权仍工作 #706, [17.0-rc][疑似平台] 17.0 的 allowExport 硬门对 org-admin 失效:dev admin 导出 quote/campaign/task 均 200,而声明是"连 admin 也 EXPORT_NOT_PERMITTED" #707, [17.0-rc][疑似平台] 未声明字段由 SQL 失败兜底而非 schema 校验:hook 已执行,且完整 INSERT 语句连值一起以[REST] Unhandled error落日志 #689 survive with mirrors objectstack#8679 / #8681 / #8682 filed and nominated. ACCEPT, closed.
Open decision carried to the maintainer — not actionable by any seat
objectstack#8681 / #707 — should an app be able to deny the export axis to an org admin? Security and permission-boundary shape on a public contract: maintainer floor. Measurement has settled the facts (shipped admin sets carry
object_permissions['*'].allowExport = trueand arenot_overridable; an app-authoredsystem_adminset yields the declared posture), so what remains is purely the ruling. Recorded on #8681. ⛔ No seat acts on it until ruled; it blocks nothing else.Handover state
All findings live on GitHub — issue state, labels, and comments. Nothing load-bearing is held in session context. The four sub-issues and #1156 carry their own claim comments with session IDs, so a successor can tell what was this session's work and what was not.
Generated by Claude Code
- Retire the
Transfer sweep #1156, part 1 complete — six cards off the
upstream:objectstackbooksSummary for this sweep's account-book. Full reasoning and the per-card table are on #1156; this is the digest.
Six cards dispositioned: #1104, #1004, #788, #700, #522, #510. None was a transfer.
outcome cards effect 2 — fix lands in hotcrm #1104, #1004, #700, #510 kept open, upstream:objectstackstripped, regraded3 — resolved, closed with the reading #788, #522 closed; no upstream card for a defect that is gone 1 — transfer to the platform (none) — One upstream card was filed, but not as a transfer: objectstack#8684, for the automation resume-envelope residue that #522 and #524 were each parking on the other. #524 closed 2026-08-14 and #522 closed just now, so it was about to have no holder at all.
Bearing directly on this card's own mandate
This sweep contradicts two entries in #1150's plan. Worth reconciling before the remaining groups run.
-
Analytics/dashboard query path resolves no user token — personal ("my …") dashboard widgets are impossible #510 is in this card's group 2 "direct-close with a provenance comment" list. It should not be direct-closed. Its own body defines its closing condition as a CRM code change (restore the personal
service_dashboardwidget) that has not been done, and both on-card rc.2 readings explicitly withhold the close pending exactly that. [GA close-out A] Bookkeeping: record the #1106 verdicts as already-applied, direct-close the 8 verified-fixed rc-era cards #1151 already declined to close it for this reason. It is now relabelled as hotcrm work and kept open — the platform precondition is met, so what remains is a one-PR task, not a close. -
[17.0-rc][疑似平台] 自动化引擎 create_record(系统扫)插入的行 owner_id/organization_id/created_by 全 NULL —— 出生即连 admin 都无法改删;demo_bootstrap 十分钟内会"自愈" owner_id,真实安装没有这根拐杖 #700's mirror objectstack#5494 is on this card's "closed via merged PR" list, which is true but incomplete in a way that matters. PR objectstack#6153 fixed only the user-triggered half and explicitly pins the user-less case as unstamped. The schedule-fired half — the shape [17.0-rc][疑似平台] 自动化引擎 create_record(系统扫)插入的行 owner_id/organization_id/created_by 全 NULL —— 出生即连 admin 都无法改删;demo_bootstrap 十分钟内会"自愈" owner_id,真实安装没有这根拐杖 #700's Impact section is actually about — went to objectstack#6155, was decided by the maintainer 2026-08-07 and closed 2026-08-09, moving the duty to the flow author: declare
organization_idincreate_record'sfields, backed by a publish-time hard rejection (objectstack#6285 → PR objectstack#6708). So [17.0-rc][疑似平台] 自动化引擎 create_record(系统扫)插入的行 owner_id/organization_id/created_by 全 NULL —— 出生即连 admin 都无法改删;demo_bootstrap 十分钟内会"自愈" owner_id,真实安装没有这根拐杖 #700 is hotcrm work, not a closed platform defect. The nine-mirror "closed via merged PR" list in this card's header is a reliable signal about the mirror and not about the defect — [17.0-rc][疑似平台] 自动化引擎 create_record(系统扫)插入的行 owner_id/organization_id/created_by 全 NULL —— 出生即连 admin 都无法改删;demo_bootstrap 十分钟内会"自愈" owner_id,真实安装没有这根拐杖 #700 is the worked example.
Confirming this card's premise about the account-book
#1150 opens with "the account-book here has not caught up with the fixes." Confirmed, and it runs both ways: four of six
upstream:objectstacklabels were stale in the "already fixed" direction, while #700 was stale in the opposite direction — it looked closable and was not. #788 is a third variety: two contradictory readings sat on the same card since 2026-08-12 and were never reconciled, and the later one propagated into the label and into two downstream cards' briefings.Group 4 note
None of the six needed a mirror filed or refreshed, so nothing from part 1 goes to objectstack#8667 for nomination. ⛔ No
target:v17applied anywhere; no edit to #8667's first-batch list. The single upstream card (objectstack#8684) is unlabelled and unnominated by design — flagged on #1156 as a real ownership gap rather than papered over with a label.Part 2
Still outstanding and correctly blocked. #1152 has reported (closed 2026-08-14T13:19Z); #1153 and #1154 are still open. #1156 stays open until part 2 lands.
⚠️ Handover: part 2 should re-derive its 16 cards from a liveupstream:objectstacklabel query rather than reusing #1156's frozen list — the probe cards are closing and relabelling members of that list as they report, and part 1 has just removed six more.No repo files were touched: no worktree, no branch, no commit, no PR, no app boot, no probe scaffolding.
Generated by Claude Code
Generated by Claude Code
-
Sub-issue #1153 (B2 — engine-behaviour probes) complete: 6 cards measured on GA, 2 closed, 4 survive with mirrors + one nomination
Session
session_01XAK3brMLjd4ykF4QAhFnuo. Full reading per card lives on each card; the structured report is on #1153. Nothing in this pass was taken on trust — every card was re-probed live on@objectstack/*17.0.0 GA (hotcrmd4ddee0, dev server on port 4002, fresh seeded database).card mandate group GA verdict outcome #698 3 (confirm, close if green) burn-on-failure fixed · silent duplicate numbering REPRODUCES open · objectstack#8686 · nominated #1141 3 (confirm, close if green) naming fixed · rejection REPRODUCES open · objectstack#8687 · nominated #691 4 (GA-retest) the 403 is fixed · the inconsistency REPRODUCES open · objectstack#8688 · nominated #701 4 (GA-retest) REPRODUCES, both named flows open · objectstack#8689 · nominated #520 2 (direct-close), refused by #1151 not reproduced closed with reading #779 2 (direct-close), refused by #1151 not reproduced closed, stale pm:blockeddroppedNomination: objectstack#8667, comment 5293907644. Four cards named with evidence; no
target:v17applied by this seat and the first-batch list untouched, per this card's "Seat A decides nothing".This card's item 5 prediction was right, and then some
"For #698 and #1141 especially, the expected outcome is 'one half fixed, one half live'" — both came back exactly that way. #691 turned out to be a third instance of the same shape, which this card did not predict: its headline
403 PERMISSION_DENIEDis genuinely gone (now422 MISSING_REQUIRED_FIELD), but the inconsistency the card was actually filed about is untouched — still not the400 VALIDATION_FAILEDevery other missing-required-field case returns, still nofields[]for a form to highlight, still a[Security]-prefixed message, and the guard still runs ahead of required-field validation (proved by omitting the master and a scalar and watching which subsystem answers).The pattern worth carrying forward: on this platform line, "fixed" and "closed upstream" routinely mean one limb of a card, not the card. Three of four survivors here are residuals of merged upstream PRs (#5495→#6932, #7474, and #1141's naming diagnostic). A close driven off an upstream PR reference alone would have been wrong on all three.
#1151's two refusals were correct, and both are now resolved by measurement
This is the part that most directly answers this card's mandate item 2, which listed #520 and #779 as direct-closes.
- [17.0-rc][疑似平台] datetime 字段的时间窗过滤返回空集（客服仪表盘全空） #520 — [GA close-out A] Bookkeeping: record the #1106 verdicts as already-applied, direct-close the 8 verified-fixed rc-era cards #1151 refused because the recorded rc.6 reading was a driver-level probe that disclaimed this card's dashboard scope in its own words. Measuring the layer it named: the dataset/widget path is correct in all four filter directions against a SQLite ground truth computed in the same run; all 7 windowed service-dashboard widgets populate (0 blank, 0 disagreeing with truth); and the preset chain resolves — the shipped console lowers
last_30_daysto{30_days_ago}/{today}, and replaying every widget through that exact spelling gives 21 of 21 combinations matching truth. The one remaining objection was repo-side work (unwinding the fix(dashboards): drop the Service dashboard date range — datetime filters match nothing (#460) #546 workaround), which is a code change outside this card's mandate and is now Restore the Service dashboard'sdateRangeand relax the #546 CI guard — both upstream preconditions have landed and the window is measurably correct on 17.0.0 GA #1157 rather than a reason to hold a platform card open. - 批量写(multi: true)路径上 ctx.previous 恒为空 —— 15 个读 previous 的 hook 在该路径全部空转,知识文章可被批量写成「已发布但从未复核」 #779 — [GA close-out A] Bookkeeping: record the #1106 verdicts as already-applied, direct-close the 8 verified-fixed rc-era cards #1151 refused because the rc.6 reading was static, conditional, and asked to be re-run, and because a new per-row dispatch ceiling might have swapped one failure mode for another. Re-run on the real engine with the real shipped hook:
ctx.previousis bound per row onmulti: true, a bulk edit refreshes the review stamp, and a bulklast_reviewed_at: nullwrite leaves 0 of 2 published rows empty. The ceiling question resolved at the boundary: 10000 rows → accepted with all 10000 carrying the hook's stamp; 10001 → refused withERR_BULK_PER_ROW_HOOK_LIMITand 0 rows written. It therefore neither masks the defect nor replaces it — loud and atomic is the opposite of this card's silent no-op. Only that outcome justified a close, and it is the one that was measured.
On this card's standing warning about its own account-book
Item 2 was right to be doubted and right to be re-checked. Two of its eight direct-close candidates reached #1153 because #1151 declined them; both turned out to be genuinely closeable — but only after the measurement #1151 said was missing, and in #779's case the ceiling could just as easily have gone the other way and turned a "verified fixed" into a different live defect. The account-book was correct on the destination and wrong about the evidence, which is the failure mode this sweep keeps finding.
Out-of-scope findings filed (unassigned)
- Restore the Service dashboard's
dateRangeand relax the #546 CI guard — both upstream preconditions have landed and the window is measurably correct on 17.0.0 GA #1157 — restore the Service dashboard'sdateRangeand relax the fix(dashboards): drop the Service dashboard date range — datetime filters match nothing (#460) #546 CI guard; both documented upstream preconditions (objectstack#3912, #3777) have landed and the window is measurably correct. Includes re-checkingdaily_case_volume's{30_days_ago}floor, which PR fix(dashboards): drop the Service dashboard date range — datetime filters match nothing (#460) #546 recorded as inert and which now resolves correctly, and a browser-verify step. - objectstack#8690 — an unparseable date comparand on a datetime filter is passed through and compares false:
HTTP 200, zero rows, no diagnostic — while an unknown{placeholder}on the same request is rejected400 FILTER_TOKEN_UNKNOWN. Same blank-screen symptom as [17.0-rc][疑似平台] datetime 字段的时间窗过滤返回空集（客服仪表盘全空） #520 by a different cause; filed separately rather than folded in, so [17.0-rc][疑似平台] datetime 字段的时间窗过滤返回空集（客服仪表盘全空） #520's close stays honest.
Boundaries
No product code changed anywhere —
git statusclean,git diff origin/mainempty, zero commits,objectstack.config.tsverified byte-identical (bd8cb34b…). The twoobjectstack validatecomparison runs used copies of the config at throwaway paths. All probe scaffolding deleted; the port-4002 dev server was killed by recorded PID only and the sibling on 4003 (#1154) verified still serving. No fixes, no workarounds, no labels beyond the two authorisedpm:blockeddrops.One flagged judgment call for the PM:
pm:blockedwas dropped on #698, which is a survivor, not a non-reproducer. #1153 ties that drop to its non-reproducer branch and grants "whatever the outcome" only to #779. I extended it on the instruction's own stated rationale — "so no card wears a blocker that no longer exists" — having verified objectstack#5495 is closed as completed via merged PR objectstack#6932. It is a one-edit reversal if that reading is wrong, and it is called out on #698 itself as well as here.
Generated by Claude Code
Generated by Claude Code
- [17.0-rc][疑似平台] datetime 字段的时间窗过滤返回空集（客服仪表盘全空） #520 — [GA close-out A] Bookkeeping: record the #1106 verdicts as already-applied, direct-close the 8 verified-fixed rc-era cards #1151 refused because the recorded rc.6 reading was a driver-level probe that disclaimed this card's dashboard scope in its own words. Measuring the layer it named: the dataset/widget path is correct in all four filter directions against a SQLite ground truth computed in the same run; all 7 windowed service-dashboard widgets populate (0 blank, 0 disagreeing with truth); and the preset chain resolves — the shipped console lowers
Sub-issue #1154 (C — browser/console probes) complete: 5/5 measured on 17.0.0 GA in a real browser
All five cards probed on a booted GA app (port 4003,
objectstack dev --seed-admin, fresh database) driven by real Chromium 141 via Playwright. Every reading carries version + probe + screenshot + result; no card was closed on a static read.card verdict disposition #664 address renders as raw JSON fixed CLOSED, pm:blockedremoved in the same label write#680 action dialog keeps raw English title fixed (all 3 locales) CLOSED #682 console chrome i18n cluster 3 headline symptoms fixed, residual survives open · mirror objectui#4645 · nominated #8668 #1122 designer offers retired Indexedkeyreproduces open · mirror objectui#4644 · nominated #8668 #986 record:reference_railundeclaredreproduces (all 3 gaps) open · mirror objectstack#8691 · nominated #8667 The card this sub-issue existed for
#664 was the point — marked fixed upstream on an rc.6 static read, never browser-verified. It is now verified:
BILLING ADDRESS | 500 Howard Street, Suite 400, San Francisco, CA 94105, USon the seeded Acme record, the exact record and address the card was filed on, with the raw-JSON signature absent and a record-identity guard ruling out a vacuous pass. The rc.6 comment's own caveat — "a formatter existing in the bundle and the detail page actually routing anaddressfield to it are two different claims" — is discharged.#682 is three fates, not one
As this card predicted. Symptoms 1 (raw API name in the lookup placeholder), 2 (toolbar chrome) and 4 (CJK joiner in the
entoast) are green on GA —Select Account first/请先选择所属客户/まず 取引先 を選択してください/Seleccione primero Cuenta;More actions→ 更多操作;Sum:→ 合计; theentoast joins with ASCII commas and U+3001 is absent page-wide. Symptom 3 (dashboard chips / KPI captions) had its attribution rejected upstream — those are app metadata, split to objectstack#5428 with aneeds-user-decisioncontract question; recorded, not re-litigated.What survives is the residual from this card's 2026-08-05 comment: built-in record-detail tabs render
Details / Related / Attachmentsin ja-JP and es-ES while zh-CN shows 详情/相关/附件, plus two English aria-labels (Record highlights,Discussion) in every locale. I re-verified the attribution rather than inheriting it — the app page authors onlypage:headerandrecord:chatter; the console synthesizer owns the tab strip.Mirror state you asked about — objectstack#5407: CLOSED (completed), 2026-08-05, by objectui PR #3379. Its per-item acceptance is on-card (① fixed via a new
dependsOnLabelsprop, and the interpolated token turned out to be the controlled field's label, not the object name; ②More actions/Add reactionfixed,Clear/Closenot reproducible; ③ attribution rejected; ④ joiner fixed per-locale,Intl.ListFormatmeasured and deliberately rejected). Its sibling #5084 was migrated, not rejected, to objectui#4024 under the file-at-destination ruling (#7167) and closed 2026-08-13 by objectui PR #4602 — that landing is what mySum:→ 合计 reading confirms shipped.#1122 and #986: the round trips, not just the symptoms
#1122 — the full reading you asked for. HotCRM cannot exercise it (code-loaded packages are read-only in Studio), so I created a throwaway writable package to reach an editable designer.
Indexedis offered in the ADVANCED section; ticking it and saving returns HTTP 422INVALID_METADATAand the draft does not save. Correcting my own first reading: my scripted toast capture returned[""], which looked like a silent failure — the screenshot shows a red inline banner carrying the full #2377/#4001 guidance. The rejection is loud; the defect is that a control writing a retired key is offered at all, and every save of that object stays blocked until it is un-ticked.#986 — both halves. Statically,
ComponentPropsMapon GA still has norecord:reference_railrow (37 keys, 6record:*). Live, I plantedfilter: [{field:'status',op:'neq',value:'completed'}]on a rail entry with 3 related rows / 2 not completed: it typechecked,validated, built, shipped verbatim intodist/objectstack.json— and the badge stayed 3 with the completed row still listed. The same build emitted loud unknown-prop warnings forrecord:related_listandrecord:activityin the same file. Planted filter reverted; page file byte-identical to HEAD (git hash-objectverified).Routing — I did not nominate everything on #8667
Three of these five are console surface, and #8667's own Scope section routes
repo:objectuicards to Seat B (#8668). Following this card's instruction literally would have put console work on the platform desk, so console mirrors went to #8668 and only thepackages/specfix went to #8667 — flagged in both nominations rather than done silently, as #1154 required. Supporting precedent: the maintainer's file-at-destination ruling (#7167, 2026-08-10) under which #5084 moved to objectui, and the fact that every fix in the #682 family landed in objectui.#986 was split rather than filed whole: gap 1 (missing spec declaration) is a contract tightening with no pull question, so it went to objectstack. Gaps 2–3 (
pluralLabel, translatable title) are capability expansion whose only consumer repo-wide is one rail on one page — named as out-of-scope in the mirror, nominated nowhere, left for a maintainer ruling per the startup-focus principle.No labels applied by me anywhere —
target:v17untouched, first-batch lists untouched. Seat A decides nothing.Scaffolding deleted,
git statusclean,git diff HEADempty — no product code changed. Full per-card report on #1154.
Generated by Claude Code
Final summary — the transfer sweep (#1156) is complete: 21 of 22 dispositioned, 1 escalated
Closing summary for this coordination node, covering #1156 end to end (part 1 + part 2) and the three probe rounds #1152 / #1153 / #1154 that fed it. Maintainer ruling the sweep ran under, 2026-08-14, verbatim and untranslated:
hotcrm 席位的原则是用平台的能力做元数据应用的开发，平台的需求应该转给平台
with the hotcrm-side disposition: 「关掉,只留指向镜像的指针」.
Where all 22 landed
outcome count cards 1 — transferred: fix lands upstream, closed here with a verified pointer 9 #706 → objectstack#8679 · #707 → #8681 · #689 → #8682 · #698 → #8686 · #1141 → #8687 · #691 → #8688 · #701 → #8689 · #1122 → objectui#4644 · #682 → objectui#4645 2 — kept: fix lands in hotcrm, relabelled and regraded 4 #1104, #1004, #700, #510 3 — closed with the reading: fixed upstream or no longer reproduces, nothing to transfer 8 #788, #522 (part 1) · #703, #705, #520, #779, #664, #680 (probe rounds, non-reproducers) escalated — needs a maintainer ruling before it can close 1 #986 The headline the label did not predict
The
upstream:objectstacklabel was a claim, not a verdict, and it was wrong on 12 of 22. Four cards were hotcrm's own work all along; eight were already fixed or no longer reproduced. Only nine were genuine transfers. This card's mandate — measure first, no bare closes — is what caught it; a blanket move by label would have pushed four cards of CRM work into a platform backlog that cannot do it, and closed eight cards' worth of already-landed fixes as if they were open platform debt.Two counterexamples worth carrying forward, because they cut in opposite directions:
- [17.0-rc][疑似平台] 自动化引擎 create_record(系统扫)插入的行 owner_id/organization_id/created_by 全 NULL —— 出生即连 admin 都无法改删;demo_bootstrap 十分钟内会"自愈" owner_id,真实安装没有这根拐杖 #700 — mirror closed via a merged PR, which is exactly the signal this card's own filing used as evidence that the account-book merely needed catching up. Reading the PR's diff showed it fixed only the user-triggered half; the successor ruling moved the remaining duty to the flow author. "Mirror closed" is reliable about the mirror, never about the defect.
- readonly: true 在 insert 路径上完全不生效，且 update 路径的剥离会连 hook 自己写的戳一起删掉 —— 已发布文章可落成 published_at = null #788 — carried two contradictory on-card readings since 2026-08-12. The later one ("still live") propagated into the label, into the scope check and into the dispatch briefing; the earlier one was correct. The behaviour is upstream-ruled intended, on a path deliberately exempted. A re-measurement that does not engage the prior contradicting reading is not a re-measurement.
The one card that did not close, and why
#986 (
record:reference_rail) stays open. Its GA reading measured three gaps; mirror objectstack#8691 carries gap 1 only, by explicit design. Gaps 2 and 3 are console-renderer capability expansion and were deliberately not filed pending a maintainer ruling on business pull — the measured consumer count is one rail on one detail page.Closing it would have stranded two measured findings and an unanswered maintainer question with no holder in any repo (objectui searched; nothing covers them, and #8691's out-of-scope prose closes when #8691 does). So it was escalated rather than dispositioned. Two clean unblocks are recorded on the card: rule no pull ⇒ mark gaps 2–3
wontfixand close with the #8691 pointer; rule pull ⇒ file one objectui card and close with both. Full analysis in the part-2 report on #1156.Cards this sweep created
- objectstack: #8679, #8681 (
security), #8682, #8684, #8686, #8687, #8688, #8689, #8690, #8691 - objectui: #4644, #4645
- hotcrm: Restore the Service dashboard's
dateRangeand relax the #546 CI guard — both upstream preconditions have landed and the window is measurably correct on 17.0.0 GA #1157 — restore the Service dashboard'sdateRange; filed while closing [17.0-rc][疑似平台] datetime 字段的时间窗过滤返回空集（客服仪表盘全空） #520, and confirmed during part 2 to be hotcrm work (itsupstream:objectstacklabel was stripped after verifying both named preconditions, objectstack#3912 and #3777, closed via merged PRs).
⚠️ The ownership gap — restated, still openobjectstack#8667 scopes hotcrm out and says so in its own words: hotcrm's P0s accuse platform defects with "no assigned verifier." This sweep has now moved nine more cards into that space. Every mirror listed above carries
bug(andsecurityon #8681) and nothing else — no release target, no verifier, no owner. Per ruling 1 the seats nominated in comments and applied notarget:v17; #8667's and #8668's first-batch lists were never touched.That is the transfer ruling working exactly as designed — each card is now in the repo where its fix lands — and simultaneously the gap flagged when #1156 was filed: the right home is not an owner. Twelve cards now sit in objectstack's and objectui's untriaged pools waiting for the maintainer to place them. Carried up rather than papered over with a label.
Final state
Open cards carrying
upstream:objectstack: 3 — this card, #1156, and #986. The 22 legacy cards are down to one, and that one is a decision, not a backlog item.No repo files were touched by any part of the transfer sweep — no worktree, no branch, no commit, no PR, no app boot. The output was GitHub issue state and comments in three repos.
Generated by Claude Code
Generated by Claude Code
GA close-out sweep — final report, card closed
PM loop, session
session_01XAK3brMLjd4ykF4QAhFnuo. All 22 named measurement targets are dispositioned, and the transfer ruling recorded on #1156 is executed 22/22. Closing under the maintainer's stand-down order (「平台相关的任务处理完就下班」).Mandate, item by item
Item 1 — apply the #1106 verdicts.
⚠️ Already applied before this card was written. #786 closed 2026-08-11T22:24:46Z; #1093 / #1086 / #853 promoted, dispatched, implemented and closed on 2026-08-12. Re-scoped to verification (#1151) rather than re-application; re-applying would have reopened or re-closed four settled cards.Item 2 — direct-close 8. 5 closed with provenance (#509 #526 #567 #656 #651). 3 refused (#520 #510 #779) because the recorded evidence did not establish a fix. All three were vindicated: #520 and #779 were later probed on GA and closed on real readings, and #510 turned out not to be a platform card at all — its fix lands here.
Item 3 — confirmation probes. #703 (p0) and #705 closed as non-reproducers; #664 closed after the browser check it had never had; #706, #698, #1141 survived and transferred.
Item 4 — GA-retest 8. #680 closed; #707 #689 #682 #701 #691 #1122 survived and transferred; #986 gap 1 transferred, gaps 2–3 decided and recorded.
Numbers
hotcrm cards closed 28 (23 defect cards + 5 sweep meta-cards) open upstream:objectstack22 → 0 mirrors filed 12 — objectstack #8679 #8681 #8682 #8684 #8686 #8687 #8688 #8689 #8690 #8691; objectui #4644 #4645 new hotcrm cards #1155, #1157 (both queued and graded) findingbacklog38 → 34 dispatchable queue 3 — #1149, #1155, #1157 product code changed none; all three checkouts clean, no PR opened Four of the 22 were never platform cards (#1104 #1004 #700 #510) — relabelled and kept as hotcrm work. A blanket transfer by label would have pushed them into a repo that cannot do them.
Three findings worth mechanising — not prose for a playbook
- "Posted but never executed" claims are unreliable as a class here — three instances in one shift (Re-verify the premise of all 37 open findings against current main — which were silently fixed by today's 15 PRs? #1106's verdict table; readonly: true 在 insert 路径上完全不生效，且 update 路径的剥离会连 hook 自己写的戳一起删掉 —— 已发布文章可落成 published_at = null #788's scope correction; my own rider repeating it). Each was authoritative-sounding, recent, and wrong. This is detectable: a card carrying a verdict/decision comment with no subsequent state change is a query, not a judgement call.
⚠️ Note objectstack#8683 was filed by another seat during this shift proposing exactly this (same-round verdict-execution clause + a merged-but-dispatched detector) — that is the right home; ⛔ not duplicating it here. - "Mirror closed via merged PR" is a reliable signal about the mirror, never about the defect. [17.0-rc][疑似平台] 自动化引擎 create_record(系统扫)插入的行 owner_id/organization_id/created_by 全 NULL —— 出生即连 admin 都无法改删;demo_bootstrap 十分钟内会"自愈" owner_id,真实安装没有这根拐杖 #700 is the worked counterexample: mirror closed, PR merged, and PR6153's actual diff fixed only the user-triggered half while successor ruling objectstack#6155 moved the remainder to the flow author. This card's own header leaned on that inference for nine mirrors.
- Binary retests over-close. [17.0-rc][疑似平台] crm_case 自动编号计数器落后于既有 case_number:REST 建单连续 409,每次失败还烧掉一个号(实测重试 25 次才成功) #698, A misspelled top-level stack key is silently stripped, not rejected — the artifact just loses it #1141 and [17.0-rc][疑似平台] 缺少必填的 master-detail 父记录时返回 403 PERMISSION_DENIED,而非其它必填字段一致的 400 VALIDATION_FAILED #691 all came back one-half-fixed; 回归:#547 实测通过的
marketing_campaign_updatesRLS 写扩权在 rc.2 上失效(403);同 PR 的 campaign_member 扩权仍工作 #706 came back inverted (a regression against rc.2 on the enrolment path); readonly: true 在 insert 路径上完全不生效，且 update 路径的剥离会连 hook 自己写的戳一起删掉 —— 已发布文章可落成 published_at = null #788 came back "intended behaviour". Any close-out asking "still broken? y/n" would have mis-filed five of these. Partial fates are the norm for rc-era cards, not the exception.
Carried to the maintainer — nothing here blocks
- objectstack#8681 / [17.0-rc][疑似平台] 17.0 的 allowExport 硬门对 org-admin 失效:dev admin 导出 quote/campaign/task 均 200,而声明是"连 admin 也 EXPORT_NOT_PERMITTED" #707 — should an app be able to deny the export axis to an org admin? Security and permission-boundary shape on a public contract: maintainer floor. The facts are settled by measurement (shipped admin sets carry
object_permissions['*'].allowExport = trueand arenot_overridable; an app-authoredsystem_adminset yields the declared posture). Only the ruling remains. - The ownership gap, now 12 cards wide. Every mirror this sweep filed carries
bug(plussecurityon #8681) and nothing else — no target, no verifier, no owner — and objectstack#8667 excludes hotcrm-origin work by its own Scope section. The transfer ruling gave these findings the right home; it did not give them an owner. ⛔ Deliberately not papered over with a label by any seat. - record:reference_rail 的 entry 授权面比页面所需更窄，且该形状未被 spec 声明：filter 写了静默失效、标题拿不到 pluralLabel #986 gaps 2–3 closed as decided-not-worked on the startup-focus principle. Veto window, not a closed door — the remedy is one objectui card and the findings are preserved in full on that card so reversal needs no re-measurement.
Handover
Every finding lives on GitHub — issue state, labels, comments. Nothing load-bearing is held in session context. #1149, #1155 and #1157 are app-side work, deliberately left queued and graded under the stand-down order's scope line, not forgotten.
Generated by Claude Code
- "Posted but never executed" claims are unreliable as a class here — three instances in one shift (Re-verify the premise of all 37 open findings against current main — which were silently fixed by today's 15 PRs? #1106's verdict table; readonly: true 在 insert 路径上完全不生效，且 update 路径的剥离会连 hook 自己写的戳一起删掉 —— 已发布文章可落成 published_at = null #788's scope correction; my own rider repeating it). Each was authoritative-sounding, recent, and wrong. This is detectable: a card carrying a verdict/decision comment with no subsequent state change is a query, not a judgement call.
Filed on maintainer ruling (2026-08-14, verbatim: 「同意」, approving item 6 of the six-item ruling list presented in chat by the objectstack PM seat, session
session_018WuTtyckQa1VcXwgd52JpN). Context: the repo is now on@objectstack/*17.0.0 GA (#1146 / PR #1147, merged 2026-08-14), and all nine objectstack mirror cards for this repo's rc-era platform findings are closed via merged PRs (objectstack-ai/objectstack#5491→PR6684, #5492→6684, #5493→6909, #5494→6153, #5495→6932, #5574→6697, #5591→6343, #7861→7974, #6080→6466). The account-book here has not caught up with the fixes. This card is the catch-up: measurement and bookkeeping only, no feature code.Mandate
1. Apply the #1106 verdict table (posted on that card 2026-08-11, never applied because the dispatching PM's session ended): close-stale #786; promote #1093, #1086, #853; keep the remaining 30 as graded.
2. Direct-close with a provenance comment each — all verified fixed with rc.2/rc.6 retest readings already recorded on-card, most with an explicit "recommends closing" comment nobody executed: #520, #510, #509, #526, #567, #656, #651, #779. (#525, #524, #521 were closed directly by the PM under the same ruling; #703 is in group 3.)
3. Confirmation probe, then close if green:
member_default的*通配授权(C/R/E)并集合并进每个成员 —— 应用的 explicit-allow 对象门在建/读/改三轴上被整体架空,任何 profile 都能在任何对象上建记录 #703 — full GA permission probe: explicit-allow object gates hold,member_defaultcarries no wildcard union (rc.6 static read already showed the root cause gone; this is the closing probe)modifyAllRecords对行级写门无效,edit 级sys_record_share实际只给读 —— sales_manager 改不了任何非本人创建的记录 #705 / 回归:#547 实测通过的marketing_campaign_updatesRLS 写扩权在 rc.2 上失效(403);同 PR 的 campaign_member 扩权仍工作 #706 — RLS write-widening re-probe on GA (their mirrors landed via PRs #6684/#6909)4. GA-retest the 8 likely-live (never re-measured since rc.2, or measured-still-broken): #707 (security: allowExport bypass for org-admin), #689 (security-adjacent: full INSERT with values logged at ERROR), #682 (console-chrome i18n cluster — also check the state of its mirror objectstack-ai/objectstack#5407), #680, #701, #691, #986, #1122. For each survivor: file or refresh an objectstack mirror and nominate it for
target:v17on objectstack-ai/objectstack#8667 (Seat A decides nothing — the maintainer approves nominations). For each non-reproducer: close with the reading.Rules
Measurement first; every close carries its reading (version, probe, result) — no bare closes. No code changes beyond probe scaffolding. Report progress on this card. The v17 bug-focus regime (objectstack-ai/objectstack#8667 / #8668) stays scoped to objectstack + objectui: nothing from this card enters those seats except maintainer-approved mirror nominations from group 4.