Merge remote-tracking branch 'origin/main' into claude/project-thread-ybjm3h

Author: claude

.changeset/25694-anonymous-write-carries-no-file.md

@@ -0,0 +1,19 @@
+---
+'@objectstack/service-storage': patch
+---
+
+fix(storage)!: an anonymous write carries no file
+
+Ruling C ("an anonymous submission carries no file") now holds at every anonymous write door of ADR-0138 D2, not only at the public form door. A record write whose caller has no user, such as the guest an `authRequired: false` endpoint executes as under the grants a deployment binds to the guest, may not put a value in a file field (`file`, `image`, `avatar`, `video`, `audio`). It is refused before anything is written, with the form door's envelope: `400 VALIDATION_FAILED`, one `fields[]` entry per refused field carrying the ADR-0114 field code `invalid_value` and the field's label. An empty or absent file field is written as before. Signed-in callers, system writes and context-less programmatic writes are unchanged. No error code is added.
+
+Clause-②: no (narrowing) — an anonymous write that carried a value in a file field is refused. Nothing that was refused becomes accepted.
+
+Metadata-protocol: none (a write path's file rule; nothing a metadata author writes changes)
+
+<!-- adr-0087: not-required (no-migration-prescription) No metadata moves: no spec key, authorable spelling, object definition, stored row or stored shape is added, removed, renamed or re-shaped, and no exported declaration is removed or narrowed, so there is nothing for `objectstack migrate meta` to rewrite. What changes is which record writes the file-reference path accepts (an anonymous caller's write carrying a file value is refused). The remedy is a change of who provides the file (a signed-in caller), never a rewrite of a package source or a stored row. The other categories are closed on facts: the package publishes (not unpublished); no ADR-0087 id is named or touched (not registered or already-registered); and nothing exported is removed or narrowed (not runtime-interface-only, type-surface-only or runtime-export-retired). -->
+
+**BREAKING** for an anonymous write that carried a file value, shipped as `patch` because the metadata protocol does not move.
+
+- **Before.** Only the public form door refused a file value from an anonymous caller.
+- **Now.** Every write whose caller has no user is refused with `400 VALIDATION_FAILED` when a file field carries a value.
+- **Fix.** Leave file fields empty in an anonymous write. A file is provided by a signed-in caller, through the authenticated upload doors.

.changeset/25792-dependency-declared-co-ownership.md

@@ -0,0 +1,34 @@
+---
+'@objectstack/core': patch
+'@objectstack/objectql': patch
+'@objectstack/service-package': patch
+'@objectstack/cloud-connection': patch
+'@objectstack/metadata-core': patch
+---
+
+feat(install): a package that declares an installed app in `manifest.dependencies` may share that app's namespace, and a boot hydrates installed packages in dependency order (ADR-0141 D5)
+
+Clause-②: yes (narrowing)
+Metadata-protocol: none
+
+<!-- adr-0087: not-required (no-migration-prescription) No key of any metadata schema is added, removed, renamed or re-shaped: `manifest.dependencies` keeps its record shape and meaning. The one narrowing is an install-local acceptance detail of the not-yet-released ADR-0141 D2 check (an artifact wrapper's own id no longer counts as a delivered package), plus the matching removal of the unreleased `DeclaredDependencyCheck.deliveredIds` option; there is nothing for `objectstack migrate meta` to rewrite and no tombstone. -->
+
+**Namespace co-ownership by declaration.** The install gate (`SchemaRegistry.installPackage`) used to admit packages into one namespace only when one release artifact delivered them together. A module shipped as its own artifact that uses its app's namespace was refused `422 NAMESPACE_CONFLICT` beside the installed app, whatever it declared. Now an installed package P co-owns namespace N with:
+
+- an installed X that P declares in `manifest.dependencies`, when both use N;
+- a sitting owner of N that declares P, which is the same relation read from the other end, so an upgrade or reinstall of the app beside its modules is admitted;
+- a sibling S, when S and P each declare one installed package that holds N (two modules of one app, neither declaring the other).
+
+Only direct declarations count. The shared parent must be installed and must hold N itself.
+
+The object-name check reads the same co-owner set. A co-owner by declaration that defines an object name another co-owner already owns is refused `422 DUPLICATE_ARTIFACT_OBJECT_NAME` before any DDL. Examples: a module redefining its app's object, a sibling redefining the other sibling's object, or an app upgrade newly defining a name one of its modules owns. The message is worded per source (same artifact, declared dependency, sibling). `NAMESPACE_CONFLICT` now names the declaration as the fix for a package that extends the app holding the namespace.
+
+**Hydrate order.** The `sys_packages` hydrate and the install-local `kernel:ready` rehydrate used to register in source-listing order. Now they sort their batch by `manifest.dependencies`, with declared ids as optional edges, through `resolvePluginOrder`. Before this, a module that hydrated before the app whose namespace it shares could be refused and stay absent for the process lifetime. In the install-local rehydrate, each ledger entry is one node, so a declared id resolves to the entry that carries that package. A dependency cycle never stops a hydrate: its members keep source order and an error names them.
+
+**BREAKING** (an install-acceptance narrowing of the unreleased ADR-0141 D2 check) at `POST /api/v1/marketplace/install-local`. A multi-package artifact's own wrapper id no longer counts as delivered unless one of its packages carries it. A module declaring the wrapper id is judged like any other entry, because it would be `absent` on its first standalone install. `DeclaredDependencyCheck.deliveredIds` is removed with it. Also, an undecided range union whose installed version is readable is now reported `found: 'unreadable-range'` instead of `'unreadable-version'`; for example, `<5 || latest` against `7.0.0`.
+
+**What changes for you.**
+
+- A module that extends an app and uses its namespace declares the app in `manifest.dependencies`, and then installs beside it as its own artifact. Two modules of one app need not declare each other.
+- Every package of the app's own artifact that uses the namespace should declare the app too.
+- New exports: `@objectstack/core` exports `orderHydrationBatch` and `declaredDependencyIds`.

.changeset/25887-replayed-build-result-card.md

@@ -0,0 +1,16 @@
+---
+'@object-ui/plugin-chatbot': patch
+'@object-ui/app-shell': patch
+---
+
+fix(plugin-chatbot,app-shell): a whole-app build approved from the proposed plan draws its result card, live and after a reload
+
+Clause-②: no
+Metadata-protocol: none
+
+Approving a proposed plan sends the approval sentence, and the runtime replays the approved `apply_blueprint` under a `replay_` tool-call id. The chat read every replay result as the verdict of a confirm card and dropped its draft review, and a replay streams no build-progress frames, so the build's own envelope (`drafted[]`, `packageId`, `checklist`, `nextSteps`) reached the chat and was drawn nowhere: no result card, no Open app, no checklist, no next steps.
+
+- **`@object-ui/plugin-chatbot`:** a replayed whole-app build that drafted keeps its draft review and draws the same result card as a model-driven build. A replayed build in an auto-publish environment (`status: 'published'`) draws the card and its next steps from that envelope; so does a published build after a reload. A replay whose publish rolled back, and a replayed incremental edit, are unchanged.
+- **`@object-ui/app-shell`:** the AI chat page's hydration keeps the same draft review, so a reloaded thread binds to the package the replay built, and the conversation cache keeps that build's draft envelope instead of the bare replay verdict.
+
+What to do: nothing.

.changeset/25976-run-door-input-shape.md

@@ -0,0 +1,25 @@
+---
+'@objectstack/runtime': patch
+---
+
+fix(runtime)!: the action door and the flow trigger door refuse a body or a `params` that is not a JSON object, instead of running with an empty bag
+
+`POST /api/v1/actions/:object/:action` read its body, and then `params`, only when each was a truthy object. A string such as `{"params":"oops"}` became an empty params bag and the action ran anyway, answering `200` and starting a run the same as `{"params":{}}`; an array `params` was handed on as the bag itself; and a JSON string or array body ran the action with an empty bag too.
+
+`POST /api/v1/automation/:name/trigger`, its legacy spelling `POST /api/v1/automation/trigger/:name`, and every declared `type: 'flow'` API endpoint read the request body only when it was a truthy object. A JSON string body dispatched the flow with an empty bag, so it failed later with a misleading `400 FLOW_FAILED` "Unknown variable" or ran doing the wrong thing, and an array body forwarded its indices as params.
+
+Both now answer `400 VALIDATION_FAILED` with one `fields[]` entry, `{ field: '(body)', code: 'invalid_type' }` for a body and `{ field: 'params', code: 'invalid_type' }` for a `params`, whose message names the type received. The refusal comes before anything is dispatched, so no run starts and no run row is written. It is the refusal the resume door already gives a non-object body, and the three doors now ask the question through one check, so their answers have the same shape; the resume door's `fields[]` message now also names the type received.
+
+Unchanged: an object `params` (an empty one included) reaches the action as before, and an action call with no body, a JSON `null` body or no `params` key still runs with an empty bag. A trigger with no body, or a JSON `null` body, still runs with an empty bag. An unknown action or flow still answers `404`, and a caller the action or flow refuses still answers `403`, before the body is judged.
+
+Clause-②: no (narrowing) — the action and trigger doors refuse a body that is a string, number, boolean or array, and the action door refuses a `params` that is a string, number, boolean, array or `null`. Nothing is widened.
+
+Metadata-protocol: none (an HTTP request body's handling at the action and trigger doors; nothing a metadata author writes changes)
+
+<!-- adr-0087: not-required (no-migration-prescription) No metadata moves: no spec key, authorable spelling, object definition, stored row or stored shape is added, removed, renamed or re-shaped, and no exported declaration is removed or narrowed, so there is nothing for `objectstack migrate meta` to rewrite. What changes is how the action and flow trigger doors handle a request whose body or `params` is not a JSON object: it is refused instead of dropped. The remedy is a request edit (send `params` or the body as an object, or leave it out), never a rewrite of a package source or a stored row. The other categories are closed on facts: the package publishes (not unpublished); no ADR-0087 id is named or touched (not registered or already-registered); and nothing exported is removed or narrowed (not runtime-interface-only, type-surface-only or runtime-export-retired). -->
+
+**BREAKING** for a caller that sent the action door's body or `params`, or the trigger door's body, as something other than an object and relied on the call running anyway, shipped as `patch` because the metadata protocol does not move.
+
+- **Before.** A non-object body or `params` on the action door, or a non-object trigger body, was dropped (an array trigger body was forwarded as index-keyed params), and the action or flow was dispatched.
+- **Now.** The request is refused with `400 VALIDATION_FAILED` naming `params` or `(body)`, and nothing runs.
+- **Fix.** Send `params` as an object of input names to values, for example `{"params":{"note":"x"}}`, send the action body as an object (`{"recordId":"…","params":{…}}`), and send a trigger body as an object (`{"params":{"ownerId":"u1"}}` or a flat `{"ownerId":"u1"}`), or leave any of them out.

.changeset/25990-notify-both-channels-unheld-address.md

@@ -0,0 +1,15 @@
+---
+'@objectstack/service-automation': patch
+---
+
+fix(service-automation): a `notify` node naming `email` and another channel mails an address no user holds and no longer writes an inbox row addressed to it
+
+Clause-②: no
+Metadata-protocol: none
+
+An email address written out in `recipients` is the author's constant: on a node whose `channels` name `email` it is mailed as written. The inbox delivers to a user, keying its row by the recipient as a user id, and so does every channel but `email`. So on a node whose `channels` name `email` and another channel, such as `['inbox', 'email']`, an address no user holds now goes to the email channel alone.
+
+- **Fixed.** Before, the address went to every channel as it stood: the email channel mailed it, and the inbox also wrote a `sys_inbox_message` row whose `user_id` was the address, which no inbox reads. Now the node emits that address apart, on the `email` channel only, and the inbox writes no row for it. `user:ADDRESS` is handled the same way, whoever holds the address, because `user:` hands the address on as the user id with no lookup. An address whose holder cannot be looked up (no data engine, a lookup that fails) is mailed alone too.
+- **Unchanged.** The node succeeds as before. An address a user holds, written bare, still reaches that user's inbox and is mailed. A value expression that evaluates to an address on a node naming `email` still resolves to the user who holds it, or fails the node pointing to `{ emailField }`. A node that does not name `email` still fails on an address no user holds.
+- **What a run records.** When a node's recipients mix users and such addresses, the node writes two `sys_notification` events: one for the users on the node's `channels`, which the node's `notificationId` output names, and one for the addresses on `email` alone. The `delivered`, `enqueued` and `failed` outputs add up both.
+- **Who moves.** Nobody needs to change a flow. A report or audit over `sys_inbox_message` no longer sees rows whose `user_id` is an address.

.changeset/25999-flow-string-list-stored-string.md

@@ -0,0 +1,10 @@
+---
+'@object-ui/app-shell': patch
+---
+
+fix(app-shell): the flow inspector's list field shows a stored string as one entry instead of an empty list
+
+Clause-②: no
+Metadata-protocol: none
+
+A notify node's `channels` may be a single string (`channels: 'email'`) or a list; the spec accepts both and the runtime reads the string as a one-item list. Studio's flow inspector read any non-list value as empty, so the field showed no channels and adding one saved a list without `email`. A stored non-blank string now reads as a one-entry list (trimmed, as the runtime does). An edit saves the list form (`['email', 'sms']`); a field left untouched keeps the stored string.

README.md

@@ -248,17 +248,18 @@ git clone https://github.com/objectstack-ai/objectstack.git
 cd objectstack
 pnpm install          # Node 22+, pnpm 10 (corepack enable)
 pnpm build            # build all packages
-pnpm objectui:build   # build the Console SPA (not part of pnpm build)
+pnpm console:build    # put the Console SPA in packages/console/dist
 pnpm dev              # showcase example: REST + Console on :3000
 ```
 
-`pnpm objectui:build` builds [objectui](https://github.com/objectstack-ai/objectui)
-at the commit pinned in `.objectui-sha` into `packages/console/dist`
-(gitignored). It builds from a `../objectui` checkout if one sits next to this
-repo, otherwise from a shallow clone of objectui into `.cache/`; either way it
-installs objectui's dependencies, so it needs network. Skip it and `pnpm dev`
-still serves the REST API, without the Console. Rerun it when `.objectui-sha`
-moves.
+`pnpm console:build` builds the Console from its source in this workspace
+(`ui/apps/console`, against this tree's own spec and client) and copies the
+result into `packages/console/dist` (gitignored), which is where `pnpm dev`
+serves it from. Nothing is cloned or pinned. `pnpm build` builds the Console
+too but does not copy it, so after `pnpm build` this step is a copy. Skip it
+and `pnpm dev` still serves the REST API, without the Console. Rerun it after
+pulling changes under `ui/`: `packages/console/dist` is never refreshed on its
+own.
 
 A first run is slow, not stuck. Measured once on a fresh clone of `main`
 (4-vCPU container, Node 22.22, pnpm 10.31):
@@ -267,7 +268,7 @@ A first run is slow, not stuck. Measured once on a fresh clone of `main`
 |:---|---:|:---|
 | `pnpm install` | 16 s | |
 | `pnpm build` | 6 m 54 s | 72 turbo tasks |
-| `pnpm objectui:build` | 10 m 36 s | clones objectui and builds the Console |
+| `pnpm console:build` | 12 m 16 s | 72 turbo tasks: the Console and what it depends on, run before any `pnpm build` (`--concurrency=2`); a cache hit plus a copy, about 1 s, once `pnpm build` has run |
 | `pnpm test` | 54 m 03 s | the full suite: 135 turbo tasks |
 
 For your own change, test what it reaches instead of the full suite: