Skip to content

chore(release): version packages - #224

Merged
Madraka merged 1 commit into
mainfrom
changeset-release/main
Nov 15, 2026
Merged

chore(release): version packages#224
Madraka merged 1 commit into
mainfrom
changeset-release/main

Conversation

@github-actions

@github-actions github-actions Bot commented Nov 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@cloudhal/[email protected]

Minor Changes

  • f41802b: cloudhal deploy --release installs the signed release of the CLI's own version instead of building the project (RFC-0046 §11b, @cloudhal/release-verify package and cloudhal deploy --release (RFC-0046) #227).

    • Trust lists. On every run it fetches the signed key list and yank list from cloudhal.dev and verifies them against the pinned root. It never falls back to an older copy. It keeps a yank memory in ~/.cloudhal/release-trust.json, so a rolled-back list, a replayed key list or a revoked yank key is refused.
    • Before the root ceremony no root is pinned, so the command refuses and names the ceremony.
    • The release. The release must be published (not a draft) and carry a bundle; v0.8.0 and older have none. The CLI verifies it with @cloudhal/release-verify: the keys reduced by both lists, yanked versions refused, and every file checked against its digest.
    • The attestation. It checks the build-provenance attestation with gh. --allow-single-factor continues on the release key alone when gh is unavailable; a failed attestation is always refused.
    • The project. Its theme files must equal the CLI's own starter, unless --discard-local-theme is given. Its cloudhal.json build keys must match the starter's, a key the CLI does not know is refused, and the installed wrangler must be at least the bundle's.
    • Refused projects. Projects attached to another installation, multi-site projects and Workers Builds are refused.
    • Deploying. The verified files are extracted into a fresh .cloudhal/deploy/release/<version>/. Both Workers are then deployed with no_bundle wrangler configs that upload exactly those bytes.
    • Offline and dry runs. --from <dir> installs offline from the assets and both lists, and --release --dry-run stops before wrangler.

    The CLI now depends on @cloudhal/release-verify.

    @cloudhal/release-verify now typechecks under every consumer's lib settings: WebCrypto inputs are ArrayBuffer-backed views, and the gzip pipe is typed through explicitly. @cloudhal/astro-renderer names the Site Worker's single-site choice singleSiteId, so a test holds that CLOUDHAL_SITE_ID overrides the built id.

