feat: add task management module with test suite

[allaspectsdev]

Summary

• Adds a TaskManager module (src/) with full CRUD, input validation, status transition guards, filtering, sorting, and stats
• 96 tests across 3 files (tests/) covering all operations, edge cases, immutability, and invalid input handling
• Sets up project toolchain: TypeScript, Vitest, ESLint, Prettier

Test plan

• npm test — all 96 tests pass
• npm run lint — no lint errors
• Reviewer verifies feature design and test coverage

🤖 Generated with Claude Code

[allaspectsdev]

@claude what's next

[claude]

Claude finished @allaspectsdev's task in 34s —— View job

---

What's Next

• Gather context from merged PR feat: add task management module with test suite #2
• Review current codebase state
• Suggest next steps

---

PR #2 established a solid foundation: TaskManager with full CRUD, state machine transitions, filtering/sorting, validation, and 96 tests. Here are the logical next steps, roughly in priority order:

1. Persistence Layer (highest value)

The CLAUDE.md explicitly flags this as TBD. The TaskManager currently uses an in-memory Map — all data is lost on restart. Good candidates:

• JSON file — simple, no deps, good for a small tool
• SQLite via better-sqlite3 — if you want queries; requires discussing the new dependency per CLAUDE.md rules

This is a good first PR for Bryan (dariuskerpro) since task-manager.ts is currently Ryan's module and collaboration is the point of this repo.

2. CLI Interface (src/cli.ts)

The module has no entry point yet. A simple CLI using Node's built-in readline or process.argv would make this usable and is a natural next layer. No new runtime deps needed.

3. Due Dates / Deadlines

The Task type has no dueDate field. Adding one would touch task.ts, validators.ts, and the filter logic — a well-scoped PR under 300 lines.

4. Bulk Operations

TaskManager handles one task at a time. Bulk status transitions (bulkTransition(ids, status)) and bulk delete are common needs and would be straightforward to add.

5. Events / Hooks

A simple observer pattern (onTaskCreated, onStatusChanged) would make the module composable — useful if a CLI or HTTP layer is added later.

6. HTTP API (src/server.ts)

If this is meant to be a service, a minimal HTTP layer (Node's built-in http module or a lightweight framework) would be the next architectural step after persistence.

---

Suggested immediate next PR: persistence layer (JSON file store), since it's the most important gap and explicitly called out in CLAUDE.md. Happy to help design the interface or implement it if you open an issue.