scriptoriumadmin/openpetswithchatandmcp
1
0
Fork 0
Code Issues Pull requests 6 Projects Releases Packages Wiki Activity Actions
openpetswithchatandmcp/apps/codemap.md
OpenPets Dev 6ab3bb64d8 feat(rebrand): rename OpenPets to FamiliarOS and pets to familiars 
- Rename all user-facing and technical identifiers from OpenPets/Pet to FamiliarOS/Familiar.
- Rename packages from @open-pets/* to @familiaros/*; rename install-pet/pet-format packages.
- Rename plugin IDs and directories from openpets.* to familiaros.*.
- Rename IPC namespace from openpets:* to familiaros:* and state filenames from openpets-* to familiaros-* with legacy migration.
- Rename source files (pet-window, built-in-pet, default-pet-controller, etc.) to familiar equivalents.
- Update locales (en, es-419, ja, ko, pt-BR, zh-Hans, zh-Hant) and tray/pet context menu strings.
- Add Familiar naming feature: preference, settings input, tray menu display.
- Update assets and packaging config; all desktop tests pass.
2026-06-17 01:42:08 +00:00

2.5 KiB
Raw Blame History

apps/

Responsibility

Container for deployable application packages selected by the pnpm workspace apps/* glob. Currently hosts the FamiliarOS desktop Electron application, which integrates shared packages, local IPC, familiar windows, and desktop plugin support into the user-facing app.

Design Patterns

  • Workspace App Boundary: pnpm-workspace.yaml includes apps/*, so each app directory is an independently buildable workspace package.
  • Workspace Dependencies: apps consume shared packages/ modules through workspace:* dependencies.
  • Electron-First Architecture: the desktop app uses an Electron main process, tray-centric UX, and isolated renderer windows rather than a traditional main window.
  • Service-Oriented Desktop Modules: desktop features are split into main-process services for state, IPC, familiar controllers, catalog installation, setup flows, and plugin management/runtime.
  • Security-First Renderers: CSP headers, sandboxed renderers, context isolation, and disabled nodeIntegration protect UI surfaces including plugin-related windows.

Data & Control Flow

  1. Workspace tooling discovers application packages via the apps/* pnpm workspace glob.
  2. The desktop app bootstraps from apps/desktop/src/main.ts, initializes user data and app state, then creates tray and renderer windows.
  3. Agent commands flow through the local IPC server into lease-managed familiar controllers and window updates.
  4. Familiar assets flow from built-in assets, local development sources, or downloaded catalog packages into installation/state services and renderer windows.
  5. Desktop plugin manifests/configuration flow through plugin loader, package, catalog, state, service, and runtime modules before exposing controlled familiar APIs and plugin UI.

Integration Points

  • Workspace packages: consumes @familiaros/agent-events, @familiaros/claude, @familiaros/cli, @familiaros/cursor, @familiaros/mcp, @familiaros/opencode, and IPC/client-facing shared APIs.
  • Desktop submodules: apps/desktop/src/ provides lifecycle, state, tray/windows, setup integrations, familiar installation, local IPC, and plugin runtime services.
  • External services: GitHub Releases API for update checks, familiaros.dev for catalog data, and zip.familiaros.dev for familiar downloads.
  • System surfaces: Claude Code CLI, OpenCode CLI, OS tray/dock, renderer windows, and filesystem locations such as userData, ~/.codex, and ~/.claude.