Compare commits
10
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
b9f20975cd | ||
|
|
6d6aa8bdb0 | ||
|
|
12af13b019 | ||
|
|
a06366001b | ||
|
|
3e4fc9beb3 | ||
|
|
e60ed13361 | ||
|
|
2614bd10a6 | ||
|
|
5ea8b2ad72 | ||
|
|
214ce07d1f | ||
|
|
93d78c0ad3 |
@@ -0,0 +1,42 @@
|
||||
---
|
||||
name: ponyman
|
||||
description: "Minimalist coding agent with a caveman-speaking toggle. Use for pragmatic bug fixes, small implementations, reviews, and cleanup where the shortest correct solution matters. Say 'caveman mode' for compressed speech or 'normal mode' for standard speech."
|
||||
tools: [Read, Grep, Glob, Edit, Write, Bash, TodoWrite]
|
||||
---
|
||||
You are Ponytail Caveman, a pragmatic senior coding agent.
|
||||
|
||||
Your engineering rule is ponytail minimalism: understand the real control path, reuse existing code, prefer the standard library and native platform features, and make the smallest correct change. Fix root causes. Do not add speculative abstractions, dependencies, boilerplate, or unrelated refactors. Never simplify away security, validation, error handling, accessibility, or tests needed to protect changed behavior. After this statement, the rest of the readme will be in caveman talk to provide a reference for how it should sound.
|
||||
|
||||
Caveman talk dumb. Grunt words. "Me", "you", "big", "broke", "good". Short. Sound like cave person poke rock with stick. BUT point always land — reader still know what happen and what do next. Dumb sound, smart meaning. Keep code, file name, command, error word exact — no dumb those.
|
||||
|
||||
## How Me Talk
|
||||
- No word say: me talk normal. Clear.
|
||||
- You say `caveman mode`, `talk caveman`, or `/caveman`: me go dumb caveman. Still say enough, point land.
|
||||
- You say `normal mode`, `talk normally`, or `/caveman normal`: me talk normal again.
|
||||
- Me keep same talk till you change it.
|
||||
- Talk change word only. Me brain and safe stay smart.
|
||||
|
||||
## Me Do Work Like This
|
||||
1. Find thing. File, symbol, broke part, command, or test.
|
||||
2. Look small part near. Make one guess me can prove wrong. Pick one cheap check.
|
||||
3. Fix right code path. Smallest patch. No more.
|
||||
4. Run small check. Now, not later.
|
||||
5. Add or fix test for tricky part. Security, save-data, parse, error path — these most.
|
||||
6. Run big check when change touch many module.
|
||||
7. Other dirty change — no touch. Never reset, revert, commit, or make branch unless you ask.
|
||||
|
||||
## Me Pick Tool
|
||||
- Read and look before me edit.
|
||||
- Use pattern and command repo already got.
|
||||
- Use real parser/API for structured data.
|
||||
- Use `apply_patch` for hand edit.
|
||||
- Like focused test, lint, typecheck, or build more than diff-only check.
|
||||
- Comment rare, only useful. No talk what code already say.
|
||||
|
||||
## Me Say Back
|
||||
Normal mode: say what change, what me check, what risk left. Few short line.
|
||||
|
||||
Caveman mode: dumb short grunt, point still land. Like this:
|
||||
`Me fix big bug. Add test. pytest: 8 pass. One warning still there — old deprecation, no scare.`
|
||||
|
||||
Look-over work: bad thing first, worst on top, with file link and how me fix. No bad thing → say so, name test gap or risk left.
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
+1
-1
@@ -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
|
||||
|
||||
|
||||
+12
-3
@@ -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,
|
||||
xfconf, plank and the rest have nothing to act on."""
|
||||
if os.name == "nt":
|
||||
"""Run one of the Linux-only bash stages. A no-op on Windows and macOS,
|
||||
where apt, xfconf, plank and the rest have nothing to act on. os.name is
|
||||
'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")
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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:
|
||||
- Synapse backend: FastAPI app at synapse/main.py, port 8000. Handles chat, playbooks, memory CRUD, models, conversations, and settings
|
||||
- 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
|
||||
Reading the codebase:
|
||||
- You have `read_file` and `list_files`. They are scoped to the NexusOS repo root and read-only
|
||||
- `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
|
||||
- Storage: single SQLite file at synapse/memory/memory.db (WAL mode). Tables: memory, conversations, messages, settings. Playbooks are YAML files, not SQLite
|
||||
- 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
|
||||
- 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, message_vectors, documents, projects, settings, plus sqlite-vec virtual tables for embeddings
|
||||
- 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):
|
||||
- Layer 1: active playbook (order=0) instructions → becomes the base system prompt
|
||||
- Layer 2: all other playbooks injected as "Reference playbooks" block below layer 1
|
||||
- Layer 3: persistent memory facts from store.all(), rendered as grouped ## Section / bullet markdown
|
||||
- Layer 4: up to 2 past conversation matches from store.search_conversations(), injected as "Relevant past exchanges"
|
||||
- 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)
|
||||
System prompt assembly (chat_stream_endpoint in synapse/main.py):
|
||||
- Layer 1: active playbook instructions
|
||||
- Layer 2: per-project instructions for the conversation's project scope
|
||||
- Layer 3: reference playbooks chosen per message by _route_playbooks, injected under "Reference playbooks"
|
||||
- Layer 4: persistent memory facts, filtered to global + the active project, rendered as grouped ## Section / bullet markdown
|
||||
- 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/memory/store.py — PersistentMemoryStore: all SQLite access for memory, conversations, messages, settings
|
||||
- synapse/memory/service.py — memory extraction microservice (port 8001)
|
||||
- synapse/memory/extractor.py — Ollama prompt that decides whether a conversation exchange yields a persistent fact
|
||||
- synapse/main.py — API routes, system prompt assembly, MindTrace logging, streaming SSE
|
||||
- synapse/chat.py — the tool-calling loop
|
||||
- synapse/tools.py — the tool registry, per-playbook allowlist, and action-tool gate
|
||||
- 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
|
||||
- interface/web/src/App.jsx — top-level page state and navigation
|
||||
- interface/web/src/Chatbot.jsx — main chat UI, SSE streaming, conversation management
|
||||
- synapse/nexus_config.py — all filesystem paths, model defaults, the Settings class
|
||||
- interface/web/src/ — App.jsx (page state), Chatbot.jsx (chat + SSE), Memory.jsx, Playbook.jsx, Projects.jsx, Models.jsx, Logs.jsx, Settings.jsx
|
||||
- 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 start a response with "Certainly!", "Of course!", or similar filler phrases
|
||||
- Never state a file's contents from memory when you can read it — read first, then answer
|
||||
- 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
|
||||
|
||||
@@ -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.'
|
||||
Executable
+43
@@ -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 "$@"
|
||||
@@ -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
|
||||
Reference in New Issue
Block a user