@@ -15,6 +15,7 @@ A `lookup` or `master_detail` whose `reference` names a table of the stored-meta
 
 - FROM: `meta: { type: 'lookup', reference: 'sys_metadata' }` (or a `master_detail`, or `sys_metadata_history`) saved with a 200 and built with exit 0, and then only ever showed an id. TO: refused, with `422 INVALID_METADATA` at the save door and an error at `os validate` / `os build`. The message names the field, its type and the target, and ends on the family's one prescription.
 - A reference to any other table, platform tables such as `sys_user` included, is unchanged.
+- A `user` field whose authored `reference` names a family table is refused the same way: the parse accepts an authored `reference` on a `user` field, and it is the target every reader resolves.
 - The refusal of a formula or a validation rule that reads through such a field is unchanged, and is still reported at that expression.
 - A stored object row that already declares such a field keeps loading: no authoring rule runs when a stored row is rehydrated, and the engine guards keep refusing every relationship read into the family. Its next active save, or a draft's promotion, through the metadata API is refused until the field is removed or retargeted. The engine guards stay, for every path that runs no authoring rule.
 - `@objectstack/spec` (`patch`): the `reference` describe states the convention, so the generated field reference says it too.
 
@@ -89,6 +89,15 @@ describe('[#24677] a lookup or master_detail into a stored-metadata-body table i
     }
   }
 
+  it('a `user` field whose authored `reference` names the family is refused too — the collector\'s type set, not a second one', () => {
+    // `user`'s target is implied (`sys_user`), but an authored `reference` on it
+    // is not refused at parse and is the target every reader resolves, so the
+    // hop refusal's collector admits it, and this refusal judges the same set.
+    const [issue] = atReference(validateStackExpressions({ objects: [carrier('user', 'sys_metadata')] }));
+    expect(issue?.message).toContain('`meta` is a `user`');
+    expect(atReference(validateStackExpressions({ objects: [carrier('user', 'sys_user')] }))).toEqual([]);
+  });
+
   it('a master_detail refusal says its `parent` root stays unbound; a lookup refusal does not', () => {
     const [md] = atReference(validateStackExpressions({ objects: [carrier('master_detail', 'sys_metadata')] }));
     const [lk] = atReference(validateStackExpressions({ objects: [carrier('lookup', 'sys_metadata')] }));
 
@@ -1735,9 +1735,12 @@ function singleMasterOf(obj: AnyRec): string | undefined {
  * serve a hop, so the lint refuses it where it is written.
  *
  * The literal `.reference` read stays in the argument for the #5017 receiver
- * scan, exactly as in {@link masterDetailCount}. A type whose target is implied
- * (`user`, `tree`) never names the family, so the authored carrier is the only
- * one read.
+ * scan, exactly as in {@link masterDetailCount}. Only the authored carrier is
+ * read: a type whose target is implied never implies the family. A `tree`
+ * field's authored `reference` cannot name it (the object schema refuses any
+ * target but the declaring object); a `user` field's authored `reference` is
+ * not refused at parse, so a `user` naming the family is collected too
+ * (#24677 measured it).
  */
 function storedMetadataBodyReferencesOf(obj: AnyRec): Map<string, string> {
   const out = new Map<string, string>();
@@ -1774,8 +1777,9 @@ function storedMetadataBodyHopMessage(
 
 /**
  * [#24677] The refusal of the declaration every hop above presupposes: a
- * `lookup` or `master_detail` field whose `reference` is a stored-metadata-body
- * table ({@link storedMetadataBodyReferencesOf}). The engine never hydrates
+ * `lookup` or `master_detail` field (or any other type the collector admits)
+ * whose `reference` is a stored-metadata-body table
+ * ({@link storedMetadataBodyReferencesOf}). The engine never hydrates
  * such a field — `expand` keeps its stored id, and a master-detail `parent`
  * root over a family header stays unbound — so the field saves and never
  * works. It names the field, its type, the target and the rule, and ends on
@@ -1792,7 +1796,7 @@ function storedMetadataBodyReferenceMessage(field: string, type: string, target:
       + 'unbound, so every write a `parent` rule judges is refused'
     : 'and a formula or a validation rule never reads through the field';
   return `\`${field}\` is a \`${type}\` whose \`reference\` names '${target}', a table of stored metadata. `
-    + 'A `lookup` or `master_detail` field may not target a stored-metadata-body table: the engine never '
+    + 'A relationship field may not target a stored-metadata-body table: the engine never '
     + `hydrates one, so \`$expand\` keeps the stored id and never nests the row, ${consequence}. `
     + 'Those rows carry stored metadata bodies, served only '
     + 'through the metadata API (`GET /api/v1/meta/:type/:name`), where the body is projected; to point a '