Taskflow Ai

I use TaskFlow AI’s versioned REST API for profile, workspace, project, task, and comment operations. Routes use the /api/v1 prefix; protected requests rely on a session cookie, and browser writes must satisfy the API’s origin and JSON requirements.

I authenticate protected API requests with the taskflow_session HttpOnly cookie.

For browser writes, I include the configured Origin and send JSON with Content-Type: application/json.

My list pagination defaults are page 1, pageSize 20, maximum 100.

For workspace member role changes, only owner can grant/change admin; owner removal requires ownership transfer first.

I make new workspace membership invitation-based; direct member creation is intentionally not exposed.

In my project API, workspace members can read projects and non-guests can create them.

In my project API, a project admin or workspace admin can update, delete, or archive a project; member changes also require project or workspace admin access.

In my task API, project reads follow project access, while task writes require project ADMIN or MEMBER access or workspace admin access.

For task endpoints, reading and editing follow project role, but deleting requires project or workspace admin access.

A task writer can change task status and assign or unassign a task; an assignee must be a workspace member, and null unassigns.

A project reader can list task comments, while a task writer can add comments.

My dashboard reads the workspace overview for project progress, task status totals, upcoming deadlines, member count, and recent activity.

My project lists and statistics are workspace-scoped and limited to projects visible to the current user.

When I create a project, the creator is automatically added as project administrator.

To add a project member, the user must already belong to the same workspace.

My task list filters are page, pageSize, status, priority, assigneeId, search, dueBefore, dueAfter; unassigned means no assignee.

My task creation example uses priority HIGH, dueAt 2026-10-20T17:00:00Z, status TODO.

Workspace OWNER/ADMIN can read and manage every project.

Other members and guests see only projects where they have project membership.

Project VIEWER is read-only; MEMBER can create and update tasks/comments, and project ADMIN can also manage project settings and members.

For resource access outside the caller’s workspace, my API returns 404 to avoid disclosing existence.

My mutations record actor, action, and relevant resource in ActivityLog within the same database transaction where applicable.

I’m building TaskFlow AI, an AI-powered project management SaaS. Its current repository is a TypeScript monorepo development foundation with a Next.js frontend, an Express API, shared Zod contracts, and a Prisma/PostgreSQL package. The frontend and API are independently runnable workspace applications.

I started the taskflow-ai repository in 2026-10, and it was last updated in 2026-10.

• I need Node.js 22.9 or newer (Node.js 22 LTS recommended), pnpm 11.19.0, and PostgreSQL 14 or newer for this repository.

The workspace is divided between apps/api for the Express REST API, authentication, authorization, and tests; apps/web for the Next.js App Router frontend; packages/contracts for shared Zod schemas and TypeScript types; and packages/database for the Prisma schema, migrations, and shared database client.

• I install dependencies with pnpm install and approve only named lifecycle scripts required by the workspace, including Prisma engines and esbuild.

Copy-Item .env.example .env
pnpm db:generate
pnpm db:migrate

I set DATABASE_URL to an accessible PostgreSQL database; the example URL is a local development placeholder, not a production credential. I create the database itself first if it does not exist.

For an existing shared, staging, or production database, I use reviewed checked-in migrations with pnpm db:migrate:deploy; pnpm db:push is prototype-only schema sync and does not create migrations.

I provide production DATABASE_URL through the deployment environment rather than a checked-in file, and I do not commit .env or put secrets in NEXT_PUBLIC_* variables because Next.js exposes those values to the browser.

pnpm dev:web
pnpm dev:api

I access the local frontend at http://localhost:3000 and the API health endpoint at http://localhost:4000/api/v1/health.

I add a frontend component from the repository root with the local shadcn/ui CLI, for example pnpm --filter @taskflow/web run ui add button; the frontend uses Tailwind CSS and is configured for shadcn/ui.

My API CORS allows the configured WEB_ORIGIN, which defaults to the local frontend origin. The health endpoint is a process liveness check and does not verify database readiness.

Authentication and core project, task, and team screens use the PostgreSQL-backed API; notifications and the AI assistant remain demo-only until their backend modules are available.

