Sample Project — Build a Tracker App

mkdir tracker-app && cd tracker-app
git init

# Pick your preset (replace  with dotnet, typescript, python, etc.)
.\setup.ps1 -Preset <your-stack>

# Verify
.\pforge.ps1 smith

Feature: health-endpoint

Problem: The Tracker app needs a health check endpoint so load balancers
and monitoring tools can verify the service is running.

Scenarios: GET /health every 30 seconds. Returns 200 OK with
{"status": "healthy", "version": "1.0.0"}.

Acceptance Criteria:
- GET /health returns 200 with JSON body
- Response time under 50ms
- No authentication required
- If database unreachable: 503 {"status": "degraded", "reason": "database"}

Out of Scope: Deep dependency checks, metrics endpoint, custom health UI.

Feature: user-authentication

Problem: The Tracker app needs user accounts with login, registration,
and role-based access control (admin, member).

MUST Criteria:
- User registration with email + password (hashed, never plaintext)
- Login returns JWT token (access + refresh)
- Role-based authorization: admin can manage all projects, member sees own
- Protected endpoints return 401 without valid token, 403 without required role
- Password reset flow (token-based)

SHOULD Criteria:
- Rate limiting on login endpoint (5 attempts per minute)
- Audit log for authentication events

Out of Scope: OAuth/social login, MFA, user profile editing.

Feature: project-task-management

Problem: Users need to create projects and manage tasks within them.

MUST Criteria:
- CRUD for Projects (create, read, update, delete)
- CRUD for Tasks within a project
- Task fields: title, description, status (todo/in-progress/done), priority (low/medium/high), assignee, due date
- Only project owner or admin can delete a project
- List tasks with filtering by status, assignee, priority
- Pagination on list endpoints (default 20 per page)
- 90%+ test coverage on service layer

SHOULD Criteria:
- Task sorting by priority, due date, created date
- Bulk status update for selected tasks

Out of Scope: File attachments, subtasks, task templates, Kanban board UI.

Feature: comments-and-events

Problem: Users need to discuss tasks via comments, and the system needs
an event bus for audit/notification purposes.

MUST Criteria:
- Add, edit, delete comments on tasks
- Only comment author or admin can edit/delete
- Event publishing: task-created, task-updated, task-status-changed, comment-added
- Event consumers: update task activity log, update project last-modified timestamp
- Comments include created_at, updated_at timestamps

SHOULD Criteria:
- @mention support in comments (notify mentioned user)
- Activity feed endpoint: recent events across user's projects

Out of Scope: Real-time WebSocket push to clients, email notifications, rich text.

Feature: dashboard-and-reporting

Problem: Users need an overview of their projects with status summaries,
task distribution, and activity trends.

MUST Criteria:
- Dashboard endpoint: project count, task count by status, overdue tasks
- Per-project summary: task breakdown, recent activity, completion percentage
- Reporting endpoint: tasks completed this week/month, average time to close
- Cache dashboard data (invalidate on task/project changes)

SHOULD Criteria:
- Configurable date ranges on reports
- Export report as JSON

Out of Scope: Charts/graphs (API only), PDF export, scheduled reports.