Planned

Recurring billing: payment mandates + Stripe subscriptions

ADR 0035, Wave 3 — independently shippable before acceptance v2: - BillingProfile per client: stored payment method / ACH mandate, captured via Stripe on the firm's Connect account (Connect plumbing already built). - Staff can request a payment method from a client without a proposal. - Billing consumes subscription.activated → creates a real Stripe subscription; invoices mirror through the proven webhook path (live-proven test-mode capture, 2026-07-05). - Failed-payment states route to the client billing UI. Depends on: P0 Stripe webhook proof (done). Full invoice detail is a separate card.

claude-agent·about 3 hours ago
Next Up

Messaging: attachments in the composer

The sendMessage API already accepts and authz-checks attachmentIds — verified 2026-07-04 — but neither composer (client or staff) ever sends any, so attachments are dead-ended at the UI. Scope: wire the existing upload pipeline (presign → PUT → finalize → scan) into both composers, attachment chips on messages, download via the scanned/served path. Wave 0 content work per the market-audit decision #5 — runs parallel to launch hardening. Related messaging depth (reopen closed threads, filters/search) is tracked as its own card.

claude-agent·about 3 hours ago
Next Up

Notification email templates (Novu workflows)

In-app notifications are Beta and native; email is fake-backed — Novu is stood up with ZERO workflows and today a send logs failed. Scope: author the 13 per-kind email workflows on Novu using the 21 platform-default email templates shipped in Templates slice 1, prove one real send per kind, and wire per-user notification preferences. Wave 0 content work (market-audit decision #5).

claude-agent·about 3 hours ago
Planned

Proposal acceptance v2: sign + pay in one ceremony

The market audit's biggest competitive move (ADR 0035, Wave 4 — deliberately last because it composes everything below it): Accepting a proposal becomes one ceremony that captures BOTH the e-signature (proposal = engagement letter, rendered from a document template — Wave 2) and a payment method/ACH mandate (Wave 3 BillingProfile), then emits subscription.activated → real Stripe subscription. The engagement moves through a new accepting state and is finalized by the Documenso document.completed webhook, with the signed letter landing as a delivered document (Wave 1). Both vendor paths are now live-proven (Documenso e-sign on prod; Stripe signed webhook). Risk note recorded and accepted 2026-07-05: this widens launch scope; proofs stayed P0 and this build starts only after the waves under it.

claude-agent·about 3 hours ago
Under Review

Household ↔ entity client relationship model

The post-launch flagship differentiator for the client data model (market audit decision #8): model households, business entities, and person↔entity relationships (spouse, dependent, owner-of, officer-of) so one human's portal identity spans their 1040 household and their S-corp. Custom fields + tags shipped at launch as the foundation; an ADR gets written when this is scheduled. Feeds auth-and-tenancy contract addendum.

claude-agent·about 3 hours ago
Planned

Billing: full invoice detail

Owner decision 2026-07-04: launch ships full invoice depth, not the amount/status/pay stub that exists today — line items, due date, invoice number, downloadable PDF, receipt after payment, and failed-payment states. Requires schema + Stripe webhook-mirror work, and the billing contract must be updated to match before implementation. Builds on the live-proven webhook capture.

claude-agent·about 3 hours ago
Under Review

Messaging: inbound email bridge + saved replies

Post-launch milestone (market audit #7 — messaging competes with Liscio): clients reply to notification emails and the reply threads back into portal messaging; staff get saved replies/snippets for common answers. Depends on real outbound email (Novu workflows card) landing first.

claude-agent·about 3 hours ago
Planned

Scheduling: per-firm Cal.com accounts

Decision 2026-07-04; core built same day: tenant_integration_credentials (AES-256-GCM-sealed), per-tenant adapter factory with env fallback, tenant-scoped webhook route with cross-tenant apply fence, connect/disconnect UI with a pre-persist vendor probe. 5-case integration test green. Remaining to close: send the host to Cal.com on event-type create (today the host is never sent — the root cross-tenant leakage finding), tenant-scoped slugs (slugify collisions across firms), connect-flow E2E, and one live per-tenant webhook capture. Also flagged: reschedule UID drift (mirror keeps the original Cal.com UID after reschedule, so a later cancel under the new UID may not resolve).

claude-agent·about 3 hours ago
Under Review

Scheduling: round-robin, multi-host, paid bookings

Post-launch milestone (market audit #7 — scheduling competes with Calendly for teams): round-robin assignment across staff, multi-host events, and paid bookings (Stripe). Builds on the per-firm Cal.com account model shipping at launch.

claude-agent·about 3 hours ago
Planned

Dark mode toggle

Owner decision 2026-07-04: ship a user-facing dark-mode toggle with persistence. The .dark token block already exists in the design system — work is activating it, the toggle UI + persisted preference, and a full dark-mode QA pass across every screen (both portal and staff surfaces).

claude-agent·about 3 hours ago
Planned

Embedded custom-app extension point

Decision 2026-07-04: launch scope. The iframe + auth-handshake extension framework per docs/architecture/iframe-modules.md — approved external apps embed inside the portal shell with tenant-scoped auth handoff. The framework ships at launch; specific embedded apps remain per-approval post-launch (explicitly excluded from scope creep).

claude-agent·about 3 hours ago
Under Review

E-sign: KBA + IRS 8879 path

First named post-launch e-sign milestone (market audit #3): knowledge-based authentication on Documenso so firms can collect IRS 8879 e-file authorizations compliantly. Launch e-sign is engagement letters only (no KBA) — this unlocks the tax-season workflow that actually differentiates a CPA portal. Also in this lane: real SMTP for signer mail and the document-signing certificate (pre-external-signers ops items).

claude-agent·about 3 hours ago
Next Up

Firm→client document delivery

Staff deliver documents TO clients — the reverse of today's request/upload flow. Unblocks returns delivery, e-sign template sends, and title-only sends (V2/F001; market-audit decision #4, ADR-adjacent contract section already Planned in documents.contract.md). Depends on the S3 + ClamAV pipeline, which is now live-proven (clean + EICAR quarantine drills on prod, 2026-07-05). Wave 1. Feeds Templates slice 2 (engagement letters render → delivered document) and acceptance v2 (signed artifact lands as a delivered document).

claude-agent·about 3 hours ago
Planned

Templates slice 2: engagement-letter / document templates (HTML→PDF)

Document kind on the shared Templates surface (ADR 0036): author engagement letters as rich HTML with merge fields, render to PDF server-side, publish through firm→client delivery (Wave 1 dependency). This is the letter-rendering leg of acceptance v2 — the proposal a client signs IS the engagement letter rendered from one of these templates. Wave 2.

claude-agent·about 3 hours ago
Planned

Templates slice 3: form templates + CPA starter pack

Form kind on the shared Templates surface: staff instantiate forms from templates instead of building each from scratch, plus a curated CPA starter pack (organizers, engagement checklists, common intake). Needs only slice-1 plumbing. Wave 2. (P2 backlog also names drag-and-drop builder polish and CPA form templates — this card is where that lands.)

claude-agent·about 3 hours ago
In Progress

Engagements: proposals → agreements module

The engagements module (proposals, acceptance, agreements) — slices 1–2 implemented with the engagements-lifecycle E2E green in CI; contract still Draft (approval tracked under launch hardening). Acceptance v2 (sign + pay ceremony) is its own Planned card and lands on this module. Remaining in-module: lifecycle polish and the accepting state machinery that acceptance v2 introduces.

claude-agent·about 2 hours ago
Planned

Tasks: source filter + comments

Remaining tasks-module depth from the P1 list: filter the staff queue by task source (manual / automation / template), and a comments model on tasks so staff↔client discussion lives on the task instead of messaging. Detail routes, assignment UI, my-work/overdue/client filters shipped 2026-06-29/30; the tasks journey E2E is tracked under launch hardening.

claude-agent·about 2 hours ago
Planned

Messaging: reopen, filters, search

Messaging depth beyond attachments (separate Next Up card): reopen closed conversations, filter/search across threads, and thread-state management for staff. Error boundaries + unread-count helper landed 2026-07-04. The launch-scope entry calls messaging "Partial" until these land.

claude-agent·about 2 hours ago
Open

E-sign templates + field placement (make signatures usable)

From Daniel's walkthrough: signatures are confusing on both firm and client side — how do you set up templates, create a document to sign, and add fields to fill? What exists today (works, but bare): staff pick a client + a PDF (existing doc or upload), tick the signer contacts, hit Send; Documenso auto-places ONE signature field on page 1 per signer; the client gets a hosted Documenso signing link from the portal. What's missing (this slice): (1) reusable templates — save a document + its field layout once, reuse per client; (2) a field-placement UI — drag signature/date/initials/text fields onto pages, per signer; (3) signing-order and role controls. Documenso has template + field APIs we can drive from our staff UI, keeping the client experience native. Also fixes to fold in: the embedded-signing completion listener still listens for DocuSeal postMessages (latent bug), and signing mode is hard-coded to hosted.

claude-agent·about 2 hours ago
Open

Meeting booking: stand up Cal.com + firm setup flow

From Daniel's walkthrough: "No way to book a meeting." The booking journey is fully built in the product (client: browse meeting types, pick a slot, confirm, reschedule/cancel, add-to-calendar; staff: create appointment types, admin connects the vendor). It looks missing because no scheduling vendor is connected: there is no Cal.com instance deployed and the firm has no appointment types, so the client page shows the "Your firm hasn't set up bookable meeting types yet" empty state. To make it real: deploy self-hosted Cal.com (runbook docs/runbooks/calcom-selfhost.md, or Cal.com cloud per calcom-cloud.md), connect it in /staff/admin/settings, create 1-2 appointment types in /staff/scheduling. Then the client "book a slot" journey lights up end to end.

claude-agent·about 2 hours ago