Repository navigation
fix(ui): v1-honest start chips, assistant panel scroll, toast lifetime, and the remaining built-in aggregate captions - #7710
Merged
Conversation
…e, and the remaining built-in aggregate captions - cloud#1984: reword the five maker start chips in all ten packs (and the call-site defaultValue fallbacks) so they ask only for what ADR-0112 v1 builds; note beside the keys to revert when v2 re-adds flows. - objectui#7481: add step labels for get_authoring_rules, load_tools, open_record, test_flow and toggle_flow, which are newer than the pinned spec's platform-tool registry. - objectui#7480: re-arm StickToBottom on every send path so the assistant rail follows the thread; message appends deliberately do not. - objectui#7482: drop the console's bottom-right toaster override — the corner belongs to the ChatDock composer, where a resting pointer also pauses sonner's dismiss timer indefinitely. - objectui#7534: resolve builtinAggregate through buildDatasetFieldHelpers at the five headerLabel call sites, so a KPI/table/pivot/preview caption reads what the chart legend beside it reads. - objectui#7476: gate the sys_activity read on the object registry the shell already loads; every uncertainty still reads.
This was referenced Sep 5, 2026
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
hotlong
marked this pull request as ready for review
September 5, 2026 08:59
os-bill
pushed a commit
that referenced
this pull request
Sep 9, 2026
Neither has an open objectui card. Both are tests that predicted this exact
event in their own prose and said what to do when it fired, so the repair is the
one each prescribes — not a new decision.
`MetadataService.specKeyReference.test.ts` — the VERSION SKEW row. Until 17.3.0
the spec's `reference` emptiness test was an equality against `''`, so `' '`
parsed green while this writer refused it: a real divergence, declared rather
than hidden, with the spec half written as a tripwire for the day
objectstack#16920 reached the pin ("this line reddens when the pin reaches it —
at which point the reading becomes `false` and nothing else here moves").
17.4.0 carries the fix. Measured: `' '`, `''` and an absent target are now all
refused under the same `custom` issue at the same `reference` path the writer
names, while `'account'` and `' account '` still parse — the trim is for the
TEST only, which is what the writer's own pass-it-through row depends on. The
verdict flips and is asserted as an envelope (code plus path), because "refused"
and "refused AS a blank target" are separable claims. `MetadataService.ts` is
untouched, exactly as the note predicted. Closes the divergence objectui#8621
recorded; objectstack#16920 is the other repo's card and is not touched.
`toolLabels-locale-parity-7481.test.ts` — `AHEAD_OF_PIN`, the hand-held list of
tools the cloud runtime registers ahead of the spec snapshot. All five names it
carried are in `PLATFORM_TOOLS_BY_PACKAGE` at 17.4.0, and the file's own rule is
that a caught-up name must be REMOVED so the list never becomes a second
registry. Emptied, ⛔ not deleted: the next tool registered ahead of a snapshot
needs the same hatch.
⚠️ Emptying it turns three guards into tautologies — `[].filter(…)` is `[]`,
`arrayContaining([])` passes on anything — including the one whose comment says
it exists to stop the suite going vacuously green if the spec export disappears.
So they are re-anchored: a `GRADUATED` constant records the five names and
asserts they ARE in the registry, and the coverage floor is read off the
registry rather than off the emptied list. If the registry ever stops listing
one of them, that is now what reddens, and the repair is to put the name back on
`AHEAD_OF_PIN`.
⛔ objectui#7481 is CLOSED (completed via PR #7710) and is not reopened.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms
akarma-synetal
pushed a commit
to akarma-synetal/objectui
that referenced
this pull request
Sep 17, 2026
* chore(deps): take the 17.4.0 @objectstack/* line in the lockfile Float all seven `@objectstack/*` entries from 17.3.0 to 17.4.0 as one line: client, core, formula, lint, sdui-parser, spec, types. `package.json` is untouched — every declared range is a caret inside major 17 (`^17.0.0`, `^17.1.0`, `^17.2.0`, `^17.3.0`), all of which already admit 17.4.0. This is a lockfile refresh only. The re-resolve is pinned so the diff carries nothing but the seven identities. A plain `pnpm update -r "@objectstack/*"` also floats `zod ^4.4.3 -> 4.5.4`, which forks `ai@7.0.65`'s peer context and yields two physical copies each of spec, formula and lint — the objectui#8326 / objectstack-ai#8333 defect class that `scripts/check-lockfile-integrity.mjs` exists to catch. That float is not caused by this bump: `@objectstack/spec` and `@objectstack/core` declare the identical `zod: ^4.4.3` at 17.3.0 and 17.4.0. It is `pnpm update` re-resolving an already-satisfied range. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * chore(deps): move the two pins that must track the lockfile to 17.4.0 Both are mechanically coupled to the family move in the previous commit, and each carries its own prescription for exactly this event. `e2e/live/ci/backend.env` — `OBJECTSTACK_VERSION` 17.3.0 -> 17.4.0. The file's own header states the rule ("bump this in the same PR that bumps the console's @objectstack pins"), `content/docs/guide/ci-cd-pipeline.md` repeats it, and `scripts/__tests__/ci-cd-pipeline-doc.test.ts` enforces equality with the version `pnpm-lock.yaml` resolves. A mismatched pair makes the live-e2e lane carry no information either way (objectui#7689). `scripts/__tests__/check-lockfile-integrity.test.ts` — its two samples are transformations OF the real lockfile, anchored on the current pin, and the assertion that broke says so itself: "the spec snapshot key moved — rebuild this sample before trusting it". Only the anchor moves; the simulated downgrade target (17.2.0) and every assertion are unchanged, so both samples still reproduce objectui#8326 and objectui#8333 as before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * fix(scripts): keep the RegExp dot escaped when rebuilding the lockfile sample The previous commit rewrote the sample anchor from 17.3.0 to 17.4.0 and lost one backslash level in the process. The pattern is built through `new RegExp(...)` from a template literal, so `17\.4\.0` reaches the constructor as `17.4.0` and both dots become "any character" — matching, but by accident. `no-useless-escape` caught it. Restored to `17\\.4\\.0`, which is byte-identical to the base line apart from the version digit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * refactor(gantt): derive the ten extension keys from GanttConfigSchema.shape (objectui#7845) objectstack#15469 closed `GanttConfigSchema` and declared the ten keys plugin-gantt used to read through its `.passthrough()` window. objectui carried its own copy of those ten in two places; with the spec declaring them, the copies became duplicates and `ObjectGantt.blockPrecedence.test.tsx`'s no-duplicates pin measured it (40 keys, 30 unique). Retired both copies: - `GANTT_CONFIG_EXTENSION_KEYS` (`plugin-gantt/src/ObjectGantt.tsx`) — the flat key list is now `GanttConfigSchema.shape` plus the `dependencyField` alias. - `GanttConfigExtensionFields` (`types/src/zod/objectql.zod.ts`) — the flat face takes all ten from `SpecGanttConfigSchema.shape` by reference like its other members, and the nested `gantt` block is the spec schema itself rather than the spec schema extended with the local map. Compared member for member before deleting, as the card required: the spec's declarations cover the same ten keys, the same `interactions` (move/resize/progress/link) and `timeSegments` (dayStart/bands/showMidnight) sub-shapes and the same band members, with strictly fuller describes. The local copy carried no describe, alias or member the spec's lacks, so there is no difference to file. Also corrected the prose that still called the spec loose: `types/objectql.ts` said `timeSegments` was "the one key the spec genuinely does not model" and that `GanttConfigSchema` is `$loose` upstream — both false, and the first read as an invitation to write undeclared sub-keys that the `strictObject` now refuses by name. `zod/objectql.zod.ts` justified its own local `.passthrough()` by pointing at the spec's gantt/tree windows, which no longer exist; the local reason (and the measurement that `swimlaneField` / `endField` are still spec-undeclared) replaces it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * feat(dashboard)!: refreshInterval -> refreshIntervalSeconds, following the spec rename (objectui#7783) @objectstack/spec 17.4.0 renamed the dashboard's auto-refresh key (objectstack#15680, ruling B on objectstack#14478: a duration-shaped number carries its unit in the key name, not only in the describe prose) and left a `retiredKey` tombstone behind the old spelling. objectui's zod `DashboardComponentSchema` takes its spec-owned half from `SpecDashboardFields` by reference, so that face moved on its own the moment the lockfile did. What did NOT move was the TypeScript twin, and the pair's drift ledger caught it: `zod-mirror-parity.test.ts` refused to compile with `complex.zod.ts#DashboardComponentSchema` gaining `refreshInterval`. Moved here: the TS declaration; the four reader sites, keeping the `* 1000` arithmetic identical (the value is still seconds — the multiply is exactly the tell the rename exists to remove, and it now sits under a key that says so); the published registration input; the metadata-admin zh overlay key; the config panel's field key and the `DashboardConfig` model behind it; and the fixtures and pins that spell the key. ⛔ Deliberately NOT renamed, measured rather than swept: - `plugin-report` / `types` `reports.ts` / `reports.zod.ts` — the report component's own key, excluded by the card. - `DataBinding.refreshInterval` (`types/src/data.ts`) and `AIInsightsSchema.refreshInterval` (`types/src/ai.ts`). The card lists both among "the TS types" for this rename; they are not. Neither has a zod mirror or a `@objectstack/spec` counterpart (spec/ui exports nothing matching either name), so there is no producer behind a rename — and `DataBinding`'s is documented in MILLISECONDS, which makes `refreshIntervalSeconds` the wrong name for it outright. `content/docs/api/schema-reference.md` documented this key as milliseconds with a `30000` sample. It was never milliseconds; corrected with the rename. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * fix(components): element:record_picker.filter declares the ViewFilterRule array arm (objectui#7663) objectstack#14406 converged `ComponentPropsMap['element:record_picker'].filter` from the MongoDB-style `FilterConditionSchema` record onto `z.array(ViewFilterRuleSchema)` — the last record-form `filter` in the map, closing the maintainer's 2026-08-25 ruling that the platform carries one filter orthography (objectui#6206-B). @objectstack/spec 17.4.0 ships it, so the declaration here now teaches a shape the save gate refuses and a JSX page writing the legal array form draws a false `type-mismatch`. Measured at the installed spec before flipping: the record form is refused by KIND at `filter` (`invalid_type`, expected array), a bare tuple is refused at `filter.0` (expected object), and `[{ field, operator, value }]` is accepted — with `operator: 'eq'` normalised to `'equals'` on parse, which is why the fixture spells the canonical form. - `inputs.filter` flips `type: 'object'` to `'array'` and its description is rewritten around `[{ field, operator, value }, …]`. The PRECEDENCE paragraph is kept verbatim in substance: `dataSource.filter ?? filter` did not change. - The two parity pins swap sides — the record form is now the refused shape, the rule array the accepted one — and the refusals are asserted as an envelope (issue code plus path), so a parse that failed for an unrelated reason cannot stand in for the contract refusing the record form. - The coarse-type agreement test moves with them, and now states WHERE the agreement ends: `'array'` has no member arm, so a tuple list passes the manifest check and is refused only by the spec. That gap is named rather than papered over — the description carries what the coarse type cannot say. No renderer change: `filter?: unknown` passes through to `$filter` and `find()` already lowers the array form. The console parity test's `element:record_picker` arm goes green by derivation once the declaration moves; only its MEMBER_PINS prose is edited, to describe the arm that is actually pinned. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * feat(plugin-kanban): publish object-kanban `limit`, now that the spec declares it (objectui#8172) objectui#8172 was filed because four faces taught `limit` on an `object-kanban` — the renderer sending `$top: schema.limit ?? DEFAULT_KANBAN_LIMIT`, both `@object-ui/types` faces, and a documented section — while the strict `ComponentPropsMap` refused it BY NAME, so an author following this repo's own docs wrote a node the save gate rejected. The maintainer ruled option A (the contract catches up, 2026-09-07 「同意」), objectstack#16503 landed as objectstack#16562, and @objectstack/spec 17.4.0 ships `limit: z.number().int().positive().optional()`. ⭐ All three of the card's disagreeing faces were RE-MEASURED at this pin rather than assumed, as the card asked: - renderer — `ObjectKanban.tsx` still sends `$top: schema.limit ?? DEFAULT_KANBAN_LIMIT`, with `schema.limit` in the effect deps. Unchanged. - `@object-ui/types` — BOTH faces declare `limit` now (`objectql.ts` and the zod mirror `objectql.zod.ts`).⚠️ This falsifies the reading recorded on the card by the spec seat, which measured only the plugin's own `KanbanSchema` declaring it at pin `a472b07`; objectui's shared faces have since caught up, so there was no missing declaration to add. - docs — `plugin-kanban.mdx` teaches it correctly. Its one loose sentence is tightened here, because the key is now published with a precedence-bearing description and the two must agree: the binding's own `limit` wins outright, a named view's `pagination.pageSize` fills the cap only when the board leaves `limit` unset. Verified against `ElementDataSourceGate`'s `readLimit(base) === undefined` branch, not restated from the spec's describe. So the only face still out of step was this repo's registration, and that is what moves. ⛔ The declaration carries NO default: a materialised `limit` would defeat that same `readLimit(base) === undefined` branch and a bound view's `pageSize` would then never fill it — the spec seat's explicit warning. The `object-kanban::limit@spec` ledger row in `block-config-schema-parity-8216` is deleted, which is the ratchet working: a row that no longer describes a violation is as red there as a violation with no row. Its self-deleting probe went with it, so the spec-face ledger is now empty — and an empty probe list is indistinguishable from a broken oracle lookup, so a live control replaces it: the former violation must now parse clean AND an undeclared sibling must still be refused by name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * fix(console): the three unannounced @objectstack/spec 17.4.0 changes this repo asserted against (objectui#8785) Each was measured against BOTH spec versions before being repaired, so "changed in 17.4.0" is a reading rather than an inference. 1. `job.timeout` retired in favour of `timeoutMs`. The preview sample carried `timeout: 600000` and a comment arguing for that spelling ("the unit is already milliseconds"). The spec now refuses the key with a tombstone making the opposite argument — the unit belongs in the name, since the sibling `retryPolicy.backoffMs` already spelled its own and one surface was teaching two conventions. Same ruling family as objectui#7783. The SAMPLE moves; the value is unchanged. Measured: `timeoutMs: 600000` parses clean through `ObjectStackSchema`, `timeout: 600000` is refused at `jobs.0.timeout`. 2. The flow end-node `outcome` enum narrowed to `completed | refused`. The sample's `outcome: 'success'` is no longer a member. It becomes `'completed'` — ⛔ NOT `'refused'`, which the spec additionally requires a `message` beside (measured: `refused` with no message fails at `config.message`), and which would in any case describe the wrong ending for this sample. 3. The dashboard `gap` help text. The pin asserted that the ENGLISH producer copy still says "Tailwind"; 17.4.0 rewrote it to "Space between widgets, in steps of 0.25rem (4 = 1rem)". That leg is a non-vacuity control, not the subject: without it, "the zh copy does not say Tailwind" would pass just as well on copy that never said it. Re-pointing it at the new sentence buys exactly one release — this repo does not own that text. So the control now asserts the PROPERTY the overlay exists for: the producer's copy reaches for developer vocabulary (a framework name, or digits welded to a CSS unit) and the zh overlay carries none of it. Still non-vacuous, no wording pinned, and if the spec ever writes this hint in plain author language the control reddens and someone re-reads the overlay — which is correct, since the overlay would then have nothing left to do here.⚠️ `\brem\b` does not work for this: the boundary before `rem` never matches in `0.25rem`, because `5` is a word character. Measured both ways against both spec versions' copy before landing. ⛔ None of the three is patched green by relaxing an assertion: in all three the spec is the producer and it moved deliberately. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * test: discharge the two self-declared tripwires the 17.4.0 pin reached Neither has an open objectui card. Both are tests that predicted this exact event in their own prose and said what to do when it fired, so the repair is the one each prescribes — not a new decision. `MetadataService.specKeyReference.test.ts` — the VERSION SKEW row. Until 17.3.0 the spec's `reference` emptiness test was an equality against `''`, so `' '` parsed green while this writer refused it: a real divergence, declared rather than hidden, with the spec half written as a tripwire for the day objectstack#16920 reached the pin ("this line reddens when the pin reaches it — at which point the reading becomes `false` and nothing else here moves"). 17.4.0 carries the fix. Measured: `' '`, `''` and an absent target are now all refused under the same `custom` issue at the same `reference` path the writer names, while `'account'` and `' account '` still parse — the trim is for the TEST only, which is what the writer's own pass-it-through row depends on. The verdict flips and is asserted as an envelope (code plus path), because "refused" and "refused AS a blank target" are separable claims. `MetadataService.ts` is untouched, exactly as the note predicted. Closes the divergence objectui#8621 recorded; objectstack#16920 is the other repo's card and is not touched. `toolLabels-locale-parity-7481.test.ts` — `AHEAD_OF_PIN`, the hand-held list of tools the cloud runtime registers ahead of the spec snapshot. All five names it carried are in `PLATFORM_TOOLS_BY_PACKAGE` at 17.4.0, and the file's own rule is that a caught-up name must be REMOVED so the list never becomes a second registry. Emptied, ⛔ not deleted: the next tool registered ahead of a snapshot needs the same hatch.⚠️ Emptying it turns three guards into tautologies — `[].filter(…)` is `[]`, `arrayContaining([])` passes on anything — including the one whose comment says it exists to stop the suite going vacuously green if the spec export disappears. So they are re-anchored: a `GRADUATED` constant records the five names and asserts they ARE in the registry, and the coverage floor is read off the registry rather than off the emptied list. If the registry ever stops listing one of them, that is now what reddens, and the repair is to put the name back on `AHEAD_OF_PIN`. ⛔ objectui#7481 is CLOSED (completed via PR objectstack-ai#7710) and is not reopened. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * fix(docs): re-anchor the two doc ratchets this branch's own edits moved Both surfaced in the full suite, both caused by edits in this branch and neither by a spec change: - `check-doc-example-types.mjs`'s `UNGATED_EXAMPLES` is keyed by `path:line symbol`, and the gantt prose corrections in `packages/types/src/objectql.ts` added six lines above `ObjectFormSchema`'s `@example`. Re-anchored 1607 to 1613; verified by reading the `@example` line at both revisions. - `doc-version-claims` refuses a version literal on a doc surface that nothing in this repo can re-check. The `refreshIntervalSeconds` row added to `schema-reference.md` carried "@objectstack/spec 17.4.0". Taken out rather than added to `KNOWN_CLAIMS`, which is the remedy the gate itself prefers: the sentence needs the RENAME, not the release it shipped in, and the card number already points at the full account. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms * chore(changeset): declare the 17.4.0 line move and the contracts it follows `node scripts/check-changeset-presence.mjs` refused without one: 26 of the changed files are published source of a package the release covers. Scored `minor` across the eight packages whose `src/` moved — never `major`, because this repo's fixed group tracks the @objectstack major (AGENTS.md §版本号策略, enforced by scripts/check-changeset-no-major.mjs). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wtfW1ZxGnP1XKGc9uZVms --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Six small user-visible fixes on the maker / assistant / dataset surfaces, batched into one PR because they are all in this repo and none is bigger than a file or two. Verified on
6129b3b0c.References
cloud#1984. Closes #7476, Closes #7480, Closes #7481, Closes #7482, Closes #7534..objectui-shabump before any of this reaches the cloud product — nothing here ships to a tenant environment until that pin moves.cloud#1984 — the maker's start chips promised what v1 cannot deliver
The five chips on the environment home's "用 AI 搭建" are the product's own recommendations, and two of them asked for automation ADR-0112 v1 (cloud#1956 / PR #1970) does not author: the ticket chip said 「状态流转」, the inventory chip said 「低库存预警」. The measured behaviour was not a refusal — the model degraded them into a status kanban and a low-stock view — so the chip promised an alert and delivered a page.
All five reworded in all ten packs, plus the
defaultValuefallbacks inmetadataAssistantSuggestions(), which are a second copy of the same strings and would otherwise have kept the old promises on the surface with the least i18n. Each stays a real business scenario and asks only for objects, fields, views, pages, dashboards and sample data — the ticket chip now asks for a status field and a board grouped by it, the inventory chip for a view that filters items below their reorder point. A REVERT note sits beside the keys in every pack and at the call site, naming ADR-0112 v2.Also checked but NOT changed, and filed instead as objectui#7709: the maker's EDIT-mode starter
console.ai.suggestions.editApp.addAutomation(「加一个自动化 —— 审批、状态流转或通知」) is the same defect class one chip family over, but it has no v1-honest rewording that does not duplicate the three chips beside it — dropping it for v1 vs. replacing it with a different v1 capability is a product call, not a translation fix.Verified:
packages/i18n/src/__tests__/makerStartChips-v1-scope-1984.test.ts(32 cases) — all five keys present and non-empty in each of the ten packs, no chip matching that pack's OWN automation vocabulary (English-only scanning would have declared the five non-Latin packs clean without reading a character of them), and a non-vacuity control that re-runs each banned list against the wording that pack actually shipped before this PR and requires it to be flagged. PlusAiChatPage.startChips-1984.test.ts(4 cases) for the call-site copy, asserting byte-equality with theenpack.objectui#7481 —
Get authoring ruleswas unlocalized among Chinese step labelsget_authoring_rules(cloud#1837) had nochatbot.tool.*entry, so it fell through tohumanizeToolName's English title-caser. Checking the other recently-added tool names found four more in the same state:load_tools,open_record,test_flow,toggle_flow. All five are registered by cloudservice-ai-studio'splugin.tsbut are newer than the pinned@objectstack/spec'sPLATFORM_TOOLS_BY_PACKAGEsnapshot. Labels added to all ten packs.The root cause of the drift is upstream and filed as cloud#1995: the conformance test that exists to catch exactly this hand-lists four fewer definition groups than
plugin.tsregisters, so it asserts a stale list against an equally stale registry and stays green.Verified:
packages/plugin-chatbot/src/__tests__/toolLabels-locale-parity-7481.test.ts(17 cases). Coverage isregistry ∪ AHEAD_OF_PIN, so it becomes a real ratchet the moment the pin advances; a separate case fails if a name is left in the hand-held list after the registry lists it, which is what keeps that list shrinking to zero rather than becoming a second registry. Also pins that theenlabels are byte-equal to the title-caser (the packs' own stated rule, previously unchecked) and that an unknown/third-party tool still degrades to English.objectui#7480 — the assistant rail did not follow the thread after a send
Worth stating because the card's premise reads as a code divergence and is not one: the rail and the full-page maker are the same component (
ChatDock→ChatPane→ChatbotEnhanced→Conversation). What differs is width.StickToBottomauto-follows only while the view is at the bottom; in a ~360px rail a reply is two or three times taller than in the full-page column, so by the time the user has read it the lock is escaped and the next send appends off-screen.Every send path now re-arms the lock via the library's own
contextRefescape hatch — so the vendored ai-elementselements/conversation.tsxis not edited. That includes the plan card's "Build it" and the 确认修改 approval, whose own code comment already said "the approval's visible effect lands at the BOTTOM of the thread — outside the viewport when the plan card is scrolled into view". Message APPENDS deliberately do not scroll, so a user reading back through the thread while the answer streams is never yanked to the bottom.Verified:
ChatbotEnhanced.followOnSend-7480.test.tsx(4 cases) — acontextRefis handed to the conversation at all; a typed send and a start-chip send each scroll; and two successive streaming appends do not.objectui#7482 — the success toast covered the send button and never dismissed
One defect, two symptoms.
apps/consolepinned the toaster tobottom-right, an override that predates ADR-0057 P3a and the corner it gave to the ChatDock composer and its FAB. So a toast covered the send button — and sonner pauses a toast's dismiss timer whenever the pointer is inside the toaster region:expandedis set by that region's ownonMouseEnter/onMouseMove, so a pointer resting on the composer underneath held the timer at zero. The 4s default was never wrong; it never got to run. The override is gone and the console takesConsoleToaster's own documented top-right anchor.On the second half of the ask — "errors may persist" — deliberately not done, and the reason is written on the
duration: sonner'sToasterhas no per-type duration, so saying it means adurationat each of the ~100toast.error(...)call sites.closeButtonalready gives every toast a manual exit. Success toasts are at 4s, inside the 3–5s band the card asked for, and that is now pinned — nothing checked it before.Verified:
ConsoleToaster.autoDismiss-7482.test.tsx(3 cases: the default anchor is top-right, the override still works, and 「客户更新成功」 is present at 2.5s and gone by 5.5s) andconsoleToasterAnchor.ratchet-7482.test.ts(3 cases) which readsapps/console/src/App.tsxfrom source and refuses a bottom-right re-anchor, with its own non-vacuity control.objectui#7534 — built-in aggregate captions still printed the server's
CountbuildDatasetFieldHelpers().headerLabelnow takes an optionalbuiltinAggregateLabelsand resolves throughresolveMeasureLabelfirst — the seam objectui#7535/#7258 already landed forbuildChartSeries()— so there is ONE resolution order rather than two, and the five call sites pass it: the dashboardDatasetWidget(KPI caption + table/pivot headers), the three sites inDatasetReportRenderer(summary header, metric caption / chartmeasureLabel, matrix header), and app-shell'sDatasetPreview. Omitting the argument reproduces the previous output byte for byte.Verified:
dataset-format.builtinAggregate-7534.test.ts(10 cases — the full resolution order, every member of the closed vocabulary, an author-declared measure kept verbatim, a field literally namedcountwith no discriminator kept verbatim, an unrecognised discriminator, an unresolved and an empty label, and that omitting the argument changes nothing) plusDatasetWidget.builtinAggregateHeader-7534.test.tsx(5 cases) which renders the widget under a realI18nProviderand reads the KPI caption and the table header — the wiring half, which no pure test can see.objectui#7476 —
sys_activity404 on every openPremise partly retracted, and the retraction is why the change is small. "Handle the absence quietly" is already implemented, at four layers: the adapter memoizes the missing collection so no second request goes out, its
createQuietHttpLoggerdemotes the 404 toconsole.debug,sharedUserFeedsretires the feed as an ANSWER (ready, noterror, with a bounded 3-probe budget), and the panel renders its earned 「暂无最近动态」. None of that changes here. What was left is the one doomed request per page load, anddata-objectstackstates the rule for exactly that case in its own comment: "The cure for doomed requests is not issuing them, never hiding them once issued."So new
useObjectPresencereads the object registry the shell already loads for the nav (sys_*objects are in it where they exist —AppHeaderfilters them out of the app-object picker by name, and the console resolves/apps/{any app}/sys_activityas an ordinary object route). Absence has to be earned, because the two mistakes are not symmetric: a missed skip costs one request that already degrades correctly, while a wrong skip costs a real deployment its feed with no error anywhere. Only a registry that has ANSWERED and lists other objects without this one skips the read.The clause that would otherwise have shipped this broken:
useMetadata()outside a<MetadataProvider>returns a frozen no-op whosegetTypeStatussays'ready'and whosegetItemsByTypesays[]— a shape that reads exactly like "answered, and your object is not there". An empty registry therefore reads asunknown.Verified:
sharedUserFeeds.activityGate-7476.test.tsx(14 cases). Four of the six behavioural cases are "still reads" on purpose — no provider, empty registry, errored registry, present — one is "asks nothing yet" (still loading), and only the tenant-registry case is "no request at all". The pure predicate is pinned across all six status × registry-contents combinations.Verification
Host is macOS on Node v26.7.0; CI runs Node 22.x. The shared heavy-verify lock is Linux-only (
flockis util-linux), so it reports DECLARED UNLOCKED MODE here and provides no exclusion — noted rather than claimed.pnpm --filter '@object-ui/app-shell...' --filter '@object-ui/plugin-report...' --filter '@object-ui/plugin-dashboard...' --filter '@object-ui/plugin-chatbot...' --filter '@object-ui/console...' run buildpnpm --filter core --filter i18n --filter plugin-chatbot --filter plugin-dashboard --filter plugin-report --filter app-shell --filter console run type-checkDonepnpm exec vitest run packages/i18n/ packages/core/ packages/plugin-chatbot/ packages/plugin-dashboard/ packages/plugin-report/Test Files 322 passed (322),Tests 4937 passed (4937)pnpm exec vitest run packages/app-shell/ apps/console/Test Files 1 failed | 708 passed (709),Tests 7 failed | 6920 passed | 1 skipped— see below6129b3b0cpnpm exec vitest run <the nine>Test Files 9 passed (9),Tests 91 passed (91)pnpm lintTasks: 47 successful, 47 total,0 errors(2883 pre-existing warnings)eslint --format json <the 30 changed .ts/.tsx>no-explicit-any/ fast-refresh in files this PR touches by a few linescheck:i18n-keys,check:i18n-drift,check:i18n-dead-keyscheck-changeset-presence.mjs,check-changeset-no-major.mjspnpm check:control-bytesThe one red suite is pre-existing, proven
packages/app-shell/src/console/__tests__/anonSeedScope-5746.enumeration.test.tsxfails 7/7 withexpected 0 to be greater than 0on its own counter-probes — the instrument records zero sessionStorage writes, so nothing downstream of it can be measured.Checked against the merge-base rather than asserted: with the branch committed,
git checkout 8ad218d5 -- packages appsreverted the working tree to the base content (git diff --stat HEADshowed the 20 files reverting, 470 deletions), the file was re-run there and failed identically, 7/7. The tree was then restored withgit checkout HEAD -- packages appsand the restore proven bygit diff HEADbeing empty — not by the command's exit code.It also fails standalone, so it is not load-flakiness. The likeliest cause is the host's Node 26 (
localStorage is not available because --localstorage-file was not providedis emitted throughout) shadowing jsdom's storage; CI runs Node 22.x and will say. Reported rather than filed, since it reproduces only on this host so far.Ablation
The two i18n suites carry their non-vacuity controls in the file rather than as a one-off run: each locale's banned-vocabulary list is re-run against the exact wording that pack shipped before this PR and must flag it, and the toaster ratchet's matcher is re-run against the
position="bottom-right"line it replaced. A list that silently stops matching therefore fails the suite instead of passing it — which is the failure mode a manual ablation only rules out once.🤖 Generated with Claude Code