weatherfeeder/docs/roadmap/future.md

Future Work

Purpose

This document is the catch-all roadmap for planned, deferred, aspirational, experimental, or unimplemented weatherfeeder work. Current behavior belongs in the canonical docs outside docs/roadmap/.

NWS AFD Parsing Resilience

The current parser handles the concrete RAH, LWX, and MFR variants that motivated these ideas. Future work should keep those extension points maintainable as additional evidence appears.

Generalize Wrapper-Scoped Embedded Sections

The scanner currently permits undotted nested headings only inside PREV DISCUSSION. If other wrapper identities are observed, replace the single wrapper check with a small explicit provider-local registry and add a fixture for each wrapper family. Do not make the leading dot globally optional: wrapper scope is the safeguard against classifying uppercase prose as a section.

Extend Conservative Preamble Classification

Leading key-message metadata currently supports validated Issued at, Updated at, and As of <clock> <weekday>... forms. Add future wording variants as small, ordered classifiers with strict label boundaries and value grammars. Every addition should include collision tests proving that similar message prose and malformed metadata remain canonical content.

Keep List-Marker Recognition Extensible

The marker parser currently supports hyphens, asterisks, N), N., (N), and composite forms such as - (N). If new decorators appear, evolve the helper toward an explicit marker grammar or typed classification result rather than a broad punctuation heuristic. Preserve positive-number and whitespace-boundary checks so ordinary prose is not stripped.

Maintain a Cross-Office Fixture Corpus

The compact RAH, LWX, and current MFR fixtures seed regression coverage for the observed layouts. Future parser changes should add concise, deterministic HTML fixtures for materially distinct office formats and exercise them through both the provider parser and normalizer. Fixture comments should identify the format family and state that edited prose is not an archived product; tests must remain offline and assert both intended extraction and adjacent-section isolation.

SPC Convective Outlook Follow-Ups

Weatherapi Outlook Endpoints

Expose persisted SPC convective outlooks through weatherapi after the weatherfeeder storage contract is stable.

Likely endpoints:

• GET /outlooks/convective
• GET /outlooks/convective/active
• GET /outlooks/convective/location

Recommended behavior:

• Return the latest outlook run by default.
• Support active outlook filtering by current time and containsLocation=true.
• Consider optional query filters for day, outlookType, and containsLocation.
• Preserve canonical outlook geometry for downstream display and audit use.

SPC Day 4-8 Outlooks

Add SPC Day 4-8 convective outlook support as a schema-compatible extension only after Day 1-3 operation is proven.

Notes:

• Day 4-8 products have different semantics from Day 1-3 categorical/tornado/hail/wind products.
• Avoid forcing Day 4-8 assumptions into the current Day 1-3 model until the source shapes and consumer needs are reviewed.
• Prefer reusing weather.outlook.v2 if the fields remain accurate; otherwise write a separate roadmap before changing the canonical contract.

Degraded SPC Bundle Mode

Evaluate whether the SPC source should support degraded partial bundles when one required upstream product fails.

Current behavior should remain atomic: if a required GeoJSON or print-page fetch fails, emit no event for that poll.

Future degraded mode would need a clear contract for:

• distinguishing "no risk polygon" from "product missing";
• exposing per-product fetch errors without leaking raw provider internals into canonical events;
• deciding whether downstream sinks and APIs should store or serve partial snapshots.

Richer SPC Page Assets And Tables

Evaluate whether to parse additional SPC print-page metadata beyond the current discussion text.

Possible additions:

• archive GeoJSON/shapefile/KML links;
• image URLs;
• page risk tables;
• city tables;
• richer discussion section metadata.

Keep GeoJSON products authoritative for polygons, validity windows, and point matching unless a future roadmap explicitly changes that contract.