1. Run the project in a clean folder.
Download and extract the ZIP. It contains one folder named reading-list. Open a terminal in that folder and run the following commands. The test suite starts and stops its own temporary HTTP server.
node --version
npm test
npm startOpen http://127.0.0.1:4173. Press Ctrl+C in the terminal to stop it. No installation step is required: the server and tests use Node’s built-in modules. If the port is occupied, the README explains how to choose another.
The online example and your local copy have separate storage. Export a backup before moving between them. Browser-local storage does not provide cross-device sync or recovery after browser data is cleared.
2. Try the complete journey.
- Save and return. Paste
https://example.com/guide#setup, add a memorable label, and save. Reload the page. The link remains. - Repeat the action. Save the same URL with
#details. You see duplicate feedback and one saved row. - Find and move your work. Search by label. Export a backup, remove the item, and import the backup. Import it again to check that no duplicate appears.
- Inspect recovery. Invalid input is kept for correction. Failed writes keep your input. Unreadable storage offers backup, retry, and a separately confirmed reset.
The README includes troubleshooting; ACCEPTANCE.md provides the browser review script. The app never fetches saved pages or sends your list to an AI provider.
3. Understand the boundary that matters.
The interface announces a saved link only after storage accepts the write. URL validation, duplicate checks, and backup validation live in a separate core module, so those rules can be tested without a browser.
- FormCapture the URL and optional label.
- PolicyCanonicalize the URL and check for duplicates.
- StorageWrite the versioned document, or retain the old data on failure.
- FeedbackRender the result and explain the next action.
Imports validate the entire file before writing. Existing links win on duplicate URLs. Unsupported or corrupt saved data is preserved until you explicitly reset this kit’s key. The included architecture document has a diagram and explains how a future server API would change the persistence boundary.
4. Make one deliberate change.
Start with the labels and styling. Then try a behavior change, such as editing saved titles. Write the cancel, invalid-input, and failed-write cases before asking an agent to implement it. PROMPTS.md includes concrete requests, and the skill folders supply reusable instructions for scoping and reviewing the work.
Add inline title editing to this reading-list kit. Read README.md and ARCHITECTURE.md first. Preserve the 120-character limit, URL identity, and savedAt value. Define cancel and failed-write behavior, add core tests, then implement the UI. Run the tests and browser acceptance journey. Report what you actually verified.When you’re ready to host it
Upload the contents of public/ to an HTTPS static host. Preserve the relative file paths and serve .mjs files as JavaScript. The README includes the response headers and final-origin checks. The included loopback Node server is for local development.
For a shared or multi-device list, design a server-side identity and storage boundary first. This kit deliberately has no authentication, synchronization service, or browser-embedded credentials.
5. Everything is in the download.
The ZIP contains the same project that was extracted and tested during release. Nothing depends on this website being available after download.
- Start hereREADME.md, package.json, server.mjs
- Change the applicationpublic/index.html, style.css, app.mjs, core.mjs
- Prove the behaviortests/core.test.mjs, tests/server.test.mjs, ACCEPTANCE.md
- Understand and extendARCHITECTURE.md, PROMPTS.md, guide.md, two skill folders
Inspect the release file manifest
ACCEPTANCE.md1,632 bytesARCHITECTURE.md1,574 bytesPROMPTS.md1,403 bytesREADME.md6,807 bytesguide.md21,994 bytespackage.json241 bytespublic/app.mjs6,463 bytespublic/core.mjs3,194 bytespublic/index.html4,220 bytespublic/style.css3,311 bytesserver.mjs1,872 bytesskills/frame-a-feature/SKILL.md1,781 bytesskills/review-an-interface/SKILL.md1,802 bytestests/core.test.mjs4,053 bytestests/server.test.mjs1,054 bytes
Verify the download’s SHA-256
63d4c35b8aacf5caa5466ca25718cd4e09b78d9de21faa00d9f0ecfbfb37896c# In your download folder (macOS):
shasum -a 256 reading-list-1.0.1.zip
# Linux: sha256sum reading-list-1.0.1.zip6. Check the evidence, then the date.
Maintenance check overdue
Release v1.0.1 was packaged on Oct 5, 2026, 3:03 AM UTC. Its 9 automated cases cover storage behavior and the portable server. They do not certify screen-reader behavior or production hosting.
Latest completed check: Oct 5, 2026, 3:20 AM UTC. Project tests: passed. Release files: match.
The maintenance worker rechecks three fixed documentation sources and runs the admitted project’s tests daily while the worker is running. Changed source fingerprints, unavailable sources, mismatched files, or failing tests hold an update. A source change is a review signal, not proof that the kit is obsolete.
- MDN browser storage ↗
Storage, backup, and recovery guidance
- W3C form notifications ↗
Labels, error association, and status feedback
- Node.js test runner ↗
Test commands and runtime instructions
How an update reaches readers
A proposed code or documentation change must use a new version. The release command checks reviewed source fingerprints, runs tests, builds the ZIP, extracts it into a clean folder, and tests that copy. Existing versions cannot be overwritten. Reference changes require an impact review before a new baseline is recorded; automatic rewriting and semantic review by an AI agent are not yet enabled.
MDN checks use the official Markdown source; the other checks compare HTML responses, so navigation or formatting changes may also trigger a review. Checks do not scrape source prose into the guide. History preserves the result even when the next check recovers.
Recent maintenance runs
- Checks passedOct 5, 2026, 3:20 AM UTC · v1.0.1
- Held for reviewOct 5, 2026, 2:41 AM UTC · v1.0.0
Review the changed document for impact on: storage, backup, and recovery guidance. A fingerprint change alone is not a breaking change.