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

[Answer]: A

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

[Answer]: A

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

[Answer]: A

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

[Answer]: A

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

[Answer]: A

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