Org Implementation Checklist

Purpose

This file is now a status-based handoff for the shipped org client-work slice.

Use it to see:

• which org routes are already live
• which ones are still partial
• what the next implementation order should be

Global Reality

• every current org client-work route resolves the active org viewer first
• every current client-work query/mutation applies client scope through org/clientScope.ts
• owners have global client visibility
• non-owners only see clients linked by active clientAccessAssignments
• billing is the only current client-work area fully tied into the broader org capability model

Route Status

org/(dashboard)/overview

Status: live.

What exists:

• real operations dashboard summary backed by the workspace summary surface
• organization and subscription summary
• portal and settings quick links
• scoped attention metrics across the current org workspace

What is missing:

• analytics drill-in for trends, finance reporting, and longer-horizon operational questions

org/(dashboard)/customers

Status: live.

What exists:

• visible client-account list
• create client-account flow
• inline client-account editing
• primary-contact portal provisioning anchored to the client account and canonical primary person when portal access is enabled
• owner-only staff assignment management per client account
• visible assigned-member summaries

Current access rules:

• any active org member can load the page
• owners see all client accounts in the org
• non-owners only see assigned client accounts
• owner, admin, and account_manager can create and edit client accounts
• only owner can manage client-access assignments

What is still missing:

• the multi-company portal access grant model that allows one portal identity to hold parallel company access inside one agency organization
• portal-side self-service people management

org/(dashboard)/customers/[clientId]

Status: live.

What exists:

• client account summary and profile editing
• tabbed information architecture across overview, people, projects, files, billing, and activity
• first-class create/edit workflows for client contacts
• person-level portal access state and role now surfaced directly in the People tab
• assigned staff visibility and assignment management
• contacts, projects, documents, customer billing, invoices, subscriptions, and recent activity in one workspace

What is still missing:

• the multi-company portal grant rollout that replaces the current one-company-per-portal-membership assumption
• portal-side self-service people workflow
• further polish where summary, relationship management, delivery, files, and finance workflows still need tightening

It is now the control center for:

• client account summary
• clientContacts
• assigned staff
• project snapshot
• time snapshot
• billing snapshot
• document snapshot

org/(dashboard)/projects

Status: live.

What exists:

• project list across visible client accounts
• create project flow
• visibility, status, summary, and target-date display

Current access rules:

• any active org member can load the page inside their client scope
• owner, admin, and account_manager can create projects

What is still missing:

• remaining list polish and parity work where needed

org/(dashboard)/projects/[projectId]

Status: live.

What exists:

• project detail workspace
• surfaced projectUpdates
• draft versus published update workflow

What is still missing:

• only the next layer of workflow depth after the current org list and detail consistency pass

org/(dashboard)/time

Status: live.

What exists:

• timer and entries modes in one route
• recent time-entry list
• own time-entry creation
• optional project linking
• billable flag and approval state capture
• grouped dense entries review with detail drill-in

Current access rules:

• any active org member can load visible time entries inside their client scope
• any active org member can create their own draft time entries inside that scope

What is still missing:

• edit and correction workflow

org/(dashboard)/time/[timeEntryId]

Status: live.

What exists:

• read-only time-entry detail route
• metrics, metadata, and summary context for a single entry

What is still missing:

• only the next layer of edit and correction workflow if the product needs it

org/(dashboard)/billing

Status: live and capability-gated.

What exists:

• grouped invoice and subscription collections with Stripe connection health and attention state
• Stripe-backed invoice and subscription authoring from the org billing workspace
• inline customer creation/provisioning during invoice authoring
• invoice record list with detail drill-in
• subscription record list with detail drill-in

Current access rules:

• billing route access depends on the existing org billing capability set
• client scope still applies after billing access is granted

What is still missing:

• richer invoice line-item/detail visibility
• post-send invoice lifecycle depth such as revisions, credits, or refunds when those product phases land
• richer subscription timeline/history visibility
• billing reporting and analytics depth

What now exists in the backend foundation:

• agency Stripe connection setup, reconnect, and onboarding health via the client-billing Stripe connection surfaces
• Stripe webhook sync for agency connection state, invoices, and subscriptions
• hosted billing portal launchers tied to real Stripe customer mappings

Billing Profile Route Policy

Status: intentionally removed.

Current rule:

• there is no longer a dedicated user-facing billing-profile detail route
• internal billing mappings stay behind the client account plus invoice/subscription routes

org/(dashboard)/billing/invoices/[invoiceRecordId]

Status: live.

What exists:

• invoice detail route
• hosted invoice and PDF actions

What is still missing:

• richer finance workflow beyond visibility and outbound actions

org/(dashboard)/billing/subscriptions/[subscriptionRecordId]

Status: live.

What exists:

• subscription detail route

What is still missing:

• richer subscription operations beyond visibility

org/(dashboard)/documents

Status: live.

What exists:

• recent document list
• storage-backed upload flow
• client-visible versus internal visibility capture
• optional project linkage

Current access rules:

• any active org member can load visible documents inside their client scope
• any active org member can upload documents inside that scope

What is still missing:

• document detail workflows
• richer metadata edits
• file request flows

org/(dashboard)/analytics

Status: missing.

This is the next reporting route the org workspace needs.

It should be the drill-in surface for:

• delivery health trends
• utilization and billable time mix
• revenue, invoice, and subscription trend lines
• receivables and billing attention
• top clients, projects, and operational exceptions worth attention

It should sit in the org sidebar as a real route, not as extra clutter pushed into overview.

Current Slice Summary

Complete enough to call live:

• customers
• customers/[clientId]
• projects
• projects/[projectId]
• time
• time/[timeEntryId]
• billing
• billing/invoices/[invoiceRecordId]
• billing/subscriptions/[subscriptionRecordId]
• documents
• overview

Partial or legacy:

• none of the current org client-work routes are still placeholder-only

Missing and still required to finish the phase:

• analytics

Next Build Order

1. list polish and interaction consistency across the rebuilt org collections
2. row-level quick actions across the org collections
3. tabbed IA where the detail pages have outgrown a single stacked layout
4. analytics
5. clientContacts management inside customers/[clientId]
6. deeper billing and document operations on top of the current detail routes
7. portal parity for published updates, shared documents, and billing snapshots

Acceptance Rule

Do not call the org client-work phase complete until:

• the existing schema-only tables (clientContacts, projectUpdates) are surfaced in the app
• the org workspace has a real analytics drill-in route for business and finance reporting
• the major org routes have consistent list and detail interaction patterns
• client-access scope remains consistent across those detail routes
• the portal starts consuming the same relationship data instead of remaining only an account/support shell