chore: update network logs skill

.claude/agents/network-logs.md

@@ -91,7 +91,8 @@ Pods follow the pattern `{namespace}-{component}-{index}`:
 
 ## Deployment-Specific Notes
 
-- **next-net** redeploys every morning at ~4am UTC. Always use timestamp range filters (not `--freshness`) when querying next-net for a specific date, and expect logs to only cover a single instance of the network.
+- **next-net** redeploys every morning at ~4am UTC. Always use timestamp range filters (not `--freshness`) when querying next-net for a specific date, and expect logs to only cover a single instance of the network. Because next-net resets daily, its block height should start near 0 after ~4am UTC. If you are running a morning healthcheck and the block height is unexpectedly large (e.g., hundreds or thousands), flag this as an error — it likely means the nightly redeploy failed and the network is running a stale instance.
+- **mainnet** does not run sequencer validators. Instead, it runs infrastructure in **fisherman mode**: nodes simulate building a block for every slot but never actually submit the L1 transaction. This means you will see "built block" or similar messages but no "Published checkpoint" or L1 submission logs. Errors with hash `0xf3e591ac` are a known artifact of fisherman mode and are safe to ignore.
 
 ## Filter Building
 
@@ -203,6 +204,7 @@ gcloud logging read '
   NOT jsonPayload.message=~"No active peers"
   NOT jsonPayload.message=~"Not enough txs"
   NOT jsonPayload.message=~"StateView contract not found"
+  NOT jsonPayload.message=~"[Bb]lob"
 ' --limit=100 --format='table[no-heading](timestamp.date("%H:%M:%S"), resource.labels.pod_name, jsonPayload.severity, jsonPayload.module, jsonPayload.message.slice(0,180))' --freshness=<freshness> --project=<project>
 ```
 
@@ -291,6 +293,20 @@ Then synthesize into a single status report covering:
 
 This is the most common query pattern — prefer this composite approach over individual queries when the user asks for general status.
 
+### 11. Multi-Network Healthcheck
+
+When the user asks for a healthcheck across multiple networks (e.g., "how are all the networks doing?"), query each network in parallel and present results as a **summary table**:
+
+```
+| Network   | Status | Block Height | Last Block | Proving | Notes |
+|-----------|--------|--------------|------------|---------|-------|
+| testnet   | ✅ OK  | 1234         | 2m ago     | Epoch 5 | —     |
+| next-net  | ✅ OK  | 45           | 1m ago     | Epoch 1 | —     |
+| mainnet   | ✅ OK  | 890          | 3m ago     | N/A     | Fisherman mode |
+```
+
+Use ✅ for healthy, ⚠️ for degraded, ❌ for down/erroring. Follow the table with brief per-network details only if there are issues worth calling out. Remember deployment-specific notes: next-net resets daily (check block height is reasonable for time of day), mainnet runs in fisherman mode (no L1 submissions, `0xf3e591ac` errors are expected).
+
 ## Known Noise Patterns
 
 These patterns appear frequently and are usually harmless — exclude or downplay them:
@@ -302,6 +318,8 @@ These patterns appear frequently and are usually harmless — exclude or downpla
 - `No active peers to send requests to` — P2P reqresp on isolated nodes (e.g., blob-sink)
 - `Not enough txs to build block` — Normal when transaction volume is low
 - `StateView contract not found` — Price oracle warning; Uniswap V4 StateView only exists on mainnet, so all other networks emit this. Safe to ignore unless namespace is `mainnet`
+- **Blob-related errors** — Errors related to blobs (e.g., blob fetching failures, blob unavailability) are generally expected and safe to ignore. Since the Fusaka hard fork, regular consensus nodes can no longer serve blob data, and we run a couple of these nodes. Exclude or downplay blob errors unless the user is specifically investigating blob issues.
+- `0xf3e591ac` — Fisherman mode error on mainnet. Safe to ignore (see Deployment-Specific Notes).
 
 ## Reference Tool