openpetswithchatandmcp/docs/plan/FAMILIAROS_PRODUCT_ROADMAP_2026-06-17.md

FamiliarOS Product Roadmap

Date: 2026-06-17 Status: active working roadmap

Purpose

This roadmap starts where the rebrand plan stops.

The rebrand work established FamiliarOS as the product identity. This document defines the next product-shaping lanes across:

• website and account surfaces
• desktop control center polish
• motion, loading, and animation language
• consolidation of canonical code surfaces
• codebase hardening across website, desktop, packages, and plugin/runtime

Canonical surface note

Current product truth is split across two live surfaces:

• product repo: /home/dev/src/FamiliarOS
• canonical website app: /home/dev/src/FamiliarOS/website

The previous redundant parallel surfaces were backed up into:

• /home/dev/VPSM/familiaros-parallel-surface-backups/2026-06-18T002123Z

and then removed from the active workspace:

• /home/dev/src/_archived_FamiliarOSWebsite_2026-06-17
• /home/dev/src/openpets-clean
• /home/dev/src/VectorShell/websites/familiaros

Operational rule:

• new FamiliarOS website product work goes into FamiliarOS/website
• backup archives, not sibling live folders, are now the rollback lane for the removed parallel surfaces

Priority lanes

1. Canonical surface consolidation

Goal:

• eliminate ambiguity about where the real FamiliarOS website and account stack live

Planned work:

• finish replacing stale inherited website docs and brand copy
• add explicit archival notes to non-canonical FamiliarOS site roots
• remove or quarantine leftover cross-product language that still reads like a different app family
• document deployment, auth, and route ownership from the monorepo root
• retain the Scriptorium-derived workflow pack locally in FamiliarOS so future repo-custody, clean-room, and closeout work does not depend on donor repo memory
• establish FamiliarOS-local .gitnexus/ and .sentrux/ scaffolds rather than treating donor analysis state as current product truth

2. Website foundation and conversion path

Goal:

• make familiar-os.com feel like the true front door for download, accounts, subscriptions, trust, and docs

Planned work:

• tighten homepage storytelling around companion, memory, voice, and tools
• finish clean auth and account entry paths
• align pricing, register, login, support, and docs routes with real product expectations
• add clear download/install flows for desktop builds
• connect marketing CTA copy to actual user outcomes instead of generic SaaS phrasing

3. Accounts, subscriptions, and backend readiness

Goal:

• prepare FamiliarOS for real paid plans and account lifecycle flows

Planned work:

• finalize auth domain split and session behavior
• define plan/role model for Free, Companion, and Agent
• wire billing-ready product states without faking purchase completion
• define onboarding after account creation: download, connect provider, create Familiar, enable memory, enable tools

4. Motion, video, and loading language

Goal:

• define one coherent FamiliarOS motion system across website, control center, and desktop surfaces

Immediate design decision lanes:

• choose a canonical loading spinner family instead of letting per-surface spinners drift
• define when FamiliarOS uses:
  • skeletons
  • spinners
  • progress bars
  • idle ambient motion
  • status-badge motion

Requested later-slice goals:

• website hero background video system
  • use only when it strengthens the companion fantasy
  • ship with reduced-motion fallback and static poster fallback
  • keep CPU/network weight bounded
• spinner standardization pass
  • website public loaders
  • auth/account flows
  • desktop control center loaders
  • plugin/update/install busy states
  • MCP preview/test states
  • familiar status badges where spin implies active thought or waiting

Recommended motion direction:

• keep the product calm, alive, and companion-like
• prefer intentional ambient motion over constant dashboard noise
• use reduced-motion-safe defaults everywhere

5. Desktop control center polish

Goal:

• make the control center feel as alive and premium as the companion concept

Near-term candidates:

• consistent loading-state semantics across Dashboard, Familiars, Integrations, Plugins, and Settings
• richer success/error/working feedback for long-running actions
• better installation/update progress affordances for familiars and plugins
• stronger route transition polish without adding latency or visual clutter

Recommended later animation ideas:

• soft route-to-route panel dissolve with slight depth shift
• familiar-preview idle shimmer or pulse on selection changes
• memory-save confirmation ripple instead of generic toast-only feedback
• MCP tool activity rail that animates only while work is active
• plugin install/update progress trail with bounded, non-blocking motion
• voice test waveform pulse during playback/listen-ready states

6. Companion-side delight surfaces

Goal:

• extend FamiliarOS beyond utilitarian chat into a living companion system

Recommended later animation ideas:

• desktop familiar anticipation animation before a spoken response
• tiny memory-capture sparkle or badge pulse after a saved memory event
• contextual mood or energy transitions that feel readable, not noisy
• onboarding reveal moments when the Familiar is first named or first speaks

7. First-party familiar asset and IP-safe catalog program

Goal:

• move FamiliarOS toward first-party familiar ownership instead of relying on ambiguous legacy pack rights

Planned work:

• treat inherited OpenPets familiar packs as replace-or-verify, not blanket redistributable first-party assets
• create or commission a first-party FamiliarOS familiar starter set with complete animation coverage
• keep temporary/dev fixture familiars neutral and clearly first-party-safe
• document pack-by-pack verification rules when exceptions are justified

8. Full codebase hardening program

Goal:

• parse the full product codebase end-to-end and reduce risk before broader feature expansion

Audit sequence:

1. website public routes, auth, loaders, and deployment assumptions
2. desktop renderer and preload bridge surfaces
3. Electron main-process security and IPC boundaries
4. plugin runtime, panel sandboxing, storage, network, and permissions
5. package-level integration surfaces (client, mcp, cli, cursor, opencode, pi)
6. docs/runbooks that still risk sending work to stale surfaces

Hardening themes:

• stale-brand and stale-surface removal
• accessibility and reduced-motion compliance
• busy-state consistency
• bridge/API naming cleanup where safe
• FamiliarOS-local analyzer regeneration with the Scriptorium-root GitNexus workflow and FamiliarOS-specific Sentrux rules
• CSP and sandbox posture verification
• dependency/update pressure review
• test-gap identification and patching

Suggested next packet order

Recommended immediate sequence:

1. canonical website/docs cleanup
2. public-site copy and loader consistency pass
3. control-center loading-state polish and spinner unification
4. auth/account readiness packet
5. first-party familiar asset and rights packet
6. website background video design packet
7. broader codebase hardening audit packets

Explicitly not immediate unless requested

These are good roadmap goals but should not displace the foundation packet above unless the user reprioritizes them:

• full background video implementation
• large motion-system rollout across every surface at once
• deep restyling of all control-center routes in one pass
• broad package/runtime refactors before the surface map is stabilized