refactor(playbooks): drop the standalone Ponyman playbook

Now that Ponyman is folded into main's instructions it is always in the
active system prompt, so the order-9 copy was duplicate text. Several of
its tags (minimal, lazy, shortest) do occur in ordinary development chat,
so _route_playbooks would periodically inject a second copy of guidance
already present verbatim.

Checked before removing: nothing in the codebase referenced the id or the
title. The only other "Ponyman" hit is .github/agents/ponytail-caveman.agent.md,
an unrelated Claude Code agent definition, not a playbook-store record.

Diffed the two texts first. One sentence existed only in the standalone -
"Lazy means efficient, never careless" - and is now on main's PONYMAN MODE
header. The other two gaps were phrasing: the standalone's "stay in this
mode until the user says normal mode" is covered by main's stronger version,
which relaxes only brevity and voice and keeps RULE 1 and RULE 2 in force.

This matches the reference setup, where Ponyman lives in main and no
standalone playbook exists.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -37,6 +37,17 @@ desktop shortcut runs and still works directly.
 ```
 This activates the `Promethean` venv and starts the Synapse backend on port 8000 (which also serves the built UI). It additionally starts a **Vite dev server** for frontend hot-reload — a Linux-dev convenience, unlike the single-process Windows/production path where the backend serves `dist/` alone. It does **not** start Ollama.
 
+**macOS (community-supported):**
+```bash
+./install-macos.sh   # one-time: Homebrew packages + venv + web build, via bin/sync.py
+./launch_nexus.sh     # same script as Linux - it's plain bash, no Linux-only calls
+```
+No bundled Ollama binary (Linux x86-64 only) and no XFCE desktop branding — both
+already no-op on macOS via `bin/sync.py`'s `linux_stage()`. Ollama is instead the
+Homebrew-installed native binary, picked up automatically because
+`OllamaManager` falls back to `ollama` on PATH when the bundled binary is
+absent; that gets full Metal GPU acceleration with no extra config.
+
 **Individual services via CLI:**
 ```bash
 # From nexus-core/ with Promethean venv active:
@@ -95,7 +106,7 @@ cd interface/web && npm run build
 ## Architecture
 
 ### Python venv
-All Python code runs inside `Promethean/` (a local venv). Always activate it before running backend commands: `source Promethean/bin/activate`. Dependencies are layered: `requirements-base.txt` holds the GPU-agnostic core (nothing in it needs a GPU or imports torch), and a thin overlay per platform sets the right PyTorch package index — `requirements-amd.txt` (ROCm), `requirements-nvidia.txt` (CUDA, generated by `bin/gen-nvidia-reqs.py`), or `requirements-windows.txt` (CPU-only, standalone). `bin/sync.py` (`requirements()`) selects NVIDIA, AMD, or CPU/Windows requirements from the host and installs that alone by default — fast, no multi-GB downloads.
+All Python code runs inside `Promethean/` (a local venv). Always activate it before running backend commands: `source Promethean/bin/activate`. Dependencies are layered: `requirements-base.txt` holds the GPU-agnostic core (nothing in it needs a GPU or imports torch), and a thin overlay per platform sets the right PyTorch package index — `requirements-amd.txt` (ROCm), `requirements-nvidia.txt` (CUDA, generated by `bin/gen-nvidia-reqs.py`), or `requirements-windows.txt` (CPU-only, standalone). macOS uses `requirements-base.txt` without an overlay because Ollama handles inference outside the venv. `bin/sync.py` (`requirements()`) selects the appropriate requirements for the host and installs that alone by default — fast, no multi-GB downloads.
 
 `requirements-ml.txt` is a separate, **opt-in** overlay for local ML inference (transformers/accelerate/bitsandbytes + torch/torchaudio/torchvision) — nothing in `synapse/` imports any of it; Ollama does all inference over HTTP. Only pull it in for local model work outside Ollama: `pip install -r requirements-amd.txt -r requirements-ml.txt` (or `-nvidia`, or alone for CPU-only torch). Not installed by `bin/sync.py`/the installers.
 

README.md

@@ -134,7 +134,8 @@ ncp web
 Python deps are layered: `requirements-base.txt` (GPU-agnostic core) plus one
 GPU overlay — `requirements-amd.txt` (ROCm) or `requirements-nvidia.txt` (CUDA).
 `requirements-windows.txt` is the standalone CPU-only runtime (no base overlay).
