scriptoriumadmin/openpetswithchatandmcp
1
0
Fork 0
Code Issues Pull requests 6 Projects Releases Packages Wiki Activity Actions
openpetswithchatandmcp/AGENTS.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

4.3 KiB
Raw Blame History

Repository Map

A full codemap is available at codemap.md in the project root.

Before working on any task, read codemap.md to understand:

  • Project architecture and entry points
  • Directory responsibilities and design patterns
  • Data flow and integration points between modules

For deep work on a specific folder, also read that folder's codemap.md.

Catalog Direction

Catalog v2 is legacy and exists only for old app versions/fallback compatibility. For new work, migrations, and Control Center UI, do not optimize for v2 behavior. Use catalog v3 (thumbnail, spritesheet, paginated pages, and search index) as the source of truth.

Forward-Only Product Direction

Move the current app forward; do not keep legacy compatibility code, duplicate paths, stale shims, or old behavior in current runtime code unless it is required so older released app versions can still open/use versioned catalogs or existing published data. Prefer clean migrations, versioned catalog/data boundaries, and removing obsolete code over preserving backwards-compatible branches. The bar is: old app versions should not break catastrophically, but the current app should not carry legacy bloat for deprecated plugin/catalog behavior.

Plugin Docs

Before changing plugin platform code, official plugins, plugin catalog generation, plugin packaging, plugin runtime behavior, or plugin-facing UI, read:

  • docs/plugins.md for the current plugin platform architecture, manifest/runtime rules, local development workflow, publishing commands, and troubleshooting notes.
  • docs/superplugins.md for the companion-first plugin direction, planned official plugin lineup, bundling defaults, and right-click plugin action strategy.

When plugin work is finished, update these docs if behavior, commands, manifests, plugin IDs, default bundled/enabled status, catalog workflow, permissions, or the planned plugin lineup changed. Do not leave plugin docs stale after implementation.

Logging for Fast DX

When working on desktop UI, renderer, IPC, catalog, plugin, or familiar-window behavior, add targeted logging as part of the implementation when it helps diagnose issues quickly. Prefer concise, scoped logs that capture data shape, selected IDs, load/error states, and boundary decisions. Route renderer diagnostics into the app log when possible so failures are visible in familiaros.log, not only DevTools. Avoid noisy permanent logs, secrets, full payload dumps, or logging in tight animation/render loops.

Control Center CSP

When adding any renderer-visible URL scheme, image source, dev server endpoint, or internal protocol, update the Control Center CSP in both apps/desktop/vite.config.ts and apps/desktop/src/renderer/index.html. Common familiar image protocols include familiaros-codex:, familiaros-installed:, and familiaros-familiar-preview:; forgetting CSP causes images to load as the default/fallback familiar even when install/render logic is correct.

Ubuntu VMware Testing

An Ubuntu 24.04 ARM64 VMware/Vagrant development VM exists for Linux GUI testing. See /Volumes/external/repos/vagrants.md for the host-side VM inventory and commands.

  • VM directory: /Volumes/external/vmware/ubuntu24
  • Provider: vmware_desktop / VMware Fusion on Apple Silicon
  • Guest FamiliarOS checkout: /home/vagrant/src/familiaros
  • Guest helper aliases: cdpets and familiaros-dx

Do not mount the macOS FamiliarOS checkout into Ubuntu for development. The macOS node_modules tree contains platform-specific packages and ownership metadata; using it from Linux can break local macOS development. Ubuntu testing should use the isolated guest clone and its own Linux node_modules.

For Linux GUI bug reproduction or Electron desktop testing:

  1. Start or inspect the VM from /Volumes/external/vmware/ubuntu24 with vagrant up / vagrant status.
  2. SSH with vagrant ssh.
  3. In the guest, run cdpets then familiaros-dx to update dependencies, fix Electron sandbox permissions, and launch FamiliarOS in the Ubuntu desktop session.
  4. Check guest logs at ~/.config/@familiaros/desktop/logs/familiaros.log.

The VM is configured to boot into the Ubuntu desktop (graphical.target) with GDM auto-login for the vagrant user. Prefer this VM when validating Linux-specific renderer, Electron, tray, familiar-window, IPC, plugin, or packaging behavior.