active-priority
Billing Foundation Follow-up
- Stripe client billing foundation is now structurally in place across backend config, Connect callback handling, webhook ingestion, customer mapping, and org billing route scaffolding.
- The first invoice/subscription operations slice is now live in the org billing workspace and client billing surfaces, including invoice draft/finalize/send/void, subscription create/update/cancel/reactivate actions, and shared catalog-backed line-item selection.
- Commercial provenance is now live on quote, invoice, subscription, and contract detail surfaces, the client overview now exposes cross-track next actions anchored on the client account, and subscription detail now includes derived plan-history and billing-timeline views.
- Immediate next work for billing should focus on reporting, analytics, and remaining operational polish on top of the now-live provider-backed Stripe layer, including post-send invoice lifecycle depth and any remaining catalog synchronization edge cases.
- Keep Polar SaaS billing work separate from this org-operated Stripe client billing track.
Active Priority
Current Phase
The client-work foundation baton has moved past basic org and portal scaffolding. The repo now has live org operations, org project delivery, and portal client-work visibility, so the phase is about finishing the remaining operational detail and cleanup work.
Core Logic Guardrails
Before adding another product area, keep the system anchored to these rules:
clientAccountremains the company-level anchor for delivery, billing, drive, contracts, quotes, and portal accessclientContactremains the company-local human record; portal identity stays an access layer, not a second client directory- commercial records (
invoiceRecords,quoteRecords,subscriptionRecords,contracts) must extend the client account's billing and legal/commercial context instead of forming parallel relationship models; contracts own their own workflow, content, and attachments and must not collapse back into the Drive feature - the portal remains a client-facing projection of org truth plus explicit shared-collaboration records; do not invent portal-only business records that bypass the org model
overviewremains the operational snapshot andanalyticsbecomes the reporting drill-in; do not collapse both jobs into one page
What Is Complete In This Phase
- the first client-work schema and seed data are in the backend
- org client accounts are live through the
clientsroute - org client detail is live through
clients/[clientId] - org project detail is live through
projects/[projectId] - org detail-route IA now uses real subpaths for
clients/[clientId]/*andprojects/[projectId]/*instead of query-param tabs - org time and commercial queues now use real page paths for job switches:
timevstime/timerandinvoicesvssubscriptions - org sidebar billing navigation now lands on explicit
InvoicesandSubscriptionsentries instead of a singleBillingcollection entry - org time now treats
Entriesas the sidebar workspace and keepsTimeras a utility route and shell action instead of a second sidebar destination - org invoices now use the secondary bar for fixed status queues while keeping search and client filters local to the billing collection toolbar
- org entries now use the secondary bar for approval queues while keeping search local to the entries collection toolbar
- org entries now use a dense table plus inline approval dropdowns instead of drag-and-drop approval lanes
- org clients now use a true hybrid split: list mode is the default dense table with assigned-member summaries and local status filtering, while organize mode is the search-driven drag-and-drop board without a conflicting status filter
- org portals now use their own queue-switched operational workspace, separate from clients, for per-client portal access and workspace management
- org shell search now uses a deliberate split: the launchpad remains the quick command surface, and the topbar Spotlight modal now handles paged operational search with type filters and broader entity coverage
- client create/edit now seeds the primary person's portal access from the canonical client-account record when portal access is enabled
- client
Peoplenow acts as the canonical company people list, with per-person portal access state and role shown directly in the org workspace - the org portals workspace now derives live/unlinked/attention state from the unified portal-access summary on each client account instead of a separate primary-contact heuristic
- the org collection taxonomy is now explicit in
docs/app/development/org-workspace-collection-ux.md: queue-switched record lists, hybrid list/organize collections, and pure record lists each have different secondary-bar, toolbar, and drag-and-drop rules - the client drive source-of-truth is now explicit in
docs/app/product/client-drive-spec.mdanddocs/app/development/client-drive-implementation-plan.md - first-class client-contact create/edit workflows are live in the client detail workspace
- org project updates now support draft and published states in the app
- scoped client visibility is live through
clientAccessAssignments - org projects, time, billing, and the current drive-finder route are live
- org time-to-billing rollups now derive client billing state from tracked work, invoices, and subscriptions
- the org
overviewroute is now a real operations dashboard backed by the workspace summary surface - the org collection-shell baseline is now in place across the rebuilt record-heavy workspace routes
- org time-entry detail is live through
time/[timeEntryId] - org billing detail is live through the client billing tab plus
invoices/[invoiceRecordId],subscriptions/[subscriptionRecordId], andquotes/[quoteRecordId] - Stripe-backed invoice and subscription write flows are now live from the org billing workspace, client billing tab entry points, and detail routes
- commercial provenance blocks are now live across quote, invoice, subscription, and contract detail so cross-record follow-through is explicit without inventing fake ownership
- quote and contract surfaces now exist as client-account-scoped commercial artifacts and should remain attached to the same commercial/legal spine
- client records now own rich billing identity/defaults, including Stripe customer sync inputs and invoice rendering template defaults
- the client overview now acts as a real operating hub with state-based next actions across access, commercial, delivery, and collaboration
- the portal has real authenticated client-work routes for overview, projects, billing, files, activity, settings, and support
- portal project drill-in is live through
projects/[projectId] - the backend drive migration is now cut over to
driveItems,fileAssets, andrichDocuments; the legacydocumentstable is no longer part of the live collaboration model - portal session and workspace runtime are now grant-aware through
portalAccessGrants, so one portal identity can hold multiple client-company grants inside the same agency organization
What Is Still Missing In This Phase
- remaining collaboration closeout decisions on top of the now-landed portal request inbox, response submission flow, acknowledgment step, and richer destination metadata
- richer time reporting and manager workflow polish on top of the now-landed approval and lock baseline
- smaller operational polish and residue cleanup after package-wide validation was restored
Immediate Goal
Finish the language, IA, and cross-feature coherence pass inside the existing org and portal client-work slice without reopening the rest of the product model.
The next work should keep the client-first model intact, build on the now-landed portal self-service people and time-lock slices, and deepen collaboration metadata plus reporting polish without reopening the corrected commercial and collaboration model.
The Stripe authoring baseline is now present, so the next billing work should stay on time-to-billing workflow depth and customer-surface coherence instead of reopening the provider foundation.
Use docs/app/development/agency-owner-smart-workflows.md as the source of truth for anticipatory UX and cross-track follow-through during this polish pass.
The client and portal model is now explicit and should remain the source of truth:
clientAccountis the company-level client recordclientContactis a human inside that company- portal access is a capability and lifecycle state on that person, not a second parallel identity model in org UI
portalUseris the org-scoped portal identity for that personportalAccessGrantis the company-specific grant that links that identity to one client company and one company-local person record- the org
Peopletab is the canonical company-level person management surface - the org
Portalsworkspace is the cross-client operational view over that same underlying access model
Use org-workspace-completion-milestone.md as the move-on gate for this baton.
Fundamental Logic Hardening Pass
Before any broader product expansion, run this pass in order and treat each slice as a completion gate.
-
Access and permissions coherence. Done means org-side visibility, role policy, and billing visibility rules read as one system instead of scattered feature-by-feature exceptions. Status: landed. See
docs/app/planning/fundamental-logic-hardening-audit.md. -
Portal grant-model coherence. Done means portal and org people/access flows use
portalAccessGrantsas the only company-access mental model and stop depending on older single-company assumptions. Status: landed. Seedocs/app/planning/fundamental-logic-hardening-audit.md. -
Stripe truth versus app truth discipline. Done means billing flows, analytics, exports, and UI copy keep Stripe as finance truth while app-side billing records stay operational projections with client-account context. Status: landed. See
docs/app/planning/fundamental-logic-hardening-audit.md. -
Collaboration closure rules. Done means the request lifecycle has an explicit lightweight definition of review, acknowledgment, and close without reopening heavy approval workflow design. Status: landed. See
docs/app/planning/fundamental-logic-hardening-audit.md. -
Cross-feature ownership audit. Done means each major surface still points back to client account as the anchor and no track starts pretending to own another track's records. Status: landed. See
docs/app/planning/fundamental-logic-hardening-audit.md.
Rule for this pass: do not add a new product area while one of these five slices is still logically unresolved.
Current Baton
- Land the next anticipatory UX slice from
docs/app/development/agency-owner-smart-workflows.md, starting with actionable spotlight rows and timer-stop follow-through where it still sharpens cross-track handoff. - Close the remaining collaboration lifecycle polish on top of the request inbox, response submission, acknowledgment, destination metadata, and the now-landed scoped external upload-link baseline across both org and portal creation surfaces.
- Deepen time reporting on top of the now-landed approval and lock workflow without making the entries workspace heavier.
- Keep trimming remaining legacy-presentation and registered-surface naming carryover only where it reduces future ownership drift without reopening the model.
Sequencing Rule
Do not start a second wave of new tables before the current first-wave tables are actually used in the app.
Specifically:
- use
clientContactsbefore inventing another contact model - use
projectUpdatesbefore inventing a second project activity model - use the current billing records before adding parallel digest tables for convenience
- do not add a second parallel file model beside the planned drive tables
Out Of Scope Until This Baton Clears
- a second wave of time workspace complexity beyond the current approval-plus-lock baseline
- complex drive approval workflows beyond the lightweight request layer
- general public browsing of client drive folders
- the post-baton operator layer for shell-level
Notesand the sidebarTodayworkspace defined indocs/app/product/notes-and-today-spec.md - platform multi-agency operations