Record reference provenance in manifests

docs/integrations/json-output.md

@@ -98,6 +98,30 @@ approved.
 
 Fields with empty values may be omitted by JSON encoding.
 
+`source_digests` contains source document digests only. Bound references are
+recorded separately under `references`, which contains provenance only:
+lane ID, slot name, origin type and URI, digest, media type, byte size, and
+binding source. Reference content is not written to durable output.
+
+When references are bound, the manifest section has this shape:
+
+```json
+{
+  "references": [
+    {
+      "lane_id": "events",
+      "slot_name": "roster",
+      "origin_type": "file",
+      "origin_uri": "file:///absolute/path/roster.txt",
+      "digest": "sha256:...",
+      "media_type": "text/plain; charset=utf-8",
+      "size_bytes": 123,
+      "binding_source": "config"
+    }
+  ]
+}
+```
+
 `module_metadata` is omitted when no singleton module provides metadata.
 
 `validation_status` is `approved` when no candidates were rejected and

docs/internal/diagnostics.md

@@ -33,6 +33,7 @@ Implemented artifact names:
 - `invocation.json`
 - `effective-config.json`
 - `resolved-pipeline.json`
+- `resolved-references.json`
 - `source-document.json`
 - `run-manifest.json`
 - `run-report.json`

docs/internal/pipeline.md

@@ -42,7 +42,9 @@ During run preparation, resolved file references are materialized before any
 LLM-backed pipeline work. Config bindings resolve relative to the config file,
 CLI bindings resolve relative to the current working directory, and materialized
 reference content is passed to extractors through `ExtractionRequest`.
-Reference content is omitted from diagnostics and manifests.
+Reference content is omitted from diagnostics and manifests. The CLI writes
+provenance-only resolved reference diagnostics, and the run manifest records
+lane-scoped reference provenance separately from source digests.
 
 Prompt bundles can declare reference slots and use `reference` and
 `hasreference` template functions. Bundle loading validates string-literal slot
@@ -176,7 +178,7 @@ On successful execution, the manifest validation status is:
 
 The manifest records run ID, pipeline ID, pipeline digest, module keys, top-level
 module metadata, artifact lanes, LLM profile metadata, source digest,
-validation status, and timing.
+reference provenance, validation status, and timing.
 
 Singleton pipeline modules may add non-secret metadata by implementing
 `contracts.ManifestMetadataProvider`. The runner records that metadata under

docs/operations.md

@@ -62,6 +62,9 @@ Implemented diagnostics artifacts:
   path, selected lanes, run ID, and pipeline digest when available.
 - `effective-config.json`: resolved config with API keys redacted.
 - `resolved-pipeline.json`: resolved module bindings and pipeline digest.
+- `resolved-references.json`: lane-scoped resolved reference provenance,
+  including origin, digest, media type, byte size, and binding source, without
+  reference content.
 - `run-manifest.json`: the same run manifest written to durable output when it
   is available, including top-level module metadata when present.
 - `warnings.json`: warning list.