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)

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)

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)

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)

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)

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

4.2 KiB Raw Permalink Blame History