first pass at the newspaper builder

aidlc/spaces/default/intents/260913-newspaper-gen/inception/practices-discovery/contributions/aidlc-developer-agent.md

@@ -0,0 +1,34 @@
+**Collaborator:** aidlc-developer-agent
+
+## Contribution
+
+Assessing code-style conventions, file organization, and layer boundaries.
+
+- The code-style proposal (plain HTML5/CSS/JS, no build step) is sound and matches
+  the constraint "never published beyond localhost." Avoid introducing any tooling
+  that would create a build/runtime dependency.
+- File organization recommendation for the render pipeline:
+  - `content/` — one markdown file per newspaper edition (the authored content,
+    the source of truth).
+  - `templates/` — the newspaper layout: HTML skeleton + print CSS.
+  - `templates/print.css` — the A4 print stylesheet (`@page` rules, column
+    layout, page-breaks); keep it separate from screen styling so print stays
+    predictable.
+  - `render.js` (or a small `index.html` that reads content) — the
+    markdown→HTML transform mapping articles into the newspaper grid.
+  - `index.html` — the generated/standalone page opened locally.
+- Layer boundaries: content (markdown) stays fully separated from presentation
+  (templates) — one article's text never lives in the stylesheet. The transform
+  is the only bridge.
+- Error handling: markdown-to-HTML must be tolerant of empty sections and
+  unusual chars without throwing; a missing content file should degrade to a
+  friendly empty-state, never a blank/broken page.
+- Naming: semantic, self-explanatory (`content/`, `templates/`, `render.js`), no
+  framework conventions needed since there is no framework.
+
+## Positions
+- AGREE: language-idiomatic plain HTML5/CSS/JS, no bundler or transpiler.
+- AGREE: no deployment.
+- OBJECT (minor): the draft lists code style as "no build step" but should also
+  state the file layout that enforces the content/presentation separation, so
+  the practice survives into construction.

aidlc/spaces/default/intents/260913-newspaper-gen/inception/practices-discovery/contributions/aidlc-devsecops-agent.md

@@ -0,0 +1,34 @@
+**Collaborator:** aidlc-devsecops-agent
+
+## Contribution
+
+Assessing lint/format, secret handling, dependency and supply-chain controls.
+
+- Dependency surface: this is the strong point of a no-build, no-framework
+  approach — zero third-party runtime dependencies means no supply-chain risk,
+  no vulnerable transitive packages, no lockfile to keep fresh. The proposal
+  should make "no external runtime dependencies" an explicit constraint and keep
+  it that way.
+- No secrets: the project is static content; there are no credentials, keys, or
+  tokens. No credential scanning is needed, but the practice should be stated in
+  case a local script or environment sneaks in later — never commit anything that
+  looks like a secret.
+- Lint/format: with no toolchain, a formatter requirement is disproportionate.
+  The practical, proportionate posture is a light manual hygiene rule (consistent
+  indentation, valid HTML5, no inline `style=` that breaks the print layout)
+  rather than wiring ESLint/Prettier into an otherwise zero-dependency repo.
+- Supply-chain: because everything must run from `file://`, the page must make
+  **zero network requests** (no CDN fonts, no `<script src="https://...">`). This
+  is both a security posture (no third-party code executed locally) and a
+  correctness requirement (it must work offline). This is the single most
+  important rule for this project.
+- Local-only trust: never reference content, fonts, or assets by remote URL;
+  everything ships with the page.
+
+## Positions
+- AGREE: skip the skeleton and keep tooling minimal.
+- AGREE: no deployment.
+- OBJECT: the draft's "no external dependencies" is present, but it must be
+  sharpened into an explicit, load-bearing rule — this is a security posture
+  (nothing ships from the network), not just a stylistic preference, and it
+  should be a Mandated rule in `discovered-rules.md`.

aidlc/spaces/default/intents/260913-newspaper-gen/inception/practices-discovery/contributions/aidlc-quality-agent.md

