@@ -0,0 +1,11 @@
+---
+'@object-ui/plugin-detail': patch
+---
+
+A record activity feed shows an object's `activityMilestones` rows of type `completed`, such as "Case resolved", instead of hiding them as completed tasks (objectui#12106).
+
+A milestone keeps the `type` its declaration names, so "Case resolved" declared with `type: 'completed'` arrived as a `completed` row. The feed mapped every `completed` row to a `task` item, and `showCompleted` is off by default, so the milestone was hidden on every record page that did not set it, including the default page.
+
+plugin-audit now stamps `metadata.kind: 'milestone'` on a row a milestone fired (objectstack#22771). The feed reads that marker. A `completed` row that carries it renders as a `system` item, the presentation every other author-typed milestone already gets, and shows whatever `showCompleted` says. A task's own "Task completed" milestone shows on that task's page for the same reason.
+
+A `completed` row without the marker is unchanged: it is a `task` item, hidden unless `showCompleted` is on. That covers rows from a runtime that does not stamp the marker yet, and rows an app inserts itself. `filterMode: 'tasks_only'` and `types: ['task']` still select tasks only, so they do not list a milestone. The `record:activity` block's own read and the console record page's feed both read rows through `activityRowToFeedItem`, so both change together. No export, prop or type changes.
@@ -0,0 +1,7 @@
+---
+'@object-ui/types': patch
+---
+
+A record-source refusal (`RECORD_SOURCE_REQUIRED`, raised by every arm that requires a record source) now reports the same path every time (objectui#5250).
+
+The refusal's `path` was one array, built when the arm was defined and handed to every issue. zod copies an added issue shallowly and prefixes its `path` in place as the issue climbs out of an array slot or an object key, so the first refusal reported from inside a container rewrote the path of every later refusal of that arm for as long as the module stayed loaded. A process that judges many documents saw the drift: `objectui check` over a project, or `objectui validate` called repeatedly in one process, could report a root refusal at a path like `0 → 0 → 0 → 0`. Each issue now carries its own copy. The refusal, its message and its code are unchanged.
@@ -185,3 +185,15 @@ jobs:
       # narrowing what the gate scans.
       - name: Compile JSDoc `@example` blocks against the built types
         run: node scripts/check-doc-example-types.mjs
+
+      # objectui#5250 (the maintainer ruling's JSON-fence slice). Every `json` /
+      # `jsonc` node document in `content/docs` is judged through the STRICT
+      # authoring face — `StrictAnyComponentSchema`, read from the
+      # `@object-ui/types` the build step above produced (the snippet gate's
+      # closure carries it) — the face `objectui validate` judges with. A fence
+      # that is deliberately not a complete node document is declared on the
+      # line above it, and the declaration is re-judged on every run. Last of
+      # the three, for the reason the step above gives: a newly wired blocking
+      # gate must not mask an established one.
+      - name: Judge JSON doc fences through the strict authoring face
+        run: node scripts/check-doc-json-fences.mjs
@@ -710,7 +710,7 @@ A single-record detail view with grouped fields, actions, and tabs.
       "title": "Customer Info",
       "fields": [
         { "name": "customer", "label": "Customer", "type": "text" },
-        { "name": "email", "label": "Email", "type": "email" },
+        { "name": "email", "label": "Email", "type": "text" },
         { "name": "created", "label": "Created", "type": "date", "format": "MMM d, yyyy" }
       ]
     },
 
@@ -54,13 +54,17 @@ behaviour. Common customisations:
 
 ### Wire Up Submission
 
+A control that runs something is its own node type, `action:button`, and its
+props go in the `properties` bag; `actionType: "api"` sends the request to
+`target`:
+
 ```json
 {
-  "type": "button",
-  "label": "Sign In",
-  "action": {
-    "type": "submit",
-    "endpoint": "/api/auth/login",
+  "type": "action:button",
+  "properties": {
+    "label": "Sign In",
+    "actionType": "api",
+    "target": "/api/auth/login",
     "method": "POST"
   }
 }
 
@@ -33,13 +33,16 @@ Customize dashboard blocks for your needs:
 
 ### Add Real Data
 
+A `card` fetches nothing. A live figure comes from a data-bound block: an
+`element:number` takes its object from the per-element `dataSource` binding and
+its aggregate from its `properties` bag (see the
+[Data Source guide](/docs/guide/data-source)):
+
 ```json
 {
-  "type": "card",
-  "dataSource": {
-    "api": "/api/stats/revenue",
-    "method": "GET"
-  }
+  "type": "element:number",
+  "dataSource": { "object": "order" },
+  "properties": { "aggregate": "count" }
 }
 ```
 
@@ -55,13 +58,16 @@ Customize dashboard blocks for your needs:
 
 ### Add Actions
 
+A control that runs something is its own node type, `action:button`, and its
+props go in the `properties` bag; `actionType: "url"` navigates to `target`:
+
 ```json
 {
-  "type": "button",
-  "label": "View Details",
-  "action": {
-    "type": "navigate",
-    "path": "/dashboard/details"
+  "type": "action:button",
+  "properties": {
+    "label": "View Details",
+    "actionType": "url",
+    "target": "/dashboard/details"
   }
 }
 ```
 
@@ -39,25 +39,30 @@ Customize e-commerce blocks for your store:
 
 ### Add Product Data
 
+A `card` fetches nothing. Records come from a data-bound block that names its
+object in the per-element `dataSource` binding (see the
+[Data Source guide](/docs/guide/data-source)):
+
 ```json
 {
-  "type": "card",
-  "dataSource": {
-    "api": "/api/products",
-    "method": "GET"
-  }
+  "type": "object-grid",
+  "dataSource": { "object": "product", "limit": 20 }
 }
 ```
 
 ### Add to Cart Action
 
+A control that runs something is its own node type, `action:button`, and its
+props go in the `properties` bag; `actionType: "api"` sends the request to
+`target`:
+
 ```json
 {
-  "type": "button",
-  "label": "Add to Cart",
-  "action": {
-    "type": "submit",
-    "endpoint": "/api/cart",
+  "type": "action:button",
+  "properties": {
+    "label": "Add to Cart",
+    "actionType": "api",
+    "target": "/api/cart",
     "method": "POST"
   }
 }
 
@@ -93,13 +93,17 @@ or in a TypeScript-authored schema pass the real thing —
 
 ### Add Submit Action
 
+A control that runs something is its own node type, `action:button`, and its
+props go in the `properties` bag; `actionType: "api"` sends the request to
+`target`:
+
 ```json
 {
-  "type": "button",
-  "label": "Submit",
-  "action": {
-    "type": "submit",
-    "endpoint": "/api/contact",
+  "type": "action:button",
+  "properties": {
+    "label": "Submit",
+    "actionType": "api",
+    "target": "/api/contact",
     "method": "POST"
   }
 }
 
@@ -46,19 +46,6 @@ Customize marketing blocks for your campaigns:
 }
 ```
 
-### Add Analytics
-
-```json
-{
-  "type": "button",
-  "label": "Get Started",
-  "action": {
-    "type": "analytics",
-    "event": "cta_clicked"
-  }
-}
-```
-
 ### Customize Content
 
 ```json
 
@@ -34,6 +34,7 @@ The glyph is named by `icon`:
 `name` is the SDUI identity key every node carries, alongside `id`. It is **not**
 read as a glyph name on `ui:icon`, and writing one there renders no icon:
 
+{/* doc-json: fragment — a deliberately refused node: it shows the retired name-as-glyph shape the paragraph below describes */}
 ```json
 { "type": "icon", "id": "save_icon", "name": "save_icon" }
 ```
Original file line number	Diff line number	Diff line change
`@@ -710,7 +710,7 @@ A single-record detail view with grouped fields, actions, and tabs.`
`710`	`710`	`"title": "Customer Info",`
`711`	`711`	`"fields": [`
`712`	`712`	`{ "name": "customer", "label": "Customer", "type": "text" },`
`713`		`- { "name": "email", "label": "Email", "type": "email" },`
	`713`	`+ { "name": "email", "label": "Email", "type": "text" },`
`714`	`714`	`{ "name": "created", "label": "Created", "type": "date", "format": "MMM d, yyyy" }`
`715`	`715`	`]`
`716`	`716`	`},`