Merge remote-tracking branch 'origin/main' into claude/issue-9227-inline-columns-strict

Author: claude

.changeset/artifact-path-child-env-internal-channel.md

@@ -0,0 +1,55 @@
+---
+"@objectstack/cli": minor
+---
+
+fix(cli): `os start` / `os dev` stop writing `OS_ARTIFACT_PATH` into the child `serve` environment — the CLI's own plumbing moves to an internal channel (#8985)
+
+`os start` and `os dev` are supervisors: each resolves an artifact, then spawns
+`os serve` to boot it. Both handed the resolved path down by writing
+**`OS_ARTIFACT_PATH`** into the child environment — the same variable an operator
+sets to name an artifact. `dev` wrote it unconditionally; `start` wrote it
+whenever it had resolved anything and no `OS_ARTIFACT_URL` was in play. Both
+writes happen **before** the downstream `objectstack.config.ts` is evaluated.
+
+So inside any config, that variable was set on **every** boot, including boots
+where no operator had ever mentioned it — measured from the shipped EE image
+with its own `ENV` deliberately deleted: `os start` still printed
+`Artifact: dist/objectstack.json` and handed that path down. A config could not
+answer *"did a human ask for this, or did the CLI put it here?"*
+
+The resolved path now travels on **`OS_INTERNAL_ARTIFACT_PATH`**, a channel the
+CLI owns both ends of (`packages/cli/src/utils/internal-artifact-channel.ts`),
+and the property downstream consumers need is restored:
+
+> **the presence of `OS_ARTIFACT_PATH` in a config's environment means an
+> operator set it.**
+
+**Nothing about resolution changed.** Each command's ladder resolves in the
+parent exactly as before, and `serve` reads the new channel strictly between the
+reference and the operator knob:
+
+```
+--artifact > OS_ARTIFACT_URL > OS_INTERNAL_ARTIFACT_PATH > OS_ARTIFACT_PATH > <cwd>/dist/objectstack.json
+```
+
+That position is what preserves today's answers in both directions. It beats
+`OS_ARTIFACT_PATH` because `os start --artifact X` run with an operator's
+`OS_ARTIFACT_PATH=Y` exported boots **X** today — the parent used to overwrite
+the variable on the way down, and now inherits it untouched. It loses to
+`OS_ARTIFACT_URL` because `os dev` writes the channel unconditionally, as it
+wrote the old variable unconditionally, and the reference has always outranked
+the path.
+
+Two further behaviours are unchanged and now pinned rather than incidental:
+`start` still refuses to set `OS_BOOT_EMPTY` when a reference is driving the
+boot (an unreachable artifact host stays a loud refusal instead of a silently
+empty platform), and a resolved-but-missing artifact is still "named" to
+`resolveDefaultArtifactPath`, so it fails loudly rather than booting empty.
+
+**If you depended on the old side effect** — a config reading
+`process.env.OS_ARTIFACT_PATH` and expecting the CLI to have populated it — set
+the variable yourself, or read the artifact from the config's own inputs.
+`OS_ARTIFACT_PATH` remains a fully supported operator knob on the exact rung it
+has always occupied; the CLI simply no longer manufactures it on your behalf.
+`OS_INTERNAL_ARTIFACT_PATH` is not a supported knob and is deliberately absent
+from the environment-variable reference.

.changeset/authz-transport-wired-requires-enforced-row.md