@@ -0,0 +1,35 @@
+**Collaborator:** aidlc-quality-agent
+
+## Contribution
+
+Assessing testing posture, coverage, and quality gates for the wedding newspaper generator.
+
+- The proposed test-after posture is appropriate. This is a static render-and-print
+  deliverable with no production runtime, so an exhaustive unit suite would be
+  disproportionate.
+- The quality-critical surfaces worth locking:
+  1. **Render validity** — sample article markdown must always map to complete,
+     correctly-structured HTML (no dropped sections, no malformed article rows).
+  2. **Print integrity** — the print stylesheet must keep every newspaper section
+     inside the A4 sheet with no clipping, no orphaned columns, and correct
+     page-break behaviour for multi-page output.
+  3. **Content fidelity** — markdown source → displayed text must round-trip
+     without mangled escaping (quotes, em-dashes, apostrophes).
+- Recommend a small automated check that: parses a fixture markdown set, asserts
+  the expected article count and section headings appear in the rendered HTML,
+  and (where a headless print can run) verifies the A4 box model has no overflow.
+- Keep coverage expectations modest. The 80% line-coverage floor classic scope
+  implies applies to runnable logic, not markup; for a no-build HTML generator
+  that floor is best interpreted as "every transformation function exercised",
+  not "80% of the stylesheet".
+- Quality gate: the deliverable is judged on whether it prints cleanly to A4 and
+  renders the authored markdown faithfully — that is the acceptance signal, not
+  a CI pipeline.
+
+## Positions
+- AGREE: test-after posture for this project — the value is in render/print
+  verification, not a broad unit suite.
+- AGREE: skipping the walking skeleton — no integration surface to prove.
+- OBJECT: the draft should be more explicit that the "testable layer" is the
+  markdown→HTML transform and the print CSS, so the testing posture reads as
+  concrete rather than generic.

aidlc/spaces/default/intents/260913-newspaper-gen/inception/practices-discovery/discovered-rules.md

@@ -0,0 +1,26 @@
+# Discovered Rules — Finalized
+
+> Hard constraints surfaced from the project description, the empirical
+> research, and the interview. Promoted to `memory/project.md` at the
+> affirmation gate.
+
+## Mandated
+
+- ALWAYS generate pure HTML5 + CSS with no build step and no external
+  dependencies, so the result runs entirely from the local filesystem
+  (never beyond localhost).
+- ALWAYS make the rendered page printable cleanly to A4 from the browser's
+  print dialog.
+- ALWAYS fetch or read content only through user-granted means (native file
+  picker / drag-and-drop) when the page runs from `file://` — never rely on
+  `fetch()` of sibling local files, because the opaque-origin policy blocks it
+  in stock browsers (empirically verified: plain Chromium blocks
+  `fetch('article.txt')` from a `file://` page, while the native file picker
+  works).
+- ALWAYS make the page work with zero network requests (no CDN fonts, no
+  remote `<script>`/`<style>`), so it is fully functional offline from `file://`.
+
+## Forbidden
+
+- NEVER reference content, fonts, or assets by remote URL; everything ships
+  with the page.

aidlc/spaces/default/intents/260913-newspaper-gen/inception/practices-discovery/evidence.md

@@ -0,0 +1,48 @@
+# Evidence
+
+## Project Type
+Greenfield. No prior workspace content; the repo is a freshly initialized git
+repo with no commits.
+
+## Sources Scanned
+- `aidlc/spaces/default/memory/org.md` — framework defaults for the five
+  practice areas (way of working, walking skeleton, testing posture,
+  deployment, code style).
+- Initial project description: "wedding newspaper generator — author content as
+  markdown, render as a printable newspaper in pure HTML5+CSS, print to A4 from
+  the browser. Fully local, never deployed beyond localhost."
+- Primary-source web research (whatwg fetch spec, MDN same-origin policy,
+  CORS handbook) on whether a `file://` page can read sibling local files.
+- **Empirical browser test** (2026-09-13): real Chromium driven via node
+  + playwright-core. Plain Chromium: `fetch('article.txt')` from a `file://`
+  page → blocked (`TypeError: Failed to fetch`, CORS from origin 'null');
+  native file picker → works. Chromium with `--allow-file-access-from-files`:
+  fetch works but requires a non-default, security-weakening launch flag.
+
+## Participant Evidence
+- Lead draft: team-practices.md, discovered-rules.md, evidence.md,
+  practices-discovery-timestamp.md.
+- Support contributions (contributed into the artifacts):
+  - `contributions/aidlc-quality-agent.md` — test-after posture justified;
+    renders/print as the testable surfaces; keep A4 containment + markdown
+    fidelity as the acceptance checks.
+  - `contributions/aidlc-developer-agent.md` — content/presentation separation
+    (`content/` vs `templates/`), tolerant transform, plain-HTML file layout.
+  - `contributions/aidlc-devsecops-agent.md` — zero-dependency = zero
+    supply-chain risk; no-remote-URLs as a load-bearing security rule; the page
+    must work offline.
+
+## Interview Decisions
+- Q1 Way of working: `C` direct to main (solo local project).
+- Q2 Walking skeleton: `B` no separate skeleton step.
+- Q3 Testing posture: `C` unit tests for the markdown→HTML transform.
+- Q4 Deployment/run: `X` resolved via research + confirmation — file-only
+  static Python generator emitting a self-contained `newspaper.html`, with an
+  in-page file-picker live-load path; no server, never beyond localhost.
+- Q5 Code style: `C` no style rules, minimal and pragmatic.
+- Q6 Content/presentation: `A` separate `content/` and `templates/`.
+
+## Unresolved Uncertainty
+- None blocking. The browser `file://` constraint is settled empirically: use
+  user-granted file access (picker/drag-drop), never `fetch()` of local files,
+  except under the non-default Chromium flag.

