further simplify plan

PEER_AUTH_PLAN.md

@@ -151,11 +151,11 @@ mutation.
 ### 3.2 Make the bundled catalog the content authority
 
 `game.db` is already the application's authority for game identity and
-version. Add a reproducibly generated companion catalog artifact, for example
-`content-manifests-v1.json`, and package it with both the desktop application
-and peer-CLI fixtures.
+version. Add reproducibly generated per-game companion manifest artifacts,
+located at `manifests/<game_id>.json` (loaded on-demand when downloading or serving a game),
+and package them with both the desktop application and peer-CLI fixtures.
 
-For each supported `(game_id, game_version)`, the artifact contains:
+For each supported `(game_id, game_version)`, the manifest artifact contains:
 
 ```text
 CatalogContentManifest {
@@ -177,10 +177,9 @@ Entries are sorted by canonical path. `content_id` is BLAKE3 over a
 versioned, length-delimited encoding of all preceding manifest fields and
 hashes, excluding the `content_id` field itself; it is not the current
 noncryptographic `u64 manifest_hash`. Golden tests freeze that encoding. The
-ordinary chunk size initially matches Lanspread's existing 128 MiB transfer
-chunk so verification does not create a second chunking scheme.
+ordinary chunk size matches Lanspread's 128 MiB transfer chunk.
 
-The catalog publishing workflow must generate these manifests from the
+The catalog publishing workflow must generate these per-game manifests from the
 canonical game packages, verify them by rereading the packages, and fail the
 application build/release if a downloadable catalog entry lacks one. Runtime
 peer consensus and “the only peer said this hash” are not substitutes for this
@@ -191,7 +190,7 @@ games.
 Peers advertise only that they can serve a catalog `content_id`. A peer counts
 as a source for the local catalog game only when its advertised ID exactly
 matches the receiver's expected ID. The receiver builds paths, sizes, chunks,
-and expected hashes entirely from its local catalog. This replaces remote
+and expected hashes entirely from its local catalog manifest. This replaces remote
 manifest selection and majority-by-file-size consensus.
 
 For ordinary downloads:
@@ -204,7 +203,7 @@ For ordinary downloads:
    `(game_id, content_id)` and applies the same canonical/reserved-path policy
    before opening a local file. A caller-supplied path can never expose
    `local/` or another local file.
-4. Hash each chunk while receiving it and compare it before marking that chunk
+4. Hash each chunk with BLAKE3 while receiving it and compare it before marking that chunk
    complete. Exact length, offset coverage, and the catalog file shape are also
    mandatory.
 5. On mismatch, invalidate that write, quarantine that `(PeerId, content_id)`
@@ -214,10 +213,7 @@ For ordinary downloads:
    successfully. Failure leaves the game non-downloadable/non-installable and
    preserves `local/`.
 
-Existing downloaded payloads are verified against the catalog in the
-background before they are newly advertised or installed, with results cached
-against the existing file fingerprint. The user sees ordinary “Verifying game
-files” progress, not a security decision.
+No background disk-scanning or pre-hashing of existing files is required. Chunks are verified strictly as they stream in during an active transfer.
 
 Streamed install needs a catalog-owned extracted-file manifest because the
 sender controls both today's RAR CRC32 metadata and extracted bytes. The
@@ -416,7 +412,7 @@ Trusted, key-changed, backup, repair, or fingerprint-confirmation workflows.
 
 User-facing exceptional states are concrete:
 
-- `Verifying game files` while existing or newly received content is checked;
+- `Verifying downloaded chunks` while newly received content is checked;
 - `A source sent invalid data; retrying another nearby peer` when recovery is
   in progress;
 - `No nearby peer could provide the verified catalog version` after all