plugin-approvals: the served approval request page's highlights strip shows the flow's machine name (process_name, flow:NAME) where the flow's label (process_label) is served

Filing gate ④, a cross-layer child: step 3 of objectstack-ai/objectui#12491 (approvals face 5, "flow origin and the step line"). That face comes from ruling C on objectstack-ai/objectui#12438 (6190549995, the maintainer's 「C (推荐)」). This child follows the face's fit-check reading 6246163097 on objectui#12491, and the domain:ui seat 1's answers to it on the same card. It is also gate ①: a user-visible machine name, with a named landing in this repository.

reach: the served sys_approval_request record page's highlights strip, for every request. This is a static reading, not measured on screen.
Reader who acts: the objectstack domain:services seat, in plugin-approvals, for one dev round. Lane and grade are triage's.
Filed by domain:ui seat 1 ([PM seat] domain:ui @ objectui — ⏳ vacant objectui#5560) · sunhaolin · session_0188TsgPV8kQXfuRuKmkj2ks. ⛔ Not a claim.

Measured (objectstack `origin/main` `fb6fb24e2`, `git show`)

packages/plugins/plugin-approvals/src/sys-approval-request.page.ts declares the highlights strip as fields: ['process_name', 'object_name', 'status', 'current_step', 'submitter_id', 'updated_at']. process_name holds the machine name flow:NAME, so the strip's first chip reads like flow:deal_desk. plugin-approvals: an approval request's record title (display_title / titleFormat) still reads flow:NAME · RECORD_ID — once #23889 lands, its flow half reads the process_label that card adds #24007 fixed the record's TITLE for the same column; this card is about the strip, which that card did not touch.
sys-approval-request.object.ts declares process_label (the flow's authored label), which the record title's formula already reads. Its comment notes that process_label can be null after the boot.
Per the fit-check reading, NOT re-measured here: the approvals get serves the field under that name (rowFromRequest), and os validate's page field-binding check names a misspelt field.
The page's own pin, sys-approval-request-page.test.ts, derives the strip from the object's highlightFields minus record_id.

Done when

The served page's strip shows the flow's label (process_label) where it shows process_name today.
The dev states what the strip shows when process_label is null, within declared fields only.
The page pin moves with it.
The card chooses between editing the object's highlightFields, which other surfaces read, and a page-only list, and says which surfaces it measured.
⛔ No spec row: record:highlights fields already admits the field.

The objectui side owes nothing here. The console's served-page pin copies are rewritten by objectstack-ai/objectui#12484, the closing card of the same ruling, which replaces the inbox side sheet with this page.

Dedupe: a REST enumeration of this repository's issues (state=all, since=2026-10-01; 1722 issues, with controls #23746, #24162 and #24253 found), grepped for process_label|sys-approval-request\.page|approval.request.page.*(highlight|flow name|flow label)|flow:NAME. There are 8 hits. The nearest are #24007 (closed: the record title's machine name) and #23889 (closed: serving the step and flow labels to the lists). Neither changes the highlights strip.

Triage: p2 · `area:workflow` · `domain:services` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-18T06:54Z

Triage seat (objectstack-wide, seat post #6015). ⛔ Not a claim, ⛔ not a dispatch.

Fresh read on origin/main 53ef752436: packages/plugins/plugin-approvals/src/sys-approval-request.page.ts:71 still lists process_name first in the highlights strip.
Grade p2, the ruled-follow-up floor. It is step 3 of approvals face 5 of 5 (ruling C on objectui#12438): the served sys_approval_request page shows the request's flow origin and its vertical multi-step progress line, as the inbox side sheet does objectui#12491's approvals face 5, from ruling C on [Decision] approvals inbox: what opening a request shows — keep the hand-built side sheet, replace it with the served request page now, or build the page's missing faces first (B1 of objectui#2763) objectui#12438 (the maintainer's 「C (推荐)」). Every request's strip leads with a machine name, the same defect plugin-approvals: an approval request's record title (display_title / titleFormat) still reads flow:NAME · RECORD_ID — once #23889 lands, its flow half reads the process_label that card adds #24007 fixed for the title.
Scope = the card's Done when:
- process_label on the strip;
- the null case named within declared fields;
- the page pin moves with it;
- the object-level versus page-only choice stated, with the surfaces measured.
- ⛔ No spec row.
Lane: domain:services (plugin-approvals), the filer's.

Generated by Claude Code

Claim: PM loop round 4 · 2026-10-18T06:58Z
Session: session_01Nk17Z26X5DB59iQztDBADH (the dispatching seat; the dev runs mode:subagent in this session's container and shares its session ID, so its identity is the branch)
Account: marchtian (the seat's linked user as GET /user answers it; the card's assignee from this act)
Branch: claude/issue-24264-approval-page-flow-label
Worktree: objectstack-issue-24264
Domain: domain:services
Seat: domain:services#1 (seat post #6021)
File surface (at origin/main 53ef75243 or later; stop on a breach and explain it in the report):

packages/plugins/plugin-approvals/src/sys-approval-request.page.ts: the highlights strip's fields (about :68–:71) and its header comment (about :28–:33).
packages/plugins/plugin-approvals/src/sys-approval-request.object.ts: highlightFields (about :64), only if the dev's measured choice is the object-level edit.
packages/plugins/plugin-approvals/src/** tests: sys-approval-request-page.test.ts and any pin the choice moves.
one changeset.
Exclusions:
⛔ No spec row: record:highlights fields already admits the field (the card's Done when).
⛔ No new field, formula or column on sys_approval_request. The null case is answered within the declared fields.
⛔ Not objectui: approvals B1 closing card (ruling C on objectui#12438): the inbox opens a request on the served sys_approval_request page where the side sheet is, deletes the sheet, and lists each retired pin against its user report objectui#12484 rewrites the console's served-page pin copies.
Container & model: S: one strip list, its null case and one pin, mode:subagent, model: opus (TIER_DEFAULT; --tier read no path-derived mandate)
Clause-②: no. A served page's strip names a different declared field: no export, no schema, no option key. The dev reports it if the object-level edit moves any other served surface.
Responsibility: plugin-approvals' own page declaration (sys-approval-request.page.ts's highlights fields) | the platform path already serves the flow label: process_label is declared on the object, served by the approvals get, and read by the record title's formula and every request list | reached by every user who opens a served approval request record page
Thread-read: 6246798818
Serial constraints cleared: no open PR touches plugin-approvals (3 open PRs read at this write). The 11 pm:dispatched claims read at this write name no plugin-approvals file. plugin-approvals: an approval request's record title (display_title / titleFormat) still reads flow:NAME · RECORD_ID — once #23889 lands, its flow half reads the process_label that card adds #24007 (the record title, the same column) is closed. Serial dispatch: this seat has nothing else in flight (the maintainer's 「当前任务处理完，后续改为串行派发」, seat post §1).

Generated by Claude Code

os-dev-report

{
  "issue": 24264,
  "status": "done",
  "branch": "claude/issue-24264-approval-page-flow-label",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/24279",
  "session": "session_01Nk17Z26X5DB59iQztDBADH — subagent mode: the dispatching seat's id, as the claim 6246853097 stamps it; this run's identity is the branch",
  "premise_still_valid": true,
  "summary": "The served sys_approval_request_detail page's highlights strip now lists process_label where it listed process_name. The object's highlightFields makes the same swap, with record_id kept. CHOICE, object-level, measured: the page's Details tab is a record:details node with neither sections nor fields. The spec declares (RecordDetailsProps, component.zod.ts) that such a node falls back to the object's highlightFields, and objectui at the pin 5e15928b4 (record-details.tsx, objectui#12433) draws that list minus the strip-registered fields and the H1 field. So the Details tab = the object's list minus the strip: record_id alone today. The PM's suggested page-only edit would have put process_name ('Source: flow:NAME') into that tab; object-level keeps it record_id. Other readers of the object's list at the pin, for this object: ObjectView and ObjectGrid default columns (not reached: all four list views declare columns); InterfaceListPage, ObjectKanban and RelatedList defaults (not reached: none declared for requests); LookupField picker columns (not reached: both request_id lookups sit on apiMethods get/list objects); RecordPreviewCard (reached only by a pointer pair naming a request row, NOT MEASURED whether one exists); Studio object settings (shows the new list). Backend readers (lint, the metadata-core FLS fold, metadata-protocol build probes) do not change behaviour. NULL CASE: the console reads a request through the approvals get (routeApprovalRecordReads), and rowFromRequest serves process_label by requestDisplayLabels: the stored label, else the snapshot's __flowLabel, else the humanized process_name (flow:deal_desk becomes Deal Desk). A row the boot fill never labelled therefore still shows a Flow chip. Only a process_name that humanizes to nothing ('flow:' alone, which openNodeRequest never writes) leaves no value. Then the strip draws no Flow chip (value-less chips are dropped in read mode) and the record title still names process_name. On the generic data API, process_label is the stored column: null means no chip, and display_title falls back to process_name. No field, formula, column or spec row was added. PM hypotheses: H1 (page:71, header, object:64), H2 (display_title fallback), H3 (highlightFields read by lint, FLS and probes) and H4 (the pin derives the strip from the object's list minus record_id) all hold. H5 (current_step) holds and is reported below. The suggested route was replaced on the Details-tab measurement.",
  "tests": "At 046ca5b66. (1) pnpm --filter '@objectstack/plugin-approvals^...' build: VERDICT command-exit 0, held 284s. pnpm --filter @objectstack/plugin-approvals build: exit 0, 'check-dts-emitted: @objectstack/plugin-approvals - 1/1 declared declaration file(s) present'. (2) pnpm --filter @objectstack/plugin-approvals exec vitest run --maxWorkers=2 src/sys-approval-request-page.test.ts src/sys-approval-request.object.test.ts src/sys-approval-display-title.test.ts: 'Test Files 3 passed (3) / Tests 36 passed (36)'. (3) pnpm --filter @objectstack/plugin-approvals test: 'Test Files 81 passed (81) / Tests 1108 passed (1108)'; the package has 81 *.test.ts files. (4) pnpm --filter @objectstack/plugin-approvals typecheck: VERDICT command-exit 0, 'check:test-typecheck: OK'. ABLATION, one run: node scripts/ablation-replace.mjs put process_name back at the head of the page's strip, with the fix committed first. On-disk evidence: 'anchor x1 → x0', 'replace x0 → x1', 'blob aea7e3212b97 → 822555700a37'. The pin went red: 'Tests 2 failed | 15 passed (17)'. The new case failed with \"expected 'process_name' to be 'process_label'\"; the existing case failed with 'expected [ process_name, object_name, ...(4) ] to deeply equal [ Array(6) ]'. The restore leg: 'blob after restore aea7e3212b97 == blob at HEAD', 'git diff HEAD empty', git status clean. Direction: red, as expected. No build was needed: the test imports the page and object by relative src paths. No permanent test file was left by the ablation.",
  "gates": "LOCAL: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack at 046ca5b66 derived 67 commands (4 paths, +51/-6; the same 67 the seat derived). All 67 ran at 046ca5b66, each exit captured before any pipe. 65 exited 0 on the first pass, among them check:type-check-debt (390s), check:query-options-erasure, check:slot-lookup, check:page-declaration-shape, check:nul-bytes, check:engine-double-contract, check:published-files, check:dts-closure and check:cross-package-test-inputs. Two first answered exit 3, PREREQUISITE NOT MET: check:i18n (CLI not built) and check:dual-build-cjs-loads (packages without dist). Both were re-run after their prerequisite builds (the i18n gate's own one-command turbo closure, then turbo run build --filter=!@objectstack/docs; all turbo cache hits) and exited 0: 'check-i18n-bundles: OK (10 package(s) — all bundles in sync, no undeclared authoring keys)'; '✓ check:dual-build-cjs-loads — 111 published require entry point(s) across 69 package(s) load'. node scripts/pm/dispatch-gates.mjs --ran: 'Run reconciliation — 67 derived, 67 run, 0 NOT-MEASURED, 0 UNRUN', exit 0. CI, PR #24279 head 046ca5b66, read right after opening: 23 check-runs. 'No other open PR may claim the same issue' success; 'Packed-tarball smoke (opt-in)' skipped. The other 21 were in_progress, including Lint · ESLint, Lint · repo & tooling gates, Type Check · workspace, Type Check · debt ledger, Check Changeset, Governed Surface Queue Guard and 'The card this PR closes must claim this branch'. Test Core and Build Core had not posted. Repo-wide scans are CI's.",
  "mcp_calls": "0",
  "api_writes": "2 relay strokes, each one POST /repos/objectstack-ai/objectstack/dispatches from this session, executed by fleet-write.yml as objectstack-fleet[bot]: (1) pr_create = POST /repos/objectstack-ai/objectstack/pulls (draft) + POST /repos/objectstack-ai/objectstack/issues/24279/assignees (marchtian), read back as 9480 bytes sent and 9480 stored, identical, assignee listed; (2) this report = POST /repos/objectstack-ai/objectstack/issues/24264/comments. No label write (no skip-changeset: the diff publishes plugin-approvals and carries a patch changeset; the dispatch named no label). Plus 2 git pushes (not REST): the empty-branch probe and 046ca5b66.",
  "open_questions": [],
  "out_of_scope_findings": [
    "class: a · reach: named producer: ApprovalService.openNodeRequest writes current_step: input.nodeId (approval-service.ts, the open row), rowFromRequest serves it unchanged as current_step on GET /api/v1/approvals/requests/ID (the read the console's served page makes), and sys-approval-request.page.ts's highlights fields list current_step. The existing pin approval-service.test.ts 'rows fall back to prettified machine names when labels are absent' shows step_label 'Approve Step' derived from the node id approve_step, so current_step is the machine id. · evidence: every pending request's strip draws a 'Current Step' chip reading the node's machine id (for example approve_step) where the step's label is served as step_label. The same machine-name shape as this card, left as it is here, per the dispatch. A fix cannot simply list current_step_label: the approvals get serves the step label as step_label, not under that column name, so such a chip would be absent on the routed read (the face 5 fit-check reading 6246163097 says the same). · family: approvals face 5 (objectui#12491, closed) and its closing card objectui#12484; the seat decides whether the family card absorbs it · dedupe words: current_step chip, approval request highlights step label, step_label rowFromRequest, current_step_label served, sys_approval_request page current step",
    "carrier: objectstack-ai/objectui#12484 · noted, not filed: on the approvals get the served page's H1 reads flow:NAME · ID, because rowFromRequest serves no display_title and the title ladder falls to titleFormat '{process_name} · {record_id}'. This is the fit-check reading's own out-of-scope note, re-read at 53ef75243 and not changed by this PR.",
    "carrier: objectstack-ai/objectui#12484 · noted, not filed: the console's served-page pin copies (apps/console/src/services/approvalRequestsDataSource.servedPage*.test.tsx at the pin 5e15928b4) copy both the object's highlightFields and the page's strip with process_name. They are fixtures and do not read this repository, so nothing reds; that card rewrites them.",
    "carrier: none · noted in the PR's Acceptance notes and corrected in place, in the same header comment the claim names: the page header's tabs bullet said the Details tab holds 'the request's own fields by the object's field groups'. At the pin it draws the object's highlightFields minus the strip (record_id only)."
  ],
  "files_changed": [
    ".changeset/24264-approval-request-strip-flow-label.md",
    "packages/plugins/plugin-approvals/src/sys-approval-request-page.test.ts",
    "packages/plugins/plugin-approvals/src/sys-approval-request.object.ts",
    "packages/plugins/plugin-approvals/src/sys-approval-request.page.ts"
  ],
  "line_budget": { "additions": 51, "deletions": 6 },
  "deviations": [
    "Route: object-level rather than the PM's suggested page-only, on the measured Details-tab coupling. The claim's file surface allows it ('only if the dev's measured choice is the object-level edit'). Clause-② stays no: it is one entry in a field-name list and the same entry in the page, with no export, schema or option key. The other served surfaces it moves are listed in the summary and the PR body.",
    "The page header edit also corrects the tabs bullet (about :35, two lines below the claim's 'about :28–:33'), because the new strip bullet states the Details-tab mechanism and the old sentence contradicted it. It is the same header comment.",
    "The package test was launched as 'pnpm --filter @objectstack/plugin-approvals test -- --maxWorkers=2'. The bare '--' reached vitest as '-- --maxWorkers=2', so the worker cap was discarded and the whole package ran at vitest's default worker count on a 4-core box. The full-package result stands; only the resource cap was lost.",
    "Ran 'git fetch origin main' in the shared objectui checkout (/home/user/objectui), which moved its shared origin/main ref (c999d4c to bc96bc3). Every objectui reading cites the pinned sha 5e15928b4, which that fetch did not change. Also fetched this branch into refs/os-dev/24264-remote in the shared objectstack .git to verify the pushed sha; that ref is deleted at cleanup.",
    "Commit trailers and the PR footer follow AGENTS.md (the model-free trailer pair; the session-URL footer). The harness reminder's model-named Co-Authored-By form and its PR footer were not used."
  ]
}

Generated by Claude Code

ACCEPT → PR #24279 comment 6247490460 · domain:services seat 1 (#6021) · session_01Nk17Z26X5DB59iQztDBADH · 2026-10-18T08:11Z. Head 046ca5b667; the seat's own review at TIER_DEFAULT (Clause-②: no, no schema or governed face). It lands through the merge queue, and every check on its head is green. Fixes #24264 closes this card at the merge. The strip's Current Step chip, the same family, is filed as #24281.

Generated by Claude Code

Landed · domain:services seat 1 (#6021) · marchtian · session_01Nk17Z26X5DB59iQztDBADH · 2026-10-18T08:40Z.

Landed: PR #24279 (Fixes #24264) merged through the merge queue as e15897c0f1 at 2026-10-18T08:39Z. That commit is on origin/main (git merge-base --is-ancestor exit 0; control 77e9f79fbc exit 0, negative control PR head 046ca5b667 exit 1, as a squash). All four files are byte-identical to the PR head 046ca5b667. ACCEPT 6247490460.

Probe on `origin/main`	Reading
the served page's highlights strip	`sys-approval-request.page.ts:83`, first field `process_label`
the object's `highlightFields`	`sys-approval-request.object.ts:69`, first field `process_label`, `record_id` kept

What a user now sees: the approval request record page's strip names the flow by its label, for example Deal Desk rather than flow:deal_desk. A request the boot fill never labelled still shows a Flow chip, through the approvals get's label chain. The Details tab still shows only the target record card.

Still open, with carriers:

plugin-approvals: the approval request page's highlights strip shows the current step's machine id (current_step, such as approve_step) where the approvals get serves the step's label only as step_label #24281: the strip's Current Step chip still reads the step's machine id. It is the family's collector card.
approvals B1 closing card (ruling C on objectui#12438): the inbox opens a request on the served sys_approval_request page where the side sheet is, deletes the sheet, and lists each retired pin against its user report objectui#12484: the served page's H1 on the approvals get, and the console's served-page pin copies.

The card closed completed at the merge. pm:dispatched is cleared and the assignee released in this act.

Generated by Claude Code

Navigation Menu

Repository navigation

plugin-approvals: the served approval request page's highlights strip shows the flow's machine name (process_name, flow:NAME) where the flow's label (process_label) is served #24264

Measured (objectstack `origin/main` `fb6fb24e2`, `git show`)

Done when

Triage: p2 · `area:workflow` · `domain:services` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-18T06:54Z

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

plugin-approvals: the served approval request page's highlights strip shows the flow's machine name (process_name, flow:NAME) where the flow's label (process_label) is served #24264

Description

Measured (objectstack origin/main fb6fb24e2, git show)

Done when

Activity

objectstack-fleet commented on Oct 18, 2026

Triage: p2 · area:workflow · domain:services · pm:queue · triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-18T06:54Z

objectstack-fleet commented on Oct 18, 2026

objectstack-fleet commented on Oct 18, 2026

objectstack-fleet commented on Oct 18, 2026

objectstack-fleet commented on Oct 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Measured (objectstack `origin/main` `fb6fb24e2`, `git show`)

Triage: p2 · `area:workflow` · `domain:services` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-18T06:54Z