✨ Introduce seed-telegrams tool for generating synthetic telegrams for testing and development. Enhance README with detailed usage instructions, command-line parameters, and examples. Add unit tests for telegram generation and status selection logic to ensure robustness. Update documentation to reflect new features and usage scenarios.

docs/dev-guide.md

@@ -31,6 +31,25 @@ Stop and clean the stack when finished:
 docker compose -f docker-compose.dev.yml down -v
 ```
 
+In development (`GO_ENV=dev` or unset), if you run the application while
+stopping and recreating the NATS/JetStream containers (for example:
+
+```bash
+docker compose -f docker-compose.dev.yml down -v
+docker compose -f docker-compose.dev.yml up -d postgres nats nats-box
+```
+
+), the JetStream state will be reset. The processor behaves as follows:
+
+- The NATS client keeps retrying the connection and automatically reconnects
+  when NATS is back.
+- The JetStream consumer detects missing streams/consumers and, in dev/test
+  environments, uses shared `EnsureStream`/`ensureConsumer` logic to
+  auto-recreate them.
+- In production environments, missing streams/consumers are treated as
+  configuration/operational errors and are not auto-recreated; operators
+  should investigate and fix the underlying issue.
+
 ### Using Taskfile shortcuts
 
 The `Taskfile.yml` includes helper targets that wrap the commands above:

docs/reliability.md

@@ -101,6 +101,27 @@ Recommended pattern:
 - Use a backoff array such as `[5s, 30s, 2m]`.  
 - Treat messages that still fail after `max_deliver` as candidates for DLQ, via the permanent error/poison message path where applicable.
 
+### JetStream Availability and Auto-Recovery (Dev vs Prod)
+
+- When the JetStream API is temporarily unavailable (for example, NATS has just
+  restarted and returns `ErrNoResponders`), the consumer uses an exponential
+  backoff when retrying `Fetch` calls (roughly `1s, 2s, 4s, ...` up to
+  around `30s`) to avoid log spam while allowing the system to recover.
+- In dev/test environments, if the stream or consumer is detected as missing at
+  runtime (for example after `docker compose down -v`), the consumer calls the
+  shared `EnsureStream` and `ensureConsumer` logic to recreate them and
+  re-establish subscriptions.
+- In production environments, missing streams/consumers are treated as
+  configuration or operational errors:
+  - They are **not** auto-recreated.
+  - Errors are logged prominently so operators can diagnose and fix the issue.
+- On the publishing side, JetStream `ErrNoResponders` and similar errors are
+  treated as temporary by the processor:
+  - Such errors cause the consumer to NAK messages and rely on the configured
+    backoff for retries.
+  - Permanent configuration/permission errors remain mapped to permanent
+    failures and follow the DLQ + ACK flow.
+
 ### Alerts and Dashboards
 
 Prometheus alert suggestions: