# 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: In progress — routes and interface - Last updated: 2026-08-08 - Next milestone: Ownership-safe task service layer ## 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 ```text 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. ``` ## Next Work ### 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.