Revise the feature roadmap for consistency with the implementation plan
This commit is contained in:
@@ -2,8 +2,8 @@
|
||||
|
||||
## Purpose
|
||||
|
||||
This roadmap defines the target state and implementation work needed to replace
|
||||
the existing `daily` report with a new generated-text-template `daily` report.
|
||||
This roadmap defines the target state and policy choices for replacing the
|
||||
existing `daily` report with a new generated-text-template `daily` report.
|
||||
|
||||
The new report is not implemented yet. Current report behavior remains
|
||||
documented outside `docs/roadmap/`.
|
||||
@@ -289,126 +289,40 @@ Recommended initial fields should match Tomorrow planning:
|
||||
Private helper functions may be shared with Tomorrow planning when the
|
||||
underlying logic is truly identical.
|
||||
|
||||
## Implementation Plan
|
||||
## Acceptance Criteria
|
||||
|
||||
1. Replace Daily report identity.
|
||||
- Add `report.Daily` with value `daily`.
|
||||
- Remove active `report.DailyToday` and the `daily_today` report definition.
|
||||
- Replace `dailyTodayDefinition` with a generated-text-template
|
||||
`dailyDefinition`.
|
||||
- Ensure `report.DefaultRegistry()` includes `daily` and not `daily_today`.
|
||||
- Ensure `report.IDForCommandName("daily")` returns `report.Daily`.
|
||||
- Ensure `report.IDForConfigKey("daily")` returns `report.Daily`.
|
||||
- Ensure `report.IDForConfigKey("daily_today")` is rejected.
|
||||
- Add a resolver that requires a supplied target date.
|
||||
The feature is complete when:
|
||||
|
||||
2. Update CLI date behavior.
|
||||
- Keep parsing `--date YYYY-MM-DD` for `generate daily`.
|
||||
- Change missing `--date` from default-current-date behavior to an
|
||||
actionable error.
|
||||
- Keep `generate today` as the current-day report with its own date behavior
|
||||
as currently implemented.
|
||||
- Keep `generate tomorrow` date-free.
|
||||
- `weatherreporter generate daily --date YYYY-MM-DD` runs the new Daily report.
|
||||
- `weatherreporter generate daily` without `--date` fails with an actionable
|
||||
error.
|
||||
- `daily` report metadata, RunID content, artifact paths, data-package paths,
|
||||
distributor template variables, generated-text assets, and rendered Markdown
|
||||
all use report ID `daily`.
|
||||
- The active report registry includes `daily` and does not include
|
||||
`daily_today`.
|
||||
- `reports.daily` is the implemented config override key for Daily.
|
||||
- `reports.daily_today` is rejected rather than treated as an alias.
|
||||
- Daily uses generated-text-template generation with prompt ID
|
||||
`weather.daily_generated_text`.
|
||||
- Daily uses dedicated schema, prompt, template, generated-text type,
|
||||
render-context type, and planning-module surfaces.
|
||||
- Daily rendered Markdown initially matches Tomorrow's report format.
|
||||
- Daily data packages include `daily_planning`, not `tomorrow_planning`.
|
||||
- Daily Recent Changes compare against prior Daily snapshots for the same valid
|
||||
local date.
|
||||
- Daily is not included in morning or evening scheduled batches.
|
||||
- Existing Today and Tomorrow report semantics remain unchanged.
|
||||
- Historical `daily_today` workspace artifacts are left untouched.
|
||||
- Non-roadmap documentation is updated after implementation to describe only
|
||||
implemented Daily behavior.
|
||||
|
||||
3. Add Daily planning module.
|
||||
- Add `module.DailyPlanning`.
|
||||
- Add `DailyPlanningOptions`.
|
||||
- Add `DailyPlanningModule` and builder under `internal/briefing`.
|
||||
- Register it only for `report.Daily`.
|
||||
- Add tests for output shape, supported report, unsupported reports, and
|
||||
empty/fallback behavior.
|
||||
## Implementation Plan Reference
|
||||
|
||||
4. Add Daily generated-text validation and assets.
|
||||
- Add `generatedtext.Daily`.
|
||||
- Add `ValidateDaily`.
|
||||
- Add `daily.generated_text.schema.json`.
|
||||
- Add `daily.generated_text.md`.
|
||||
- Add `daily.md.tmpl`.
|
||||
- Register Daily in the generated-text catalog and reporttemplate asset
|
||||
lookup.
|
||||
|
||||
5. Add Daily template context.
|
||||
- Add `DailyRenderContext`, `DailyReportContext`, and
|
||||
`DailyTemplateModules`.
|
||||
- Add `BuildDailyRenderContext`.
|
||||
- Use Daily-specific public types.
|
||||
- Share private snapshot/daypart helper mechanics only where appropriate.
|
||||
|
||||
6. Integrate app workflow.
|
||||
- Ensure `weatherreporter generate daily --date YYYY-MM-DD` runs through the
|
||||
generated-text-template workflow.
|
||||
- Persist raw generated text, structured run result, normalized generated
|
||||
text, render context, Markdown report, metadata, and optional output copy.
|
||||
- Ensure report metadata, RunID, artifact paths, data-package paths,
|
||||
distributor template variables, and rendered report use report ID `daily`.
|
||||
- Ensure Daily Recent Changes uses same-valid-date comparison against prior
|
||||
Daily snapshots.
|
||||
|
||||
7. Update implemented documentation after code changes.
|
||||
- Update `docs/cli.md`, `docs/config.md`, `docs/operations.md`,
|
||||
`docs/templates.md`, `docs/internal/report-registry.md`,
|
||||
`docs/internal/generatedtext.md`, `docs/internal/reporttemplate.md`,
|
||||
`docs/internal/module.md`, `docs/internal/app-orchestration.md`, and
|
||||
maintained examples as needed.
|
||||
- Non-roadmap docs must describe only the implemented Daily behavior after
|
||||
the code changes land.
|
||||
- Remove implemented-doc references that describe `daily_today` as an active
|
||||
report.
|
||||
|
||||
## Test Plan
|
||||
|
||||
Add or update tests for:
|
||||
|
||||
- report registry membership for `daily`
|
||||
- removal of active `daily_today`
|
||||
- `daily` command-name resolution to `daily`
|
||||
- config-key resolution for `reports.daily`
|
||||
- rejection of `reports.daily_today`
|
||||
- valid period for an explicit daily target date in the configured timezone
|
||||
- missing `--date` error for `generate daily`
|
||||
- malformed `--date` error for `generate daily`
|
||||
- generated-text unknown fields, trailing JSON, missing required fields, blank
|
||||
fields, paragraph trimming, and canonical output
|
||||
- generated-text catalog completeness
|
||||
- template/schema asset lookup
|
||||
- render context labels, module extraction, nil optional modules, Daily
|
||||
planning extraction, and daypart ordering
|
||||
- Daily planning module output and supported-report validation
|
||||
- app workflow artifacts for `generate daily --date YYYY-MM-DD`
|
||||
- optional `--out` copy behavior
|
||||
- distributor template values and managed report notification source
|
||||
- config report module overrides for `reports.daily`
|
||||
- no scheduled batch membership for Daily
|
||||
|
||||
Suggested validation:
|
||||
|
||||
```sh
|
||||
go test ./internal/report ./internal/generatedtext ./internal/reporttemplate
|
||||
go test ./internal/briefing ./internal/module
|
||||
go test ./internal/app ./internal/cli ./internal/config
|
||||
go test ./...
|
||||
go run ./cmd/weatherreporter --help
|
||||
git diff --check
|
||||
```
|
||||
|
||||
## Documentation Updates After Implementation
|
||||
|
||||
Update implemented docs only after the code exists:
|
||||
|
||||
- `docs/cli.md`: document `generate daily --date YYYY-MM-DD` as required.
|
||||
- `docs/config.md`: document `reports.daily` module overrides and remove
|
||||
`reports.daily_today` from implemented config docs.
|
||||
- `docs/operations.md`: document Daily artifact paths and manual dated report
|
||||
behavior.
|
||||
- `docs/templates.md`: document Daily template variables.
|
||||
- `docs/internal/report-registry.md`: document Daily report identity and
|
||||
removal of active Daily Today.
|
||||
- `docs/internal/generatedtext.md`: document Daily generated-text schema and
|
||||
validation behavior.
|
||||
- `docs/internal/reporttemplate.md`: document Daily template assets.
|
||||
- `docs/internal/module.md`: document `daily_planning`.
|
||||
- `docs/internal/app-orchestration.md`: document Daily workflow only if it
|
||||
differs from the generic generated-text-template flow.
|
||||
Use `docs/roadmap/implementation.md` for the staged implementation plan. This
|
||||
feature roadmap intentionally does not define implementation stages, file-by-file
|
||||
work packages, or validation commands so that implementing agents have a single
|
||||
sequencing authority.
|
||||
|
||||
## Ambiguities Addressed
|
||||
|
||||
|
||||
Reference in New Issue
Block a user