Repository navigation
chore(deps): bump actions/cache from 4 to 5 - #110
Merged
Merged
Conversation
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
|
Contributor
|
✅ All checks passed!
|
Bumps [actions/cache](https://github.com/actions/cache) from 4 to 5. - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits](actions/cache@v4...v5) --- updated-dependencies: - dependency-name: actions/cache dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/github_actions/actions/cache-5
branch
from
January 21, 2026 01:16
5ac2aa1 to
59875cc
Compare
Contributor
|
|
Contributor
|
✅ All checks passed!
|
This was referenced Sep 10, 2026
baozhoutao
pushed a commit
that referenced
this pull request
Sep 10, 2026
…g raise could not (objectui#8816) `fffa30d3f` raised `PER_CHUNK_GZIP_CEILINGS['i18n-locales']` to 465,000 over a 456,196 baseline and rested that raise, in the header, on the maintainer's INSTRUCTION of 2026-09-10 that red pull requests are RESOLVED rather than parked. That was a priority instruction, and at the time it was the only thing that existed: whether it also authorised route A rather than only the urgency was named as an open fork on objectui#8816 while the fork was still open. The ruling exists now — director seat summon #21, decision batch #110 item 3, recorded on objectui#8816 at comment 5615808548 on 2026-09-10, on the maintainer's reply to the recommendation of route A at comment 5615318265 — and the header rests on it instead, quoting both the reply and the ruling's own refusal to be read as a precedent: the next change that meets this line returns to the decision box. The sequence is recorded plainly, because it is the half a later reader cannot recover from the constant. The pair landed at 06:05:37Z as a RIDER inside PR objectui#8901 (`fix(data-objectstack): a refused view read is not an object with no saved views`), about two hours and forty minutes AHEAD of the ruling, and not in the dedicated pull request the ruling's execution clause asks for. No constant moves, in either direction. Reverting a maintainer-ruled value in order to re-land it in the ruled shape would land `main` red on `Bundle Analysis` for form; the number is right and it is ruled, and what was wrong is the record. Everything the block already got right is kept: the four-build derivation, the 8,804-byte = 0.10x headroom arithmetic, and that the size comes from this key's own convention rather than from the overage. Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FhBNJcLRZLe8M87VcUgpKr
akarma-synetal
pushed a commit
to akarma-synetal/objectui
that referenced
this pull request
Sep 17, 2026
…g raise could not (objectui#8816) (objectstack-ai#8956) * docs(scripts): record the maintainer ruling the `i18n-locales` ceiling raise could not (objectui#8816) `fffa30d3f` raised `PER_CHUNK_GZIP_CEILINGS['i18n-locales']` to 465,000 over a 456,196 baseline and rested that raise, in the header, on the maintainer's INSTRUCTION of 2026-09-10 that red pull requests are RESOLVED rather than parked. That was a priority instruction, and at the time it was the only thing that existed: whether it also authorised route A rather than only the urgency was named as an open fork on objectui#8816 while the fork was still open. The ruling exists now — director seat summon objectstack-ai#21, decision batch objectstack-ai#110 item 3, recorded on objectui#8816 at comment 5615808548 on 2026-09-10, on the maintainer's reply to the recommendation of route A at comment 5615318265 — and the header rests on it instead, quoting both the reply and the ruling's own refusal to be read as a precedent: the next change that meets this line returns to the decision box. The sequence is recorded plainly, because it is the half a later reader cannot recover from the constant. The pair landed at 06:05:37Z as a RIDER inside PR objectui#8901 (`fix(data-objectstack): a refused view read is not an object with no saved views`), about two hours and forty minutes AHEAD of the ruling, and not in the dedicated pull request the ruling's execution clause asks for. No constant moves, in either direction. Reverting a maintainer-ruled value in order to re-land it in the ruled shape would land `main` red on `Bundle Analysis` for form; the number is right and it is ruled, and what was wrong is the record. Everything the block already got right is kept: the four-build derivation, the 8,804-byte = 0.10x headroom arithmetic, and that the size comes from this key's own convention rather than from the overage. Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FhBNJcLRZLe8M87VcUgpKr * docs(scripts): the `i18n-locales` baseline's forward reading is spent, both sites (objectui#8816) The `PER_CHUNK_BASELINE` entry for `i18n-locales` was recorded as a FORWARD reading: 456,196 named "the state `main` reaches once objectui#8901 and objectui#8888 have BOTH landed", and the inline comment above the constant pointed at that note for "why this one names a state `main` has not reached yet ... while only one claimant has landed". `main` has reached it. `fffa30d3f` landed at 2026-09-10T06:05:37Z and `8ea3beee4` at 2026-09-10T06:05:40Z, three seconds apart, and both are ancestors of the tip. The two sentences were therefore false as written, in the present tense, six lines from the constant they describe — the same defect as the provenance repaired in the commit before this one, falsified by the same event, and repaired the same way. Both sites move together, deliberately. Repairing one and leaving the other is the split record this card exists to stop. Neither rewrite restates a headroom. The old sentence's arithmetic is kept as history, in the past tense, with the gate's own printed figure named as the one in force — a comment cannot keep a number that moves on most builds, which is the rule the prose pin in `scripts/__tests__/check-eager-closure-budget.test.ts` enforces one column over. No constant moves. All eight budgeted values still read byte-identically to `origin/main`, and the diff touches no line that names one. Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FhBNJcLRZLe8M87VcUgpKr --------- Co-authored-by: Claude <noreply@anthropic.com>
akarma-synetal
pushed a commit
to akarma-synetal/objectui
that referenced
this pull request
Oct 7, 2026
…at declares grouping (objectui#7347) (objectstack-ai#11191) Fixes objectstack-ai#7347 Clause-②: no ## What this is Ruling C on objectstack-ai#7347 (batch objectstack-ai#110 item 5) put the fix at the producer: `@objectstack/spec`'s `GroupingFieldSchema.field` refuses a grouping field name with leading or trailing whitespace (objectstack-ai/objectstack#17360), and objectui#11086 already moved this repository to the spec version that carries it. What was left for objectui is the regression pin that the refusal reaches objectui's own validation faces before any renderer is handed the name, plus one stale docblock sentence. - `packages/types/src/__tests__/grouping-field-padded-refused-7347.test.ts` (new): on every face that declares `grouping` (`list-view`, `object-gallery`, and `object-view`'s named list views), for each of four parse doors (the tolerant `AnyComponentSchema`, `safeValidateSchema` which is what `objectui validate` runs, the strict `StrictAnyComponentSchema`, and the exported mirror itself), the unpadded control parses green and each padded spelling fails with exactly one issue: code `custom`, path at that entry's `field`. The spec's message is not pinned; code and path are. A census derives from `AnyComponentSchema` which arms declare `grouping` and requires that set to equal the fixture table, so an arm that starts declaring `grouping` is covered or the census goes red. - `packages/core/src/utils/grouping-fields.ts`: comment only. The sentence calling `GroupingFieldSchema.field` "a bare `z.ZodString`" was false against the installed spec; it now says the field refuses a padded name, names the pin, and says the harvester's trim stays as defence. The trim itself is untouched, as ruled. - `.changeset/7347-padded-grouping-refused-pin.md`: empty frontmatter (tests and a comment, nothing released). No reader-side normalization anywhere: grid, gallery and kanban are untouched (ruling C refused that). ## Measured before building (the dispatch's mechanism assumptions) 1. **The installed spec refuses.** In this worktree `node_modules/@objectstack/spec` is 17.5.0 (the only resolved version). `GroupingFieldSchema.safeParse({ field: ' business_unit ' })` answers one `custom` issue at `field`; `{ field: 'business_unit' }` parses. `GroupingConfigSchema` answers the same issue at `fields.0.field`. Confirmed. 2. **objectui's faces inherit it by construction.** Confirmed for every face that declares `grouping`, and measured rather than read. A walk over the 145 flattened arms of `AnyComponentSchema` (and over every zod export of the published `@object-ui/types/zod` barrel) finds exactly three that declare `grouping` in their own document: `list-view` at `grouping`, `object-gallery` at `grouping`, `object-view` at `listViews.*.grouping`. On each, all four doors refuse the padded name as above and parse the control. The mechanism, checked on the gallery arm: `stripImportedDefaults` does rebuild the enclosing `GroupingConfig` and `GroupingField` objects (their `order` / `collapsed` defaults are stripped, so they are no longer reference-equal to the spec's), but the `field` string node crosses the boundary by reference and carries its one check. No face needed a fix, so no objectui schema source changes here. `objectui validate` end to end (the command's `validate()` run from source with `tsx` on JSON files; the CLI `dist` was not built): unpadded `list-view` answers `Schema is valid!` and exit 0; padded `list-view` answers exit 1 with `Code: custom` and `Path: grouping → fields → 0 → field`; padded `object-view` answers exit 1 at `listViews → all → grouping → fields → 0 → field`. 3. **The docblock sentence was false.** Corrected as above; that sentence and nothing else in the paragraph. 4. **`groupByField` is not this card.** Not touched; one reading in the Acceptance notes. ## Tests and gates, at `4d99273` Run from the worktree root, exit codes captured by redirect before any pipe; heavy runs through the shared verify lock. - `pnpm exec vitest run packages/types/` exit 0: `Test Files 286 passed (286)`, `Tests 6673 passed (6673)`. The pin is in that population (`vitest list packages/types/ --filesOnly` names it). - The pin alone: `Test Files 1 passed (1)`, `Tests 62 passed (62)` (1 producer case, 3 arms × 4 doors × 5 cases, 1 census). - `pnpm exec vitest run packages/core/src/utils/__tests__/grouping-fields.test.ts` exit 0: `Tests 14 passed (14)`. - `pnpm --filter @object-ui/types type-check` exit 0 (`tsc --noEmit && tsc -p tsconfig.examples.json && tsc -p tsconfig.test.json`; `tsc -p tsconfig.test.json --listFilesOnly` lists the pin once). `pnpm --filter @object-ui/core type-check` exit 0. - `pnpm --filter '@object-ui/core^...' build` exit 0 (that closure is `@object-ui/types`: `dist completeness: 1 package(s) complete`). `pnpm --filter '@object-ui/types^...' build` answers `ERR_PNPM_RECURSIVE_RUN_NO_SCRIPT` (exit 1): that closure holds no package with a build script, so there was nothing to build; not a red gate. - `node scripts/check-changeset-presence.mjs` exit 0: `2 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)`, empty frontmatter. - `pnpm check:control-bytes`, `check:changeset-claims`, `check:pending-changeset-literals`, `check:test-path-roots`, `check:shell-escape-residue`, `check:vi-mock-specifiers`, `type-check:coverage`: exit 0 each. `pnpm check:new-line-citations`: `VERDICT new-cross-file-line-citations: 0 new citation(s)`. - ESLint, narrowed to the two touched source files and shown to exclude nothing: `eslint --print-config` returns a config for both (both inside the linted population); `--format json` reports 2 files, 0 errors, 0 warnings; the effective config sets neither `parserOptions.project` nor `projectService`, so linting is not type-aware and this diff cannot move any untouched file's verdict. The repo-wide `pnpm lint` is CI's. - `@object-ui/cli` suite not run: no `validate` case was added. ## Ablation (one-off, not kept in the tree) The fix was committed first; each leg went through `ablation-replace.mjs` (the anchor must hit, blob hashes before and after) inside a script carrying an `EXIT INT TERM` restore trap. The pin imports the mirrors by relative path, so the mutated source is what runs (no `dist` in the path). - **A: the import boundary drops the refinement.** In `imported-defaults.ts`'s leaf arm, every imported `string` leaf was rebuilt as a fresh `z.string()`, which has no checks. Landed: anchor 1 → 0, marker 0 → 1, blob `0fa9694db112` → `ac546120b72e`. Expected: every padded case red and every control green. Observed: `Tests 48 failed | 14 passed (62)`. The 48 are the four padded case names × 12 arm-door pairs; the 14 are the producer case, the 12 controls and the census. Restored: blob back to HEAD's `0fa9694db112`, `git diff HEAD` empty. - **B: an arm starts declaring `grouping`.** `grouping` was added to the `object-grid` mirror. The first attempt was refused by the tool as a no-op (the replacement contained the anchor, so the count stayed at 1; nothing ran) and was re-anchored. Observed: `Tests 1 failed | 61 passed (62)`, the census, whose found set gained `object-grid`. Restored: blob back to HEAD's `091582208cc9`, `git diff HEAD` empty. ## Boundary: where this pin does not reach, and why it stays out On the tolerant face, and so through `objectui validate`, an `object-grid` or `object-kanban` node carrying `grouping: { fields: [{ field: ' business_unit ' }] }` parses green, and so does `grouping: 42`. Neither mirror declares `grouping`, and `BaseSchema`'s passthrough keeps an undeclared key without judging it. The strict face refuses `grouping` on both by name (`unrecognized_keys`) whatever its value. So nothing is stripping the refinement there; the key is undeclared. `object-grid`'s `grouping` already sits in the parity ledger's `UnmirroredDeclared` entry for `ObjectGridSchema` (the objectui#6152 worklist). `object-kanban` reads `grouping` through its index signature, which `ObjectKanban.tsx`'s own docblock names. Declaring either would change a published face's accept set, which `Clause-②: no` rules out for this card, so both go to the seat in the report and are not changed here. If either is declared later, the census picks it up (leg B shows that). ## Acceptance notes - In passing (dispatch assumption 4): under the installed spec, a `list-view` with `kanban.groupByField: ' stage '` is refused `custom` at `kanban.groupByField` on both faces (the unpadded control parses), and `gantt.groupByField` is refused the same way at `gantt.groupByField`. That axis is not this card; nothing here touches it. - `ListView.tsx`'s grouping-projection comment still calls `GroupingFieldSchema.field` "a bare string". Its point (nothing checks that the name is a declared field) still holds. Not edited here because it is outside this card's file surface; no carrier. - In-flight overlap: this diff does not touch `objectql.zod.ts`, so it does not intersect PR objectui#10278 or PR objectui#11125. --- _Generated by [Claude Code](https://claude.ai/code/session_0122Knsowci76D2rBWReCzzZ)_ Co-authored-by: Claude <noreply@anthropic.com>
This branch had an error being deployed
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.
Bumps actions/cache from 4 to 5.
Release notes
Sourced from actions/cache's releases.
... (truncated)
Changelog
Sourced from actions/cache's changelog.
... (truncated)
Commits
8b402f5Merge pull request #1692 from GhadimiR/main304ab5alicense for httpclient609fc19Update licensed record for cacheb22231eBuild93150cdAdd PR link to releases9b8ca9fBump actions/cache to 5.0.39255dc7Merge pull request #1686 from actions/cache-v5.0.1-release8ff5423chore: release v5.0.19233019Merge pull request #1685 from salmanmkc/node24-storage-blob-fixb975f2bfix: add peer property to package-lock.json for dependenciesDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)