@@ -25,4 +25,4 @@ Measured through `POST /api/v1/data/:object/query` on SQLite and PostgreSQL 16 (
 | `{ $not: { owner: { region: "NA" } } }` | `INVALID_FILTER` / 400 | `d2`, `d4` |
 | `{ owner: { region: "APAC" } }` (no owner matches) | `INVALID_FILTER` / 400 | no rows |
 
-On the in-memory driver, a multi-valued relation's `$contains` still matches a stored id by substring per element, so there an id that is a substring of another stored id (`u1` inside `u10`) also matches; SQLite and PostgreSQL match the element.
+SQLite, PostgreSQL and the in-memory driver match the element of a multi-valued relation, so an id that is a substring of another stored id (`u1` inside `u10`) does not match it.
@@ -0,0 +1,21 @@
+---
+"@objectstack/driver-memory": minor
+---
+
+fix(driver-memory): `$contains` / `$notContains` on a multi-valued or JSON-stored field answer by membership, as the SQL drivers do
+
+Clause-②: yes (widening) — one new public method on the exported `InMemoryDriver` class, `filterContainsTest`; its return type `MemoryContainsTest` is not re-exported from the package entry. No accepted filter key or operator is added: `$contains` and `$notContains` keep their declared shape.
+
+On a field whose declaration makes it JSON-stored (`multiple: true` on a `lookup`, `user`, `select`, `radio`, `file` or `image` field, a `multiselect`, `checkboxes` or `tags` field, or a structured type such as `json`), the in-memory driver now answers `{ field: { $contains: v } }` by whole-element membership: some element of the stored array equals `v`. It used to match each element by substring, so `u1` matched a row storing `['u10']` and `'red'` matched a row storing `['redwood']`. A number member answered nothing: `{ nums: { $contains: '1' } }` missed `[1, 2]`. `$notContains` is the exact complement, and a row with no value still satisfies it. A scalar text column keeps the case-exact substring test.
+
+`driver-sql` gives the same answer on SQLite, PostgreSQL and MySQL; the two drivers were measured over the same fixture. The answer holds on every face of this driver:
+
+- `find()` and `count()`, in both filter spellings;
+- the nested-relation filter on a multi-valued relation, which the engine lowers to one `$contains` per related id;
+- `MemoryAnalyticsService`'s query, and its SQL echo, which now renders SQLite's `json_each` membership construct for such a column.
+
+The comparand is still a string. A number or boolean member is named by its text: `'1'` matches the stored number `1` (and `'1.50'` the number `1.5`), `'true'` matches the boolean `true`, and `'null'` matches a `null` member. A field the driver holds no declaration for, such as a field on an object never passed through `syncSchema`, keeps the substring reading.
+
+New: `InMemoryDriver.filterContainsTest(object, field, value)` returns the one test every face above lowers `$contains` to. It is a narrow seam for the analytics face, beside `filterSubstringPattern` and `filterComparandStorageForm`. The added public method is why this entry is `minor`.
+
+**If your tests relied on the old answer:** on the in-memory driver, a filter that matched an id by prefix or a tag by substring now returns only the member rows. That is what SQL already returned in production. Write `$contains` with the whole member value.
@@ -0,0 +1,13 @@
+---
+'@objectstack/metadata-protocol': patch
+---
+
+fix(metadata-protocol): the by-name read of a flow name a managed package ships serves the package's flow, as the flow list does (#20946)
+
+Clause-②: no
+
+`flow` is in ADR-0126's Regime C: a managed package's flow is sealed, and there is no overlay read path for it. The flow list, `GET /api/v1/meta/flow`, and the execution view the automation engine binds flows from already serve the package's flow for a name a managed package ships (#20913). The by-name read, `GET /api/v1/meta/flow/:name`, did not: for such a name it served a stored flow of that name, marked as the package's flow. So the two read doors answered two different flows for one name.
+
+The by-name read now applies the same rule the list applies, through the same checks. For a name a managed package ships, it serves the package's flow, with or without a package scope, whatever the stored flow's own package binding or markings say.
+
+The stored flow is not deleted, rewritten or refused. It stays in the store, and the automation engine still reports it as a shadowed definition at startup. Pending drafts, flow names no managed package ships, organization-scoped rows and every other metadata type are read as before.
@@ -0,0 +1,29 @@
+---
+'@objectstack/rest': patch
+---
+
+fix(rest): the `hint` on a NOT NULL refusal leads with the remedy for a column that requires a value, and names schema drift only as a condition, so an author who declared `storage: { notNull: true }` is no longer sent to `os migrate` (#20963)
+
+Clause-②: no
+
+A field that declares `storage: { notNull: true }` without `required` is a column
+the database keeps NOT NULL on purpose (ADR-0113). A write with no value for it,
+through `POST /api/v1/data/:object` or `PATCH /api/v1/data/:object/:id`, is
+refused by the database and answers `400 VALIDATION_FAILED` with a `required`
+finding for the field. That answer was right. Its `hint` said the field is
+optional in the metadata and "the physical schema has drifted from metadata",
+and told the caller to run `os migrate`, which changes nothing for a column
+declared NOT NULL.
+
+The `hint` now reads: "The database column for 'FIELD' requires a value: provide
+it, or declare the field `required` in the object metadata. If the object
+declares neither `required` nor `storage: { notNull: true }` for 'FIELD', the
+physical schema has drifted from metadata instead: run 'os migrate' to reconcile
+(or reset the dev database)." The first sentence holds for every NOT NULL
+refusal. The second names the drift case under the condition that makes it drift.
+
+**What is not affected.** The status, `code`, `error`, `fields` and `object` of
+the answer are unchanged, and no key is added. The import row is untouched: it
+does not carry a `hint`. Nothing reads the field map to tell the two cases
+apart, so the `hint` stays advice for the author to read against the object's
+declaration.
@@ -646,6 +646,9 @@ reached by that run.
   **nine** of the items on this page were live and unaddressed on that stack. Its
   scope is the protocol chain; everything else on this list is outside it. (It
   also prints `runtime 17.0.0` on a 17.3.0 install.)
+  **Correction (2026-10-01):** from 17.4.0 the parenthetical on the `Chain:`
+  line reads `(this runtime implements protocol 17)`; `(runtime 17.0.0)` was
+  the 17.3.0 output. See #15585 (the human-readable line landed in #16058).
 
 **Metadata and build — run `os validate` before you ship**
 
 
@@ -25,8 +25,9 @@
     // BUILD ARTIFACT — so `tsc --noEmit` would be checking against whatever was
     // last built rather than against the source in this checkout, and a stale
     // `dist` typechecks green over an engine contract that has since moved.
-    // `pnpm check:type-source-resolution` is the gate; it wants the `paths`
-    // rule, not a registry entry.
+    // `check:type-source-resolution` was the gate, and it wanted the `paths`
+    // rule, not a registry entry, until it was retired on 2026-09-18 (#18373);
+    // no gate checks this rule now.
     "paths": {
       "@objectstack/formula": ["../../packages/formula/src/index.ts"]
     }
 
@@ -38,8 +38,9 @@
     // direction is SILENT: a `dist` merely BEHIND the source type-checks GREEN
     // against old declarations. This app is the fixture for a brand-new spec
     // surface (ADR-0130 D4's `packages[]`), which makes that exactly the
-    // reading it must not be able to give. `pnpm check:type-source-resolution`
-    // is the gate; it wants the `paths` rule, not a registry entry.
+    // reading it must not be able to give. `check:type-source-resolution` was
+    // the gate, and it wanted the `paths` rule, not a registry entry, until it
+    // was retired on 2026-09-18 (#18373); no gate checks this rule now.
     //
     // Two keys, and the star follows a separator: a tsconfig `paths` key
     // without a star is an EXACT match, and the `@objectstack/spec*` spelling
 
@@ -25,8 +25,9 @@
     // BUILD ARTIFACT — so `tsc --noEmit` would be checking against whatever was
     // last built rather than against the source in this checkout, and a stale
     // `dist` typechecks green over an engine contract that has since moved.
-    // `pnpm check:type-source-resolution` is the gate; it wants the `paths`
-    // rule, not a registry entry.
+    // `check:type-source-resolution` was the gate, and it wanted the `paths`
+    // rule, not a registry entry, until it was retired on 2026-09-18 (#18373);
+    // no gate checks this rule now.
     //
     // Same rule, same reason, for the email plugin: `test/email-template-locale.test.ts`
     // resolves this app's declared email templates through plugin-email's real
 
@@ -245,8 +245,9 @@ const CLI_PACKAGE_JSON = fileURLToPath(new URL('../package.json', import.meta.ur
  * `compilerOptions.paths` to EVERY specifier it resolves — including this
  * CLI's own. Ten in-tree directories carry such a rule, written for tsc so a
  * `typecheck` grades against a producer's source rather than its last build
- * (`check:type-source-resolution` requires them), and #11094 named the runtime
- * half "a latent runtime redirect for any tsx-honouring tool". Run this shim
+ * (`check:type-source-resolution` required them until it was retired on
+ * 2026-09-18, #18373), and #11094 named the runtime half "a latent runtime
+ * redirect for any tsx-honouring tool". Run this shim
  * from one of them and the CLI's imports are re-routed:
  *
  *     cd examples/app-multi-package
 
@@ -30,12 +30,13 @@
  * likely to be re-litigated: `plugin-email` already ships the explicit
  * `./email-plugin.js` extension and fails identically to `formula`'s
  * extensionless `./registry`. Adding extensions to the redirected packages
- * cannot fix this, and neither can removing the `paths` blocks — those are
- * mandated by `pnpm check:type-source-resolution`, which was green throughout.
- * So was `pnpm check:test-source-alias`. The two gates cover the **types** axis
- * and the **vitest** axis; the axis that broke — a CLI child's **runtime**
- * module resolution — is covered by neither, which is why the defect lived on
- * `main` while every gate reported success. The general third-axis guard is
+ * cannot fix this, and neither could removing the `paths` blocks — those were
+ * mandated by `pnpm check:type-source-resolution` (retired on 2026-09-18 —
+ * #18373), which was green throughout. So was
+ * `pnpm check:test-source-alias`. The two gates covered the **types** axis and
+ * the **vitest** axis; the axis that broke — a CLI child's **runtime** module
+ * resolution — was covered by neither, which is why the defect lived on `main`
+ * while every gate reported success. The general third-axis guard is
  * separate scope and tracked separately; this pin is the narrow half that
  * belongs to the fix.
  *
@@ -285,8 +286,8 @@ describe('no CLI command puts a child process under oclif\'s TypeScript source l
       + 'packages to their .ts source there — so the child resolves a CommonJS package to '
       + 'TypeScript and Node\'s CJS resolver then fails on that file\'s sibling imports '
       + '(`Cannot find module \'./registry\'`), killing `os dev` before the server starts. '
-      + 'Neither check:type-source-resolution (types axis) nor check:test-source-alias '
-      + '(vitest axis) sees this; they were both green while it was broken. Pass the child '
+      + 'Neither check:type-source-resolution (types axis, retired 2026-09-18) nor check:test-source-alias '
+      + '(vitest axis) saw this; they were both green while it was broken. Pass the child '
       + '`process.env` unmodified, or a NODE_ENV that is not '
       + `${[...SOURCE_LOADER_ACTIVATING].map((v) => `'${v}'`).join(' or ')}`
       + ' — and if a child genuinely needs dev semantics, let the child command set them '