@@ -0,0 +1,43 @@
+---
+"@objectstack/dogfood": patch
+---
+
+test(qa): a wired realtime transport can no longer be signed off by the row that records the absence of authorization (#9083)
+
+The ADR-0056 D10 authz conformance matrix carries a tripwire note promising
+that wiring an end-user realtime transport reds CI "until this row is upgraded
+with the enforcement site." The gate did not hold that out. `checkLedger`
+requires an `enforcement` site only when `state === 'enforced'`, while a row's
+`covers` keys classify a discovered surface **regardless of state** — so the
+shortest path from red back to green was to append the tripwire key to the
+`experimental` `realtime-delivery-authz` row, whose own summary records that
+realtime fan-out has **NO** per-recipient authorization.
+
+Measured on `origin/main` before the fix, both legs reproduced from the filing:
+wiring `new EventSource('/api/v1/stream')` into `packages/client/src/realtime-api.ts`
+fails 2 of 15 cases as `UNCLASSIFIED surface — … realtime:client/realtime-api.ts:transport(TRANSPORT-WIRED)`;
+appending that one key to the experimental row — with the transport still wired
+and zero authorization written — returns 15/15 green. The `removed` state was
+measured to admit the identical exit, so the rule keys on **not `enforced`**
+rather than on `experimental`.
+
+`checkTransportWiredAdmission` in `authz-conformance.test.ts` now refuses a
+`TRANSPORT-WIRED` key covered by any row that is not `enforced`, and
+`checkLedger`'s existing enforced-has-site invariant supplies the other half —
+the two compose into the promise the note makes, so flipping a row's state
+without writing the site is refused as well. The rule lives beside the probe
+table rather than in the shared ADR-0060 `checkLedger` helper on purpose:
+`TRANSPORT-WIRED` is this ledger's own vocabulary, and five other conformance
+ledgers share that helper without having transport tripwires. Tripwire keys are
+now minted through one `tripwireKey()` helper so the marker cannot drift out of
+the rule's sight (the keys themselves are byte-identical to before), and every
+assertion in the file drives the composed gate instead of `checkLedger`.
+
+The matrix note, the `covers` field TSDoc and both file headers were corrected
+to describe the gate that actually ships — the declared-≠-enforced defect here
+was in the *note*, so leaving it in place would only have moved the
+discrepancy. Six cases pin the new rule, including both reverse-verification
+legs and a positive control proving an `enforced` row naming its site still
+admits the key; each refusal case also asserts that bare `checkLedger` accepts
+the same ledger, so none can pass for an unrelated reason. Gate behaviour only
+— no runtime, spec or product surface changes, and no matrix row changed state.

.changeset/automation-resume-status-unification.md

@@ -0,0 +1,58 @@
+---
+'@objectstack/service-automation': minor
+'@objectstack/runtime': minor
+'@objectstack/client': minor
+---
+
+**BREAKING** — `POST /api/v1/automation/:name/runs/:runId/resume` answers real HTTP
+status codes for a failed run instead of HTTP 200 wrapping an inner `{success: false}`.
+
+Until now a screen flow driven to a server-side node failure answered:
+
+```
+HTTP 200
+{"success":true,"data":{"success":false,"error":"Node 'create_opportunity' failed: …"}}
+```
+
+The run genuinely failed; the transport reported success. A scripted or integration
+caller that branches on the HTTP status alone read a failed run as a successful one.
+This applies to the resume route the ruling for `/actions` (business failures must not
+ride HTTP 200 inside a double envelope), which every other automation refusal on this
+route already followed.
+
+What changes on the wire:
+
+- **A run that resumed and then failed ⇒ `400` with `error.code: 'FLOW_FAILED'`.** The
+  node failure stays the human-readable `error.message`. The flow author's own
+  `errorMessage` travels in `error.details.errorMessage` — one documented location, the
+  same one the console reads — and the run's per-node `summary` in
+  `error.details.summary`. `durationMs` is no longer carried on this response.
+- **A stale suspension ⇒ `404`.** The flow the run belongs to was deregistered, or the
+  node it was parked on was edited away under a live pause. Nothing ran and the pause can
+  never continue, so this is reported as terminal rather than as a business rejection.
+  The engine now classifies both cases as `RUN_NOT_FOUND`; the message names which one.
+- **Unchanged:** every refusal that leaves the suspension intact keeps its own code and
+  stays retryable — `PERMISSION_DENIED` (403), `INVALID_SIGNAL` /
+  `INVALID_SCREEN_INPUT` (400), `RESUME_IN_PROGRESS` (409), `STORE_UNAVAILABLE` (503) —
+  and a resume that pauses again still answers 200 with the next screen.
+
+**`@objectstack/client`:** `client.automation.resume()` and
+`client.project(id).automation.resume()` now **reject** on a failed run instead of
+resolving with `{success: false, error, summary}` — the SDK throws on every non-2xx
+before unwrapping. Callers that inspected the resolved value must move to a `catch`:
+
+```ts
+try {
+  await client.automation.resume(flow, runId, { inputs });
+} catch (err: any) {
+  err.code;                   // 'FLOW_FAILED' (400) — the run ran and failed
+  err.httpStatus;             // 400 | 404 | 403 | 409 | 503
+  err.message;                // the node failure, verbatim
+  err.details?.errorMessage;  // the flow author's own message, when the flow declares one
+}
+```
+
+Raw-HTTP callers that treated `2xx` as success and never opened the inner envelope now
+see the failure they were already being told about, one level up.
+
+<!-- adr-0087: not-required (no-migration-prescription) retires no metadata surface: no Zod schema, no authorable key, no stored sys_metadata row changes shape, so `objectstack migrate meta` has nothing to rewrite and no ledger entry can be written for it. What changes is an HTTP status plus an SDK method's promise contract, and the only channel that reaches those consumers is this changeset itself. -->

.changeset/cli-migrate-duplicates-inventory.md

@@ -0,0 +1,56 @@
+---
+"@objectstack/cli": minor
+---
+
+feat(cli): `os migrate duplicates` — an operator-facing inventory of the business identifiers the tenancy split already minted twice (#8928)
+
+Two producers of untenanted rows have been closed (#8686's seed loader plus its
+one-shot backfill, and #8844's runtime system-context write). Neither touches
+the **damage already done**, and both rulings say the same thing about it: a
+business identifier that has already been handed out — on an invoice, in a
+notification, in another system's idempotence key — is not the platform's to
+rewrite. What an operator needs instead is to know **which ones they are**.
+
+```bash
+os migrate duplicates                        # the whole report, JSON on stdout
+os migrate duplicates > duplicates-2026-08-17.json
+os migrate duplicates --object crm_case      # narrowed (and the report says so)
+```
+
+**Run it BEFORE the #8686 backfill is applied.** The evidence is perishable:
+`organization_id = NULL` is the marker that says "this row came from the
+untenanted side", and it is exactly what that repair overwrites. The repair also
+merges and deletes the `__global__` counter, which is the report's only
+forward-looking line — an install that repairs before reporting can never
+produce it again. The command itself applies nothing: it boots read-only (no
+DDL, no seed, no database file brought into existence) and issues SELECTs only.
+
+What the report contains, per the 2026-08-16 maintainer ruling on all five of
+the card's decision points:
+
+- **one row per duplicated value, with its holders** — id, organization,
+  partition and creation timestamp per row, so the operator can decide case by
+  case rather than per value. JSON on stdout, no persistence and no new schema:
+  the operator archives it;
+- **the narrow definition of duplicate** — a value held by rows in more than one
+  of the partitions `COALESCE(organization_id, '__global__')` separates
+  (ADR-0120 D3). A value repeated *inside* one partition is refused by the
+  partitioned unique index and is not reported;
+- **the live condition too** — an object still running a `__global__` counter
+  beside an organization-scoped one is about to mint more duplicates;
+- **a data-side probe** — `GROUP BY <field> HAVING COUNT(*) > 1` over the
+  object's own table, never an enumeration of `_objectstack_sequences`, so a
+  duplicate whose counter was since merged is still found. The counter table is
+  read for the live condition alone, because that fact lives nowhere else.
+
+Scope is every registered object that is organization-scoped, and on it every
+`autonumber` or `unique` field. `sys_` / `cloud_` / `ai_` objects are **not**
+filtered out — that filter is correct for a repair (platform seeds stay global
+by design) and wrong for a report, which must not silently omit a real
+duplicate. Anything that could not be probed is listed in `skipped` with the
+driver's own message, so a target the command could not read never reads as a
+target with no findings; a driver with no raw-SQL seam refuses loudly and exits
+non-zero rather than reporting zero duplicates.
+
+⛔ Reporting is all it does. Renumbering, deduplicating or otherwise rewriting an
+already-minted identifier stays out of scope per both rulings.