4.9 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: 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
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.