Getting started

Start a thread, attach context, and review visible work

Start from the app, describe the outcome you want, and let North Star turn that into a plan or a scoped action. The workbench is where progress, files, approvals, and reports should appear.

Start a thread

Use New chat for a fresh work request. Good prompts include the desired output, constraints, files or links to inspect, and whether North Star should ask before taking actions.

Sign-in gate

Entry route: /app and /login. Status: Live for password signup/sign-in and Cloudflare-backed email link/code sign-in when Email Service is verified and TASKCENTER_AUTH_EMAIL_ENABLED=1. Data source: Cloudflare D1 auth users, credentials, sessions, and email challenges with Cloudflare Turnstile verification on login and signup routes; the public Turnstile site key, email-link/code availability, and first-account bootstrap state are read from /api/auth/config so deployed Worker bindings are visible to the browser while secrets remain server-only. The standalone login page exposes an explicit Create Account mode and defaults to it when production has no verified auth users, so the first production user can complete owner setup instead of attempting to sign in with an email that does not exist yet. Signup starts a pending account and membership for verification, but it does not create a session, grant welcome credits, or count bootstrap as complete until the email link or 6-digit code verifies the address; repeat signup attempts for the same unverified email refresh the pending credentials and resend verification instead of claiming a finished account already exists. Password sign-in and session lookup both reject unverified users. Password credentials use Workers-compatible PBKDF2-SHA256 settings and persist only salted hashes. After successful password or OTP sign-in, the client stores only id/email/name display data in sessionStorage and broadcasts an auth-profile event so the sidebar can show the signed-in account immediately while protected APIs continue to rely on the D1 session cookie. The /api/auth/session payload also exposes a verified profile object with id/email/name/role/organizationId so public chrome can show the account name and a direct Enter action when a real session cookie is already present. Turnstile tokens are treated as single-use: after any auth request consumes or rejects a token, the client resets the widget and clears local token state before retries or next-step email-code verification. Localhost Next.js development can issue a clearly marked local preview session when the D1 binding is unavailable; Cloudflare preview and production still use D1-backed sessions. Email link/code requests create one 10-minute login email containing both a magic link and a 6-digit OTP; overlapping unexpired email codes remain valid so delayed delivery or repeat clicks do not invalidate a code the user just received, and the code entry screen exposes a Send new code recovery action. Forgot-password recovery reuses that same link/code challenge, exposing the code/link only in localhost preview and sending through Cloudflare Email Service in production without revealing whether an account exists. Production fails clearly if Cloudflare email delivery is unavailable or disabled. Required permissions: authenticated workspace actors are required before chat, thread creation, issue control-plane data, or usage data can run, and normal users only read their own assistant threads/messages/events/artifacts by owner_user_id. Empty state: an unauthenticated user can type a prompt, but Taskcenter opens the login panel and keeps the prompt for submission after sign-in; a fresh verified account starts with an empty chat list unless it owns threads. Failure state: protected APIs return authentication_required instead of falling back to anonymous workspace access, Turnstile failures use human-facing retry guidance instead of raw provider error codes, and signup failures are classified into lookup/create/session stages so production logs identify the failing auth boundary.

Review the work

For agentic work, the user should see plan steps, child-agent status, tool calls, sources, artifacts, and durable question/approval cards. The main chat should show user-facing results, task progress, files, ratings, and suggested follow-ups only when they are relevant; internal runtime evidence and raw event-log terms belong in the workbench or retained run inspector, not in the chat transcript. If a run is blocked, the UI should show the blocking reason instead of pretending the task is complete.

Approve changes

Taskcenter's operating model is proposal-first. Risky changes, external delivery, routines, and secrets should use clear approval or connection flows before execution.