This library tracks the core product surfaces, the ownership model behind them, and the upgrade work required to keep the logic orderly enough to document once and trust later.
8
Docs
3 published
72/100
Average orderliness
5 reviewed
4
Upgrade watchlist
Needs cleanup
0
Deprecated
Should be retired
Organized by user goal, not by code module.
8 docs
First-run setup, account readiness, and activation.
Turn a blank workspace into a functioning support system with one canonical path for onboarding.
Document the roles, ownership boundaries, and access model that keep support work orderly.
Install, brand, and control the public entry point.
Show how the public entry point is installed, branded, and configured without implying hidden defaults.
Inbox triage, assignment, and collision handling.
Define the canonical path for conversation handling, ownership, and handoff in the inbox.
Ticket intake, routing, SLA, and escalation.
Keep ticket creation authoritative, validated, and tied to the same operational model as the inbox.
Agent configuration, knowledge grounding, and handoff rules.
Document how the AI agent is grounded, when it should escalate, and what support data it can trust.
Publish permanent docs with screenshots and ownership.
A permanent docs system for the whole product, with owners, review gates, and real visual proof.
Teams, integrations, and operational controls.
Explain the operational settings that shape how the rest of the product behaves.
These docs should be tightened first because the logic is still evolving or the flow needs cleanup.
Help center authoring and screenshot rules
Documentation
Orderliness
58/100
AI agent configuration and escalation
AI Platform
Orderliness
61/100
Ticket intake and SLA
Support Operations
Orderliness
66/100
Inbox triage and routing
Support Engineering
Orderliness
68/100
Permanent docs should be ordered, owned, and tied to the real product behavior.
Every doc needs an owner and a source of truth.
Every public doc needs a review date and status.
Screenshots should come from real UI when the route exists.
Low-orderliness flows should be upgraded before they are documented as final.
Each doc lists the routes that should be captured with Playwright so the docs stay visually truthful.
2 capture targets
Onboarding checklist
Capture the activation path.
/dashboard/onboardingTeam invite
Show how the org becomes usable.
/dashboard/settings/team2 capture targets
Roles page
Show owner/admin boundaries.
/dashboard/settings/teamInvite flow
Capture the onboarding handoff.
/dashboard/settings/team2 capture targets
Widget settings
Capture installation and launcher config.
/dashboard/settings/widgetWidget preview
Capture the branded entry point.
/dashboard/settings/widget2 capture targets
Inbox list
Capture triage state and filters.
/dashboard/conversationsConversation detail
Capture assignment and internal notes.
/dashboard/conversations2 capture targets
Ticket list
Capture filters and SLA indicators.
/dashboard/ticketsCreate ticket
Capture intake and validation paths.
/dashboard/tickets2 capture targets
AI settings
Capture grounding and handoff controls.
/dashboard/settings/aiKnowledge base
Capture the source of truth used by AI.
/dashboard/knowledge-basePublish changes only after the feature logic is understandable enough to describe once. If the doc feels messy, the feature probably is too.