Content outline

This page is the working outline for the VENV shell. It describes what each surface needs to communicate before the final data model, automations and permissions are connected.

Website

Home

• Explain what VENV is and why the shell exists.
• Show the relationship between marketing site, docs, release notes and dashboard.
• Give visitors a fast next step into docs or the login.

Pricing

• Show the expected packaging logic.
• Frame what changes between tiers, even if final pricing is not approved.
• Capture the questions commercial and product still need to answer.

Docs

• Explain repository setup, ownership and content boundaries.
• Act as the source of truth for how the shell should evolve.
• Separate framing decisions from backend implementation details.

Release notes

• Reflect product changes in clear, dated release notes.
• Keep product communication factual and dated.
• Serve as the public log of what changed and why it matters.

Auth

• Set expectations for access and onboarding.
• Be explicit when flows are still demo-only.
• Point users toward the dashboard shell without implying production auth is finished.

Dashboard

Overview

• Explain what the workspace is meant to monitor.
• Frame metrics and charts as placeholders for future API-backed signals.
• Link users into the main operational areas.

Inbox

• Represent incoming work, review items and operational follow-up.
• Clarify that items are sample records until the live event model is connected.
• Provide a clear empty state and reply/action framing.

Accounts

• Represent the eventual record list for customers, contacts or workspaces.
• Explain filters, actions and ownership without claiming the fixture data is real.
• Reserve room for future API-backed tables and detail panels.

Settings

• Explain where profile, team, notification and security decisions live.
• Make governance visible before permission logic is finalized.
• Keep copy practical and operational rather than generic template text.

What stays intentionally provisional

• Live metrics and KPIs
• Final pricing, legal language and SLA promises
• Auth and permission enforcement
• API object names that are not stable yet
• Support workflows that still depend on backend implementation