Web task manager

01 Problem and context

In a task manager, what breaks is rarely the list itself, but the rules: which status a duplicate inherits, what disappears from view upon archiving, or how due status is derived from deadlines. Scattered across components, these rules end up contradicting each other as the application grows.

A personal task manager where the interesting part is not the list but the rules: what state a copy inherits, what disappears from view once archived, how overdue is derived from the deadline. It runs entirely in the browser, with no account and no server. It is the smallest project of the set and plays a clear role: pinning down the domain model and the business rules in TypeScript before carrying them into a database-backed, multi-user architecture.

02 Solution

The domain model was built first in TypeScript, defining status, priority, and deadline as first-class fields, with business rules centralized in global state behind a five-operation contract. Verification was conducted against a written script covering the two most error-prone scenarios: resetting duplicates to Pending and removing archived tasks from the main view.

1. 01Domain model first: TypeScript types for task, project, list and tag, with status, priority and due date as first-class fields.
2. 02Business rules centralised in the store rather than scattered across components: title is mandatory, a new or duplicated task starts as Pending, archived items drop out of default views, and overdue is derived from the deadline.
3. 03Global state through React Context exposing a deliberately narrow contract of five operations.
4. 04Two views: a summary panel and a list with search, combined filtering and sorting.
5. 05A hand-rolled interface in plain CSS with custom properties, no component framework.
6. 06Manual verification against a written six-step script covering the two cases most likely to break: a duplicate that must revert to Pending, and an archived task that must leave the main list.

03 Results

Verifiable figures in the repository and its documentation:

04 How it's built

Personal task management web application ("Tasker.io") built as a SPA with React 18, TypeScript, and Vite. It allows users to create, edit, duplicate, archive, and complete tasks with priorities, deadlines, projects, lists, and tags. State is managed with React Context, applying business rules such as returning duplicated tasks to pending status and excluding archived tasks from the main view. It includes a summary dashboard and a list view with search, combined filters, and sorting.

05 Ethical decisions

• ✦No account, no server, no telemetry: the app collects nothing because it has nowhere to send it. That follows from the scope rather than from an elaborate stance, and it is stated as such.

06 Highlights

• ✦React 18 SPA with strict TypeScript and Vite build.
• ✦Global state managed via React Context, applying custom business logic.
• ✦List view with search, filtering by priority, status, and date, and sorting.
• ✦Typed data model for tasks, projects, lists, tags, and categories.

07 Limitations

There is no dataset and no persistence: state lives in React memory and a page reload wipes it entirely. This was not a limitation discovered late, it is what the scope allowed, and it explains why the project is archived rather than maintained: its natural continuation, with accounts, a database and per-user isolation, was built afterwards in the command centre.