3.7 KiB
Domain Design — Questions
Fill in each
[Answer]:tag. Options A-E plus X (Other). The file is the authoritative record of your component-decomposition decisions.
Q1: Generator monolith vs. separated components
How should the generator's build-time work be split as reusable components?
A) A single Generator component that reads content and orchestrates rendering, with clearly separated internal responsibilities (config, content, funnies, layout) — cohesive, simple for a local tool (recommended)
B) Split into multiple independent components (ContentLoader, FunniesBuilder, LayoutEngine, Renderer) that the CLI calls in sequence
C) Minimal: one thin script + the emitted static page only
X) Other (please specify)
Q2: AI draft client boundary
The AI copy generation (US8/US9) uses local Ollama. Should it be its own component?
A) Yes — a distinct AiDraft component that talks only to local Ollama, owns the draft + per-article review contract, and is fully optional (recommended)
B) No — fold the Ollama calls into the generator as an optional step
X) Other (please specify)
Q3: Funnies generation ownership
The funnies (crossword, find-a-word, comics, xkcd cartoon) are generated from content (Q5=X). Which component should own this?
A) A distinct Funnies component that takes theme words/context from the content and produces the crossword/find-a-word grids + selects/embeds a cartoon (recommended)
B) Fold funnies generation into the main generator as a sub-step
C) Separate into puzzle-gen and cartoon-fetch sub-components
X) Other (please specify)
Q4: Review page data handoff (R-01 from mockups)
Under the no-server constraint (Q1=A/Q4=B), how should the per-article review page receive the AI draft for a single file:// page to read it?
A) The CLI writes a draft bundle (JSON) the review-page loads through the native file picker (user-granted, NFR5) — recommended B) The review page is served briefly by a temporary localhost server just during review, then the final static HTML is produced C) Merge review into the CLI prompt loop (no HTML review page) — Q3=A in mockups says review page, so this departs from it X) Other (please specify)
Q5: Entity model for content & issue
For a purely local generator, how should we model the domain entities (an "issue", "article", "config", "puzzle")?
A) Lightweight plain data shapes (Issue, Article, MastheadConfig, Puzzle) owned by the generator, no database — the content filesystem is the store (recommended) B) A formalized issue/entity model with strict schemas up front C) No explicit entity model — keep it all file/template-driven X) Other (please specify)
Consolidated Summary Confirmation
Summary of your five architecture answers before the component catalogue and ADRs are generated:
- Generator decomposition: single Generator component with clearly separated internal responsibilities (config, content, funnies, layout) (Q1=A)
- AI draft client: distinct, optional AiDraft component that talks only to local Ollama and owns the draft + per-article review contract (Q2=A)
- Funnies ownership: distinct Funnies component that takes theme words/context from content and produces the crossword/find-a-word grids + selects/embeds a cartoon (Q3=A)
- Review-page data handoff: CLI writes a draft JSON bundle the review page loads through the native file picker (user-granted, NFR5) — resolving mockups R-01 (Q4=A)
- Entity model: lightweight plain data shapes (Issue, Article, MastheadConfig, Puzzle) owned by the generator; the content filesystem is the store (Q5=A)
Does this all look correct before I generate the component catalogue and ADRs?
- Looks correct
- Request changes
Answer: Looks correct