docs(vt): owner confirmed — binary .met/.nav readers stay for convert-on-import only

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/plans/2026-09-06-campaign-vt-slice1-files-and-columns.md

@@ -134,4 +134,4 @@ change in combat/buff/loot/nav (slices 2-6).
 - 2026-09-07 Part A final re-check: all twelve round-3 items CLOSED with failable tests, VTClassic confirmed to skip the MossTank expression block by length, byte-identity theories run with zero normalization, plugin has no file access outside embedded resources — MERGE-READY. Three non-blocking findings: #488 (latent newline/length mismatch in the `.utl` expression block), dead `remaining` branches in two sweeps, the meta Delete notice text. **Merged into the campaign branch at `f680bf234`.** Merged-branch gates: build 0/0, MossTank 625/625, Core plugin 50/50, App plugin+markup 238/238; full App suite run separately (known env-gated lanes only).
 
 ## Closeout
-Slice 1 is COMPLETE on `claude/latest-main-sync-497549` (Part B `da0fcb374`, Part A `f680bf234`). Nothing merged to main, nothing pushed. Owner items: (1) the binary `.met`/`.nav` readers survive as one-shot import only (writers deleted) — say if they should go entirely; (2) `bore_quest.af`/`bore_enhanced.af` are hand-edited and excluded from byte identity; (3) a check column shorter than its list draws inert lamps; (4) pointing `ACDREAM_VTANK_PROFILE_DIR` at a real VirindiTank folder writes `.cdf` lines naming `.af` files that real VTank cannot load (AD-122). Next slice per the VT2 order and the owner's "looks like VTank" priority: slice 7 (tabs on the new columns; visual gate), then slice 2 (scheduler).
+Slice 1 is COMPLETE on `claude/latest-main-sync-497549` (Part B `da0fcb374`, Part A `f680bf234`). Nothing merged to main, nothing pushed. Owner items: (1) RESOLVED 2026-09-07 — the binary `.met`/`.nav` readers stay for one-shot import (convert on import, save as `.af`), writers stay deleted; (2) `bore_quest.af`/`bore_enhanced.af` are hand-edited and excluded from byte identity; (3) a check column shorter than its list draws inert lamps; (4) pointing `ACDREAM_VTANK_PROFILE_DIR` at a real VirindiTank folder writes `.cdf` lines naming `.af` files that real VTank cannot load (AD-122). Next slice per the VT2 order and the owner's "looks like VTank" priority: slice 7 (tabs on the new columns; visual gate), then slice 2 (scheduler).

docs/plans/2026-09-06-campaign-vt-vtank-oracle.md

@@ -17,7 +17,7 @@ catalog.
 |---|---|
 | Decompile set | VTank (`utank2-i.dll`), VirindiViewService, VTank Classic Looter (`VTClassic.dll`). UtilityBelt and Mag-Tools are read from their open source, not decompiled. No Decal core. |
 | UI | Our own native retained UI (retail chrome, DAT fonts). VVS is NOT ported. VTank's own view XML is the layout truth (control inventory, grouping, density per tab); pixel-matching the VVS theme is not required. **Sharpened by the owner 2026-09-06: "I don't care if the UI is constructed the same way, just as long as it looks basically the same" — the acceptance bar for every tab is visual resemblance plus the same interactions from the player's seat, never VVS control internals (padding constants, hit-test rules, scrollbar mechanics).** |
-| Files | Drop-in compatibility for `.usd` profiles and `.utl` loot profiles (load unchanged; settings keep VTank's names). **Metas and navs use metaf `.af` (owner, 2026-09-06 amendment):** MossTank reads and writes the human-readable metaf format for both metas and nav routes and does NOT implement binary `.met` or author `.nav`; conversion to/from VTank's binaries is the metaf tool's job. Reference parser: `C:\Users\erikn\source\repos\metas\metaf_monolithic.py` (port of `metaf.cs`, GPLv3 — read, never paste), with 148 real `.af`, 25 `.met`, 130 `.nav` files beside it. Memory: `claude-memory/reference_metaf_af_format.md`. |
+| Files | Drop-in compatibility for `.usd` profiles and `.utl` loot profiles (load unchanged; settings keep VTank's names). **Metas and navs use metaf `.af` (owner, 2026-09-06 amendment):** MossTank reads and writes the human-readable metaf format for both metas and nav routes and does NOT implement binary `.met` or author `.nav`; MossTank keeps the byte-exact binary `.met`/`.nav` READERS for one-shot import only (owner confirmed 2026-09-07: "keep them for consistency and just convert them if the user imports in the plugin") — an imported binary is parsed once, saved as `.af`, and never rewritten; the binary writers are deleted and nothing in the plugin can produce a `.met` or `.nav`. Batch conversion outside the client is the metaf tool's job. Reference parser: `C:\Users\erikn\source\repos\metas\metaf_monolithic.py` (port of `metaf.cs`, GPLv3 — read, never paste), with 148 real `.af`, 25 `.met`, 130 `.nav` files beside it. Memory: `claude-memory/reference_metaf_af_format.md`. |
 | Knowledge base | Full catalog with decompile citations BEFORE implementation. |
 | Platform | Linux is a first-class target: no `System.Drawing`, no GDI+/Windows fonts, no Windows-only paths or registry, no COM. The plugin stays BCL-only per `AcDream.Plugin.Abstractions`. |
 | Interop | **NONE (owner, 2026-09-06): "We should not do any interops. All plugins will have to get rewritten for acdream." VTank relies on Decal hooking/injecting the client; acdream controls the client through its own API.** No VTank export-API surface, no Decal-shaped relay, no compatibility layer for existing Decal plugins (MosswartMassacre, UtilityBelt, Mag-Tools are rewritten as acdream plugins when wanted). KB doc 09's interop sections stay as historical context only. VTank has no real API — what KB 09 calls its "export API" is a reflection relay behind a signed handshake that every real consumer bypassed. If acdream plugins ever need to talk to each other, acdream creates its own plugin API later, on its own terms ("we can of course create one later on"). |