6ab3bb64d8
- 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.
66 lines
4.3 KiB
Markdown
66 lines
4.3 KiB
Markdown
## 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.
|