Add operational troubleshooting documentation
This commit is contained in:
@@ -1,8 +1,12 @@
|
||||
# Weatherreporter Operations
|
||||
|
||||
This guide covers normal operation, generated artifacts, inspection, recovery,
|
||||
and current operational caveats. For symptom-specific diagnosis, see
|
||||
[Troubleshooting](troubleshooting.md).
|
||||
|
||||
## Normal Workflow
|
||||
|
||||
The implemented generation workflows are:
|
||||
Implemented generation commands:
|
||||
|
||||
```text
|
||||
weatherreporter generate daily --date 2026-05-29
|
||||
@@ -10,22 +14,27 @@ weatherreporter generate tomorrow
|
||||
weatherreporter generate three-day
|
||||
weatherreporter generate weekend
|
||||
weatherreporter generate storm --start 2026-05-29T18:00 --end 2026-05-30T06:00
|
||||
```
|
||||
|
||||
Each command resolves a report period, fetches a Weather API bundle, builds a
|
||||
briefing, builds a prompt input data package, runs `scriptorium render`, runs
|
||||
`scriptorium run`, and writes managed artifacts under the configured workspace.
|
||||
`--out PATH` writes an extra Markdown copy for the current generated report.
|
||||
|
||||
Implemented batch commands:
|
||||
|
||||
```text
|
||||
weatherreporter run morning
|
||||
weatherreporter run evening
|
||||
```
|
||||
|
||||
These commands fetch weather data, build a briefing for the resolved valid
|
||||
period, build the prompt input data package, run `scriptorium render`, run
|
||||
`scriptorium run`, and write inspectable artifacts under the configured
|
||||
workspace. The evening run resolves only the Tomorrow Planning Brief. The
|
||||
morning run generates Daily Today and the 3-Day Outlook, plus Weekend Outlook
|
||||
except on Sunday. Storm Report generation is manual and uses the explicit
|
||||
`--start` and `--end` bounds as its valid period.
|
||||
|
||||
Scheduled run commands print a JSON aggregate summary to stdout and compact
|
||||
per-report status lines to stderr. If one report fails, remaining independent
|
||||
reports are still attempted. The command returns nonzero after the run when any
|
||||
report failed.
|
||||
`run morning` generates Daily Today and the 3-Day Outlook, plus Weekend Outlook
|
||||
except on Sunday. `run evening` generates the Tomorrow Planning Brief. Batch
|
||||
commands print a JSON summary to stdout, write compact per-report status lines
|
||||
to stderr, continue independent reports after one report fails, and return
|
||||
nonzero when any report failed. `--out-dir PATH` writes extra Markdown copies
|
||||
using report default filenames such as `daily.md`, `three-day.md`,
|
||||
`weekend.md`, and `tomorrow.md`.
|
||||
|
||||
## Filesystem Layout
|
||||
|
||||
@@ -87,51 +96,37 @@ workspace/
|
||||
<run_id>.md
|
||||
```
|
||||
|
||||
The Markdown report is written to a RunID-managed report path. When `--out` is
|
||||
provided to `generate daily`, `generate tomorrow`, `generate three-day`,
|
||||
`generate weekend`, or `generate storm`, the managed report is also copied to
|
||||
that path.
|
||||
Managed artifact filenames use the RunID, so repeated runs for the same valid
|
||||
period do not overwrite each other.
|
||||
|
||||
For `run morning` and `run evening`, `--out-dir PATH` writes extra Markdown
|
||||
copies using each report definition's default filename, such as `daily.md`,
|
||||
`three-day.md`, `weekend.md`, or `tomorrow.md`.
|
||||
## RunID And Metadata
|
||||
|
||||
## Run Identifiers
|
||||
|
||||
Run IDs are based on generation time plus report ID, such as:
|
||||
RunIDs are based on generation time plus report ID:
|
||||
|
||||
```text
|
||||
20260529T100000.123456789Z_daily_today
|
||||
```
|
||||
|
||||
Managed artifact filenames use the RunID so repeated runs for the same valid
|
||||
date do not overwrite each other.
|
||||
|
||||
## Metadata
|
||||
|
||||
Each generated report writes metadata that links:
|
||||
|
||||
- RunID
|
||||
- report ID and prompt ID
|
||||
- generation time and valid period
|
||||
- RunID, report ID, variant, and prompt ID
|
||||
- generation time, timezone, and valid period
|
||||
- source location, source hashes, and source warnings
|
||||
- briefing snapshot path
|
||||
- prompt input data package path
|
||||
- preflight output path
|
||||
- rendered report path
|
||||
- managed Markdown report path
|
||||
|
||||
Run summaries include each report ID, prompt ID, RunID, status, error text when
|
||||
applicable, valid period, and artifact paths known to the application.
|
||||
Batch summaries include report status, error text when applicable, valid
|
||||
period, and known artifact paths for each attempted report.
|
||||
|
||||
## Inspection
|
||||
|
||||
Use `weatherreporter inspect reports` to list recent generated runs from the
|
||||
configured workspace. The output includes RunID, report ID, valid period,
|
||||
metadata path, briefing path, report path, and source warning count.
|
||||
|
||||
Run-specific inspection commands emit JSON for a single RunID:
|
||||
Inspection commands read existing workspace artifacts and emit JSON to stdout.
|
||||
They do not fetch weather data or run `scriptorium`.
|
||||
|
||||
```text
|
||||
weatherreporter inspect reports --limit 10
|
||||
weatherreporter inspect metadata RUN_ID
|
||||
weatherreporter inspect briefing RUN_ID
|
||||
weatherreporter inspect data-package RUN_ID
|
||||
@@ -139,44 +134,54 @@ weatherreporter inspect prior RUN_ID
|
||||
weatherreporter inspect sources RUN_ID
|
||||
```
|
||||
|
||||
`inspect prior` shows the prior comparable snapshot selected from stored
|
||||
metadata, or `null` when none exists. `inspect sources` shows source provenance
|
||||
and source warnings without dumping full weather payloads.
|
||||
Use `inspect reports` to find recent RunIDs and artifact paths. Use
|
||||
`inspect metadata` to see the artifact links recorded for a run. Use
|
||||
`inspect briefing` and `inspect data-package` to review the exact structured
|
||||
inputs used for rendering. Use `inspect prior` to see the prior comparable
|
||||
snapshot selected for Recent Changes, or `null` when none exists. Use
|
||||
`inspect sources` to review source provenance and warnings without dumping full
|
||||
weather payloads.
|
||||
|
||||
## Recent Changes
|
||||
|
||||
When a prior comparable Daily briefing snapshot exists for the same valid local
|
||||
date, the app compares structured briefing data before writing the prompt input
|
||||
data package. Daily Today and Daily Tomorrow can compare with each other when
|
||||
they cover the same valid local date. Meaningful changes are included under
|
||||
`recentChanges.items`.
|
||||
Recent Changes are computed from structured briefing snapshots, not rendered
|
||||
Markdown text.
|
||||
|
||||
3-Day Outlook generation compares against a prior compatible 3-Day briefing
|
||||
snapshot for the same valid local date when one exists.
|
||||
|
||||
Weekend Outlook generation compares against a prior compatible Weekend briefing
|
||||
snapshot for the same weekend window when one exists. Friday evening and
|
||||
Saturday runs may narrow the valid start while keeping the same Monday endpoint.
|
||||
|
||||
Storm Report generation currently leaves Recent Changes empty. Its explicit
|
||||
event window is still recorded in briefing and metadata artifacts.
|
||||
Daily Today and Daily Tomorrow can compare with each other when they cover the
|
||||
same valid local date. 3-Day Outlook compares with prior compatible 3-Day
|
||||
snapshots for the same valid local date. Weekend Outlook compares with prior
|
||||
compatible Weekend snapshots for the same weekend window. Storm Report currently
|
||||
leaves Recent Changes empty.
|
||||
|
||||
When no prior comparable snapshot exists, or no configured threshold is crossed,
|
||||
the Recent Changes list is empty.
|
||||
`recentChanges.items` is empty.
|
||||
|
||||
## Recovery
|
||||
|
||||
If render preflight exits nonzero after producing a result, the captured stdout,
|
||||
stderr, exit code, and command are still written to the preflight artifact, and
|
||||
metadata is still written for inspection.
|
||||
A failed generation run may still leave useful artifacts:
|
||||
|
||||
If `scriptorium run` exits nonzero after writing a report, the generated report
|
||||
and metadata remain available for inspection. Exit code `2` is still returned as
|
||||
an error because it indicates validation failed, even if report output exists.
|
||||
- If `scriptorium render` returns a result with a nonzero exit code, the
|
||||
preflight JSON and metadata are written for inspection.
|
||||
- If `scriptorium run` exits nonzero after writing a report, the managed report
|
||||
and metadata remain available.
|
||||
- For batch commands, inspect the stdout JSON summary first, then inspect the
|
||||
artifact paths for each failed report.
|
||||
|
||||
For scheduled runs, inspect stdout first for the aggregate JSON summary, then
|
||||
use the per-report artifact paths in that summary to inspect briefing,
|
||||
data-package, preflight, metadata, and rendered report files.
|
||||
For a bad report, start with:
|
||||
|
||||
The application does not currently implement resume, cleanup, archive, or
|
||||
remote storage behavior.
|
||||
```text
|
||||
weatherreporter inspect metadata RUN_ID
|
||||
weatherreporter inspect sources RUN_ID
|
||||
weatherreporter inspect briefing RUN_ID
|
||||
weatherreporter inspect data-package RUN_ID
|
||||
weatherreporter inspect prior RUN_ID
|
||||
```
|
||||
|
||||
## Operational Caveats
|
||||
|
||||
- The application uses one configured Weather API endpoint.
|
||||
- The application writes local filesystem state only.
|
||||
- The application does not implement resume, cleanup, archive, remote storage,
|
||||
daemon operation, or automatic storm monitoring.
|
||||
- Generated reports and Scriptorium stderr can contain sensitive operational
|
||||
context. Store workspace artifacts with appropriate filesystem permissions.
|
||||
|
||||
Reference in New Issue
Block a user