Merge remote-tracking branch 'origin/main' into claude/issue-21646-seed-created-at

Author: claude

.changeset/21589-detail-entry-sort-field-retired.md

@@ -0,0 +1,36 @@
+---
+'@objectstack/spec': minor
+---
+
+feat(spec)!: an `object-master-detail-form` detail entry's `sortField` is retired — the console derives the line-position field from the child object and reads no authored value (#21589)
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: registered object-master-detail-form-detail-sort-field-removed, object-master-detail-form-detail-sort-field-retired -->
+
+**BREAKING** — an accept-set narrowing on a published authoring surface, shipped as `minor` under the launch-window convention for accept-set narrowings.
+
+`ComponentPropsMap['object-master-detail-form'].details[].sortField` named the child field the line grid stamps with each line's position on drag-reorder. The console stopped reading it: the field it stamps is derived from the child object, and the pinned console crossed that change while the spec still declared the key. So an authored `sortField` went through `os validate` clean and was dropped, and a drag-reorder stamped the derived field, or none (ADR-0049 enforce-or-remove).
+
+### FROM → TO
+
+| before | what to write instead |
+| --- | --- |
+| `details: [{ childObject: 'crm_invoice_line', sortField: 'line_no' }]` | delete `sortField`. The grid stamps the child object's first field named `position`, `sort_order`, `sequence`, `line_no`, `line_number` or `sort`. |
+| `sortField` naming a field outside that list | give the child object one of those fields; the line order is kept there. |
+| an entry that names `relationshipField` and at least one column and gives every column a `type` | unchanged: the renderer keeps that entry exactly as authored, loads no child schema for it, and stamps no line position, before and after the upgrade alike. |
+
+**The one-line fix: delete `sortField` from every `object-master-detail-form` detail entry.** `os migrate meta --from 17` lists the mechanical edits for existing sources; apply them by hand.
+
+**What an author now sees.** Writing the key fails `tsc` (its input type is the retired-key mark), and `os validate`, `os build` and `os lint` report it as a `component-props-invalid` warning carrying the prescription at `properties.details.N.sortField`. A page that carries it still saves and loads: a page component's `properties` is not parsed on the metadata save or load path.
+
+### The retirement kit
+
+- **Tombstone.** `sortField` is a `retiredKey()` on the strict detail entry. Its prescription prints the derived field names from their one declaration, a module reached by relative import only (`data/inline-grid-sort-fields.ts`), which the derived inline-grid columns read too.
+- **D2 conversion `object-master-detail-form-detail-sort-field-removed`** (step 18, retired from the load path): a lossless delete of `sortField` from every `properties.details[]` entry of an `object-master-detail-form`, scoped by component type and by position. Stored `sys_metadata` pages and built artifacts replay it, one notice per entry.
+- **D3 entry `object-master-detail-form-detail-sort-field-retired`** carries the judgment the delete cannot make: whether the child object declares the field the line order is kept in.
+- **`RETIRED_KEYS_BY_MAJOR[18]`** registers the nested key `ui/ObjectMasterDetailFormProps:details.sortField`.
+- **`record:line_items`' answer to `sortField`** no longer sends the author to the detail entry: no block takes an authored `sortField` any more.
+- **No deprecation window**: the writer census is zero.
+
+**Measured producers: none.** On origin/main 9a4182a752, no `object-master-detail-form` detail entry in `examples/`, `apps/`, `packages/`, `skills/` or `content/docs/` writes `sortField`, against the sibling detail-entry key `addLabel` on the showcase project workspace's entry as the control, through the same instrument. At the objectui pin `89cad75d5570` the only detail entries that write it are probes asserting that nothing reads it. Deployed metadata NOT MEASURED.

.changeset/21624-flow-write-nodes-family-refusal.md

@@ -0,0 +1,13 @@
+---
+'@objectstack/service-automation': patch
+---
+
+fix(service-automation): a flow's `create_record`, `update_record` and `delete_record` nodes refuse a stored-metadata table as their target (#21624)
+
+Clause-②: no
+
+The two stored-metadata tables (the current metadata bodies and their version history) have one writer for app-authored work: the metadata protocol, where a change is validated and its provenance is recorded. A flow's write nodes wrote those tables directly, outside it. Under `runAs: 'system'` the write ran elevated, so the security middleware never judged it; under `runAs: 'user'` only a composition with the security plugin refused it, as a routable runtime failure with no code. A write node's `filter` was also evaluated against the stored rows, so whether the write acted answered a predicate over the stored body.
+
+**What changes.** A `create_record`, `update_record` or `delete_record` node whose `objectName` is either table is refused before it resolves its filter or its field values and before any engine write, under either run identity. The refusal names the metadata API as the way to change metadata and carries the standard `PERMISSION_DENIED` code, the code the data door answers a non-platform principal's write to these tables with. It is a guard failure: the run fails, nothing downstream of the node runs, and a `fault` edge does not route it. A `try_catch` catch region reads the code on `{$error.code}`. Metadata is changed through the metadata API (`PUT /api/v1/meta/:type/:name`), never through a flow's data nodes.
+
+**What does not change.** Every other object is created, updated and deleted exactly as before. `get_record` keeps serving these tables projected and keyed.

content/docs/references/ui/component.mdx

@@ -1084,7 +1084,7 @@ Sort field and direction pair
 | **formFields** | `string[]` | optional | Child field names for the per-row expand form. When omitted they are derived from the child object's fields — except on an entry that names both `relationshipField` and at least one column, which is kept as authored: nothing is derived, and the per-row form is offered only when `inlineMode` is 'form', where it draws the child object's full field list |
 | **inlineMode** | `Enum<'grid' \| 'form'>` | optional | Inline-edit form factor: 'grid' = editable cells; 'form' = read-only list + per-row full form. When omitted it is resolved from the relationship field's `inlineEdit`, else from the child object's shape — except on an entry that names both `relationshipField` and at least one column, which is kept as authored: nothing is resolved, the collection renders as a grid, and the per-row form is offered only when `formFields` lists more fields than `columns` |
 | **amountField** | `string` | optional | Numeric child column summed for the running total and the `totalField` rollup. When omitted it is picked from the grid's number and currency columns: a computed one, else one named `amount`, `total`, `subtotal`, `line_total`, `line_amount` or `net_amount`, else the last currency column, else the last numeric one — except on an entry that names `relationshipField` and at least one column and gives every column a `type`. The renderer keeps that entry exactly as authored, so nothing is picked. With no `amountField` authored or picked, the sums read a child column named `amount`, and the grid shows a running total only when `totalField` is set |
-| **sortField** | `string` | optional | Child field holding the line sort position, stamped on drag-reorder. When omitted it is the child object's first field named `position`, `sort_order`, `sequence`, `line_no`, `line_number` or `sort`, if it has one — except on an entry that names `relationshipField` and at least one column and gives every column a `type`. The renderer keeps that entry exactly as authored: nothing is derived, the grid stamps no line position, and a drag-reorder is not saved |
+| **sortField** | `never` | optional | [REMOVED] `object-master-detail-form` property `details[].sortField` was removed in @objectstack/spec 17 (ADR-0087 D2) — the console reads no authored value: the field the line grid stamps with each line's position on drag-reorder is derived from the child object, so an authored `sortField` was accepted and dropped. Delete the key. For a drag-reorder to be saved, give the child object a field named `position` / `sort_order` / `sequence` / `line_no` / `line_number` / `sort`: the renderer stamps the child's first field with one of those names — except on an entry that names `relationshipField` and at least one column and gives every column a `type`, which the renderer keeps exactly as authored and stamps no line position on. Run `os migrate meta --from 17` to list the mechanical edits for existing sources; apply them by hand. |
 | **totalField** | `string` | optional | Parent field to receive the rolled-up sum |
 | **title** | `string` | optional | Section title |
 | **minRows** | `number` | optional | Minimum number of rows |

packages/lint/src/validate-component-props.test.ts

@@ -91,6 +91,32 @@ describe('validateComponentProps — undeclared keys', () => {
     }
   });
 
