# 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.