nx_vault_capture.nx

nx_vault_capture.nx -- SAVE, as a first-class sovereign verb. (v2: ref-root/phys-root split) OPERATOR 2026-08-06: "saving an image doesn't just go to a download folder -- you have the ability to save the media or the whole site for future consumption if you choose, from the browser to the OS." WHAT THIS DOES: one verb, three scopes, one destination. media <url> the asset alone page <url> the document AS AN ITEM + every image it references site <url> a bounded same-host crawl, every page captured as above Each captured byte becomes a content-addressed vault item (CID = identity, so re-saving is free and duplicates collapse) carrying its provenance at ingest. ONE CHOKEPOINT (vc_ingest_file): the album downloader (mvf_fetch_album_pfx) filed downloads into collections but wrote NO item record, and does not even import the ingest module -- so it structurally COULD NOT. A capture path that does its own recording can forget to record. So there is exactly one way in, and the gate asserts the invariant it holds: EVERY COLLECTION MEMBER RESOLVES TO A RECORD (T6), with a negative control (T7). REF-ROOT vs PHYS-ROOT (v2, the fix for the v1 15/15 live failure). The record's `ref` uses the LOGICAL DSM root /volume1/vault -- a shared folder that needs root/DSM to create and DOES NOT EXIST as a plain dir. All existing records carry that logical root, and nx_vault_gateway SERVES by stripping its 14-char prefix and prepending a writable PHYSICAL root (~/vaultfs). v1 used ONE root for both the ref and the bytes, so every write under the nonexistent /volume1/vault failed (a page + 14 assets = 15/15). v2 keeps the LOGICAL ref in the record (consistent with existing records + the gateway remap) and writes bytes to the PHYSICAL root. Both roots are data-driven (knowledge/status/vault_roots.conf), rule 11/17. ORDERING (nx_mvault_coll): collections are declared BEFORE the bytes land. Composes only proven organs. license_tier: ORIGINAL