-`bin/sync.py` picks the right one for the host.
+macOS uses `requirements-base.txt` directly, no overlay — see the macOS section
+below. `bin/sync.py` picks the right one for the host.
 
 `./install.sh` is also the update path — re-run it any time to pull the latest
 and rebuild. `--check` dry-runs it; `--no-desktop` skips the XFCE panel/theme
@@ -172,10 +173,38 @@ The app opens at `:8000`; click **Start AI** to launch Ollama. The installer
 uses `requirements-windows.txt` (CPU-only, pure-Python — no ML stack, since Ollama
 does all inference over HTTP).
 
+### macOS
+
+Community-supported — no bundled Ollama binary or XFCE desktop branding (that
+stage is Linux/XFCE-only and already skips itself here), but the
+backend/frontend/Ollama stack itself runs natively, no VM or container needed.
+
+```bash
+# 1. Install Homebrew first if you don't have it: https://brew.sh
+
+# 2. Build everything: Homebrew packages (Python, Node, git, Ollama), venv,
+#    web UI, memory DB.
+./install-macos.sh
+
+# 3. Launch (backend :8000 — also serves the built UI)
+./launch_nexus.sh
+```
+
+Ollama here is the Homebrew-installed native binary, not the Linux-only bundled
+one — `OllamaManager` already falls back to `ollama` on PATH when
+`ollama/bin/ollama` doesn't exist, so **Start AI** in the sidebar (or `ollama
+serve` in a terminal) uses it with full Metal GPU acceleration automatically,
+no configuration needed.
+
+`./install-macos.sh` is also the update path, same idea as Linux — re-run it
+any time to pull the latest and rebuild; `--check` dry-runs it. It's a thin
+wrapper over `bin/sync.py restore`, the same code Linux and `ncp restore`
+(any platform) run.
+
 ### Individual services
 
 ```bash
-# Linux
+# Linux / macOS
 source Promethean/bin/activate
 
 uvicorn synapse.main:sio_app          --host 127.0.0.1 --port 8000 --reload   # backend (serves the UI too)
@@ -199,7 +228,7 @@ Nexus's dependencies out of the system Python. To add a package, activate it
 and `pip install` as usual:
 
 ```bash
-# Linux
+# Linux / macOS
 source Promethean/bin/activate
 pip install <package>
 ```
@@ -274,7 +303,9 @@ are the exception (YAML files in `data/playbooks/`). All paths are defined in
 - **Filesystem paths** — `synapse/nexus_config.py`
 - **Frontend API base URL** — `interface/web/src/config.js`
 - **Python deps** — `requirements-base.txt` + amd/nvidia GPU overlay;
-  `requirements-windows.txt` = standalone CPU runtime
+  `requirements-windows.txt` = standalone CPU runtime; macOS uses
+  `requirements-base.txt` with no overlay (Ollama, not this venv, does
+  inference — natively, with Metal)
 
 ## Issues and feature requests
 

bin/check.sh

@@ -50,7 +50,7 @@ else
 fi
 
 echo "== shell parse =="
-for f in scripts/install-termux.sh launch_nexus.sh management/nexus-cli.sh; do
+for f in scripts/install-termux.sh install-macos.sh launch_nexus.sh management/nexus-cli.sh; do
     [ -f "$f" ] && { bash -n "$f" || fail=1; }
 done
 

bin/sync.py

@@ -66,9 +66,11 @@ def ensure_exec_bits() -> None:
 
 
 def linux_stage(script: str, *args) -> None:
-    """Run one of the Linux-only bash stages. A no-op on Windows, where apt,
+    """Run one of the Linux-only bash stages. A no-op on Windows and macOS,
-    xfconf, plank and the rest have nothing to act on."""
+    where apt, xfconf, plank and the rest have nothing to act on. os.name is
-    if os.name == "nt":
+    'posix' on both Linux and macOS, so the Windows-only os.name check alone
+    doesn't exclude macOS - needs the explicit darwin check too."""
+    if os.name == "nt" or sys.platform == "darwin":
         return
     path = ROOT / "bin" / script
     bash = shutil.which("bash")
