Merge remote-tracking branch 'origin/main' into claude/issue-23543-f5-http-reserved-node-names

Author: claude

.changeset/23385-walled-accepted-defaults.md

@@ -0,0 +1,26 @@
+---
+'@objectstack/plugin-security': minor
+---
+
+feat(plugin-security): under a walled posture, the deployment-level acceptance of package defaults can be host configuration (`acceptedDefaultPermissionSets`, ADR-0131 D5) (#23385)
+
+Clause-②: yes (widening)
+
+**What was wrong.** On a walled (`group` / `isolated`) deployment with several organizations and none of slug `default`, the audience-binding suggestion record has no organization to own it. Every boot logged `[security] audience-binding suggestion sync failed (non-fatal)`, and the accept door answered `409 SUGGESTION_STATE` with the remedy "create the Default Organization (slug 'default')". That is a reserved organization for deployment-level rows, the shape ADR-0131 §1.5 rejects.
+
+**What is new.** `SecurityPluginOptions.acceptedDefaultPermissionSets?: readonly string[]` is read only under a walled posture. When it is declared, possibly as `[]`:
+
+- the `everyone` anchor derives from the baseline plus the declared sets. Each name passes the same checks an accepted suggestion does: the security catalog serves it under some package, it declares `isDefault: true`, and it carries no bit the `everyone` anchor forbids (ADR-0090 D7). A name that fails a check grants nothing and is reported, at `error` for a forbidden bit;
+- the `sys_audience_binding_suggestion` record is neither read nor written, so the boot no longer warns. Existing rows are counted once and reported, not deleted;
+- the record's list, accept and dismiss doors answer `409 SUGGESTION_STATE` naming the option.
+
+```ts
+new SecurityPlugin({ acceptedDefaultPermissionSets: [] });              // nothing beyond the baseline
+new SecurityPlugin({ acceptedDefaultPermissionSets: ['crm_readonly'] }); // every member also holds crm_readonly
+```
+
+A walled deployment that declares nothing keeps today's behaviour. When it has no organization to own the record, the refusal now names `acceptedDefaultPermissionSets` instead of "create the Default Organization".
+
+**Refused loudly.** A value that is not a list of non-empty names is refused at construction. A declaration under the `single` posture is refused at `start()`: there the record owned by the Default Organization is the acceptance. The `single` posture is otherwise unchanged, including its refusal text.
+
+**Exported for callers of the module's functions.** `readAcceptedEveryoneSets`, `syncAudienceBindingSuggestions` and `reconcileAudienceBindingSuggestions` take an optional trailing `DeploymentAcceptance` (`{ posture, acceptedDefaultPermissionSets }`), and `SuggestionDeps` gains `acceptedDefaultPermissionSets`. Omitted, they read the record as before. `WithheldAcceptance` gains `source: 'record' | 'host-configuration'`.

.changeset/23726-read-only-arms-remainder.md

@@ -0,0 +1,19 @@
+---
+'@objectstack/cli': patch
+'@objectstack/service-storage': patch
+'@objectstack/objectql': patch
+---
+
+Clause-②: no
+
+fix(cli): `os storage orphans`, the `os secret rewrap` dry run and the `os migrate summary-nulls` dry run say they write no row or table, and that opening a SQLite file can still switch its journal mode, instead of saying nothing was written
+
+**What was wrong.** Each of these runs boots through the SQL driver before it prints, and the driver's connect switches a SQLite file to the journal mode it asks for (WAL, unless `OS_DATABASE_SQLITE_JOURNAL_MODE=delete` is set in the command's own environment or the project's `.env`). Measured on a file still on a rollback journal, each run moved the header's journal-mode bytes (18 and 19, from 1,1 to 2,2) and its change counter, and changed no row or table, while printing "nothing was written". Nothing was lost.
+
+**What changed.** Each sentence below now claims no row or table. Where the run opened a SQLite file, the report's line is followed by the note the other read-only arms already carry: "Opening a SQLite file can still switch its journal mode (to WAL by default), which changes its header only." On PostgreSQL or MySQL the line ends without it.
+
+- `os storage orphans` (`formatStrandedOrphanInventory`, `@objectstack/service-storage`). FROM: "This pass is READ-ONLY: nothing was written, tombstoned or deleted." TO: "This pass is READ-ONLY: no row or table was written, tombstoned or deleted." and the note.
+- `os secret rewrap` (the dry run's note, `REWRAP_NOTES.dryRun`, also in `--json` `report.notes`). FROM: "Dry run: every attributed row was opened, re-sealed and verified in memory, and nothing was written. Re-run with --apply to write." TO: "… and no row or table was written. Re-run with --apply to write." The note already follows the dry run's closing line on a SQLite file, so this sentence carries none.
+- `os migrate summary-nulls` (the dry run that found NULL roll-ups, `formatSummaryBackfillReport`, `@objectstack/objectql`). FROM: "Dry run — nothing was written. Re-run with --apply to backfill." TO: "Dry run — no row or table was written. Re-run with --apply to backfill." and the note.
+
+**Unchanged.** No exit code, flag, prompt, refusal or export signature changes, and no `--json` document gains a field; the note is printed in the text output only. What the driver does on connect is unchanged: once a file is in the mode the driver asks for, these runs leave it byte-identical.

.changeset/23838-identity-feeds-off.md

@@ -0,0 +1,23 @@
+---
+'@objectstack/platform-objects': minor
+---
+
+feat(platform-objects)!: Setup's organization, team, business-unit and user records carry no Discussion feed: `sys_organization`, `sys_team`, `sys_business_unit` and `sys_user` declare `enable.feeds: false`, so a comment create on one of their records answers `403 FEEDS_DISABLED`
+
+Clause-②: no (narrowing: the comment create door refuses on four platform objects that accept it today)
+
+<!-- adr-0087: not-required (no-migration-prescription) No metadata moves: no spec key, authorable spelling, export or stored shape is added, removed, renamed or re-shaped, and no stored row is rewritten or deleted, so there is nothing for `objectstack migrate meta` to rewrite. What narrows is one runtime write door: the existing `enable.feeds` gate now refuses a comment whose thread names one of four platform objects, and the remedy is in the request a caller sends to that door, 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 no exported declaration is removed or narrowed (not runtime-interface-only, type-surface-only or runtime-export-retired). -->
+
+**BREAKING** (an accept-set narrowing), shipped as `minor` under the launch-window convention for breaking changes.
+
+Setup's identity records are directory entries, not discussion surfaces. The four objects declared no `enable.feeds`, so they took the default (`true`), and the console drew "Discussion (0)" with a comment composer on every organization, team, business unit and user record.
+
+What changes:
+
+- **The record page.** The console reads the flag (`enable.feeds !== false`), so it no longer draws the Discussion feed or its composer on these four objects' records. The record's activity history is unchanged.
+- **The data API.** A `sys_comment` create whose `thread_id` names one of these objects (`sys_user:USER_ID`, `sys_organization:ORG_ID`, `sys_team:TEAM_ID` or `sys_business_unit:UNIT_ID`) answers `403 FEEDS_DISABLED` and writes nothing, through REST, the SDK and every other caller of the data engine. An update that moves an existing comment into one of these threads is refused the same way.
+- **Comments already stored** on these records are kept. They stay readable through the data API, and an edit that does not change `thread_id`, such as a body edit, still saves.
+
+Unchanged: every other platform object and every application object keeps its own `enable.feeds` setting, and an object that declares none still accepts comments.
+
+Remedy: stop creating comments on these four objects' records. A discussion about a user, a team or an organization belongs on a record of an object that keeps its feed on.

.changeset/23847-turso-remote-not-null.md

@@ -0,0 +1,16 @@
+---
+'@objectstack/driver-turso': patch
+---
+
+fix(driver-turso): a Turso remote database enforces the `storage.notNull` a field declares, on the tables and columns its schema sync creates
+
+Clause-②: no
+
+**What was wrong.** On a Turso database reached over the remote transport (`libsql://…`, the transport hosted environments use), schema sync created every declared column nullable. A field declared `storage: { notNull: true }` was not enforced there: an insert that left it empty was stored. The same declaration on a local SQLite file (`file:`) has always produced a `NOT NULL` column. The drift report, which compares the database with the declarations through the shared differ, also read each such column as destructive `tighten_not_null` drift on a database the remote sync had just created.
+
+**What changes.** The remote face's `CREATE TABLE` and `ALTER TABLE … ADD COLUMN` add `NOT NULL` to a column whose field declares `storage.notNull`, wherever the local face adds it: on every field type, multi-value fields included, and never for `required` alone. On a remote database synced after this release, an insert that leaves such a field empty is refused by the database, and the drift report names no `tighten_not_null` for it.
+
+**What does not change.**
+
+- A column that already exists is not touched. A remote database synced by an earlier release keeps its nullable columns, and its drift report still names them `tighten_not_null`; no data at rest is migrated. So the remote face still declares its drift-report caveat (reworded to say this), and the `OS_ARTIFACT_URL` boot gate still does not act on a remote report.
+- Adding a `storage.notNull` field to a remote table that already holds rows is refused by SQLite (`Cannot add a NOT NULL column with default value NULL`), as it is on a local SQLite file, and that object's schema sync fails loudly. The remote error now names the refused statement. One case still differs: when the field also declares a literal `defaultValue`, the local face creates the column with that DEFAULT and accepts it, while the remote face emits no declared column DEFAULT and refuses it.

.changeset/23853-form-help-texts-plain.md

@@ -0,0 +1,14 @@
+---
+'@objectstack/spec': patch
+'@objectstack/platform-objects': patch
+---
+
+Clause-②: no
+
+Six help texts an administrator reads in Setup no longer carry ADR numbers. On the Permission Sets edit form,
+`isDefault`, `managedBy` and `packageId` are rewritten as plain sentences that say what the field does, and
+`adminScope` drops its "(ADR-0090 D12)" prefix. On the Positions edit form, `delegatable` drops "(ADR-0091 D3)".
+The view form's End-user controls description drops "(ADR-0047, Airtable Interface parity)".
+
+The ADR references moved to the comments beside the form rows. The generated metadata-forms translations carry
+the new wording in en, zh-CN, ja-JP and es-ES. No key, type or accept/refuse result changes.

.changeset/23855-settings-banner-translation-slot.md

@@ -0,0 +1,18 @@
+---
+'@objectstack/spec': minor
+---
+
+Clause-②: yes (widening)
+
+The platform translation bundle (`PlatformTranslationDataSchema`) gains a slot for a settings
+`info_banner` row: `settings.<namespace>.banners.<banner_id>.title` and `.text`, keyed by the
+specifier's `id`, beside `groups`, `keys` and `actions`. `title` translates the specifier's `label`
+(the heading spelling `groups` already uses) and `text` translates its `bannerText` (markdown).
+Before this, a translated banner was refused with `unrecognized_keys`, so a banner reached every
+locale in its manifest English. The slot is strict: a borrowed `label`, `bannerText` or
+`description` leaf, or a singular `banner` group, is refused with the spelling it meant.
+
+Two resolvers read it, `resolveSettingsBannerTitle` and `resolveSettingsBannerText`, from the
+`resolveSettings*` family: they walk the requested locale and the declared fallback chain, then
+return the manifest literal. The `info_banner` specifier's own accept set is unchanged. Give the
+banner an `id` to make it addressable; a banner without one keeps rendering its literals.

.changeset/23863-explicit-sqlite-non-file-refusal.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/runtime': patch
+---
+
+fix(runtime): an explicit `sqlite` or `sqlite-wasm` driver selection refuses a database URL that is not a file path, instead of opening a SQLite file at a path made of the URL
+
+Clause-②: no
+
+An explicit selection (`OS_DATABASE_DRIVER`, `--database-driver`, or the `databaseDriver` option) skips the URL classification, so the only check its URL meets is the SQLite file-name rule, `sqliteFilenameFromUrl`. Both hosts call that rule: the runtime's standalone host (`os dev`, `os start` and `os serve` over a plain config or an artifact, every `os migrate` subcommand, every embedder of `createStandaloneStack`) and the CLI's legacy `os serve` path, which re-raises its refusal as the fatal `UnsupportedDriverError`.
+
+- **Before, an opaque scheme (two or more characters and a `:` with no `//`).** `OS_DATABASE_DRIVER=sqlite OS_DATABASE_URL=jdbc:postgresql://127.0.0.1:5999/db os serve --dev` printed `✓ Server is ready` and created the directories `./jdbc:postgresql:/127.0.0.1:5999/`. `redis:h` opened a file named `redis:h`. This happened under both kinds.
+- **Before, a server URL under `sqlite-wasm`.** The WASM kind refused nothing: `OS_DATABASE_DRIVER=sqlite-wasm` beside `OS_DATABASE_URL=postgres://USER:PASSWORD@127.0.0.1:5999/db` booted ready and created `./postgres:/USER:PASSWORD@127.0.0.1:5999/`, which put the credentials in a directory name. `redis://h/x.db` opened a file too.
+- **After.** Under either kind, all of these get the refusal the `sqlite` kind already gave a `postgres://` URL. The kind is named in the sentence: `[StandaloneStack] sqlite-wasm driver was selected but the URL does not look like a file path (its scheme is "postgres://"). Use file:/path/to/db.sqlite, or set OS_DATABASE_DRIVER explicitly.` The message names the scheme only, never the URL, so credentials in the URL are not printed. The boot stops before it creates anything on disk.
+- **One file name changes answer.** Under an explicit selection a first path segment that holds a colon now reads as a scheme, as it already does when the URL selects the driver: `backup:2026.db` was a SQLite file and is now refused as the scheme `backup:`. Write `./backup:2026.db` or `file:backup:2026.db` for that file. A one-letter drive is a path, not a scheme (`C:\data\app.db`, `C:/data/app.db`).
+- **A `sqlite:` alias on a rung that does not normalize it.** `sqlite:` and `sqlite://` are aliases of `file:` in `OS_DATABASE_URL`, `--database` and the `databaseUrl` option. A declared default datasource's `url` and `TURSO_DATABASE_URL` reach the rule as written. There, under an explicit selection, `sqlite:./x.db` is now refused as the scheme `sqlite:`, where it used to open a file named `sqlite:./x.db`. `sqlite:///…` was already refused there under `sqlite` and is now refused under `sqlite-wasm` as well.
+
+`file:./x.db`, `./x.db`, `:memory:`, `wasm-sqlite:///path` (under `sqlite-wasm`), `sqlite:./x.db` in `OS_DATABASE_URL`, and paths with no scheme resolve to the same file as before. An empty name under `sqlite-wasm` is still `:memory:`.

content/blog/context-window-is-the-constraint.mdx

@@ -38,19 +38,25 @@ a dashboard, a lead-conversion flow, permission sets, an action, translations.
 
 | | |
 | :--- | :--- |
-| Files | 31 |
-| Lines | 1,929 |
-| Approximate tokens | ~18,500 |
+| Files | 30 |
+| Lines | 1,844 |
+| Approximate tokens | ~17,500 |
 
 That's the **whole example app**. Not a module of it — the data model, the
 UI, the automation, the access rules, all of it. It fits in about 9% of a
 200k-token context window.
 
-The Todo example is ~24.5k tokens. The kitchen-sink showcase app — which
-deliberately exercises every metadata type in the protocol, 91 files of it — is
-~174k. Even that one, the maximalist case, still fits in a 200k-token window —
+The Todo example is ~25k tokens. The kitchen-sink showcase app — which
+deliberately exercises every metadata type in the protocol, 90 files of it — is
+~175k. Even that one, the maximalist case, still fits in a 200k-token window —
 about 87% of it, leaving about 13% free for the actual work.
 
+These figures were measured at commit
+[`7a6ba0310`](https://github.com/objectstack-ai/objectstack/tree/7a6ba03109dbb7e91359eb0f7f3e64dd1263bca8/examples)
+over the non-test `.ts` files in each example's `src/`, with tokens estimated
+at four bytes each. The examples keep changing, so today's counts will differ a
+little.
+
 Measure your own:
 
 ```bash

content/blog/the-ontology-is-the-software.mdx

@@ -116,8 +116,9 @@ pages that is parsed into a UI tree and never executed as code.
 **The whole system becomes small enough to be held.** The bundled example CRM in
 this repository — accounts, contacts, leads, opportunities, activities, views, a
 dashboard, a lead-conversion flow, permission sets, actions, translations — is
-31 files and roughly 18,500 tokens. That is the whole application, not
-a module of it. An agent can load it end to end, answer *what breaks if I change
+30 files and roughly 17,500 tokens, measured at commit
+[`7a6ba0310`](https://github.com/objectstack-ai/objectstack/tree/7a6ba03109dbb7e91359eb0f7f3e64dd1263bca8/examples/app-crm).
+That is the whole application, not a module of it. An agent can load it end to end, answer *what breaks if I change
 this*, and refactor across data, API, UI, and permissions in a single change.
 We wrote about why that number is the one that matters in
 [The Constraint Isn't Typing Speed. It's the Context Window.](/blog/context-window-is-the-constraint)

content/docs/concepts/metadata-driven.mdx

@@ -228,12 +228,15 @@ actions, translations):
 
 | | |
 | :--- | :--- |
-| Files | 31 |
-| Lines | 1,929 |
-| Approximate tokens | ~18,500 |
+| Files | 30 |
+| Lines | 1,844 |
+| Approximate tokens | ~17,500 |
 
 That's the **whole example app** — about 9% of a 200k-token context window.
-Count it yourself:
+These figures were measured at commit
+[`7a6ba0310`](https://github.com/objectstack-ai/objectstack/tree/7a6ba03109dbb7e91359eb0f7f3e64dd1263bca8/examples/app-crm),
+with tokens estimated at four bytes each. The example keeps changing, so count
+it yourself for today's numbers:
 
 ```bash
 find examples/app-crm/src -name '*.ts' -not -name '*.test.ts' | xargs cat | wc -l