7.5 KiB
Development Progress
This is the living implementation log for Steady. Update it after every meaningful development step with what changed, why it changed, how it was verified, and what remains.
Current Status
- Current phase: Phase 2 — Task Management
- Status: Complete
- Last updated: 2026-08-08
- Next phase: Phase 3 — ADHD-Specific Features
Phase 1 — Core Infrastructure
1. Application foundation
Added an application factory, environment-specific configuration, secure defaults, feature flags, and independently initialized Flask extensions.
Why: isolated application instances support testing and future deployments, while init_app() keeps extensions reusable. Feature packages can be added without creating a single tightly coupled application module.
Key files: app/__init__.py, app/extensions.py, config.py, and wsgi.py.
2. Modular routing
Added core and auth Blueprints, a /health endpoint, and reserved packages for tasks, settings, admin, and the versioned API.
Why: each feature owns its routes and implementation. The health endpoint provides a lightweight operational check that does not depend on authentication or database access.
3. Secure authentication
Implemented user registration, login, POST-only logout, password hashing, CSRF protection, safe redirects, generic login failures, and unique username/email handling. Authentication is separated into models, forms, services, and routes under app/auth/.
Why: separating HTTP handling from business logic allows future web and API interfaces to reuse the same account services. Security checks are part of the initial design rather than later additions.
4. Shared interface
Added a reusable Jinja base template, authentication pages, navigation, feedback messages, and a responsive pastel stylesheet.
Why: all future features inherit consistent navigation and accessible interaction. The interface includes keyboard focus indicators, system light/dark themes, restrained animation, and reduced-motion support.
5. Database migrations
Configured Flask-Migrate and generated the initial Alembic migration for the user table.
Why: committed migrations provide a reproducible database history as additional features introduce new tables and schema changes.
6. Tests and documentation
Added factory, configuration, CSRF, route, registration, password, duplicate-account, login/logout, and redirect-security tests. Added local setup, migration, and testing instructions to README.md.
Why: tests protect observable behavior and security boundaries. The documentation gives contributors a repeatable development workflow.
Verification
10 tests passed in 0.52s
Flask discovered all expected routes.
Alembic reported no pending model changes.
Python compilation completed successfully.
git diff --check completed successfully.
Phase 2 — Task Management
Phase 2.1 — Task data model and migration
Added an independently registered task Blueprint plus typed Task and Subtask models. Tasks include status, priority, due date, ownership, completion time, and reserved Phase 3 timing fields. Database constraints restrict status and priority values; owned subtasks cascade safely when their task is deleted. Progress is derived from subtask completion instead of stored redundantly.
Why: database constraints protect invariants even outside web forms, while ownership keys prepare every query for user isolation. Keeping progress derived prevents stale percentages when subtasks change.
Generated, reviewed, and applied the Add tasks and subtasks Alembic migration. The existing 10-test suite remained green after the schema change.
Phase 2.2 — Task service layer
Added service operations for owned task lookup, filtered lists, the seven-item Today view, creation, editing, deletion, subtask creation, and subtask toggling. Today excludes completed and future-dated tasks while accepting undated inbox items. Sorting consistently favors active, higher-priority, nearer-due work.
Why: ownership filtering in the service boundary prevents routes and future APIs from accidentally exposing another user's records. Centralized ordering and completion timestamps keep behavior consistent across every interface.
Next: add validated forms and authenticated routes that use these services.
Phase 2.3 — Forms and authenticated routes
Added validated task and subtask forms plus authenticated routes for task lists, Today, create, detail, edit, delete, subtask creation, and subtask toggling. Invalid filters return 400; missing or foreign-owned records return 404; all mutations require POST and CSRF validation.
Why: forms constrain input at the HTTP boundary, while the service layer remains the ownership authority. Separating read routes from POST mutations prevents links or crawlers from changing data and gives CSRF protection complete coverage.
Next: build the templates and visual components for filtering, priorities, subtasks, and progress.
Phase 2.4 — Task-management interface
Added the full task list, Today view, create/edit form, and task detail templates. The interface includes status filters, calm priority badges, accessible native progress bars, subtask toggles, responsive layouts, empty states, and a deliberately disclosed delete action. Authenticated navigation now links to Today and Tasks.
Why: Today reduces visible choices to seven without hiding the full workspace. Native progress elements retain semantic meaning for assistive technology. Delete is available but visually separated to reduce accidental destructive actions, while empty states give a low-pressure next action.
Next: cover Phase 2 behavior and ownership boundaries with automated tests.
Phase 2.5 — Automated coverage
Added eight Phase 2 tests covering authentication gates, complete task CRUD, status filtering, invalid filters, the seven-item Today limit, future/completed hiding, cross-user isolation, subtask-derived progress, and whitespace-only title rejection. The shared database fixture now always establishes an application context.
Why: these tests protect the feature's behavioral and security boundaries. In particular, the ownership test proves that another user receives 404 and cannot delete the record, while the Today test validates the query result and not merely page text.
Verification at this step: 18 passed in 1.51s.
Next: run compilation, migration consistency, route discovery, whitespace, and full regression checks.
Phase 2.6 — Final verification
Completed the full regression suite, Alembic model comparison, route discovery, Python compilation, dependency consistency check, trailing-whitespace scan, and patch-format validation.
Why: a feature is complete only when its behavior, schema, dependencies, and integration with earlier work agree. Running the Phase 1 suite alongside the new tests proves that task management did not regress authentication or the application factory.
Final results:
18 tests passed in 1.50s
Alembic detected no pending model operations.
Flask discovered all expected authentication, core, and task routes.
Python compilation completed successfully.
No broken Python requirements were found.
Whitespace and git diff checks completed successfully.
Next Work
Phase 3 will add ADHD-specific interaction features on top of the stable task domain: Focus Mode, a per-task countdown timer, time-block chunking, context-reminder placeholders, positive completion feedback, and a forgiving streak model. Each feature should remain optional, accessible, and independently testable.