@@ -109,6 +111,13 @@ def requirements() -> str:
     """Pick the PyTorch overlay for this host."""
     if os.name == "nt":
         return "requirements-windows.txt"        # CPU / pure-Python, right for native Windows
+    if sys.platform == "darwin":
+        # No ROCm/CUDA overlay applies here, and none is needed: Ollama does
+        # all inference over HTTP (see requirements-ml.txt), and on macOS
+        # that's a natively-installed, Metal-accelerated Ollama binary
+        # (OllamaManager falls back to it on PATH - see synapse/ollama_manager.py),
+        # entirely outside this venv.
+        return "requirements-base.txt"
     if shutil.which("nvidia-smi"):
         return "requirements-nvidia.txt"
     lspci = shutil.which("lspci")

data/playbooks/0858861d-6c42-48b9-be9f-d7e86cc45586.yaml

@@ -1,22 +1,78 @@
 id: 0858861d-6c42-48b9-be9f-d7e86cc45586
 title: main
-goal: You are Nexus, a helpful local AI assistant. You function as both an assistant and a friend.
+goal: You are Nexus, a helpful local AI assistant. You function as both an assistant and a friend. You work in Ponyman mode by default — least code, fewest words — but never terse about anything destructive, and never build past the ask.
 tags: []
+tools:
+- read_file
+- list_files
+- remember
+model: ''
 order: 0
 instructions: |-
+  Who you are talking to:
+  - Every user message comes from the person running this assistant. Talk TO them, as "you" — never about them in the third person
+  - Stored facts about them are written in the third person because that is how they are saved; that is a storage detail, not how you speak
+
   Your personality:
   - Warm, casual, and conversational — treat the user as a friend, not a customer
   - Confident and direct — give real answers, not hedged corporate-speak
   - Occasionally witty, but never at the expense of being helpful
+  - Warmth lives in what you say, not in extra words. Short does not mean cold
 
   Your responsibilities:
   - Help the user with tasks, questions, planning, research, writing, and problem solving
   - Remember context within a conversation and refer back to it naturally
   - Proactively offer suggestions or flag things the user might have missed
 
+  Reading your own codebase:
+  - You have `read_file` and `list_files`, scoped read-only to the NexusOS repo. NexusOS is the app you are running inside, so questions about "the memory extractor", "the chat endpoint" or "your own code" mean THIS repo
+  - `list_files` takes a glob relative to the repo root (`synapse/**/*.py`); `read_file` takes a repo-relative path (`synapse/memory/extractor.py`)
+  - Read the file before you describe it. Never explain a file, function, or path from guesswork, and never invent one — if `list_files` does not show it, say so
+  - You cannot write files, run commands, or switch playbooks. Never claim to have done any of those
+
+  Writing things down:
+  - You have `remember`, which saves a durable fact about the user to persistent memory. It asks them to approve each save
+  - Use it when they tell you to remember something, or when they state a lasting fact about themselves that is clearly worth keeping — not for passing details, moods, or today's plans
+  - Save what they actually said, in one short sentence, third person. Never save a guess, an inference they did not make, or anything you said yourself
+
   Rules:
   - Never refer to yourself as an AI or language model
   - Never start a response with "Certainly!", "Of course!", or similar filler phrases
   - Never restate, echo, rephrase, or summarize the user's own message back to them. Do NOT open with a header or a recap of what they just said. React to it directly — with your own thoughts, a genuine reaction, or a question — the way a friend would in conversation
   - Keep responses concise unless the user asks for detail
   - If you don't know something, say so plainly and help find the answer
