Problem
A simple visual way to manage personal tasks without accounts, servers, or real work data.
Public build record
How this was built: G0 to G5
A complete, public record of how a small browser app moved from a problem statement to verified code. Every gate produced an artifact, every behavior task followed test-first development, and every approval was recorded before the next gate began.
6
approved gates
10
implementation tasks
32
automated tests
9
browser scenarios
0
dependencies
G0
Discovery
Start with the problem, user, smallest useful scope, measurable success, constraints, and explicit non-goals before discussing implementation.
MVP
Add, move, delete, and automatically preserve tasks after refresh.
Non-goals
No editing, dates, priorities, collaboration, notifications, or cloud sync.
G1
Constitution
Lock the engineering rules before code exists. These rules become constraints for every later decision and implementation task.
- Synthetic, local-only data; no secrets or company work data.
- Plain HTML, CSS, and JavaScript with no external dependencies.
- Test-first task behavior and browser inspection for presentation.
- Keyboard access, visible errors, and no silent failures.
- No gate begins before its predecessor is approved.
G2
Specification
Convert the MVP into a technology-independent behavior contract: four user stories, twelve functional requirements, nine acceptance scenarios, constraints, and explicit exclusions.
Input contract
Trim titles, require 1 to 100 characters, and reject invalid input visibly.
Movement contract
Start, Back, Complete, and Reopen expose only valid status transitions.
Persistence contract
Save every successful mutation, restore on load, and surface storage failures.
G3
Architecture, Design, and Plan
G3 was deliberately split into three ordered artifacts. Design was approved before planning to prevent implementation tasks from being written against an unstable architecture.
G3A: ADR
Functional core, one versioned storage document, fail-safe persistence, and native ES modules.
Read adr.mdG3B: Design
Files, module contracts, transitions, data flow, errors, accessibility, tests, and requirement traceability.
Read design.mdG3C: Plan
Ten sequential tasks with red-green evidence, dependency order, and exact commit boundaries.
Read plan.mdG4
Implementation
Implementation followed ten sequential tasks. Behavior work began with a failing test, moved to the smallest passing implementation, reran the complete suite, reviewed the diff, and committed only that task.
1. Write failing test
2. Observe RED
3. Implement minimum
4. Verify GREEN
5. Review and commit
| Phase | Task | Outcome |
|---|---|---|
| 1 | 1.1 | Dependency-free project scaffold |
| 2 | 2.1 | Title validation and adding |
| 2 | 2.2 | Safe status transitions |
| 2 | 2.3 | Immutable task deletion |
| 3 | 3.1 | Validated storage loading |
| 3 | 3.2 | Atomic save and write failures |
| 4 | 4.1 | Accessible responsive shell |
| 4 | 4.2 | Startup, rendering, and creation |
| 4 | 4.3 | Movement and confirmed deletion |
| 4 | 4.4 | Fail-safe final integration |
The exact tests are public in
test/.
G5
Verification
Verification repeated the tests and browser scenarios independently, injected load and save failures, inspected responsive and keyboard behavior, reviewed network and console output, repaired defects, and updated the documentation.
Automated
32 tests passed, JavaScript parsed, whitespace passed, and dependencies remained zero.
Browser
All nine scenarios passed with keyboard use, responsive layout, clean console, and local-only requests.
Failure injection
Corrupt loads and failed saves produced visible errors without overwriting the last valid board.
Complete artifact index
The public snapshot mirrors the artifact shape used during the private learning loop, but excludes private commit hashes, session notes, and unrelated files.
| Artifact | Question it answers |
|---|---|
| discovery.md | What problem and smallest useful scope are we solving? |
| CONSTITUTION.md | Which rules must all later work follow? |
| spec.md | What exact user-visible behavior must exist? |
| adr.md | Which architecture choices were made and why? |
| design.md | How do files, modules, data, errors, and tests fit together? |
| plan.md | In what safe order should implementation happen? |
| test/ | What automated evidence protects behavior? |
| docs-updated.md | What final verification evidence closes the loop? |
| status.json | Which gates and tasks completed, and in what order? |