Remove obsolete briefing snapshot artifacts

docs/operations.md

@@ -52,22 +52,18 @@ workspace/
   snapshots/
     daily/
       YYYY-MM-DD/
-        <run_id>.briefing.json
         <run_id>.modules.json
         <run_id>.metadata.json
     three-day/
       YYYY-MM-DD/
-        <run_id>.briefing.json
         <run_id>.modules.json
         <run_id>.metadata.json
     weekend/
       YYYY-MM-DD/
-        <run_id>.briefing.json
         <run_id>.modules.json
         <run_id>.metadata.json
     storm/
       YYYY-MM-DD/
-        <run_id>.briefing.json
         <run_id>.modules.json
         <run_id>.metadata.json
   data-packages/
@@ -136,7 +132,7 @@ Each generated report writes metadata that links:
 - RunID, report ID, variant, and prompt ID
 - generation time, timezone, and valid period
 - source location, source hashes, and source warnings
-- briefing snapshot path
+- module snapshot path
 - prompt input data package path
 - preflight output path
 - managed Markdown report path
@@ -169,9 +165,9 @@ report generation has a distinct retry identity. The default bundle path uses
 the valid-period start date, artifact group, and RunID. Distributor owns
 destination merge, retention, and derived snapshot behavior such as `latest`.
 
-Notification happens after final metadata save. Weather API, briefing, module
-snapshot, data-package, render preflight, Scriptorium run, and metadata-save
-failures do not trigger notification. A notification failure fails that report.
+Notification happens after final metadata save. Weather API, module snapshot,
+data-package, render preflight, Scriptorium run, and metadata-save failures do
+not trigger notification. A notification failure fails that report.
 In a batch, other reports continue, the failed report includes notification
 fields in the JSON summary, and the batch returns nonzero.