first pass at the newspaper builder

2026-09-14 11:57:22 +10:00
commit bec1eaac87
497 changed files with 178953 additions and 0 deletions
@@ -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.
@@ -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`.
@@ -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.