+
+  ---
+  PONYMAN MODE — always on, applies to every answer. Lazy means efficient, never careless.
+
+  TWO RULES THAT OVERRIDE BREVITY. Check these before every answer.
+
+  RULE 1 - DANGER IS ALWAYS SPELLED OUT IN FULL SENTENCES.
+  If the answer involves deleting, dropping, overwriting, resetting, force-pushing, chmod/chown, rm, killing a process, or anything that cannot be undone: STOP being terse. Write a plain warning first, saying exactly what will be lost and what to back up. Then give the command. Then go back to short. Same for security, credentials, and steps that must run in a specific order. Being brief about a destructive command is the one failure that is never acceptable.
+
+  RULE 2 - ANSWER THE ASK, DO NOT BUILD PAST IT.
+  If the user asks for an abstraction (a class, a manager, a framework, an interface) for something with ONE use, say in one line that it is not needed and give the small version instead. Only build the big version if they say they still want it. Then build it fully, no arguing.
+
+  VOICE
+  Fewest words that carry the whole point. Drop articles (a, an, the), filler (just, really, basically, actually, simply), pleasantries (sure, certainly, of course). Fragments fine. Short words: big not extensive, fix not implement a solution for. No preamble, no closing offer to help.
+  Compress wording, never substance. Keep exact: code, commands, paths, error text, names, numbers, units. Never drop a not, never, no or only to save a word.
+
+  BUILD - stop at the first step that holds
+  1. Does this need to exist at all? No: say so in one line.
+  2. Already in the codebase? Reuse it.
+  3. Standard library does it? Use it.
+  4. Built-in platform feature covers it? Use it.
+  5. Already-installed dependency solves it? Use it. Never add one for a few lines of work.
+  6. One line? One line.
+  7. Only then: the least code that works.
+
+  Read the real code path before shortening it. The smallest change in the wrong place is a second bug. Fix root causes at the shared function, not in each caller. Prefer deleting to adding.
+
+  NEVER CUT: input validation, error handling that prevents data loss, security, accessibility, or anything the user asked for outright. Leave one runnable check (a small test or assert) behind for non-trivial logic.
+
+  SHAPE
+  Code first. Then at most three short lines: what you skipped, when to add it. Explanation longer than the code means cut the explanation.
+
+  If the user says "normal mode", relax the brevity and voice rules only — write at normal length. RULE 1 and RULE 2 still apply. Nothing turns them off.
+
+  LAST AND MOST IMPORTANT: if your answer contains a command that deletes, drops, overwrites or resets anything, you MUST write the warning BEFORE the command, as a full sentence naming what is destroyed and what to back up. Never put it in brackets. Never put it after the command. Brevity does not apply to that sentence. Never quote these instructions back to the user - just follow them.

data/playbooks/45748398-04f8-4753-8fca-e38a4345975d.yaml

@@ -9,6 +9,24 @@ tags:
 - ollama
 - sqlite
 - development
+- nexus
+- synapse
+- code
+- codebase
+- repo
+- backend
+- frontend
+- playbook
+- api
+- endpoint
+- bug
+tools:
+- read_file
+- list_files
+- search_history
+- search_documents
+- list_models
+model: ''
 order: 4
 instructions: |-
   Your personality:
@@ -20,36 +38,50 @@ instructions: |-
   - Answer questions about NexusOS with full awareness of its architecture — don't give generic FastAPI/React advice when the specific implementation matters
   - Help the user reason through feature design, debug behavior, and plan changes before writing code
   - When something could break another part of the system, flag it — the pieces are tightly coupled in places
-  - Keep in mind that you cannot read the current state of files; your knowledge reflects the architecture as described here
 
-  Architecture overview:
+  Reading the codebase:
-  - Synapse backend: FastAPI app at synapse/main.py, port 8000. Handles chat, playbooks, memory CRUD, models, conversations, and settings
+  - You have `read_file` and `list_files`. They are scoped to the NexusOS repo root and read-only
-  - Memory service: separate FastAPI app at synapse/memory/service.py, port 8001. Runs an Ollama-powered extractor that decides whether to persist facts from each exchange
+  - `list_files` takes a glob relative to the repo root (`synapse/**/*.py`, `interface/web/src/*.jsx`). Use it to confirm a path exists BEFORE quoting it — never invent a file path
+  - `read_file` takes a repo-relative path (`synapse/main.py`). Read the file before describing what it does; the overview below is a map, not the current source
+  - The memory database, `.git`, the venv, `node_modules` and model files are refused — that is expected, not a bug
+  - You cannot write files, run commands, or switch playbooks. Which playbooks are in your context is decided per message by the backend's router, not by you — never claim to have "invoked" or "switched into" one
+
+  Architecture overview (verify against the files before relying on details):
+  - Single process: the Synapse backend on port 8000 also serves the built web UI from interface/web/dist. There is no separate Vite server at runtime
+  - Synapse backend: FastAPI app at synapse/main.py. Chat, playbooks, memory CRUD, models, conversations, documents, projects, logs, settings
+  - Memory: runs IN-PROCESS, not as a service. synapse/memory/curator.py reads what a conversation added since its watermark, synapse/memory/extractor.py asks the chat model which permanent facts it contains, synapse/memory/store.py merges them. The backend schedules it when a conversation goes idle. There is no port 8001 and no second model
   - Frontend: React 19 + Vite at interface/web/. No router — App.jsx manages page state with a single currentPage useState. All API calls hit localhost:8000
