28 lines
1.0 KiB
Markdown
28 lines
1.0 KiB
Markdown
|
---
|
||
|
|
id: "0001"
|
||
|
|
date: 2026-07-06
|
||
|
|
status: Accepted
|
||
|
|
supersedes:
|
||
|
|
superseded-by:
|
||
|
|
affected-paths: [bin/reportgen, lib/reportgen/renderer.rb]
|
||
|
|
affected-components: []
|
||
|
|
---
|
||
|
|
|
||
|
|
# 0001 — Reports generated as static artifacts, no server component
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
reportgen produces client reports on a schedule. Running a persistent server process for what is fundamentally a batch job would add operational surface (uptime, deploys, auth) with no corresponding benefit for this workload.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
reportgen ships as a CLI invoked by cron on the ops box. Each invocation generates static report artifacts (HTML/CSV) and, for the deliver command, ships them to the client. There is no long-running server component.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
Simple to operate and reason about; no server to patch or scale. Any future need for on-demand/interactive report generation would require revisiting this decision.
|
||
|
|
|
||
|
|
## Alternatives rejected
|
||
|
|
|
||
|
|
A small Sinatra/Rack service exposing report generation on demand was considered and rejected as unnecessary complexity for a batch workload.
|