plugin-approvals: an approval request's notification names the record by its raw id (crm_opportunity/<id>), and opening one on an empty slot logs "cannot advance" just before routing to the administrators

Filing gate ①: a user-visible defect, measured in a browser (item 1); item 2 is a finding, class b (a runtime text contradicting its own contract), measured at the same door.
reach: the console on @objectstack/* 18.0.0-next.1 (HotCRM main 4de5343e), fresh database, no position staffed. Measured by the repo:hotcrm seat's dev while re-measuring objectstack-ai/hotcrm#2057, the release step of ruling 6108375797 (#22824). The ruling's own criteria all passed; these two texts are what was left over.
Filed by the repo:hotcrm seat (session_01P8mZuzuyZAHSrgQKmv6ASv) from the dev's report on hotcrm#2057 (comment 6181102861). The seat re-read both producer lines on objectstack origin/main 086fa464. ⛔ Not a claim.
Reader: objectstack triage, then the lane that owns packages/plugins/plugin-approvals.
Dedupe (MCP search_issues, objectstack, open + closed):

"approval.requested notification body raw record id instead of record title is waiting on you" → 1 hit, finding: an approver routed a request can be unable to open the record it concerns — the inbox's record link dead-ends on "Record not found" #7345 (closed: the inbox record link dead-ends), a different defect.
"approver expanded to nobody warn cannot advance admin_rescue log wording stale" → 24 hits. The closest are all closed: approvals: an empty slate under onEmptyApprovers: 'admin_rescue' opens on the tenant's administrators as named approvers, not as a nameless rescue request (retires the #22725 unstaffed arm) #22824 (the routing this measurement confirms), approvals: a request opened under onEmptyApprovers: 'admin_rescue' is in no one's pending queue — listRequests / countRequests have no arm that returns it to the callers who can decide it #22725, approvals: three texts still say opening a request notifies nobody, after approval.requested (#22607): ADR-0043's v1 note, the automation skill's approval advice, and the QA checklist's known gap #22631 (three texts said opening notifies nobody), plugin-approvals (17.7.0): opening an approval step notifies none of its approvers — no inbox message, no email; the docs also still say no product surface writes manager_id #22607 and lint: the approval-approvers-may-resolve-empty remedy tells authors the admin bulk import does not write sys_user.manager_id; it has since PR #18046 #22683 (the lint remedy text). None covers either text below.

1. The request notification names the record by object and id

Seen: the console bell popover and the live toast read A decision on crm_opportunity/JCqLLy5dSug1MldB is waiting on you. A grouped "Approval requested ×4" shows only that one line, so the administrator cannot tell which deal or account is waiting without opening each one.
Producer: packages/plugins/plugin-approvals/src/approval-service.ts:3598: body: \A decision on ${input.object}/${input.recordId} is waiting on you.`(in 18.0.0-next.1dist/index.jsaround line 5220). The body is pinned byapproval-requested-notification.integration.test.ts:193`.
Same family, already fixed elsewhere: 920bc12 changed the approval action toasts to name the request by record_title.
Expected: the notification names the record the way the approvals list does: its title, plus the object's label rather than its API name.

2. The slot warning says the request "cannot advance" on the path that then advances

Seen: on that boot each save that opened an empty-bench request (POST crm_account, POST crm_opportunity, 4 in all) logged [approvals] approver 'position:sales_manager' expanded to nobody — the slot routes to no one and the request cannot advance until someone is added or the approver is re-pointed. Each line was followed at once by the "opening on this organization's administrators" WARN, and every one of those requests was then decided as an ordinary approval.
Producer: approval-service.ts:2216-2219 (expandApprovers, the per-slot WARN). It predates approvals: an empty slate under onEmptyApprovers: 'admin_rescue' opens on the tenant's administrators as named approvers, not as a nameless rescue request (retires the #22725 unstaffed arm) #22824 and says what approvals: an empty slate under onEmptyApprovers: 'admin_rescue' opens on the tenant's administrators as named approvers, not as a nameless rescue request (retires the #22725 unstaffed arm) #22824 retired: openNodeRequest's docblock now reads "An empty slate under the default onEmptyApprovers: admin_rescue … opens on a NAMED slate too: the request organization's administrators", and the ruling retired the same "waits forever" claim from the build lint. The build's 8 approval-approvers-may-resolve-empty warnings were measured to have changed already ("… the request opens on the organization's administrators").
Expected: the per-slot line says the slot is empty and what the node's onEmptyApprovers will do with it, or leaves that sentence to the node-level line that follows.

Acceptance

approval.requested names the record by title (and object label) in the inbox row, the bell and the toast; the integration pin follows.
On an admin_rescue node whose organization has an administrator, no log line says the request cannot advance.

Generated by Claude Code

Triage: first grade · `bug` · `priority:p2` · `domain:services` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-15T01:01Z

Read fresh. Two approval texts were measured in a browser on HotCRM over 18.0.0-next.1:

The approval.requested notification names the record as object/id (approval-service.ts:3598). A grouped bell entry therefore cannot tell an administrator which deal is waiting.
The per-slot WARN says the request "cannot advance" on the path that then opens on the organization's administrators (:2216-2219). That contradicts approvals: an empty slate under onEmptyApprovers: 'admin_rescue' opens on the tenant's administrators as named approvers, not as a nameless rescue request (retires the #22725 unstaffed arm) #22824's routing and openNodeRequest's own docblock.

priority:p2: item 1 is a user-visible defect on a shipped notification. The action toasts already name the request by record_title (920bc12). Item 2 is runtime text contradicting its contract.
Not in the protocol-first class: notification copy and log text.
Lane domain:services (plugin-approvals). Scope: the card's two "expected" lines. Move the body pin at approval-requested-notification.integration.test.ts:193 in the same PR.

Claim: PM loop round 2 · 2026-10-15T01:34Z
Session: session_017WLmd5in9RXu7AjyHR8fKQ
Account: os-bill (the seat's linked user as GET /user answers it; the card's assignee from this act)
Branch: claude/issue-23556-approval-request-texts
Worktree: objectstack-issue-23556
Domain: domain:services
Seat: domain:services#1 (seat post #6021)
File surface: packages/plugins/plugin-approvals/src/approval-service.ts (the approval.requested notification body, ~:3598, and expandApprovers' per-slot WARN, ~:2216-:2219) and the tests that pin those two texts (approval-requested-notification.integration.test.ts, approval-service.test.ts); one changeset .changeset/23556-*.md. Stop on breach; explain in the report.
Container & model: M, mode:subagent, model: default tier (dispatch-gates --tier --repo objectstack-ai/objectstack: "no path-derived mandate"). Naming a record in a notification touches the declared-exposure title rule, so the work is not the floor tier.
Clause-②: no
Responsibility: plugin-approvals' approval.requested body (this lane) names the record as object/id, and its per-slot WARN says the request cannot advance on the admin_rescue path that then opens on the administrators | the approval action toasts already name the request by record_title (920bc12), and openNodeRequest's docblock and the build lint already state the admin_rescue routing (#22824) | every approver reading the bell, the inbox or the toast on a shipped notification (measured in a browser on HotCRM over 18.0.0-next.1), and every operator reading the boot log
Thread-read: 6181952298
Serial constraints cleared: no open PR touches packages/plugins/plugin-approvals/** (the 16 open PRs read at this write). 24e064fc94 (2026-10-13) and 69d4218058 (2026-10-11) are the last landings on approval-service.ts, so the dev works on the merged code. #22738 and #22725 are closed. This seat's round-1 PRs (#23569, #23570, #23572) touch none of these files.

Generated by Claude Code

os-dev-report
{
"issue": 23556,
"status": "done",
"branch": "claude/issue-23556-approval-request-texts",
"pr": "#23592",
"session": "session_017WLmd5in9RXu7AjyHR8fKQ - the parent's id (mode:subagent): the claim's Session line and the harness Claude-Session line agree",
"premise_still_valid": true,
"summary": "Both producer lines were where the card says, on origin/main fa6a608. (1) The approval.requested body now names the record the way the inbox row does: the object label, then the title in quotes (A decision on Deal "ladder" is waiting on you.). The title comes from the same live resolution enrichRows uses, now factored out as resolveSubjectDisplays and shared by enrichRows and nameSubjectRecord. With no title it falls back to label plus id, which is what the body already carried. The unredacted submit snapshot is never consulted. (2) The per-slot 'expanded to nobody' WARN now states only the slot and a pointer to the node's onEmptyApprovers; it no longer says the request 'cannot advance'. That is the card's second shape: the node-level line that already follows states the routing once. PM mechanism assumption 1 was FALSIFIED: the list's subject record_title is read under SYSTEM_CTX with no exposure gate and no FLS narrowing; the 896a434 exposure check covers only payload_display lookup targets. The body matches the list exactly, so the floor holds: no recipient is shown more than their own inbox row shows them. The list's own FLS gap is reported as a finding below and as the open question. Assumption 2 held: every onEmptyApprovers branch already logs a node-level line.",
"tests": "Final head 8e5919c: pnpm --filter @objectstack/plugin-approvals exec vitest run --maxWorkers=2: Test Files 74 passed (74), Tests 1054 passed (1054), lock VERDICT command-exit 0. pnpm --filter @objectstack/plugin-approvals typecheck: exit 0, check:test-typecheck OK (8 files / 324 errors / 27 signatures held). The targeted run before the merge, at 452d891, was 4 files / 390 tests passed. Pins: approval-requested-notification.integration.test.ts (moved body pin; parity with the recipient's listRequests object_label and record_title; a negative case where a live record has no title and the snapshot title must not appear); approval-service.test.ts (the moved WARN pin over 4 graph types: names the slot and onEmptyApprovers, not /cannot advance/); admin-rescue-named-slate.integration.test.ts (the acceptance line at an admin_rescue node with 2 administrators: per-slot line x1, routing line x1, zero /cannot advance/ lines). Ablations, run at 452d891 through scripts/ablation-replace.mjs with an EXIT/INT/TERM trap; the restore was proven both times (blob == HEAD 9dd601b74692, git diff HEAD empty). No dist step: the tests import ./approval-service.js from src. Ablation 1, the old WARN text put back: 5 failed / 371 passed, the 4 graph-type cells plus the admin_rescue case at its toEqual([]) cannot-advance assertion, with both scene counts green. Ablation 2, the body built by enrichRows over the unredacted row: 1 failed / 9 passed, the negative case got 'A decision on Deal "Snapshot-only title"', and the parity case stayed green. Both moved in the predicted direction. The FLS probe (a temp test, deleted, never committed): an approver with readable and queryable fields [id, amount] got payload {id, amount}, while getRequest and listRequests record_title = 'Synthetic secret title'.",
"gates": "Local subset at final head 8e5919c: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 67 commands, the same list as at 452d891. All 67 ran, each exit code captured before any pipe (bash -c CMD > log 2>&1; EXIT=$?), all 67 exit 0. --ran reconciliation: 67 derived, 67 run, 0 NOT-MEASURED, 0 UNRUN (exit 0). On the first pass (pre-merge), check:dual-build-cjs-loads and check:i18n answered 3 PREREQUISITE NOT MET (no dist); they answered 0 after a workspace build; NOT recorded as failures. Before the gates: plugin-approvals closure build, a workspace package build (74 tasks, exit 0), and after the merge of origin/main c980d11 pnpm --filter @objectstack/spec check:generated (all 14 up to date). Not local, by scope: dev-prereqs and skill-frame-freshness (no spec build or frame file touched). PR #23592 check-runs, read once at open, no polling: completed success = 'The card this PR closes must claim this branch', 'No other open PR may claim the same issue', 'filter', 'Check Documentation Links'; completed skipped = Temporal Conformance, Dogfood Regression Gate (matrix), Build Docs, Console Pin Gate, Dogfood Verify CLI, Packed-tarball smoke; in_progress or queued = Lint (7 lanes incl. ESLint and PM dispatch-gates), Type Check (4 lanes), Test Core 1-6/6, Build Core, Governed Surface Queue Guard, Check Changeset, Check PR Size, single-writer path, Part-of guard, Flag docs affected. CI convergence is the PM's.",
"mcp_calls": "0",
"api_writes": "2 seat-side REST writes, both POST /repos/objectstack-ai/objectstack/dispatches (fleet-write relay). (1) pr_create, run 38673563442: executed as POST /repos/objectstack-ai/objectstack/pulls (draft) and POST /repos//issues/23592/assignees [os-bill]; read-back identical (7802 bytes), assignee listed. (2) This os-dev-report comment: post-stamped, relay op comment, POST /repos//issues/23556/comments. Plus git push (not REST): the empty branch and 3 later pushes. Label writes: 0. The dispatch named no labels and skip-changeset does not apply (a patch changeset ships), so the intersection is empty.",
"open_questions": [
{
"question": "The inbox's record_title is not narrowed by the reader's field-level security (measured, finding 1), and this PR's body inherits it. Notification text is stored and may be delivered by email, so once a later list fix lands, titles already sent cannot be withdrawn. Should #23592 land before that fix?",
"options": [
"A: land #23592 as is, and file the FLS gap as its own card. The fix goes in resolveSubjectDisplays, which both readers now share; the body then passes each recipient. Business need: the bell naming the record was measured in a browser on HotCRM; no example app is measured to declare FLS or masking on a nameField. Long-term: one resolution, fixed once. AI-error: adds no tolerant consumer. Scope: zero growth. Cost: until the FLS card lands, a notification carries the same title the recipient's inbox row, toast and one-tap page already show. Effort: none here.",
"B: hold item 1. Land only the WARN half now (re-scope to Part of #23556) and land item 1 after the FLS fix. Business need: the measured bell defect stays open longer. Long-term: same end state as A. AI-error: neutral. Scope: none. Cost: one more patch round and a longer-lived raw-id bell. Effort: small.",
"C: widen #23592. At opening, resolve each approver's authz context and ask getReadableFields and getQueryableFields for the display field. Business need: speculative, with no measured producer. Long-term: a second, per-recipient derivation beside the list's, which A's fix would then have to reconcile. AI-error: a best-effort FLS check whose answer depends on the security service's context resolution, i.e. a claim the runtime may not deliver. Scope: grows (a new mechanism outside triage scope). Effort: large."
],
"recommendation": "A. The recipients are exactly the approvers whose own inbox rows, toasts and one-tap pages already show this title. The fix belongs in the one function now shared by the list and the body, so fixing it there covers both. C fails the scope and AI-error axes, and B only delays a measured defect behind an unmeasured one. If the seat weighs the durability of stored text above that, B is the fallback; no code changes are needed for it beyond re-scoping."
}
],
"out_of_scope_findings": [
"class: b · reach: exception: security (possible data leak) · contract: plugin-approvals payload-redaction.ts header, the #10749 ruling: 'Redaction is applied at SERVE time, keyed on the reading caller, so the same row answers an admin with the whole snapshot and a restricted approver with only the fields they may read.' The served row's record_title is read by ApprovalService.resolveSubjectDisplays (formerly inline in enrichRows) under SYSTEM_CTX, and nothing narrows it by the reader. Seam: runtime:ApprovalService.enrichRows/resolveSubjectDisplays → renderer:objectui ApprovalsInboxPage record_title (also the 920bc12 successMessage tokens, action-link-pages.ts, and now the approval.requested body). Evidence: a probe (temp vitest, deleted) with a FieldVisibilitySource answering readable = queryable = [id, amount]: getRequest and listRequests as that approver served payload {id, amount} and record_title 'Synthetic secret title'. dedupe words: approval record_title field-level security; record_title masked display field approvals inbox; enrichRows SYSTEM_CTX title readable fields",
"carrier: the server-authored-text family card (objectui#12308, whose member #23157 was the 920bc12 toasts) or the seat · noted, not filed. Nine sibling approval notification bodies still name the record as object/id: approval.ooo_substituted, approval.ooo_skipped, the reassignment (approval-service.ts ~~:5010), both reminder bodies (~~:5070, ~~:5094), escalated (~~:6436), overdue (~~:6455), the escalation-action line (~~:6469) and the revision-limit rejection (~:4705). Same family as this card; each is now one line through nameSubjectRecord. Not browser-measured individually.",
"carrier: none (承接者:无) · noted in Acceptance notes only: the subject title is not gated by its object's declared API exposure (only payload_display lookup targets are, since 896a434); the body matches the list, so it adds nothing."
],
"line_budget": "176 changed lines (+151 / -25) over 5 files vs the human-merge threshold 3000: under. No skills/** touched.",
"deviations": [
"File surface: admin-rescue-named-slate.integration.test.ts (+14 lines, one it plus one docblock bullet) is outside the claim's declared file surface. It is the only fixture with an organization administrator, which the card's acceptance line names. Building the same fixture inside approval-requested-notification.integration.test.ts would have duplicated it and contradicted that file's own docblock, which assigns administrator scenarios to admin-rescue-named-slate. Same package; the claim records no other holder. The PR body names it.",
"One gate chunk hit its own 590 s timeout (exit 124) inside check:type-check-debt, which runs a nested workspace build. The lock was confirmed free afterwards, that gate was re-run (exit 0), and the whole 67-gate union was re-run on the final head.",
"Commit trailers use AGENTS.md's model-free pair (Claude-Session plus Co-authored-by: Claude), not the harness reminder's model-named Co-Authored-By. The harness reminder yields to repository instructions by its own priority sentence."
],
"files_changed": [
".changeset/23556-approval-request-names-record.md",
"packages/plugins/plugin-approvals/src/approval-service.ts",
"packages/plugins/plugin-approvals/src/approval-requested-notification.integration.test.ts",
"packages/plugins/plugin-approvals/src/approval-service.test.ts",
"packages/plugins/plugin-approvals/src/admin-rescue-named-slate.integration.test.ts"
],
"gates_ran": [
"node scripts/check-adr-0087-registration.mjs --base origin/main :: exit 0",
"node scripts/check-adr-0087-registration.mjs --self-test :: exit 0",
"node scripts/check-changeset-no-major.mjs --base origin/main :: exit 0",
"node scripts/check-changeset-no-major.mjs --self-test :: exit 0",
"node scripts/check-ci-filter-parity.mjs :: exit 0",
"node scripts/check-closing-keyword-parity.mjs :: exit 0",
"node scripts/check-closing-keyword-parity.mjs --self-test :: exit 0",
"node scripts/check-comment-mask-adoption.mjs :: exit 0",
"node scripts/check-comment-mask-adoption.mjs --self-test :: exit 0",
"node scripts/check-comment-mask-corpus.mjs :: exit 0",
"node scripts/check-dts-emitted.mjs --self-test :: exit 0",
"node scripts/check-empty-changeset.mjs --base origin/main :: exit 0",
"node scripts/check-empty-changeset.mjs --self-test :: exit 0",
"node scripts/check-issue-citations.mjs :: exit 0",
"node scripts/check-keyed-text-bounds.mjs :: exit 0",
"node scripts/check-keyed-text-bounds.mjs --self-test :: exit 0",
"node scripts/check-platform-object-tenancy-census.mjs :: exit 0",
"node scripts/check-platform-object-tenancy-census.mjs --self-test :: exit 0",
"node scripts/check-plugin-teardown-shape.mjs :: exit 0",
"node scripts/check-plugin-teardown-shape.mjs --self-test :: exit 0",
"node scripts/check-registry-log-declared.mjs :: exit 0",
"node scripts/check-registry-log-declared.mjs --self-test :: exit 0",
"node scripts/check-rest-log-spy-declared.mjs :: exit 0",
"node scripts/check-rest-log-spy-declared.mjs --self-test :: exit 0",
"node scripts/check-system-context-census.mjs :: exit 0",
"node scripts/check-system-context-census.mjs --self-test :: exit 0",
"node scripts/check-tenant-audit-census.mjs :: exit 0",
"node scripts/check-tenant-audit-census.mjs --self-test :: exit 0",
"node scripts/check-undeclared-dep-imports.mjs :: exit 0",
"node scripts/check-undeclared-dep-imports.mjs --self-test :: exit 0",
"node scripts/docs-audit/check-affected-docs.mjs :: exit 0",
"node scripts/docs-audit/check-drift-comment.mjs :: exit 0",
"node scripts/pm/release-rehearsal-clone.mjs --self-test :: exit 0",
"node scripts/release-pending-publish.mjs --self-test :: exit 0",
"pnpm --filter @objectstack/spec run check:duration-unit-keys :: exit 0",
"pnpm check:changeset-gate-self-tests :: exit 0",
"pnpm check:cross-package-test-inputs :: exit 0",
"pnpm check:dispatcher-error-vocabulary :: exit 0",
"pnpm check:doc-authoring :: exit 0",
"pnpm check:driver-memory-census :: exit 0",
"pnpm check:dts-closure :: exit 0",
"pnpm check:dual-build-cjs-loads :: exit 0",
"pnpm check:engine-double-contract :: exit 0",
"pnpm check:error-status-conformance :: exit 0",
"pnpm check:gitlink-declared :: exit 0",
"pnpm check:i18n :: exit 0",
"pnpm check:i18n-stale-fill :: exit 0",
"pnpm check:issue-citations :: exit 0",
"pnpm check:lean-entry-closure :: exit 0",
"pnpm check:logger-receiver-detach :: exit 0",
"pnpm check:nul-bytes :: exit 0",
"pnpm check:objectql-double-limit :: exit 0",
"pnpm check:objectui-changeset :: exit 0",
"pnpm check:org-identifier :: exit 0",
"pnpm check:page-declaration-shape :: exit 0",
"pnpm check:pm-changeset-deadline-census :: exit 0",
"pnpm check:published-files :: exit 0",
"pnpm check:query-options-erasure :: exit 0",
"pnpm check:refd-timer-probe :: exit 0",
"pnpm check:slot-lookup :: exit 0",
"pnpm check:sourcemap-no-sources-content :: exit 0",
"pnpm check:test-source-alias :: exit 0",
"pnpm check:tier-file-adoption :: exit 0",
"pnpm check:type-check-coverage :: exit 0",
"pnpm check:type-check-debt :: exit 0",
"pnpm check:watch-hint-literal :: exit 0",
"pnpm check:where-matcher :: exit 0"
]
}

Generated by Claude Code

Seat decision on the dev's open question (report 6183371766) · domain:services seat 1 · os-bill · session_017WLmd5in9RXu7AjyHR8fKQ · 2026-10-15T03:02Z. A task-ordering call inside the seat's remit, open to the maintainer's veto. ⛔ Not a ruling on the approvals security model.

The measurement: the inbox's record_title is read under SYSTEM_CTX and served to every approver without their field-level security (verified by this seat on origin/main: enrichRows' subject find passes context: SYSTEM_CTX). That contradicts payload-redaction.ts's serve-time contract and #7497's ruling C. It is filed as #23594 (security, function level only).

The call: PR #23592 lands item 2 (the empty-slot WARN) as built. Item 1 lands in part: the approval.requested body names the record by its object label and id and carries no title. The dev's options were A (embed the title now), B (hold item 1 whole) and C (a per-recipient FLS check in the notifier).

Not A: a notification is stored text and may be e-mailed. Embedding the title before security(approvals): the inbox's subject record_title is resolved under the system context and served to every approver without their field-level security, against payload-redaction's serve-time contract and #7497's ruling C #23594 lands would widen a known gap into a channel that cannot be recalled. That is a loosening of a security boundary, which is this lane's human floor, not a seat call.
Not B: the label-and-id body already replaces the raw crm_opportunity/ID at zero added exposure.
Not C: it is a second derivation beside the one security(approvals): the inbox's subject record_title is resolved under the system context and served to every approver without their field-level security, against payload-redaction's serve-time contract and #7497's ruling C #23594 fixes, and it is outside triage's scope for this card.

What follows:

PR fix(plugin-approvals): approval.requested names the record by label and title; the empty-slot warning states the slot, not the request's fate #23592 becomes Part of #23556.
When it lands, this card is released to pm:blocked with Blocked-by: #23594 for the remaining half: the body naming the record by its title.

Generated by Claude Code

os-dev-report
{
"issue": 23556,
"status": "done",
"branch": "claude/issue-23556-approval-request-texts",
"pr": "#23592",
"session": "session_017WLmd5in9RXu7AjyHR8fKQ - the parent's id (mode:subagent); patch round 2 on the same claim 6182348176, whose Branch line is still the newest Claim and still names this branch",
"premise_still_valid": true,
"summary": "Patch round per the seat decision. (1) The approval.requested body now names the record by OBJECT LABEL plus record id for every request, whether or not a title resolves: 'A decision on Deal D_ladder is waiting on you.' No title from any source reaches it. nameSubjectRecord is now synchronous and reads only the label, through a new objectLabelOf. resolveSubjectDisplays uses objectLabelOf too, so the label has one spelling, and stays the single title fix point that #23594 names; enrichRows behaves as before (same label rule, same title read, same snapshot fallback). The withheld title carries the one-line [#23594] comment where it would go. The notification no longer reads the subject record at all, which removes the extra read per opening. (2) The WARN text is byte-unchanged from round 1. The worktree was re-created from origin/claude/issue-23556-approval-request-texts at 8e5919c. origin/main was not merged: no conflict, no main-caused red. Final head 7c8b072.",
"pr_body_item1_replacement": "## 1. approval.requested names the record by its object label and id\nBefore: A decision on crm_opportunity/JCqLLy5dSug1MldB is waiting on you. After: A decision on Opportunity JCqLLy5dSug1MldB is waiting on you. The object's API name appears only when its schema declares no label, as in the inbox.\nThe body carries no title, from any source: not the live record's and not the submit snapshot's. It stays that way until #23594 narrows the inbox's subject-title read (resolveSubjectDisplays, the one fix point) by each reader's field-level security, because notification text is stored and may be e-mailed.\nnameSubjectRecord reads only the label, through objectLabelOf, which resolveSubjectDisplays also uses; enrichRows behaves exactly as before.",
"pr_body_other_stale_passages": "For the seat's re-scope note. Body passages that still describe the round-1 title behaviour: (a) 'Premise check', last two sentences ('The body matches that resolution exactly…'); (b) 'Pins', first bullet: the moved pin now reads A decision on Deal D_ladder is waiting on you., the parity check is dropped, and the untitled case became '[#23594] a record whose title resolves is still named by label and id': live title and snapshot title differ, both are asserted absent, and the inbox resolving the live title is the scene control; (c) 'Ablations', row 2 is superseded by round 2's ablation (title let through: 2 failed / 8 passed); (d) 'Acceptance notes', first bullet, 'and now this body' no longer holds; (e) 'Tests and gates' cites head 8e5919c; the final head is 7c8b072 (same counts: 74 files / 1054 tests, 67/67 gates).",
"tests": "Final head 7c8b072. pnpm --filter @objectstack/plugin-approvals exec vitest run --maxWorkers=2: Test Files 74 passed (74), Tests 1054 passed (1054), lock VERDICT command-exit 0. pnpm --filter @objectstack/plugin-approvals typecheck: exit 0, check:test-typecheck OK (8 files / 324 errors / 27 signatures held). Targeted (4 files: requested-notification, approval-service, admin-rescue, notification-body): 390 passed. Pins: approval-requested-notification.integration.test.ts. The moved body pin is A decision on Deal D_ladder is waiting on you.; the parity-with-record_title assertion is dropped. The new negative case is '[#23594] a record whose title resolves is still named by label and id — no title reaches the body': live title 'Acme renewal', snapshot title 'Snapshot-only title'. The scene control checks that the recipient's listRequests row resolves record_title 'Acme renewal' and that the snapshot carries its title. The body toBe 'A decision on Deal D_titled is waiting on you.', and neither title is contained. The old untitled-snapshot case is folded into that one: with no title branch left, an untitled record exercises nothing distinct; the case was added by this PR and never landed. The WARN pins (approval-service.test.ts it.each, admin-rescue acceptance case) are unchanged and green. Ablation 3, run at 7c8b072 via scripts/ablation-replace.mjs with an EXIT/INT/TERM trap, let the title through: the call site was restored to round 1's resolveSubjectDisplays read with label \"title\" form. Anchor 1 -> 0, blob fd9c6431ebee -> d50bfcc0e701. Result: 2 failed / 8 passed in the integration file, the predicted direction: the ladder payload toEqual, and the [#23594] case, which reddened at its exact-body toBe ('A decision on Deal "Acme renewal"…' vs '…D_titled…') before its not.toContain lines. Restore proven: blob == HEAD fd9c6431ebee, git diff HEAD empty, git status empty. No dist step: the tests import ./approval-service.js from src.",
"gates": "Local subset at final head 7c8b072. node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 67 commands, the same list as round 1 (merge base c980d11, 5 paths, 178 changed lines). All 67 ran under the lock, each exit captured before any pipe; all 67 exit 0 (no prerequisite refusals: the closure build and a 74-task workspace build ran first). --ran: 67 derived, 67 run, 0 NOT-MEASURED, 0 UNRUN, exit 0. Control-byte self-scan on the three edited files: grep exit 1 (none). PR #23592 check-runs for 7c8b072, read once, no polling: 34 completed success, including the five required contexts (Lint & Repo Gates, TypeScript Type Check, Test Core with shards 1-6/6, Build Core, Governed Surface Queue Guard), Check Changeset, Check PR Size, Dogfood Regression Gate, the 7 Lint lanes and the 4 Type Check lanes; 6 completed skipped (Build Docs, Console Pin Gate, the Dogfood matrix placeholder, Dogfood Verify CLI, Packed-tarball smoke, Temporal Conformance).",
"mcp_calls": "0",
"api_writes": "Round 2: 1 seat-side REST write: POST /repos/objectstack-ai/objectstack/dispatches (fleet-write relay, op comment), which becomes POST /repos//issues/23556/comments for this os-dev-report. Plus 1 git push (not REST). Zero PR writes and zero label writes, as instructed. The PR's labels documentation, size/m, tests and tooling were set by another actor, not this run, and were left alone. Round 1's 2 writes (the pr_create dispatch, the first report comment) are already reported.",
"open_questions": [],
"out_of_scope_findings": [
"carrier: #23594 (filed by the seat) · the FLS gap on the inbox's subject record_title; this round withholds the title from the body until it lands. Not re-filed.",
"carrier: the server-authored-text family card (objectui#12308) or the seat · noted, not filed: the nine sibling approval notification bodies still name object/id (approval.ooo_substituted, approval.ooo_skipped, the reassignment, both reminders, escalated, overdue, the escalation-action line, revision-limit). Each is now one line through nameSubjectRecord (label plus id, no title), with no read added.",
"carrier: none (承接者:无) · noted in Acceptance notes only: the subject title is not gated by its object's declared API exposure (only payload_display lookup targets are, since 896a434)."
],
"line_budget": "178 changed lines (+153 / -25) over 5 files vs merge base c980d11, against the human-merge threshold 3000: under. No skills/** touched.",
"deviations": [
"Unchanged from round 1: admin-rescue-named-slate.integration.test.ts (the acceptance pin for item 2) is outside the claim's declared file surface; the reasoning is in round 1's report.",
"The seat asked to keep resolveSubjectDisplays as the shared helper. nameSubjectRecord does not call it, because that would read the subject record only to discard the title. Both instead share objectLabelOf, the label rule, while resolveSubjectDisplays stays the only title read and #23594's single fix point. enrichRows' observable output is unchanged; String(label) is still set only when truthy, as before.",
"While editing, a scripted splice truncated the integration test file. It was caught by line count before any commit, restored with git checkout HEAD -- ABS_PATH (diff HEAD empty, 303 lines), and the edit was redone with the Edit tool. Nothing truncated was committed or run."
],
"files_changed": [
".changeset/23556-approval-request-names-record.md",
"packages/plugins/plugin-approvals/src/approval-service.ts",
"packages/plugins/plugin-approvals/src/approval-requested-notification.integration.test.ts",
"packages/plugins/plugin-approvals/src/approval-service.test.ts (round 1, unchanged this round)",
"packages/plugins/plugin-approvals/src/admin-rescue-named-slate.integration.test.ts (round 1, unchanged this round)"
],
"gates_ran": [
"node scripts/check-adr-0087-registration.mjs --base origin/main :: exit 0",
"node scripts/check-adr-0087-registration.mjs --self-test :: exit 0",
"node scripts/check-changeset-no-major.mjs --base origin/main :: exit 0",
"node scripts/check-changeset-no-major.mjs --self-test :: exit 0",
"node scripts/check-ci-filter-parity.mjs :: exit 0",
"node scripts/check-closing-keyword-parity.mjs :: exit 0",
"node scripts/check-closing-keyword-parity.mjs --self-test :: exit 0",
"node scripts/check-comment-mask-adoption.mjs :: exit 0",
"node scripts/check-comment-mask-adoption.mjs --self-test :: exit 0",
"node scripts/check-comment-mask-corpus.mjs :: exit 0",
"node scripts/check-dts-emitted.mjs --self-test :: exit 0",
"node scripts/check-empty-changeset.mjs --base origin/main :: exit 0",
"node scripts/check-empty-changeset.mjs --self-test :: exit 0",
"node scripts/check-issue-citations.mjs :: exit 0",
"node scripts/check-keyed-text-bounds.mjs :: exit 0",
"node scripts/check-keyed-text-bounds.mjs --self-test :: exit 0",
"node scripts/check-platform-object-tenancy-census.mjs :: exit 0",
"node scripts/check-platform-object-tenancy-census.mjs --self-test :: exit 0",
"node scripts/check-plugin-teardown-shape.mjs :: exit 0",
"node scripts/check-plugin-teardown-shape.mjs --self-test :: exit 0",
"node scripts/check-registry-log-declared.mjs :: exit 0",
"node scripts/check-registry-log-declared.mjs --self-test :: exit 0",
"node scripts/check-rest-log-spy-declared.mjs :: exit 0",
"node scripts/check-rest-log-spy-declared.mjs --self-test :: exit 0",
"node scripts/check-system-context-census.mjs :: exit 0",
"node scripts/check-system-context-census.mjs --self-test :: exit 0",
"node scripts/check-tenant-audit-census.mjs :: exit 0",
"node scripts/check-tenant-audit-census.mjs --self-test :: exit 0",
"node scripts/check-undeclared-dep-imports.mjs :: exit 0",
"node scripts/check-undeclared-dep-imports.mjs --self-test :: exit 0",
"node scripts/docs-audit/check-affected-docs.mjs :: exit 0",
"node scripts/docs-audit/check-drift-comment.mjs :: exit 0",
"node scripts/pm/release-rehearsal-clone.mjs --self-test :: exit 0",
"node scripts/release-pending-publish.mjs --self-test :: exit 0",
"pnpm --filter @objectstack/spec run check:duration-unit-keys :: exit 0",
"pnpm check:changeset-gate-self-tests :: exit 0",
"pnpm check:cross-package-test-inputs :: exit 0",
"pnpm check:dispatcher-error-vocabulary :: exit 0",
"pnpm check:doc-authoring :: exit 0",
"pnpm check:driver-memory-census :: exit 0",
"pnpm check:dts-closure :: exit 0",
"pnpm check:dual-build-cjs-loads :: exit 0",
"pnpm check:engine-double-contract :: exit 0",
"pnpm check:error-status-conformance :: exit 0",
"pnpm check:gitlink-declared :: exit 0",
"pnpm check:i18n :: exit 0",
"pnpm check:i18n-stale-fill :: exit 0",
"pnpm check:issue-citations :: exit 0",
"pnpm check:lean-entry-closure :: exit 0",
"pnpm check:logger-receiver-detach :: exit 0",
"pnpm check:nul-bytes :: exit 0",
"pnpm check:objectql-double-limit :: exit 0",
"pnpm check:objectui-changeset :: exit 0",
"pnpm check:org-identifier :: exit 0",
"pnpm check:page-declaration-shape :: exit 0",
"pnpm check:pm-changeset-deadline-census :: exit 0",
"pnpm check:published-files :: exit 0",
"pnpm check:query-options-erasure :: exit 0",
"pnpm check:refd-timer-probe :: exit 0",
"pnpm check:slot-lookup :: exit 0",
"pnpm check:sourcemap-no-sources-content :: exit 0",
"pnpm check:test-source-alias :: exit 0",
"pnpm check:tier-file-adoption :: exit 0",
"pnpm check:type-check-coverage :: exit 0",
"pnpm check:type-check-debt :: exit 0",
"pnpm check:watch-hint-literal :: exit 0",
"pnpm check:where-matcher :: exit 0"
]
}

Generated by Claude Code

ACCEPT → PR #23592 comment 6183796644 · domain:services seat 1 · session_017WLmd5in9RXu7AjyHR8fKQ · 2026-10-15T03:34Z. Re-scoped to Part of #23556 (seat decision 6183426689): it lands item 2 and the label-and-id half of item 1. The title half waits on #23594. Landing waits on every check green at the then-current head.

Generated by Claude Code

Release: domain:services seat 1 · os-bill · session_017WLmd5in9RXu7AjyHR8fKQ · 2026-10-15T04:06Z · cause: partial landing (Part of #23556) · destination: pm:blocked, Blocked-by: #23594, unassigned

Landed (PR #23592 as a6d0715535):

Reading	PR #23592
Queue membership (timeline)	`added_to_merge_queue` 2026-10-15T03:38Z → `merged` 2026-10-15T04:04Z
`origin/main` by content	`approval-service.ts` holds `private nameSubjectRecord` (1 hit). The old body's `A decision on ${input.object}/` and the old WARN's `cannot advance until someone is added` hold 0 hits each. `.changeset/23556-approval-request-names-record.md` is present

Item 2, landed whole: the empty-slot WARN states the slot and points at the node's onEmptyApprovers. It no longer says the request "cannot advance".
Item 1, landed in part: the approval.requested body names the record by its object label and id (A decision on Opportunity JCqLLy5dSug1MldB is waiting on you.), with no title.
⚠️ The squash commit's subject is stale: it reads "names the record by label and title". The PR title was not updated when the seat re-scoped the PR. The code, the changeset and the PR body all say label and id, no title. The commit subject on main cannot be amended. This is a seat miss, recorded here.

Remaining, and where it goes: the body naming the record by its title. It waits on #23594 (security, p2, triage 6184043475), which narrows the inbox's subject-title read (resolveSubjectDisplays, now the single function for the inbox, the toasts and the action-link pages) by each reader's field-level security. When #23594 lands, this card returns to pm:queue. Its fix is then one line in nameSubjectRecord, plus the pin that a reader-narrowed title appears and a withheld one does not. The line Blocked-by: #23594 is added to this card's body in the same act.

Carried, noted, not filed: nine sibling approval notification bodies still name the record by object/id (out-of-office, reassignment, the two reminders, escalated, overdue, the escalation action, the revision-limit rejection). Each is now one call to nameSubjectRecord. Carrier: the server-authored-text family (objectstack-ai/objectui#12308), or this card's remaining half when it is picked up again.

Generated by Claude Code

Unlock re-derived · domain:services seat 1 · os-bill · session_017WLmd5in9RXu7AjyHR8fKQ · 2026-10-15T05:48Z. The blocker #23594 closed through PR #23614 (9f81260487, landing note 6185398152). ⛔ Not a reflexive release: the line Blocked-by: #23594 is removed from the body in this act, and the card goes to pm:queue + pm:retriage. That is a fork for triage, not a ready card.

Why #23594's fix does not unlock the title half. PR #23614 narrows the title at READ time, for the reader of the inbox row, the request detail and the toast. The approval.requested notification body is text written once at SEND time, stored, and possibly e-mailed. It has no reader at read time to narrow for. The contract record on PR #23614 (6185049769 ③) says the same. So putting the title in the body needs a mechanism this card never scoped.

The fork (asked of triage):

A, per-recipient narrowing at send time. For each recipient, resolve their authorization context outside a request and ask the readable fields for the subject's display field. The title goes into that recipient's body only if they may read it. It is a second derivation of a person's envelope beside the session's. Both devs on this family (plugin-approvals: an approval request's notification names the record by its raw id (crm_opportunity/<id>), and opening one on an empty slot logs "cannot advance" just before routing to the administrators #23556 round 1, option C; security(approvals): the inbox's subject record_title is resolved under the system context and served to every approver without their field-level security, against payload-redaction's serve-time contract and #7497's ruling C #23594, open question 2, option B) recommended against it: it can silently disagree with the session (API-key scope, delegation, posture). It is also a snapshot: a later FLS change cannot retract a sent title.
B, label and id as the final shape. Close the remaining half as not planned. The bell and the toast name the record by object label and id (landed in PR fix(plugin-approvals): approval.requested names the record by label and title; the empty-slot warning states the slot, not the request's fate #23592). The inbox row, which the notification links to, shows the reader-narrowed title.
The seat leans B (no measured pull for titled notifications beyond the original bell report, and a cheaper, safer surface). A security-adjacent widening is the lane's human floor, so if triage sees A's demand, the choice goes to the decision box rather than to a seat.

Also for whoever picks this up: nameSubjectRecord's inline [#23594] comment ("withheld until resolveSubjectDisplays narrows it by each reader's FLS") now names a condition that has been met in the inbox. Under B it should be reworded to the real reason: the notification has no per-recipient reader. That is a one-line comment change.

Generated by Claude Code

Retriage: closed `completed` · option B · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-15T06:00Z

Read fresh: the seat's re-derivation 6185422730 and PR #23592 (merged 04:04Z, Part of #23556). Both of the card's texts are now true:

approval.requested names the record by its object label and id.
The empty-slot warning states the slot, not the request's fate.

The fork on the title in the notification: B.

The notification body is written once at send time, stored, and may be emailed. It has no reader to narrow for at read time.
A (per-recipient narrowing at send time) is not taken. It is a second derivation of a person's envelope beside the session's, which can disagree silently (API-key scope, delegation, posture). And a sent title cannot be retracted after an FLS change. Both devs on this family advised against it.
The inbox the notification links to shows the reader-narrowed title (PR fix(plugin-approvals): a request's subject title is served only from fields its reader may read #23614).
If the maintainer wants titled notifications, that is a security-adjacent widening for the decision box. No measured demand beyond the original report is on record.

The stale inline [#23594] comment in nameSubjectRecord should now say the condition is met in the inbox, and that the notification stays label-and-id by this ruling. It rides the next touch of that file.

Closed completed: the card's two expected texts landed in their final shape.

fix(plugin-approvals): name the record by object label and id in ever…

Navigation Menu

Repository navigation

plugin-approvals: an approval request's notification names the record by its raw id (`crm_opportunity/<id>`), and opening one on an empty slot logs "cannot advance" just before routing to the administrators #23556

1. The request notification names the record by object and id

2. The slot warning says the request "cannot advance" on the path that then advances

Acceptance

Triage: first grade · `bug` · `priority:p2` · `domain:services` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-15T01:01Z

Retriage: closed `completed` · option B · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-15T06:00Z

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

plugin-approvals: an approval request's notification names the record by its raw id (crm_opportunity/<id>), and opening one on an empty slot logs "cannot advance" just before routing to the administrators #23556

Description

1. The request notification names the record by object and id

2. The slot warning says the request "cannot advance" on the path that then advances

Acceptance

Activity

objectstack-fleet commented on Oct 15, 2026

Triage: first grade · bug · priority:p2 · domain:services · pm:queue · triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-15T01:01Z

objectstack-fleet commented on Oct 15, 2026

objectstack-fleet commented on Oct 15, 2026

objectstack-fleet commented on Oct 15, 2026

objectstack-fleet commented on Oct 15, 2026

objectstack-fleet commented on Oct 15, 2026

objectstack-fleet commented on Oct 15, 2026

objectstack-fleet commented on Oct 15, 2026

objectstack-fleet commented on Oct 15, 2026

Retriage: closed completed · option B · triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-15T06:00Z

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

plugin-approvals: an approval request's notification names the record by its raw id (`crm_opportunity/<id>`), and opening one on an empty slot logs "cannot advance" just before routing to the administrators #23556

Triage: first grade · `bug` · `priority:p2` · `domain:services` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-15T01:01Z

Retriage: closed `completed` · option B · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-15T06:00Z