Portal priorities
The client does not need the full consultant operating system. They need only the work that is relevant to them.
Only client-lane tasks should be surfaced as required actions.
Chat belongs to one workspace, not to a universal inbox.
Documents, invoices, and forms show their latest state, with history inside the record thread.
What carries over from the prototype
The portal side keeps the strong product ideas that already made sense.
Consultant drafts, signatures, revisions, and executed copies remain one document thread, not duplicate top-level records.
Chat stays tied to one workspace and should appear alongside activity and task context.
Invoices continue through sent, paid, refunded, and written-off states under one billing thread.
Portal delivery status
This is the first live portal surface while the full invite and OTP layer comes online.
The production portal will only show authenticated client work. It will not inherit the prototype’s demo reset or seeded-state behavior.