@@ -0,0 +1,18 @@
+---
+'@objectstack/objectql': minor
+'@objectstack/service-storage': minor
+---
+
+A reader refused `sys_file` read now sees the name, size and type of a file the record they are reading owns, whenever the download door would serve them its bytes
+
+Clause-②: yes
+
+The download door already judges a field-owned file by the record that owns it (ADR-0104 D3): a declared `fileAccessDelegate` decides where the owner object names one, otherwise the caller's read of that record. Record file-field hydration judged the same file by `sys_file` object read instead, which the default member grants do not include. So one reader could download a contract's signed PDF but saw the field as `{ id, metadataRefused: true }`: the bytes yes, the name no.
+
+- **From.** A reader with read on `contract` and no `sys_file` read gets `{ "signed_pdf": { "id": "f_7cQx2Lm90a", "metadataRefused": true } }` for every file id the record holds.
+- **To.** For a file whose `ref_object` / `ref_id` name the record being read, that reader gets the hydrated `{ "id": "f_7cQx2Lm90a", "name": "signed.pdf", "size": 2048, "mimeType": "application/pdf", "url": "/api/v1/storage/files/f_7cQx2Lm90a" }`, exactly as a `sys_file` reader does, when the door's field-owned verdict allows it. A delegate-governed object (for example `sys_approval_action`, delegate `approvals`) gets its delegate's answer, not the raw record read.
+- **Unchanged.** Every other id keeps `{ id, metadataRefused: true }`: an id copied in from another record, an attachment-only or unclaimed file, a `public_read` file the record does not own, and an owned file the delegate or the record read refuses. `sys_file`'s own read rule is unchanged, so a direct `sys_file` query by the same reader is still refused. A reader with `sys_file` read is served by their own read, as before. The download door's verdict for every request is unchanged.
+
+**One verdict, two callers.** `@objectstack/service-storage` moves the download door's field-owned arm into one module-private function (not exported) and hands it to the engine through a new seam, `ObjectQL.registerFieldOwnedFileReadAuthorizer` (type `FieldOwnedFileReadAuthorizer`, exported from `@objectstack/objectql`), the same handover `registerHeldFileResolver` already makes. The engine never re-derives it. An engine with nothing registered keeps the refused marker for every id. On a refused hydration the engine makes one more `sys_file` read under the caller's tenant (it reads only ids whose ownership pair names a record in the result) and asks the verdict once per read.
+
+**For consumers.** Nothing to change. A refused reader may now receive the full file object where it used to receive the marker, and code that already handles all three `expanded` read forms handles this.
@@ -167,7 +167,10 @@ can be shared across records). Reclamation is handled by the platform LifecycleS
   sweep tidies it, and a file with no holder left still answers
   `FILE_NOT_FOUND` (404) and keeps its bare id in a record payload — except to
   a reader refused `sys_file` read, who gets `{ id, metadataRefused: true }` for
-  every file id, held or not ([`file` read forms](/docs/protocol/objectql/types#file)).
+  every file id the record being read does not own, or that the download door's
+  field-owned verdict refuses them, held or not; a file the record owns and the
+  door would serve them reads exactly as it does for a `sys_file` reader
+  ([`file` read forms](/docs/protocol/objectql/types#file)).
 - **`sys_upload_session`** — abandoned/terminal chunked-upload sessions are
   reaped, and a reap guard aborts the underlying backend multipart upload
   (S3 `AbortMultipartUpload` / local parts dir) first, so already-uploaded
 
@@ -1163,7 +1163,11 @@ with `multiple: true`) into one of **three** forms, and none of them fails the
 record read that asked for it.
 
 **The file object** — the caller's `sys_file` read found the file (a committed
-row, or a tombstone something still holds). `url` is its only required member,
+row, or a tombstone something still holds). A caller refused that read gets it
+too for a file the record being read owns (its `ref_object` / `ref_id` name that
+record) whenever the download door would serve them its bytes: the same
+field-owned verdict — the object's declared `fileAccessDelegate`, or else the
+caller's read of that record — decides both. `url` is its only required member,
 derived from the id rather than stored:
 
 ```json
@@ -1185,9 +1189,14 @@ provisioned yet, or the read failed for any reason other than a refusal (an
 outage, which the engine logs as a warning).
 
 **`{ "id": "abc123", "metadataRefused": true }`** — the caller may read the record
-but is refused the `sys_file` read. The value is the id the record holds plus the
-marker, nothing else: no `url`, `name`, `size` or `mimeType`, because none was
-read, and it says nothing about whether the file exists. It is distinct from an
+but is refused the `sys_file` read, and the file is not one the record being read
+owns that the download door's verdict lets them read: an id copied in from
+another record, an attachment-only or unclaimed file (`acl: 'public_read'`
+included), an owned file whose delegate or record read refuses them, or an owned
+file whose verdict could not be asked (an outage, which the engine logs as a
+warning). The value is the id the record holds plus the
+marker, nothing else: no `url`, `name`, `size` or `mimeType`, because none is
+served to this caller, and it says nothing about whether the file exists. It is distinct from an
 empty field, which holds no file at all, and from the file object, which always
 carries `url`.
 [`FileRefusedValueSchema`](/docs/references/data/field-value#filerefusedvalue)