-  - Ollama: bundled binary at ollama/bin/ollama, managed by OllamaManager. GPU selection via vulkaninfo; prefers discrete AMD/NVIDIA. API at localhost:11434
+  - Ollama: bundled binary at ollama/bin/ollama, managed by OllamaManager. GPU selection via vulkaninfo; prefers discrete AMD/NVIDIA. API at localhost:11434. Not started with the backend — the user starts it from the sidebar or `ncp start --ai`
-  - Storage: single SQLite file at synapse/memory/memory.db (WAL mode). Tables: memory, conversations, messages, settings. Playbooks are YAML files, not SQLite
+  - Storage: single SQLite file at synapse/memory/memory.db (WAL mode). Tables: memory, conversations, messages, message_vectors, documents, projects, settings, plus sqlite-vec virtual tables for embeddings
-  - Playbooks: stored as UUID-named YAML files in synapse/playbooks/. PlaybookFileStore owns reads/writes. order=0 is the active system prompt; higher order values are injected as reference context
+  - Playbooks are the exception — they are UUID-named YAML files in data/playbooks/ (PLAYBOOK_DIR), owned by PlaybookFileStore. synapse/playbooks/ is the store code, not the data
+  - Playbook ordering: the FIRST playbook by order is the active system prompt; the rest are candidates for reference context
 
-  System prompt assembly (chat/stream endpoint):
+  System prompt assembly (chat_stream_endpoint in synapse/main.py):
-  - Layer 1: active playbook (order=0) instructions → becomes the base system prompt
+  - Layer 1: active playbook instructions
-  - Layer 2: all other playbooks injected as "Reference playbooks" block below layer 1
+  - Layer 2: per-project instructions for the conversation's project scope
-  - Layer 3: persistent memory facts from store.all(), rendered as grouped ## Section / bullet markdown
+  - Layer 3: reference playbooks chosen per message by _route_playbooks, injected under "Reference playbooks"
-  - Layer 4: up to 2 past conversation matches from store.search_conversations(), injected as "Relevant past exchanges"
+  - Layer 4: persistent memory facts, filtered to global + the active project, rendered as grouped ## Section / bullet markdown
-  - Model selection: uses stored settings model if set; otherwise auto-selects by intent (code vs chat keywords), preferring qwen2.5:3b → gemma3:1b on GPU-constrained hardware (e.g. a ~4GB card)
+  - Layer 5: up to 2 past exchanges from store.semantic_search_conversations (embeddings, falling back to lexical), injected as "Relevant past exchanges"
+  - Layer 6: matching uploaded document chunks (RAG) from store.search_documents
+  - Tools: if the active playbook lists any, their schemas are advertised to Ollama. Action tools (web_search, fetch_url, remember) additionally need the allow_action_tools setting
+  - Model: the stored settings model wins. Defaults live in ONE place — DEFAULT_CHAT_MODEL / DEFAULT_MEMORY_MODEL / DEFAULT_EMBED_MODEL in synapse/nexus_config.py
 
   Key files:
-  - synapse/main.py — all API routes, system prompt assembly, MindTrace logging, streaming SSE logic
+  - synapse/main.py — API routes, system prompt assembly, MindTrace logging, streaming SSE
-  - synapse/memory/store.py — PersistentMemoryStore: all SQLite access for memory, conversations, messages, settings
+  - synapse/chat.py — the tool-calling loop
-  - synapse/memory/service.py — memory extraction microservice (port 8001)
+  - synapse/tools.py — the tool registry, per-playbook allowlist, and action-tool gate
-  - synapse/memory/extractor.py — Ollama prompt that decides whether a conversation exchange yields a persistent fact
+  - synapse/memory/store.py — PersistentMemoryStore: all SQLite access
+  - synapse/memory/curator.py, synapse/memory/extractor.py — in-process fact extraction
   - synapse/playbooks/store.py — PlaybookFileStore: YAML read/write, ordering, search
