Briefs Daily
The reference web client
Briefs Daily is a read-focused Next.js client for viewing items, statuses, and activity history. Work is captured and updated through MCP, while Daily gives people a clear place to review what changed.
What Daily does
Daily is the reference client in client/web/daily. It shows the current item projection and append-only activity history from the Briefs System API. The default workflow is assistant-first: create or update work through MCP, then use Daily to review the result.
The /briefs/new questionnaire is the deliberate human-intake exception. It creates an item through the same System API and activity contract used by the other clients.
A daily driver for durable work
Daily is meant to be the place a person returns to throughout the day. It turns assistant and automation activity into a calm, human-readable work surface: what is open, what changed, what needs attention, and which actor made the change.
The conversation is where work is captured. Daily is where the resulting work is reviewed. That split keeps assistants fast and natural while giving people a stable view that does not disappear when a chat ends.
1. Ask an assistant to capture a task or note.
2. The assistant writes an Item through MCP.
3. Open Daily to review the current work queue.
4. Inspect an item's Activity history when context matters.
5. Ask the assistant to update status or details as work moves forward.Where Daily fits in the repository
Daily is a reference implementation, not a separate product model. It is intentionally thin: the System API owns persistence, @briefs/shared owns the schemas, and MCP owns the assistant-facing write tools.
| Repository area | Responsibility |
|---|---|
| client/web/daily | The daily-driver web experience and auth/session boundary. |
| client/mcp | Assistant-facing tools for creating, updating, and reading work. |
| system | REST API, persistence, actor resolution, and activity history. |
| shared | The Item, Actor, Activity, and input schemas shared by every client. |
Run it locally
From the repository root, start the System API and Daily together:
npm ci
npm run dev:system # API — http://localhost:8001
npm run dev:daily # Daily — http://localhost:3000Copy client/web/daily/.env.example to .env.local in the Daily package. Without OAUTH_ISSUER, a non-production process can use the development identity configured by DEV_USER_ID.
Environment variables
| Variable | Purpose |
|---|---|
| NEXT_PUBLIC_API_URL | System API base URL used by the client. |
| NEXT_PUBLIC_MCP_URL | MCP endpoint shown in the Connect flow. |
| NEXT_PUBLIC_DOCS_URL | Link back to the SDK documentation site. |
| APP_URL | Daily origin used to construct the OAuth callback URL. |
| OAUTH_ISSUER | OAuth/OIDC issuer used for production sign-in. |
| OAUTH_CLIENT_ID | OAuth client registration identifier. |
| SESSION_SECRET | Secret used to sign the Daily session cookie. |
| AUTH_SECRET | Secret required by production authentication flows. |
| DEV_USER_ID | Local development identity when OAuth is disabled. |
Authentication
Production Daily uses OAuth 2.1 with PKCE and an email-capable OAuth provider. The provider decides which email addresses are allowed to authenticate; Daily receives the resulting identity and stores a signed session. Configure the callback as:
https://your-daily-host.example/auth/callbackDaily forwards the session's bearer token to the System API and MCP. When the token is missing or rejected, the client treats the session as unauthenticated and asks the user to sign in again. Production also requires OAUTH_ISSUER, AUTH_SECRET, and a non-default SESSION_SECRET.
How it connects
Server components and actions call the System API. With OAuth enabled, requests use the session bearer token; local development can use the configured development identity instead.
GET /api/v1/items
Authorization: Bearer <access-token>Daily does not need to be hosted for the platform to work. Run it locally, replace it with another client, or use the source as a starting point for a custom web experience.
Customize or replace it
To build another client, keep the contracts stable and choose your own presentation layer. Reuse @briefs/shared for schemas and @briefs/web-shared for UI primitives, then give the new client its own API adapter and environment configuration.
See Build a client for the shared Next.js structure and Quickstart for the complete local setup.