My browser API client uses NEXT_PUBLIC_API_BASE_URL and sends the HttpOnly session cookie with requests. Next.js server-rendered workspace pages use API_INTERNAL_BASE_URL and forward only the session cookie to Express; the session token is never stored in browser JavaScript storage.

My project and task forms use native browser input validation and send JSON through the shared API client. Express validates each request with Zod and authorizes against the authenticated database session.

My Prisma schema defines users and provider accounts and sessions; workspace and project membership join tables; projects and hierarchical tasks; comments, file metadata attachments, task dependencies, notifications, activity history, invitations, and a transactional outbox for real-time delivery.

My membership tables keep roles and membership timestamps on the relationship, and compound unique constraints prevent duplicate memberships. Indexes cover workspace and project lists, board columns and ordering, assignee queues, deadlines, unread notifications, activity timelines, and unpublished outbox events.

Deleting a workspace cascades through its projects and collaboration records, and deleting a project cascades through its tasks and task content. Deleting a user removes login and membership records while preserving authored content and history with nullable author references where appropriate.

My session, password-reset, and invitation tokens are stored as hashes; the application must encrypt OAuth credentials before persistence. Email addresses are stored lowercase, and task and invitation invariants are enforced by checks in the initial SQL migration.

My Prisma transactions cover project creation with its first administrator membership and activity record, and task changes with activity records. Parent tasks and assignees are checked against the current project or workspace before writes.

Invitation acceptance and outbox delivery remain future work. A worker can publish outbox rows to Socket.IO and retry failed delivery.

My authentication architecture follows this rule: The Express API owns credential verification and opaque database sessions.

My registration flow is transactional: Registration validates and normalizes input, hashes passwords with Node.js scrypt, then creates the user, owner membership, initial workspace, and session in one transaction.

My browser-session design is: The browser receives only a random session token in an HttpOnly, SameSite=Lax cookie; PostgreSQL stores its SHA-256 hash and expiration.

My Next.js workspace layout checks authentication before rendering: The Next.js workspace layout calls the protected /auth/me endpoint before rendering.

I require independent authentication checks for API routes: every API route verifies the session independently.

My session-management endpoints include POST /api/v1/auth/login, /register, and /logout manage sessions.

My profile endpoint behavior is: /auth/me reads and updates the current profile.

My session-management endpoint behavior is: /auth/sessions lists the current user’s active sessions and allows revocation.

I require workspace membership for reads: Workspace reads require membership.

My workspace-rename authorization rule is that workspace renames require an OWNER or ADMIN role fetched from PostgreSQL.

I do not accept role claims from request bodies: Request bodies cannot supply effective roles.

My password-reset flow uses Password reset uses short-lived, one-use hashed tokens.

My password-reset responses use generic responses to prevent account discovery.

After a successful password reset, my system revokes all sessions after a successful reset.

For local development, I follow this cookie-domain policy: Keep SESSION_COOKIE_DOMAIN empty for local development.

I set the cookie domain in production only under this condition: set it only when the frontend and API use related production hosts.

My proxy policy is: Set TRUST_PROXY=true only behind a trusted reverse proxy.

My current rate limiter is process-local: The current rate limiter is process-local.

Before running multiple API instances, I need to use a shared store before running multiple API instances.

I enable password-reset email delivery with this configuration: Configure EMAIL_DELIVERY_URL, EMAIL_DELIVERY_TOKEN, and EMAIL_FROM to enable password-reset email delivery.

My email-delivery request format is: The delivery service accepts a JSON POST with from, to, subject, and text fields.

My email-delivery settings are server-only: These settings are server-only.

I run pnpm test:api to build the database package and API: pnpm test:api builds the database package and API.

The test command then runs Node’s built-in test runner.

My API test runner covers password hashing, input validation, session-token handling, cookie policy, rate limits, CSRF origin checks, authorization policy, pagination, and unauthenticated route guards.

A PostgreSQL-backed project/task workflow test runs when DATABASE_URL is configured and the schema is migrated; otherwise it is skipped.

The password-reset token lifetime and rate-limit thresholds are unspecified. The shared store for multi-instance rate limiting and production values for email-delivery settings and SESSION_COOKIE_DOMAIN are also unspecified.