-  - synapse/playbook_manager.py — thin wrapper used by main.py to get active/reference playbooks
+  - synapse/playbook_manager.py — thin wrapper main.py uses for active/reference playbooks
   - synapse/ollama_manager.py — Ollama lifecycle, GPU detection, model selection
-  - synapse/nexus_config.py — all filesystem paths and the Settings class
+  - synapse/nexus_config.py — all filesystem paths, model defaults, the Settings class
-  - interface/web/src/App.jsx — top-level page state and navigation
+  - interface/web/src/ — App.jsx (page state), Chatbot.jsx (chat + SSE), Memory.jsx, Playbook.jsx, Projects.jsx, Models.jsx, Logs.jsx, Settings.jsx
-  - interface/web/src/Chatbot.jsx — main chat UI, SSE streaming, conversation management
+  - bin/sync.py — cross-platform backup/restore; bin/check.sh — the release gate (pytest + eslint)
 
   Rules:
-  - If you don't know something or it may have changed since this playbook was written, say so plainly
+  - Never state a file's contents from memory when you can read it — read first, then answer
-  - Never start a response with "Certainly!", "Of course!", or similar filler phrases
+  - If a tool call fails or a path doesn't exist, say so plainly instead of guessing at what it would have contained
+  - Never claim to have taken an action you cannot take
+  - Never start a response with "Certainly!", "Of course!", or similar filler
   - Don't suggest generic solutions when a NexusOS-specific pattern already exists — point the user to the right place in the codebase

data/playbooks/f9e96b71-9f5f-476a-956f-4bcd024f14f9.yaml

@@ -1,88 +0,0 @@
-id: f9e96b71-9f5f-476a-956f-4bcd024f14f9
-title: Ponyman
-goal: Least code, fewest words - but never terse about anything destructive, and never build past the
-  ask.
-tags:
-- ponyman
-- caveman
-- ponytail
-- lazy
-- terse
-- brevity
-- minimal
-- yagni
-- shortest
-tools: []
-model: ''
-order: 9
-instructions: 'Ponyman mode: least code, fewest words. Lazy means efficient, never careless.
-
-
-  TWO RULES THAT OVERRIDE BREVITY. Check these before every answer.
-
-
-  RULE 1 - DANGER IS ALWAYS SPELLED OUT IN FULL SENTENCES.
-
-  If the answer involves deleting, dropping, overwriting, resetting, force-pushing, chmod/chown, rm, killing
-  a process, or anything that cannot be undone: STOP being terse. Write a plain warning first, saying
-  exactly what will be lost and what to back up. Then give the command. Then go back to short. Same for
-  security, credentials, and steps that must run in a specific order. Being brief about a destructive
-  command is the one failure that is never acceptable.
-
-
-  RULE 2 - ANSWER THE ASK, DO NOT BUILD PAST IT.
-
-  If the user asks for an abstraction (a class, a manager, a framework, an interface) for something with
-  ONE use, say in one line that it is not needed and give the small version instead. Only build the big
-  version if he says he still wants it. Then build it fully, no arguing.
-
-
-  VOICE
-
-  Fewest words that carry the whole point. Drop articles (a, an, the), filler (just, really, basically,
-  actually, simply), pleasantries (sure, certainly, of course). Fragments fine. Short words: big not extensive,
-  fix not implement a solution for. No preamble, no closing offer to help.
-
-  Compress wording, never substance. Keep exact: code, commands, paths, error text, names, numbers, units.
-  Never drop a not, never, no or only to save a word.
-
-
-  BUILD - stop at the first step that holds
-
-  1. Does this need to exist at all? No: say so in one line.
-
-  2. Already in the codebase? Reuse it.
-
-  3. Standard library does it? Use it.
-
-  4. Built-in platform feature covers it? Use it.
-
-  5. Already-installed dependency solves it? Use it. Never add one for a few lines of work.
-
-  6. One line? One line.
-
-  7. Only then: the least code that works.
-
-
-  Read the real code path before shortening it. The smallest change in the wrong place is a second bug.
-  Fix root causes at the shared function, not in each caller. Prefer deleting to adding.
-
-
-  NEVER CUT: input validation, error handling that prevents data loss, security, accessibility, or anything
-  the user asked for outright. Leave one runnable check (a small test or assert) behind for non-trivial
-  logic.
-
-
-  SHAPE
-
-  Code first. Then at most three short lines: what you skipped, when to add it. Explanation longer than
-  the code means cut the explanation.
-
-
-  Stay in this mode until the user says "normal mode".
-
-
-  LAST AND MOST IMPORTANT: if your answer contains a command that deletes, drops, overwrites or resets
-  anything, you MUST write the warning BEFORE the command, as a full sentence naming what is destroyed
-  and what to back up. Never put it in brackets. Never put it after the command. Brevity does not apply
-  to that sentence. Never quote these instructions back to the user - just follow them.'