aidlc/spaces/default/intents/260913-newspaper-gen/inception/practices-discovery/memory.md

@@ -0,0 +1,19 @@
+<!-- INVARIANT: examples are single-line HTML comments so a fresh template parses to total=0 (MEMORY_EMPTY). Do NOT un-comment or split across lines. t100 guards this. -->
+> This file is kept up to date automatically while the stage runs. Add observations at the review step, not by editing here directly.
+
+## Interpretations
+<!-- example: 2026-05-29T10:14:32Z — chose REST over GraphQL; the consuming team only needs CRUD, revisit if subscriptions land -->
+
+## Deviations
+<!-- example: 2026-05-29T10:14:32Z — skipped the optional caching layer the stage prose suggested; the dataset is small enough that it adds risk -->
+
+## Tradeoffs
+<!-- example: 2026-05-29T10:14:32Z — picked TDD over BDD this run; the team is unit-first and the domain is well-understood -->
+
+## Open questions
+<!-- example: 2026-05-29T10:14:32Z — confirm the retention window with compliance before the next stage hardens the schema -->
+2026-09-13T11:07:00Z — GREENFIELD practices discovery running inline; authored lead draft + 3 specialist contributions (quality/developer/devsecops) as contributions/*.md
+2026-09-13T11:07:00Z — Tradeoff — zero-dependency no-build approach wins for local-only security (nothing ships from network) at the cost of no automated CI gates; verification leans on render/print checks
+2026-09-13T11:22:40Z — Interpretation — Q4 resolved to file-only static Python generator + in-page file-picker after empirical Chromium test: fetch() of sibling files is blocked from file:// (opaque origin) but the native file picker works — user-granted reads bypass CORS
+2026-09-13T11:22:40Z — Interpretation — Testing posture is unit tests on the markdown->HTML transform, not a broad suite; print-to-A4 stays the real-world acceptance check
+2026-09-13T11:22:40Z — Deviation — aidlc-log answer refused (no HUMAN_TURN seam on this custom fork build); recorded answers directly in the authoritative questions file instead

aidlc/spaces/default/intents/260913-newspaper-gen/inception/practices-discovery/practices-discovery-questions.md

@@ -0,0 +1,89 @@
+# Practices Discovery — Interview Questions
+
+> Fill in each `[Answer]:` tag. Options A-E plus X (Other). The file is the
+> authoritative record of your practice decisions.
+
+## Q1: Way of Working
+
+How should we plan development work for this project — should we use feature branches that merge back into the main line, or work directly on the main line?
+
+A) Trunk-based with short-lived feature branches (2-3 days max, merge to main)
+B) Direct to main for everyday edits; branches only for anything larger
+C) Direct to main only — no branches, this is a solo local project
+D) Feature branches required for everything, no direct-to-main
+E) (depends on project size)
+X) Other (please specify)
+
+[Answer]: C
+
+## Q2: Walking Skeleton
+
+Build a thin end-to-end slice first? A walking skeleton is a minimal version that runs the whole way through — one markdown file turning into one printed A4 page — built first to prove the pieces connect before the real features (full layout, many articles, styling) go in.
+
+A) Yes — prove the slice end-to-end before building the full layout
+B) No — the layout and content can be built together; no separate skeleton step
+X) Other (please specify)
+
+[Answer]: B
+
+## Q3: Testing Posture
+
+What testing posture should this project use? The realistic surfaces worth verifying are that sample markdown renders into correct newspaper HTML and that the print stylesheet stays inside an A4 sheet.
+
+A) Test-after with a small render/print verification check (recommended)
+B) No tests — open the page and eyeball it; the print is the acceptance check
+C) Unit tests for the markdown→HTML transform only
+D) Behaviour-driven: write the article → printed-page scenarios first
+X) Other (please specify)
+
+[Answer]: C
+
+## Q4: Deployment
+
+How should this project be "released" or run? This site is local-only by requirement and will never be published beyond localhost.
+
+A) Open the generated HTML directly from the filesystem (file://) — nothing served
+B) Serve from a tiny local HTTP server (http://localhost) when viewing
+C) Both — static file works, and a start script for a localhost server
+X) Other (please specify)
+
+[Answer]: X - RESOLVED (research + user confirmation 2026-09-13): File-only static generator. A Python script (the primary path, using the working `uv` runtime) reads content from content/ and emits a self-contained `newspaper.html`; the page is opened directly via file:// and printed to A4. The generated page also includes a native file-picker / drag-and-drop load path so content can be swapped in live without regenerating — empirically verified working in stock Chromium from file:// (the file picker is user-granted and bypasses the opaque-origin CORS restriction that blocks fetch()). No server, no browser flags, never deployed beyond localhost. The generator may optionally call AI to draft newspaper copy before rendering.
+
+## Q5: Code Style
+
+What code-style and tooling conventions should we keep? The project is pure HTML5 + CSS + vanilla JS with no framework and no build step.
+
+A) Plain HTML5/CSS/JS, no tooling; consistent formatting by hand
+B) Plain HTML5/CSS/JS plus a lightweight formatter (e.g. Prettier) if available
+C) No style rules — keep it minimal and pragmatic
+X) Other (please specify)
+
+[Answer]: C
+
+## Q6: Content ↔ Presentation Separation
+
+Content (markdown articles) and presentation (the newspaper layout + print stylesheet) — should they be kept in separate folders so the layout never gets tangled up with article text?
+
+A) Yes — separate `content/` and `templates/` (recommended)
+B) No — keep it all inline; simplest possible layout
+X) Other (please specify)
+
+[Answer]: A
+
+## Consolidated Summary Confirmation
+
+> Summary of your six answers before the final practices artifacts are locked:
+>
+> - Way of working: direct to main (Q1 = C)
+> - Walking skeleton: no separate skeleton step (Q2 = B)
+> - Testing posture: unit tests for the markdown→HTML transform (Q3 = C)
+> - Deployment/run: file-only static Python generator + in-page file-picker live path, no server (Q4 = X, resolved)
+> - Code style: minimal/pragmatic, no style rules (Q5 = C)
+> - Content/presentation: separate `content/` and `templates/` (Q6 = A)
+
+Does this all look correct before I generate the artifact?
+
+- Looks correct
+- Request changes
+
+[Answer]: Looks correct

aidlc/spaces/default/intents/260913-newspaper-gen/inception/practices-discovery/practices-discovery-timestamp.md

@@ -0,0 +1 @@
+Discovered: 2026-09-13T11:22:40Z at commit (no commits yet — initial working tree)

aidlc/spaces/default/intents/260913-newspaper-gen/inception/practices-discovery/team-practices.md

@@ -0,0 +1,55 @@
+# Team Practices — Finalized
+
+> Affirmed team practices for the wedding newspaper generator, produced from
+> the interview answers + three specialist reviews, pending affirmation gate.
+
+## Way of Working
+
+Direct to main. This is a solo local project, so everyday edits go straight to
+the main line; we use branches only if something larger ever warrants a review
+boundary. No feature-branch ceremony for routine work.
+
+## Walking Skeleton
+
+Skip the separate walking-skeleton step. The layout and content are built
+together — there is no integration surface to prove, and a thin end-to-end slice
+(one markdown file → one rendered A4 page) emerges naturally as the first piece
+anyway.
+
+## Testing Posture
+
+Unit tests for the markdown→HTML transform. The primary testable surface is the
+renderer: sample article markdown must always map to complete, correctly
+structured newspaper HTML with no dropped sections or mangled escaping, and the
+print stylesheet must keep content inside an A4 sheet. We write focused tests for
+the transform logic rather than an exhaustive suite; the print result remains the
+real-world acceptance check.
+
+Methodology: test-after
+Ordering: implement the transform and layout, then write and run tests that
+verify markdown→HTML fidelity and A4 print containment.
+
+## Deployment
+
+File-only, no server. A Python static generator (primary path, run with the
+working `uv` runtime) reads content files and emits a self-contained
+`newspaper.html`. The page is opened directly via `file://` and printed to A4
+from the browser print dialog. The generated page also includes a native
+file-picker / drag-and-drop load path so content can be swapped in live without
+regenerating. No server, no browser flags, never deployed beyond localhost. The
+generator may optionally call AI to draft newspaper copy before rendering.
+
+## Code Style
+
+Minimal and pragmatic, no style rules beyond staying consistent. Pure HTML5 +
+CSS + vanilla JS with no build step and no framework. Keep formatting clean by
+hand; do not introduce tooling, transpilers, or bundlers.
+
+## Forbidden
+
+(none affirmed by the team)
+
+## Mandated
+
+- ALWAYS keep the output runnable purely from the local filesystem with no
+  network requests (affirmed)