Перейти к содержанию

Business Specification

Purpose

This document captures what the business expects from SmartKitten: goals, boundaries, and acceptance criteria. It is the reference for product, engineering, and customer-facing teams.

Business goals

ID Goal Success indicator
G1 Enable org-scoped AI productivity Users complete chat sessions within quota; MCP tools used for documents
G2 Integrate reMarkable into daily work Notes/screenshots available in cloud within minutes of capture
G3 Support on-premise edge sync Stations execute sync commands reliably without manual VPS SSH
G4 Monetize via subscriptions Plans map to enforceable limits (tokens, devices, vision, tablet minutes)
G5 Maintain operational visibility Health endpoints, metrics (Prometheus/Grafana), deployable per environment

In scope (MVP+)

  • User registration, login, email verification, password reset
  • Organisation create / join (tagline), membership, supervisor hierarchy, audit log
  • Subscription plans, entitlements, quota state, spending ledger for AI tokens
  • AI chat (OpenAI, Gemini), sessions, OCR, image generation, rate limits by plan
  • Document storage (KittenSafe paths), versions, MCP tool surface
  • Stations, devices, assignments, device status, screenshots, tablet control proxy
  • reMarkable upload, conversion, station sync, extract / insert / restore commands
  • Collaborative boards (projects, notes, sessions, presence)
  • React frontend: admin (stations/devices), playground, profile, org settings
  • Deployment via Docker + Nginx (dev / stage / prod)

Out of scope (explicit non-goals)

Item Rationale
Non-reMarkable tablets (initially) Product focus is graphical e-ink workflow proven on reMarkable
Public SaaS marketplace B2B private / org deployments first
Full billing PSP integration in docs Webhooks exist; provider specifics are implementation detail
End-user mobile native apps Web SPA is the primary client
Automatic translation of user content Platform UI can be localized; user documents are author-language

Business rules

  1. Tenancy — A user's primary context is their organisation; device and station resources belong to org_id.
  2. Authorization — JWT carries sub, org, role; services reject cross-org access.
  3. Quota enforcement — AI and device-heavy actions consult billing/spending before or after operation (per service design).
  4. Station trust — Stations are registered by org admins; sync commands are queued and acknowledged, not ad-hoc public upload.
  5. Data residency — Deployed on customer-controlled VPS; business assumes customer manages network and backup policy.

Acceptance criteria (platform level)

  • New user can register, verify email, join or create organisation, and reach the main workspace.
  • Org admin can create a station, register a device, and assign it to a member.
  • Member can start an AI chat session; token usage decreases balance; session persists across visits.
  • Latest tablet screenshot is retrievable via MCP device.get_latest_screenshot when device is assigned and data exists.
  • Station can poll pending sync command and complete extract or insert flow without data loss (per command contract).
  • Subscription change updates entitlements visible on user profile and enforced on next quota-checked action.
  • Documentation (this site) is available in English and Russian for business sections.

Dependencies between domains

flowchart TD
  Account[Account] --> Org[Organization]
  Account --> Billing[Billing]
  Billing --> Spending[Spending]
  Billing --> Chat[AI_Chat]
  Billing --> Device[Device]
  Org --> Device
  Device --> Remarkable[Remarkable]
  Chat --> Document[Document_MCP]
  Document --> Remarkable
  FE[Frontend] --> Account
  FE --> Chat
  FE --> Device
  FE --> Remarkable

Open questions (for business review)

  • Default language of org onboarding materials?
  • Which plan tiers are sold vs internal-only (enterprise)?
  • SLA targets for station offline detection?
  • Retention policy for screenshots and .rm artifacts?