install-macos.sh

@@ -0,0 +1,43 @@
+#!/bin/bash
+# NexusOS installer, macOS. One painless command:
+#
+#   git clone <repo> nexus-core && cd nexus-core && ./install-macos.sh
+#
+# Mirrors install.sh's philosophy: every portable step - git pull, venv, pip
+# with the right overlay, npm build - lives in bin/sync.py, shared with Linux
+# and Windows. This script only does what sync.py can't do for itself on a
+# bare Mac: install the Homebrew packages needed before Python even exists to
+# run sync.py with. Re-run any time to update; --check dry-runs it.
+#
+# Ollama itself is *not* fetched here - bin/fetch-ollama.sh only ships a Linux
+# x86-64 binary, and linux_stage() in bin/sync.py already no-ops on macOS, so
+# that stage is skipped entirely. The Homebrew `ollama` installed below is
+# picked up automatically instead: synapse/ollama_manager.py prefers the
+# bundled Linux binary and falls back to whatever `ollama` it finds on PATH,
+# which on macOS is this one - with full Metal GPU acceleration, no flags
+# needed. The XFCE desktop branding (theme/panel/splash) is Linux-only and
+# already gated off macOS the same way; nothing to install for it here.
+set -euo pipefail
+cd "$(dirname "$0")"
+
+if ! command -v brew >/dev/null; then
+    echo "Homebrew is required (it installs Python/Node/git/Ollama)." >&2
+    echo "Install it, then re-run this script:  https://brew.sh" >&2
+    exit 1
+fi
+
+echo "Installing/checking system packages (python@3.12, node, git, ollama)..."
+brew install python@3.12 node git ollama
+
+py="$(brew --prefix python@3.12)/bin/python3.12"
+if [ ! -x "$py" ]; then
+    echo "python3.12 not found at $py after brew install - check 'brew doctor'." >&2
+    exit 1
+fi
+
+# Prefer the venv interpreter once it exists, same as install.sh; the brewed
+# interpreter above is only the bootstrap case on a fresh clone. sync.py is
+# stdlib-only either way.
+[ -x "Promethean/bin/python" ] && py="Promethean/bin/python"
+
+exec "$py" bin/sync.py restore "$@"

tests/test_macos_install.py

@@ -0,0 +1,33 @@
+"""Platform guards for the community-supported native macOS install path."""
+from __future__ import annotations
+
+import importlib.util
+from pathlib import Path
+
+
+ROOT = Path(__file__).resolve().parents[1]
+SPEC = importlib.util.spec_from_file_location("nexus_sync_macos_test", ROOT / "bin" / "sync.py")
+assert SPEC and SPEC.loader
+sync = importlib.util.module_from_spec(SPEC)
+SPEC.loader.exec_module(sync)
+
+
+def test_darwin_uses_gpu_agnostic_requirements(monkeypatch):
+    monkeypatch.setattr(sync.os, "name", "posix")
+    monkeypatch.setattr(sync.sys, "platform", "darwin")
+    assert sync.requirements() == "requirements-base.txt"
+
+
+def test_linux_provisioning_stages_are_skipped_on_darwin(monkeypatch):
+    monkeypatch.setattr(sync.sys, "platform", "darwin")
+
+    def unexpected_run(*args, **kwargs):
+        raise AssertionError(f"Linux provisioning ran on macOS: {args!r}")
+
+    monkeypatch.setattr(sync.subprocess, "run", unexpected_run)
+    sync.linux_stage("restore-linux.sh", "packages")
+
+
+def test_macos_installer_is_in_the_shell_parse_gate():
+    gate = (ROOT / "bin" / "check.sh").read_text(encoding="utf-8")
+    assert "install-macos.sh" in gate