Patch Changes

  • 49720db: render_page on Node gives a slow Chrome more chances to start. A launch that hangs past its start budget or exits is killed, and the renderer tries again up to three times. Each try uses a new profile, and the pause doubles from 1 s. The error says how long a launch may take and how many tries were made. A Chrome that crashes after it started is launched again by the next render, and its profile is removed (CI: render-chrome test fails when Chrome does not start on a busy runner #207).

  • 74d7098: RFC-0045 rollout step 7b: reference and repeater fields are now enabled. Sites can define reference fields (entries of one to five collections of the same site, one or several, with optional conditions) and repeater fields (ordered lists of items with up to ten flat sub-fields) wherever the renderer serving them reads the two types. See docs/guides/fields.md.

    • Where. On Cloudflare, once the site Worker serving the site answers GET /__cloudhal/features with fields: 2 (0.9.0 and later): the admin Worker asks the Worker each site is routed to (SITE, or an attached SITE_n), as it asks for time gates, and remembers a yes for that Worker only. Time gates are now confirmed per site Worker too, so a site on an older attached Worker no longer inherits the installation Worker's answer. Deploy the site Worker first; until it reports fields: 2, the types stay refused with fields_unsupported on every path. On Node (cloudhal dev, studio, self-host, Docker) and in the playground, always, since the renderer runs in the same process (openLocalStore passes FIELDS_SUPPORTED).
    • Every write path follows the capability: Studio, MCP, the API, field operations and their dry runs, and every bundle: cloudhal push (the admin route passes the store's capability), pull, cloudhal import (dry runs included), --replace and --revert. A bundle that defines either type is still refused whole where the capability does not hold, and a site's new snapshot cannot point at another site's held site body to bring the types in.
    • MCP and Studio. update_collection and change_field_type list both types, and /api/instance answers features.referenceFields: true, on servers that have the capability. The store still decides per site.
    • A one-time entry_refs check per site (rebuildEntryRefs, new core-ts export): the admin Worker's new refs.rebuild system job (every five minutes, offset from lists.backfill, until every site is done; then two reads a run), and openLocalStore at start-up. Rows are written per entry, anchored on the hash each entry was read with, so a concurrent edit keeps its own rows; each chunk is anchored on the site node's hash, so no statement grows with the site's settings; it leaves a site alone while a text ↔ reference type change runs there; progress is in the new entry_refs_state table (storage migration 0034_entry_refs_state), so a run stopped anywhere resumes. It is a safety net and should find nothing to change.

  • 9501d81: Studio's list toolbars come from one shared @cloudhal/ui block. The search now fills the free width of the row, and the filters, other actions, sort and refresh follow in a fixed order. @cloudhal/ui also gains StatusIndicator, UsageMeterRow, a "View docs" pill on PageLayout, and a resource mode for one resource's detail page: its tabs under the top bar, actions on the right, and no large title (@cloudhal/ui: dashboard-pattern blocks (resource tabs, docs link, list toolbar, status indicator, usage meter row) #228).

  • Updated dependencies [4cb3ac6]

  • Updated dependencies [f41802b]

  • Updated dependencies [5baacb4]

  • Updated dependencies [61825b8]

  • Updated dependencies [3ffdf29]

  • Updated dependencies [74d7098]

@cloudhal/[email protected]

Patch Changes

@cloudhal/[email protected]

Patch Changes

@cloudhal/[email protected]

Patch Changes

  • 74d7098: RFC-0045 rollout step 7b: reference and repeater fields are now enabled. Sites can define reference fields (entries of one to five collections of the same site, one or several, with optional conditions) and repeater fields (ordered lists of items with up to ten flat sub-fields) wherever the renderer serving them reads the two types. See docs/guides/fields.md.

    • Where. On Cloudflare, once the site Worker serving the site answers GET /__cloudhal/features with fields: 2 (0.9.0 and later): the admin Worker asks the Worker each site is routed to (SITE, or an attached SITE_n), as it asks for time gates, and remembers a yes for that Worker only. Time gates are now confirmed per site Worker too, so a site on an older attached Worker no longer inherits the installation Worker's answer. Deploy the site Worker first; until it reports fields: 2, the types stay refused with fields_unsupported on every path. On Node (cloudhal dev, studio, self-host, Docker) and in the playground, always, since the renderer runs in the same process (openLocalStore passes FIELDS_SUPPORTED).
    • Every write path follows the capability: Studio, MCP, the API, field operations and their dry runs, and every bundle: cloudhal push (the admin route passes the store's capability), pull, cloudhal import (dry runs included), --replace and --revert. A bundle that defines either type is still refused whole where the capability does not hold, and a site's new snapshot cannot point at another site's held site body to bring the types in.
    • MCP and Studio. update_collection and change_field_type list both types, and /api/instance answers features.referenceFields: true, on servers that have the capability. The store still decides per site.
    • A one-time entry_refs check per site (rebuildEntryRefs, new core-ts export): the admin Worker's new refs.rebuild system job (every five minutes, offset from lists.backfill, until every site is done; then two reads a run), and openLocalStore at start-up. Rows are written per entry, anchored on the hash each entry was read with, so a concurrent edit keeps its own rows; each chunk is anchored on the site node's hash, so no statement grows with the site's settings; it leaves a site alone while a text ↔ reference type change runs there; progress is in the new entry_refs_state table (storage migration 0034_entry_refs_state), so a run stopped anywhere resumes. It is a safety net and should find nothing to change.

  • Updated dependencies [4cb3ac6]

  • Updated dependencies [f41802b]

  • Updated dependencies [61825b8]

  • Updated dependencies [74d7098]

@cloudhal/[email protected]

Patch Changes

  • 4cb3ac6: The cloudflare target no longer bakes dataDir into virtual:cloudhal/config (release: drift guard that the cloudflare target ignores dataDir (RFC-0046 §11b) #239, RFC-0046 §11b). The Site Worker reads D1 and R2 through its bindings and never read the field. The baked value was the build machine's absolute data path, so a release bundle built in CI would have carried that path to every deployment. Node targets (cloudhal dev, static builds) keep it.

    The virtual module is now typed as VirtualCloudhalConfig, with dataDir optional; the type is exported, and the starter's env.d.ts uses it. Theme code that reads dataDir must handle its absence on the Cloudflare Site Worker.

  • f41802b: cloudhal deploy --release installs the signed release of the CLI's own version instead of building the project (RFC-0046 §11b, @cloudhal/release-verify package and cloudhal deploy --release (RFC-0046) #227).

    • Trust lists. On every run it fetches the signed key list and yank list from cloudhal.dev and verifies them against the pinned root. It never falls back to an older copy. It keeps a yank memory in ~/.cloudhal/release-trust.json, so a rolled-back list, a replayed key list or a revoked yank key is refused.
    • Before the root ceremony no root is pinned, so the command refuses and names the ceremony.
    • The release. The release must be published (not a draft) and carry a bundle; v0.8.0 and older have none. The CLI verifies it with @cloudhal/release-verify: the keys reduced by both lists, yanked versions refused, and every file checked against its digest.
    • The attestation. It checks the build-provenance attestation with gh. --allow-single-factor continues on the release key alone when gh is unavailable; a failed attestation is always refused.
    • The project. Its theme files must equal the CLI's own starter, unless --discard-local-theme is given. Its cloudhal.json build keys must match the starter's, a key the CLI does not know is refused, and the installed wrangler must be at least the bundle's.
    • Refused projects. Projects attached to another installation, multi-site projects and Workers Builds are refused.
    • Deploying. The verified files are extracted into a fresh .cloudhal/deploy/release/<version>/. Both Workers are then deployed with no_bundle wrangler configs that upload exactly those bytes.
    • Offline and dry runs. --from <dir> installs offline from the assets and both lists, and --release --dry-run stops before wrangler.

    The CLI now depends on @cloudhal/release-verify.

    @cloudhal/release-verify now typechecks under every consumer's lib settings: WebCrypto inputs are ArrayBuffer-backed views, and the gzip pipe is typed through explicitly. @cloudhal/astro-renderer names the Site Worker's single-site choice singleSiteId, so a test holds that CLOUDHAL_SITE_ID overrides the built id.

  • Updated dependencies [61825b8]

  • Updated dependencies [74d7098]

@cloudhal/[email protected]

Patch Changes

  • 74d7098: RFC-0045 rollout step 7b: reference and repeater fields are now enabled. Sites can define reference fields (entries of one to five collections of the same site, one or several, with optional conditions) and repeater fields (ordered lists of items with up to ten flat sub-fields) wherever the renderer serving them reads the two types. See docs/guides/fields.md.

    • Where. On Cloudflare, once the site Worker serving the site answers GET /__cloudhal/features with fields: 2 (0.9.0 and later): the admin Worker asks the Worker each site is routed to (SITE, or an attached SITE_n), as it asks for time gates, and remembers a yes for that Worker only. Time gates are now confirmed per site Worker too, so a site on an older attached Worker no longer inherits the installation Worker's answer. Deploy the site Worker first; until it reports fields: 2, the types stay refused with fields_unsupported on every path. On Node (cloudhal dev, studio, self-host, Docker) and in the playground, always, since the renderer runs in the same process (openLocalStore passes FIELDS_SUPPORTED).
    • Every write path follows the capability: Studio, MCP, the API, field operations and their dry runs, and every bundle: cloudhal push (the admin route passes the store's capability), pull, cloudhal import (dry runs included), --replace and --revert. A bundle that defines either type is still refused whole where the capability does not hold, and a site's new snapshot cannot point at another site's held site body to bring the types in.
    • MCP and Studio. update_collection and change_field_type list both types, and /api/instance answers features.referenceFields: true, on servers that have the capability. The store still decides per site.
    • A one-time entry_refs check per site (rebuildEntryRefs, new core-ts export): the admin Worker's new refs.rebuild system job (every five minutes, offset from lists.backfill, until every site is done; then two reads a run), and openLocalStore at start-up. Rows are written per entry, anchored on the hash each entry was read with, so a concurrent edit keeps its own rows; each chunk is anchored on the site node's hash, so no statement grows with the site's settings; it leaves a site alone while a text ↔ reference type change runs there; progress is in the new entry_refs_state table (storage migration 0034_entry_refs_state), so a run stopped anywhere resumes. It is a safety net and should find nothing to change.

  • Updated dependencies [74d7098]

@cloudhal/[email protected]

Patch Changes

@cloudhal/[email protected]

Patch Changes

  • 61825b8: Signed key and yank lists for release bundles (RFC-0046 §9, Release signing phase 2: signed keys.json and yanked.json, key expiry, KMS custody (RFC-0046 §9) #226).

    @cloudhal/core-contracts gains the release-keys root (keys.json, signed by an offline root) and the release-yank-list root (yanked.json, signed by a yank key and expiring 30 days after it is issued).

    @cloudhal/release-verify gains:

    • verifyKeys, which checks a pinned root's signature and that the list is fresh (expires at most 13 months after issuedAt);
    • verifyYanked, which checks a signature by an active yank key that keys.json lists, and refuses a stale list with stale-yank-list;
    • rememberYanks and the memory option of verifyKeys and verifyYanked, for consumers that keep state: they refuse a rolled-back or pruned yank list, a replayed older keys.json, and a revoked or replaced yank key. A keys.json may list at most one active yank key;
    • mergeTrust, which only reduces trust in the pinned keys: it revokes, marks retiring, and narrows a key's validity window, and it never adds a key.

    verifyRelease now enforces each key's validity window. A statement's createdAt must lie within its key's [notBefore, notAfter]. After notAfter, a key verifies only while a fresh keys.json lists it as retiring; otherwise the release is refused with key-expired. verifyRelease also refuses a yanked version (yanked). PINNED_KEYS now carries each key's window.

@cloudhal/[email protected]

Patch Changes

  • 74d7098: RFC-0045 rollout step 7b: reference and repeater fields are now enabled. Sites can define reference fields (entries of one to five collections of the same site, one or several, with optional conditions) and repeater fields (ordered lists of items with up to ten flat sub-fields) wherever the renderer serving them reads the two types. See docs/guides/fields.md.

    • Where. On Cloudflare, once the site Worker serving the site answers GET /__cloudhal/features with fields: 2 (0.9.0 and later): the admin Worker asks the Worker each site is routed to (SITE, or an attached SITE_n), as it asks for time gates, and remembers a yes for that Worker only. Time gates are now confirmed per site Worker too, so a site on an older attached Worker no longer inherits the installation Worker's answer. Deploy the site Worker first; until it reports fields: 2, the types stay refused with fields_unsupported on every path. On Node (cloudhal dev, studio, self-host, Docker) and in the playground, always, since the renderer runs in the same process (openLocalStore passes FIELDS_SUPPORTED).
    • Every write path follows the capability: Studio, MCP, the API, field operations and their dry runs, and every bundle: cloudhal push (the admin route passes the store's capability), pull, cloudhal import (dry runs included), --replace and --revert. A bundle that defines either type is still refused whole where the capability does not hold, and a site's new snapshot cannot point at another site's held site body to bring the types in.
    • MCP and Studio. update_collection and change_field_type list both types, and /api/instance answers features.referenceFields: true, on servers that have the capability. The store still decides per site.
    • A one-time entry_refs check per site (rebuildEntryRefs, new core-ts export): the admin Worker's new refs.rebuild system job (every five minutes, offset from lists.backfill, until every site is done; then two reads a run), and openLocalStore at start-up. Rows are written per entry, anchored on the hash each entry was read with, so a concurrent edit keeps its own rows; each chunk is anchored on the site node's hash, so no statement grows with the site's settings; it leaves a site alone while a text ↔ reference type change runs there; progress is in the new entry_refs_state table (storage migration 0034_entry_refs_state), so a run stopped anywhere resumes. It is a safety net and should find nothing to change.

  • Updated dependencies [61825b8]

  • Updated dependencies [74d7098]

[email protected]

Patch Changes

@cloudhal/[email protected]

Patch Changes

  • 74d7098: RFC-0045 rollout step 7b: reference and repeater fields are now enabled. Sites can define reference fields (entries of one to five collections of the same site, one or several, with optional conditions) and repeater fields (ordered lists of items with up to ten flat sub-fields) wherever the renderer serving them reads the two types. See docs/guides/fields.md.

    • Where. On Cloudflare, once the site Worker serving the site answers GET /__cloudhal/features with fields: 2 (0.9.0 and later): the admin Worker asks the Worker each site is routed to (SITE, or an attached SITE_n), as it asks for time gates, and remembers a yes for that Worker only. Time gates are now confirmed per site Worker too, so a site on an older attached Worker no longer inherits the installation Worker's answer. Deploy the site Worker first; until it reports fields: 2, the types stay refused with fields_unsupported on every path. On Node (cloudhal dev, studio, self-host, Docker) and in the playground, always, since the renderer runs in the same process (openLocalStore passes FIELDS_SUPPORTED).
    • Every write path follows the capability: Studio, MCP, the API, field operations and their dry runs, and every bundle: cloudhal push (the admin route passes the store's capability), pull, cloudhal import (dry runs included), --replace and --revert. A bundle that defines either type is still refused whole where the capability does not hold, and a site's new snapshot cannot point at another site's held site body to bring the types in.
    • MCP and Studio. update_collection and change_field_type list both types, and /api/instance answers features.referenceFields: true, on servers that have the capability. The store still decides per site.
    • A one-time entry_refs check per site (rebuildEntryRefs, new core-ts export): the admin Worker's new refs.rebuild system job (every five minutes, offset from lists.backfill, until every site is done; then two reads a run), and openLocalStore at start-up. Rows are written per entry, anchored on the hash each entry was read with, so a concurrent edit keeps its own rows; each chunk is anchored on the site node's hash, so no statement grows with the site's settings; it leaves a site alone while a text ↔ reference type change runs there; progress is in the new entry_refs_state table (storage migration 0034_entry_refs_state), so a run stopped anywhere resumes. It is a safety net and should find nothing to change.

  • Updated dependencies [4cb3ac6]

  • Updated dependencies [f41802b]

  • Updated dependencies [61825b8]

  • Updated dependencies [74d7098]

@cloudhal/[email protected]

Patch Changes

  • f41802b: cloudhal deploy --release installs the signed release of the CLI's own version instead of building the project (RFC-0046 §11b, @cloudhal/release-verify package and cloudhal deploy --release (RFC-0046) #227).

    • Trust lists. On every run it fetches the signed key list and yank list from cloudhal.dev and verifies them against the pinned root. It never falls back to an older copy. It keeps a yank memory in ~/.cloudhal/release-trust.json, so a rolled-back list, a replayed key list or a revoked yank key is refused.
    • Before the root ceremony no root is pinned, so the command refuses and names the ceremony.
    • The release. The release must be published (not a draft) and carry a bundle; v0.8.0 and older have none. The CLI verifies it with @cloudhal/release-verify: the keys reduced by both lists, yanked versions refused, and every file checked against its digest.
    • The attestation. It checks the build-provenance attestation with gh. --allow-single-factor continues on the release key alone when gh is unavailable; a failed attestation is always refused.
    • The project. Its theme files must equal the CLI's own starter, unless --discard-local-theme is given. Its cloudhal.json build keys must match the starter's, a key the CLI does not know is refused, and the installed wrangler must be at least the bundle's.
    • Refused projects. Projects attached to another installation, multi-site projects and Workers Builds are refused.
    • Deploying. The verified files are extracted into a fresh .cloudhal/deploy/release/<version>/. Both Workers are then deployed with no_bundle wrangler configs that upload exactly those bytes.
    • Offline and dry runs. --from <dir> installs offline from the assets and both lists, and --release --dry-run stops before wrangler.

    The CLI now depends on @cloudhal/release-verify.

    @cloudhal/release-verify now typechecks under every consumer's lib settings: WebCrypto inputs are ArrayBuffer-backed views, and the gzip pipe is typed through explicitly. @cloudhal/astro-renderer names the Site Worker's single-site choice singleSiteId, so a test holds that CLOUDHAL_SITE_ID overrides the built id.

  • 5baacb4: PINNED_ROOTS now pins the offline root cloudhal-root-2026a (Ed25519, from the owner's root ceremony on 2026-11-15). verifyKeys verifies the published keys.json with it by default. The first keys.json lists the release key cloudhal-release-2026a and the yank key cloudhal-yank-2026a, and is committed as security/keys.json. A CLI built with this version can run cloudhal deploy --release once cloudhal.dev serves the lists.

  • 61825b8: Signed key and yank lists for release bundles (RFC-0046 §9, Release signing phase 2: signed keys.json and yanked.json, key expiry, KMS custody (RFC-0046 §9) #226).

    @cloudhal/core-contracts gains the release-keys root (keys.json, signed by an offline root) and the release-yank-list root (yanked.json, signed by a yank key and expiring 30 days after it is issued).

    @cloudhal/release-verify gains:

    • verifyKeys, which checks a pinned root's signature and that the list is fresh (expires at most 13 months after issuedAt);
    • verifyYanked, which checks a signature by an active yank key that keys.json lists, and refuses a stale list with stale-yank-list;
    • rememberYanks and the memory option of verifyKeys and verifyYanked, for consumers that keep state: they refuse a rolled-back or pruned yank list, a replayed older keys.json, and a revoked or replaced yank key. A keys.json may list at most one active yank key;
    • mergeTrust, which only reduces trust in the pinned keys: it revokes, marks retiring, and narrows a key's validity window, and it never adds a key.

    verifyRelease now enforces each key's validity window. A statement's createdAt must lie within its key's [notBefore, notAfter]. After notAfter, a key verifies only while a fresh keys.json lists it as retiring; otherwise the release is refused with key-expired. verifyRelease also refuses a yanked version (yanked). PINNED_KEYS now carries each key's window.

  • 3ffdf29: New package @cloudhal/release-verify (RFC-0046 §11a). It is the one verifier of Cloudhal release bundles, and it is Worker-safe.

    verifyRelease runs these checks in order, and refuses on the first failure:

    • the Ed25519 signature on release-statement.json, against the pinned release keys;
    • that the statement is for the version and channel you asked for;
    • both precompiled validators;
    • every digest and §7 limit;
    • the tarball, in two passes.

    The tarball is never held whole. The first pass checks its digest, and the second yields each entry only once it is verified. Unsafe entry paths (.., ., empty segments, backslashes, control characters, case-fold duplicates) are refused with entry-path. Every refusal carries a stable code.

    The package also exports:

    • missingScopes, which applies §3's rule that workers-scripts.admin covers workers-scripts.edit;
    • releaseAssetUrls;
    • PINNED_KEYS, which can only be reduced.

    The Node-only subpath @cloudhal/release-verify/attestation checks the GitHub build attestation with gh 2.68.0 or newer.

@cloudhal/[email protected]

Patch Changes

@cloudhal/[email protected]

Patch Changes

  • 74d7098: RFC-0045 rollout step 7b: reference and repeater fields are now enabled. Sites can define reference fields (entries of one to five collections of the same site, one or several, with optional conditions) and repeater fields (ordered lists of items with up to ten flat sub-fields) wherever the renderer serving them reads the two types. See docs/guides/fields.md.

    • Where. On Cloudflare, once the site Worker serving the site answers GET /__cloudhal/features with fields: 2 (0.9.0 and later): the admin Worker asks the Worker each site is routed to (SITE, or an attached SITE_n), as it asks for time gates, and remembers a yes for that Worker only. Time gates are now confirmed per site Worker too, so a site on an older attached Worker no longer inherits the installation Worker's answer. Deploy the site Worker first; until it reports fields: 2, the types stay refused with fields_unsupported on every path. On Node (cloudhal dev, studio, self-host, Docker) and in the playground, always, since the renderer runs in the same process (openLocalStore passes FIELDS_SUPPORTED).
    • Every write path follows the capability: Studio, MCP, the API, field operations and their dry runs, and every bundle: cloudhal push (the admin route passes the store's capability), pull, cloudhal import (dry runs included), --replace and --revert. A bundle that defines either type is still refused whole where the capability does not hold, and a site's new snapshot cannot point at another site's held site body to bring the types in.
    • MCP and Studio. update_collection and change_field_type list both types, and /api/instance answers features.referenceFields: true, on servers that have the capability. The store still decides per site.
    • A one-time entry_refs check per site (rebuildEntryRefs, new core-ts export): the admin Worker's new refs.rebuild system job (every five minutes, offset from lists.backfill, until every site is done; then two reads a run), and openLocalStore at start-up. Rows are written per entry, anchored on the hash each entry was read with, so a concurrent edit keeps its own rows; each chunk is anchored on the site node's hash, so no statement grows with the site's settings; it leaves a site alone while a text ↔ reference type change runs there; progress is in the new entry_refs_state table (storage migration 0034_entry_refs_state), so a run stopped anywhere resumes. It is a safety net and should find nothing to change.

  • Updated dependencies [61825b8]

@github-actions
github-actions Bot force-pushed the changeset-release/main branch 3 times, most recently from fa1f9c2 to f597967 Compare November 14, 2026 11:59
@Madraka Madraka mentioned this pull request Nov 14, 2026
Merged
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 7 times, most recently from a3deb61 to fd37a70 Compare November 15, 2026 08:27
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from fd37a70 to a203674 Compare November 15, 2026 09:03
@Madraka
Madraka merged commit e187ed0 into main Nov 15, 2026
@Madraka
Madraka deleted the changeset-release/main branch November 15, 2026 09:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@Madraka