- Minimal local first web app (static HTML + modular JS)
- Entrypoint:
index.html(+ static pages inpages/) - Source composed of small, focused modules in
src/(components/,utils/, ..) with colocated tests - Frequently during development and before each commit: run
npm test - Run
npm outdatedat the start of each significant task and weekly at minimum; keep dependencies healthy. Prefer bumping to theWantedversion unless blocked by incompatibilities (document any exceptions). Also runnpm auditto catch security issues even when versions are current README.mdtypically contains big picture dev. spec and context. It should be kept up to date whenever the code is ready for a PR- Static app => serve
index.htmlwith simple static server (e.g., VS Code Live Server) - Only change code directly related to the current task; keep diffs small
- Preserve existing comments & docs; add concise, long-lived comments where useful and avoid narrating changes via comments
- When external documentation is needed and you lack a browsing/online search tool, ask the user to run an online search for you (e.g., "Please search for "x" and paste back the findings")
This project follows a no-build, static workflow:
- Use native ES modules and
<script type="importmap">to map bare specifiers when needed. - Then load your entry/module scripts with
<script type="module">and import using the mapped specifiers. - Prefer CDN URLs from unpkg.com for third-party modules compatible with ESM.
- Do not add bundlers/build chains unless explicitly requested in an issue/PR.
- Unit specs:
*.test.js - Property-based specs:
*.property.test.js - Property-based tests are important, don't omit them for important components
- Keep tests deterministic and fast; avoid E2E unless asked
- Prefer the simplest fix first
- Use TDD: Add a failing test first and run
npm testto verify it's failing - Make minimal, focused changes
- Re-run
npm testafter each fix and document real output - Iterate until green
Follow this lightweight spec-first flow before coding:
- Requirements gathering
- Ask one question at a time and iterate until requirements are clear.
- Build each question on previous answers; prefer 4+ numbered response options for the user to select from.
- For larger changes: draft a high-level implementation plan and pause for explicit user approval before modifying code.
- Specification development
- Smaller changes: clearly state what changes, how it integrates, testing strategy and key edge cases.
- Major features: capture functional requirements, architecture choices/integration points, data handling (I/O, validation), error handling and edge cases, testing strategy (unit + property-based + integration), and any UI & performance considerations.
- Final specification
- Compile a concise developer-ready spec markdown next to new components if any were added. Include as a first line a summary that could also be used as a commit message for the change.