+  // #21589 — an `object-master-detail-form` detail entry's `sortField` is a
+  // retiredKey tombstone, one array level down. The same door, the same
+  // warning: the finding names the entry's key, and the page is never refused.
+  it('reports a retired detail-entry `sortField` as a warning carrying the prescription, at the entry\'s key', () => {
+    const findings = validateComponentProps(
+      stackWith([
+        {
+          type: 'object-master-detail-form',
+          properties: {
+            objectName: 'invoice',
+            details: [
+              { title: 'Payments', childObject: 'invoice_payment' },
+              { title: 'Lines', childObject: 'invoice_line', sortField: 'line_no' },
+            ],
+          },
+        },
+      ]),
+    );
+    expect(findings).toHaveLength(1);
+    const [f] = findings;
+    expect(f.severity).toBe('warning');
+    expect(f.rule).toBe(COMPONENT_PROPS_INVALID);
+    expect(f.path).toBe('pages[0].regions[0].components[0].properties.details.1.sortField');
+    expect(f.message).toContain('`object-master-detail-form` property `details[].sortField` was removed in @objectstack/spec 17');
+  });
+
   it('walks components nested inside `properties` (tabs items → children)', () => {
     const findings = validateComponentProps(
       stackWith([

packages/services/service-automation/src/builtin/crud-nodes.ts

@@ -323,6 +323,55 @@ function storedMetadataFilterRefusal(
     return undefined;
 }
 
+/** [#21624] What each write node would have done, in its refusal's own words. */
+const STORED_METADATA_WRITE_VERB = {
+    create_record: 'create a record in',
+    update_record: 'update',
+    delete_record: 'delete from',
+} as const;
+
+/**
+ * [#21624] Refuse a WRITE node aimed at the stored-metadata family
+ * (`sys_metadata` / `sys_metadata_history`, judged by the family's own
+ * predicate, {@link isStoredMetadataBodyObject}).
+ *
+ * The family has one writer for app-authored work: the metadata protocol,
+ * where a change is validated and its provenance recorded (the ruling that
+ * refuses a hook body bound to these tables, or a body's direct write to them,
+ * applied to its own reason: a flow is app-authored automation too). Under
+ * `runAs: 'system'` the engine writes elevated and cannot tell this write from
+ * the platform's own internal writers, so the rule is applied here, at the
+ * node. ⛔ Not routed through the protocol from inside the node: that would be
+ * a second write path into the family.
+ *
+ * Judged on the object name the engine would be handed, before the node
+ * resolves its `filter` or its `fields`, so a refused node answers the same
+ * whatever it names: its filter is never evaluated against a family table
+ * (the write nodes' evaluate exit) and nothing it would write is computed.
+ *
+ * The answer is a guard refusal ({@link refuseNode}: the metadata is wrong, and
+ * re-running it unchanged never succeeds) carrying the standard catalog's
+ * `PERMISSION_DENIED`: the code the data door's in-process write path answers
+ * a non-platform principal's write to these tables with in a secured
+ * composition, and the code the body-write boundary for the same ruling
+ * carries. No code is minted. `undefined` for any other object.
+ */
+function storedMetadataWriteRefusal(
+    nodeType: keyof typeof STORED_METADATA_WRITE_VERB,
+    objectName: string,
+): (ReturnType<typeof refuseNode> & { code: string }) | undefined {
+    if (!isStoredMetadataBodyObject(objectName)) return undefined;
+    return {
+        ...refuseNode(
+            `${nodeType}: refusing to ${STORED_METADATA_WRITE_VERB[nodeType]} '${objectName}': it holds stored `
+            + 'metadata, and a flow may not write it directly, so the write was not run. Change metadata through the '
+            + 'metadata API (`PUT /api/v1/meta/:type/:name`, the metadata protocol), where it is validated and its '
+            + "provenance is recorded. Elevation (`runAs: 'system'`) does not change this.",
+        ),
+        code: StandardErrorCode.enum.PERMISSION_DENIED,
+    };
+}
+
 /**
  * CRUD built-in nodes — `get_record` / `create_record` / `update_record` /
  * `delete_record`, wired to the runtime data layer (ObjectQL / IDataEngine).
@@ -478,6 +527,10 @@ export function registerCrudNodes(engine: AutomationEngine, ctx: PluginContext):
                 const cfg = parsed.config;
                 const objectName = cfg.objectName;
                 if (!objectName) return refuseNode('create_record: objectName required');
+                // [#21624] A stored-metadata family target is refused before
+                // anything is resolved or written, under either run identity.
+                const familyRefusal = storedMetadataWriteRefusal('create_record', objectName);
+                if (familyRefusal) return familyRefusal;
 
                 // #19938 / #11182 ruling D — a CEL value envelope in `fields.*` is
                 // evaluated; every other value interpolates exactly as before.
@@ -627,6 +680,10 @@ export function registerCrudNodes(engine: AutomationEngine, ctx: PluginContext):
                 const cfg = parsed.config;
                 const objectName = cfg.objectName;
                 if (!objectName) return refuseNode('update_record: objectName required');
+                // [#21624] Before the filter is resolved, so a family target's
+                // filter is never evaluated, under either run identity.
+                const familyRefusal = storedMetadataWriteRefusal('update_record', objectName);
+                if (familyRefusal) return familyRefusal;
 
                 // `filters` → `filter` converted at load (ADR-0087 D2); read canonical.
                 const filterResult = resolveNodeFilter(
@@ -721,6 +778,10 @@ export function registerCrudNodes(engine: AutomationEngine, ctx: PluginContext):
                 const cfg = parsed.config;
                 const objectName = cfg.objectName;
                 if (!objectName) return refuseNode('delete_record: objectName required');
+                // [#21624] Before the filter is resolved, so a family target's
+                // filter is never evaluated, under either run identity.
+                const familyRefusal = storedMetadataWriteRefusal('delete_record', objectName);
+                if (familyRefusal) return familyRefusal;
 
                 // `filters` → `filter` converted at load (ADR-0087 D2); read canonical.
                 // The highest-stakes of the three: an erased condition here is the