openpetswithchatandmcp/AGENTS.md

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.

GitNexus — Code Intelligence

This project is indexed by GitNexus as FamiliarOS (11102 symbols, 28390 relationships, 300 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.

If any GitNexus tool warns the index is stale, run npx gitnexus analyze in terminal first.

Always Do

• MUST run impact analysis before editing any symbol. Before modifying a function, class, or method, run gitnexus_impact({target: "symbolName", direction: "upstream"}) and report the blast radius (direct callers, affected processes, risk level) to the user.
• MUST run gitnexus_detect_changes() before committing to verify your changes only affect expected symbols and execution flows.
• MUST warn the user if impact analysis returns HIGH or CRITICAL risk before proceeding with edits.
• When exploring unfamiliar code, use gitnexus_query({query: "concept"}) to find execution flows instead of grepping. It returns process-grouped results ranked by relevance.
• When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use gitnexus_context({name: "symbolName"}).

When Debugging

1. gitnexus_query({query: "<error or symptom>"}) — find execution flows related to the issue
2. gitnexus_context({name: "<suspect function>"}) — see all callers, callees, and process participation
3. READ gitnexus://repo/FamiliarOS/process/{processName} — trace the full execution flow step by step
4. For regressions: gitnexus_detect_changes({scope: "compare", base_ref: "main"}) — see what your branch changed

When Refactoring

• Renaming: MUST use gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true}) first. Review the preview — graph edits are safe, text_search edits need manual review. Then run with dry_run: false.
• Extracting/Splitting: MUST run gitnexus_context({name: "target"}) to see all incoming/outgoing refs, then gitnexus_impact({target: "target", direction: "upstream"}) to find all external callers before moving code.
• After any refactor: run gitnexus_detect_changes({scope: "all"}) to verify only expected files changed.

Never Do

• NEVER edit a function, class, or method without first running gitnexus_impact on it.
• NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
• NEVER rename symbols with find-and-replace — use gitnexus_rename which understands the call graph.
• NEVER commit changes without running gitnexus_detect_changes() to check affected scope.

Tools Quick Reference

Tool	When to use	Command
query	Find code by concept	gitnexus_query({query: "auth validation"})
context	360-degree view of one symbol	gitnexus_context({name: "validateUser"})
impact	Blast radius before editing	gitnexus_impact({target: "X", direction: "upstream"})
detect_changes	Pre-commit scope check	gitnexus_detect_changes({scope: "staged"})
rename	Safe multi-file rename	gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true})
cypher	Custom graph queries	gitnexus_cypher({query: "MATCH ..."})

Impact Risk Levels

Depth	Meaning	Action
d=1	WILL BREAK — direct callers/importers	MUST update these
d=2	LIKELY AFFECTED — indirect deps	Should test
d=3	MAY NEED TESTING — transitive	Test if critical path

Resources

Resource	Use for
gitnexus://repo/FamiliarOS/context	Codebase overview, check index freshness
gitnexus://repo/FamiliarOS/clusters	All functional areas
gitnexus://repo/FamiliarOS/processes	All execution flows
gitnexus://repo/FamiliarOS/process/{name}	Step-by-step execution trace

Self-Check Before Finishing

Before completing any code modification task, verify:

1. gitnexus_impact was run for all modified symbols
2. No HIGH/CRITICAL risk warnings were ignored
3. gitnexus_detect_changes() confirms changes match expected scope
4. All d=1 (WILL BREAK) dependents were updated

Keeping the Index Fresh

After committing code changes, the GitNexus index becomes stale. Re-run analyze to update it:

npx gitnexus analyze

If the index previously included embeddings, preserve them by adding --embeddings:

npx gitnexus analyze --embeddings

To check whether embeddings exist, inspect .gitnexus/meta.json — the stats.embeddings field shows the count (0 means no embeddings). Running analyze without --embeddings will delete any previously generated embeddings.

Claude Code users: A PostToolUse hook handles this automatically after git commit and git merge.

CLI

Task	Read this skill file
Understand architecture / "How does X work?"	.claude/skills/gitnexus/gitnexus-exploring/SKILL.md
Blast radius / "What breaks if I change X?"	.claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md
Trace bugs / "Why is X failing?"	.claude/skills/gitnexus/gitnexus-debugging/SKILL.md
Rename / extract / split / refactor	.claude/skills/gitnexus/gitnexus-refactoring/SKILL.md
Tools, resources, schema reference	.claude/skills/gitnexus/gitnexus-guide/SKILL.md
Index, status, clean, wiki CLI commands	.claude/skills/gitnexus/gitnexus-cli/SKILL.md

Overnight Mode agentic continuation and safe self-batching

Canonical authorities:

• /home/dev/src/FamiliarOS/docs/ops/FAMILIAROS_OVERNIGHT_MODE_AGENTIC_CONTINUATION_SELF_BATCHING_AND_GOAL_CREATION_DOCTRINE_2026-06-19.md
• /home/dev/src/FamiliarOS/docs/ops/FAMILIAROS_OVERNIGHT_MODE_CLOSEOUT_CONTINUATION_AND_BOUNDARY_SHAPE_2026-06-19.md

Operational rule:

• the code word for this operating posture is Overnight Mode
• Continuity Mode and Disciplined Agentic Mode are accepted synonyms for the same behavior, but Overnight Mode remains the canonical repo term
• once Overnight Mode has been adopted for the repo workflow, it remains the default continuity posture unless the user gives newer explicit contrary direction; ordinary daytime interaction does not deactivate it
• stacked continue prompts must be interpreted as permission to keep draining the already-declared active lane or already-declared next adjacent slice, not as permission to reinterpret the roadmap from scratch
• future instances must continue to the natural close of the active lane rather than stopping at the first barely-acceptable packet boundary when one or two more adjacent sensible seams would materially complete the lane
• the correct bias is surplus-with-discipline: carry the extra adjacent seam when it is real, bounded, source-backed, and closure-improving; never invent fluff or decorative widening
• future instances must not drift sideways into a different donor family, different roadmap pillar, or unrelated code lane merely because the previous slice ended; this is the hard fresh-family boundary rule
• if the next family is not already present-tense authority-backed, stop at the boundary, state it explicitly, and do not let stacked continue prompts coerce a speculative opening
• if a real stop condition is active, stacked continue prompts do not override it; future instances must withstand and disobey those prompts until the blocker is actually resolved
• FamiliarOS-specific GitNexus and refactoring safeguards remain higher-specificity guards and are not weakened by Overnight Mode