chore: sync GovOPlaN module split state
This commit is contained in:
12
README.md
Normal file
12
README.md
Normal file
@@ -0,0 +1,12 @@
|
|||||||
|
# GovOPlaN Reporting
|
||||||
|
|
||||||
|
`govoplan-reporting` owns report definitions, BI-style views, dashboards,
|
||||||
|
scheduled outputs, and report publication/export behavior. It is intentionally
|
||||||
|
separate from reusable template rendering and from generic dataflow pipelines.
|
||||||
|
|
||||||
|
This repository is currently a tag-only scaffold. It should gain package
|
||||||
|
metadata and module manifests only after the first backend or WebUI slice is
|
||||||
|
designed.
|
||||||
|
|
||||||
|
See [docs/REPORTING_BOUNDARY.md](docs/REPORTING_BOUNDARY.md) for the boundary
|
||||||
|
decision.
|
||||||
76
docs/REPORTING_BOUNDARY.md
Normal file
76
docs/REPORTING_BOUNDARY.md
Normal file
@@ -0,0 +1,76 @@
|
|||||||
|
# Reporting Module Boundary
|
||||||
|
|
||||||
|
`govoplan-reporting` owns report definitions, execution, dashboards, BI views,
|
||||||
|
scheduled outputs, and report exports. It may use templates for formatted
|
||||||
|
outputs, but it owns the report data and publication semantics.
|
||||||
|
|
||||||
|
The core boundary decision register is in
|
||||||
|
`/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md`.
|
||||||
|
|
||||||
|
## Ownership
|
||||||
|
|
||||||
|
Reporting owns:
|
||||||
|
|
||||||
|
- report definitions, parameters, saved views, and dashboard cards
|
||||||
|
- curated query/view inputs from modules, connectors, datasources, or
|
||||||
|
configuration packages
|
||||||
|
- report execution history, generated output evidence, and scheduled runs
|
||||||
|
- report permissions and sharing rules
|
||||||
|
- export targets such as file, DMS, mail, API, RSS/Atom publication, and
|
||||||
|
downstream connector handoff
|
||||||
|
- BI-style summaries where GovOPlaN owns the underlying process evidence
|
||||||
|
|
||||||
|
## Source Inputs
|
||||||
|
|
||||||
|
Initial source categories:
|
||||||
|
|
||||||
|
- module-owned read models and summary DTOs
|
||||||
|
- curated SQL/query views exposed through a controlled capability
|
||||||
|
- connector-staged datasets and external references
|
||||||
|
- generated file/csv/xlsx inputs from files/connectors
|
||||||
|
- future `govoplan-datasources` catalog entries, if that module is created
|
||||||
|
- future `govoplan-dataflow` outputs, if that module is created
|
||||||
|
|
||||||
|
Reporting should not reach into module ORM internals directly. Module-owned
|
||||||
|
data must be exposed through capabilities, DTOs, events, read models, or
|
||||||
|
controlled query views.
|
||||||
|
|
||||||
|
## Output Targets
|
||||||
|
|
||||||
|
- dashboard/widget view
|
||||||
|
- API result
|
||||||
|
- downloadable file
|
||||||
|
- stored file/DMS evidence
|
||||||
|
- email attachment or link through mail
|
||||||
|
- scheduled export
|
||||||
|
- RSS/Atom/open-data publication through connectors
|
||||||
|
- workflow/task notification when a report run needs review
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
Reporting does not own:
|
||||||
|
|
||||||
|
- reusable template rendering; that belongs to `govoplan-templates`
|
||||||
|
- DMS lifecycle, collaborative editing, legal hold, or records management
|
||||||
|
- raw file/blob storage and provider connectors
|
||||||
|
- general-purpose ingestion/transformation pipeline ownership unless a future
|
||||||
|
`govoplan-dataflow` module is justified
|
||||||
|
- cross-module search indexing; that belongs to `govoplan-search`
|
||||||
|
|
||||||
|
## Candidate Capabilities
|
||||||
|
|
||||||
|
- `reporting.catalog`
|
||||||
|
- `reporting.run`
|
||||||
|
- `reporting.schedules`
|
||||||
|
- `reporting.exports`
|
||||||
|
- `reporting.readModels`
|
||||||
|
- `reporting.dashboardContributions`
|
||||||
|
|
||||||
|
## First Implementation Slice
|
||||||
|
|
||||||
|
1. Define manifest metadata, permissions, and capability names.
|
||||||
|
2. Add report definition and parameter DTOs.
|
||||||
|
3. Add one read-only report source contract over module-provided summary DTOs.
|
||||||
|
4. Add export target DTOs without implementing every target.
|
||||||
|
5. Add tests that report consumers/producers use capability lookup rather than
|
||||||
|
direct imports.
|
||||||
Reference in New Issue
Block a user