diff --git a/.agent/skills/postgres-memory/references/security.md b/.agent/skills/postgres-memory/references/security.md index 55452ee..75a00eb 100644 --- a/.agent/skills/postgres-memory/references/security.md +++ b/.agent/skills/postgres-memory/references/security.md @@ -7,7 +7,7 @@ After a fresh `initdb`, PostgreSQL ships with: - One superuser: `postgres` (no password) - Auth method: `trust` for localhost only - `listen_addresses = 'localhost'` — only accepts connections from inside the jail -- No remote access — other jails (cms, controlplane) cannot connect +- No remote access — the host orchestrator and cms jail cannot connect This is fine for initial setup but must be hardened before any remote jail connects. @@ -22,18 +22,29 @@ Set a password anyway as defense in depth: ```sh . /home/clawdie/clawdie-ai/.env -sudo jexec db su - postgres -c "psql -c \"ALTER USER postgres WITH PASSWORD '$POSTGRES_ADMIN_PASSWORD';\"" +sudo jexec ${AGENT_NAME}-db su - postgres -c "psql -c \"ALTER USER postgres WITH PASSWORD '$POSTGRES_ADMIN_PASSWORD';\"" ``` -### Role: clawdie_brain (Clawdie memory) +### Role: `SKILLS_DB_USER` (Agent System Skills) -For the Clawdie agent memory database: +For the skills database: ```sh . /home/clawdie/clawdie-ai/.env -sudo jexec db su - postgres -c "createuser clawdie_brain" -sudo jexec db su - postgres -c "psql -c \"ALTER USER clawdie_brain WITH PASSWORD '$CLAWDIE_DB_PASSWORD';\"" -sudo jexec db su - postgres -c "createdb -O clawdie_brain ai_brain" +sudo jexec ${AGENT_NAME}-db su - postgres -c "createuser ${SKILLS_DB_USER}" +sudo jexec ${AGENT_NAME}-db su - postgres -c "psql -c \"ALTER USER ${SKILLS_DB_USER} WITH PASSWORD '$SKILLS_DB_PASSWORD';\"" +sudo jexec ${AGENT_NAME}-db su - postgres -c "createdb -O ${SKILLS_DB_USER} ${SKILLS_DB_NAME}" +``` + +### Role: `MEMORY_DB_USER` (User-Agent Memory) + +For the user/agent memory database: + +```sh +. /home/clawdie/clawdie-ai/.env +sudo jexec ${AGENT_NAME}-db su - postgres -c "createuser ${MEMORY_DB_USER}" +sudo jexec ${AGENT_NAME}-db su - postgres -c "psql -c \"ALTER USER ${MEMORY_DB_USER} WITH PASSWORD '$MEMORY_DB_PASSWORD';\"" +sudo jexec ${AGENT_NAME}-db su - postgres -c "createdb -O ${MEMORY_DB_USER} ${MEMORY_DB_NAME}" ``` ### Role: strapi_cms (CMS) @@ -62,7 +73,7 @@ host all all ::1/128 trust ### Target Keep localhost trust for admin. Add password-authenticated remote access -for specific jails only: +for the host on `warden0` and for the future cms jail only: ``` # local admin — trust (postgres superuser only uses this) @@ -70,11 +81,12 @@ local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust -# controlplane jail — Clawdie memory -host ai_brain clawdie_brain 10.0.0.100/32 scram-sha-256 +# host-side orchestrator on warden0 gateway +host ${SKILLS_DB_NAME} ${SKILLS_DB_USER} 10.0.0.1/32 scram-sha-256 +host ${MEMORY_DB_NAME} ${MEMORY_DB_USER} 10.0.0.1/32 scram-sha-256 # cms jail — Strapi CMS -host strapi_cms strapi_cms 10.0.0.3/32 scram-sha-256 +host strapi_cms strapi_cms 10.0.0.5/32 scram-sha-256 # deny everything else from the subnet host all all 10.0.0.0/24 reject @@ -88,7 +100,7 @@ no other jail on the subnet can connect. ```sh # edit pg_hba.conf inside db jail (use the commands above) # then reload — no restart needed -sudo jexec db service postgresql reload +sudo jexec ${AGENT_NAME}-db service postgresql reload ``` ## Listen addresses (postgresql.conf) @@ -104,7 +116,7 @@ Change from: To: ``` -listen_addresses = 'localhost, 10.0.0.2' +listen_addresses = 'localhost, 10.0.0.3' ``` This makes PostgreSQL listen on both localhost (for admin) and the VNET @@ -113,7 +125,7 @@ interface (for remote jails). Do NOT use `'*'` — only bind to known IPs. Reload after changing: ```sh -sudo jexec db service postgresql reload +sudo jexec ${AGENT_NAME}-db service postgresql reload ``` ## Verification @@ -121,21 +133,21 @@ sudo jexec db service postgresql reload ### From inside db jail (should work — trust) ```sh -sudo jexec db su - postgres -c "psql -c 'SELECT 1;'" +sudo jexec ${AGENT_NAME}-db su - postgres -c "psql -c 'SELECT 1;'" ``` -### From controlplane jail (should work — password) +### From host (should work — password) ```sh -sudo jexec controlplane psql -h 10.0.0.2 -U clawdie_brain -d ai_brain -c "SELECT 1;" +psql "$MEMORY_DB_URL" -c "SELECT 1;" ``` -Will prompt for password. Use the `clawdie_brain` password. +Will use the password embedded in `MEMORY_DB_URL`. ### From cms jail (should work — password) ```sh -sudo jexec cms psql -h 10.0.0.2 -U strapi_cms -d strapi_cms -c "SELECT 1;" +sudo jexec ${AGENT_NAME}-cms psql -h 10.0.0.3 -U strapi_cms -d strapi_cms -c "SELECT 1;" ``` Will prompt for password. Use the `strapi_cms` password. @@ -143,7 +155,7 @@ Will prompt for password. Use the `strapi_cms` password. ### From a random jail or host (should be rejected) ```sh -psql -h 10.0.0.2 -U postgres -d postgres -c "SELECT 1;" +psql -h 10.0.0.3 -U postgres -d postgres -c "SELECT 1;" ``` Should fail with: `FATAL: pg_hba.conf rejects connection` @@ -154,17 +166,24 @@ All database passwords live in `/home/clawdie/clawdie-ai/.env`: ``` POSTGRES_ADMIN_PASSWORD= -CLAWDIE_DB_PASSWORD= +SKILLS_DB_PASSWORD= +MEMORY_DB_PASSWORD= STRAPI_DB_PASSWORD= ``` +The setup flow derives PostgreSQL-safe names from `AGENT_NAME`. Example: +`AGENT_NAME=clawdie-ai` becomes `SKILLS_DB_USER=clawdie_ai_reader` and +`MEMORY_DB_USER=clawdie_ai_brain`. + Generate with: `python3 -c "import secrets; print(secrets.token_urlsafe(24))"` Source before running setup commands: `. /home/clawdie/clawdie-ai/.env` -When jails need their own `.env`, copy only the relevant variable: -- controlplane: `CLAWDIE_DB_PASSWORD` -- cms: `STRAPI_DB_PASSWORD` +When a future Strapi layer needs its own `.env`, copy only the relevant +variables: +- cms / Strapi DB: `STRAPI_DB_PASSWORD` +- cms / Strapi app: `STRAPI_APP_KEYS`, `STRAPI_API_TOKEN_SALT`, + `STRAPI_ADMIN_JWT_SECRET`, `STRAPI_TRANSFER_TOKEN_SALT`, `STRAPI_JWT_SECRET` Never commit passwords to git. Never store them in skill files. @@ -172,13 +191,13 @@ Never commit passwords to git. Never store them in skill files. 1. ZFS snapshot db jail first 2. Set postgres superuser password -3. Create clawdie_brain role + ai_brain database -4. Create strapi_cms role + strapi_cms database +3. Create skills + memory roles/databases +4. Create strapi_cms role + strapi_cms database (reserved for later Strapi use) 5. Update pg_hba.conf with remote access rules 6. Update listen_addresses in postgresql.conf 7. Reload PostgreSQL 8. Test from inside db jail (trust) -9. Test from controlplane jail (password) +9. Test from host-side memory access (password) 10. Test from cms jail (password — after cms jail exists) 11. ZFS snapshot db jail after successful setup diff --git a/AGENTS.md b/AGENTS.md index dbc4832..a378e82 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -120,6 +120,18 @@ Use `warden0` as the canonical host bridge name for Bastille/Warden networking. - Runtime source of truth lives in `src/jail-config.ts`. - If a historical reference must remain, mark it explicitly as archived. +## Internal DNS Naming + +Use `home.arpa` as the canonical internal namespace for host and jail-local +resolution. + +- `AGENT_INTERNAL_DOMAIN` should default to `.home.arpa`. +- Do not introduce new `.local` defaults for internal service names. +- `.local` is reserved for mDNS and can create resolver ambiguity or name + leakage on the local link. +- `AGENT_DOMAIN` is public-facing and should use a real public domain or the + safe placeholder `.invalid`, not an internal hostname. + ## ZFS Snapshot Naming **User-facing manual snapshots** must use `DD.mmm.YYYY` rendered through the diff --git a/LICENSE b/LICENSE index 994d9a1..3086101 100644 --- a/LICENSE +++ b/LICENSE @@ -1,7 +1,7 @@ BSD 3-Clause License Copyright (c) 2026, Sam (Samo Blatnik) and Clawdie contributors -Built on NanoClaw — Copyright (c) 2024 Peter Steinberger (MIT License) +Built on NanoClaw — Copyright (c) 2024 Gavriel (MIT License) All rights reserved. Redistribution and use in source and binary forms, with or without diff --git a/docs/LOCAL-KNOWLEDGE-BOOTSTRAP.md b/docs/LOCAL-KNOWLEDGE-BOOTSTRAP.md index 826e9ed..505993b 100644 --- a/docs/LOCAL-KNOWLEDGE-BOOTSTRAP.md +++ b/docs/LOCAL-KNOWLEDGE-BOOTSTRAP.md @@ -10,14 +10,14 @@ provider is configured. This means: -- Brain A ships prebuilt -- Brain A imports into the `db` jail during bootstrap -- Brain B remains separate and evolves later +- Agent System Skills ship prebuilt +- Agent System Skills import into the `db` jail during bootstrap +- User-Agent Memory remains separate and evolves later - provider keys are not required for initial install ## Definitions -### Brain A +### Agent System Skills Built-in Clawdie knowledge: @@ -26,7 +26,7 @@ Built-in Clawdie knowledge: - product skills - curated support content shipped with the repo/release -### Brain B +### User-Agent Memory Runtime/user memory: @@ -36,14 +36,14 @@ Runtime/user memory: ## Default Strategy -1. Build Brain A outside the user install flow. -2. Ship Brain A as a versioned artifact. -3. Import Brain A into the local `db` jail during bootstrap. +1. Build Agent System Skills outside the user install flow. +2. Ship Agent System Skills as a versioned artifact. +3. Import Agent System Skills into the local `db` jail during bootstrap. 4. Add production LLM keys later for live agent execution. ## Step-by-Step -### Step 1: Select Brain A source content +### Step 1: Select Agent System Skills source content Start with a fixed allowlist: @@ -82,13 +82,13 @@ Allowed paths: The install path should not depend on either being available on the target host. -### Step 4: Export a Brain A artifact +### Step 4: Export an Agent System Skills artifact Ship an importable artifact, not a live PostgreSQL data directory. Recommended first format: -- SQL dump for Brain A tables +- SQL dump for Agent System Skills tables - metadata JSON next to it Metadata must include: @@ -107,14 +107,14 @@ During install: 1. create `{agent}-db` 2. install PostgreSQL + pgvector 3. apply schema -4. import Brain A SQL artifact +4. import Agent System Skills SQL artifact 5. verify metadata and row counts -This is the moment Brain A becomes available locally. +This is the moment Agent System Skills become available locally. ### Step 6: Defer provider setup -Only after Brain A import succeeds: +Only after Agent System Skills import succeeds: - prompt for production provider keys - write keys to `.env` @@ -123,16 +123,16 @@ Only after Brain A import succeeds: This keeps onboarding useful even before provider setup. -### Step 7: Support local Brain A rebuild later +### Step 7: Support local Agent System Skills rebuild later After install, allow local updates from git/Gitea changes. Recommended evolution path: -1. detect changed Brain A source files +1. detect changed Agent System Skills source files 2. re-chunk changed files only 3. re-embed changed chunks locally -4. update Brain A overlay/current index +4. update the Agent System Skills overlay/current index Preferred local backend direction: @@ -142,17 +142,17 @@ Storage remains in the `db` jail. ## First Implementation Rules -- default = import prebuilt Brain A +- default = import prebuilt Agent System Skills - no mandatory online provider during install - no mandatory local model during install -- keep Brain A and Brain B separate +- keep Agent System Skills and User-Agent Memory separate - keep the `db` jail as storage/query layer - do not store raw Postgres data directories in git ## Immediate Follow-Up -1. Define the exact Brain A source allowlist +1. Define the exact Agent System Skills source allowlist 2. Define the first chunking policy 3. Define artifact schema + metadata contract 4. Fold built-in knowledge import into the default `db` bootstrap sequence -5. Add provider setup after Brain A import, not before +5. Add provider setup after Agent System Skills import, not before diff --git a/examples/astro-cv/README.md b/examples/astro-cv/README.md index 1b7f5c3..e267dae 100644 --- a/examples/astro-cv/README.md +++ b/examples/astro-cv/README.md @@ -1,5 +1,9 @@ # Starlight Starter Kit: Basics +Prototype note: this Starlight example is not the recommended first deployment +path for Clawdie on FreeBSD. The v1 `cms` jail route should prefer a minimal +Astro site without `sharp` or Astro image optimization. + [![Built with Starlight](https://astro.badg.es/v2/built-with-starlight/tiny.svg)](https://starlight.astro.build) ``` diff --git a/html/clawdie/clawdie-eng-v1.md b/html/clawdie/clawdie-eng-v1.md index 1eb089a..8fc7e98 100644 --- a/html/clawdie/clawdie-eng-v1.md +++ b/html/clawdie/clawdie-eng-v1.md @@ -28,10 +28,10 @@ on FreeBSD. She lives on your own hardware, connects through Telegram, remembers everything in a Postgres database, and is accessible via a tmux glass-pane console. No corporate cloud. No subscription. No data leaving your server. -She is built on the **OpenClaw** ecosystem — -the open source personal AI assistant framework created by -Peter Steinberger (https://github.com/steipete) — -and adapted to run on FreeBSD with a Tailscale-secured infrastructure. +She is built on the **OpenClaw** line. +Peter Steinberger's OpenClaw set the broader ecosystem, +NanoClaw carried that line into a lean upstream assistant, +and Clawdie adapts it to run on FreeBSD with a Tailscale-secured infrastructure. Building a working AI assistant is constant work. Clawdie is actively developing. Our mission is always one step ahead — connecting the assistant to the physical @@ -58,9 +58,10 @@ built independently by developers and hardware makers around the world. We stand on their shoulders. ### OpenClaw -The original. Personal AI assistant you run on your own devices. +The original direction. Personal AI assistant you run on your own devices. Multi-channel (Telegram, WhatsApp, Slack, Discord), voice, browser automation. -Created by Peter Steinberger — the foundation Clawdie is built on. +Created by Peter Steinberger — the broader foundation that later inspired +NanoClaw and, eventually, Clawdie. TypeScript · Node ≥22 · MIT · openclaw.ai https://github.com/openclaw/openclaw diff --git a/html/clawdie/docs/install.html b/html/clawdie/docs/install.html index f7492a1..6bd9d2c 100644 --- a/html/clawdie/docs/install.html +++ b/html/clawdie/docs/install.html @@ -347,13 +347,13 @@ npm run wizard Auto-advance: 9s
01 / 11 — Welcome

This wizard locks in the operator account, SSH bootstrap, deployment profile, local code hosting, service jails, and provider settings before writing .env.

Architecture choices stay early so jail roles and reserved IPs remain stable.

Enter = continueEsc = exit
-
02 / 11 — Operator User

Choose the operator account that will exist inside controlplane for SSH access, repo checkout, screenshots, and operator tooling.

Username:clawdie

Default is clawdie. Replace it if you want to use your own operator account name.

Type = editAllowed: a-z 0-9 _ -
-
03 / 11 — Controlplane SSH Method

Host → controlplane SSH is bootstrapped separately from the later controlplane → host automation key.

▶
Generate dedicated host key
Recommended when the operator differs from the installer user.
 
Use existing public key
Only .pub files are listed. Private keys are never copied.
 
Paste public key manually
Fallback when autodetect finds nothing useful.
Authorized key target/home/<operator-user>/.ssh/authorized_keys
-
04 / 11 — Deployment Profile
 
Minimal
Controlplane + database only.
▶
Standard
Controlplane + database + local git + CMS.
 
Full
Standard + full GUI desktop.
Default profileStandard
+
02 / 11 — Operator User

Choose the operator account used for host-side setup, repo checkout, screenshots, and service administration.

Username:clawdie

Default is clawdie. Replace it if you want to use your own operator account name.

Type = editAllowed: a-z 0-9 _ -
+
03 / 11 — Operator Access Method

Host-side setup can reuse an existing public key or generate a dedicated one for operator access and later service automation.

▶
Generate dedicated host key
Recommended when the operator differs from the installer user.
 
Use existing public key
Only .pub files are listed. Private keys are never copied.
 
Paste public key manually
Fallback when autodetect finds nothing useful.
Authorized key target/home/<operator-user>/.ssh/authorized_keys
+
04 / 11 — Deployment Profile
 
Minimal
Worker + database only.
▶
Standard
Worker + database + local git + CMS.
 
Full
Standard + full GUI desktop.
Default profileStandard
05 / 11 — Code Hosting
 
External only
Bootstrap and clone from a remote Git URL.
▶
Plain local git
Bare repositories in a dedicated git jail.
 
Local Gitea
Plain local git plus a lightweight web UI.
Standard / Full defaultPlain local git
06 / 11 — Remote Git URL

This step only appears when External only is selected for code hosting.

Remote URL:https://codeberg.org/Clawdie/Clawdie-AI.git

Use this when bootstrap should come from Codeberg, a LAN mirror, or another self-hosted remote.

Exampleshttps://... or ssh://git@...
07 / 11 — Service Toggles
▶
CMS
Astro + Strapi in the dedicated cms jail.
 
Ollama
Optional local inference and embeddings in a separate jail.
 
GUI desktop
Only available for the Full profile.
DefaultCMS on, Ollama off
-
08 / 11 — Network Configuration

Lower IP numbers are reserved for more foundational services.

 
.2 controlplane
Operator runtime and glasspane.
 
.3 db
PostgreSQL + pgvector.
 
.4 git
Local repositories.
 
.5 cms
Astro + Strapi.
 
.6 ollama
Optional local inference.
 
.7 browser
Reserved browser automation / GUI desktop.
Default subnet10.0.0.0/24
+
08 / 11 — Network Configuration

Lower IP numbers are reserved for more foundational services.

 
.2 reserved
Compatibility slot only, no active jail role.
 
.3 db
PostgreSQL + pgvector.
 
.4 git
Local repositories.
 
.5 cms
Astro + Strapi.
 
.6 ollama
Optional local inference.
 
.150 browser
Reserved browser automation / GUI desktop.
Default subnet10.0.0.0/24
09 / 11 — Identity and Provider

Set the assistant name, choose the provider, and add the matching API key before Telegram and protected-path credentials.

▶
Assistant identity
Default name is Clawdie.
 
AI provider
z.ai, OpenRouter, OpenAI, Anthropic, or Claude subscription.
 
API key
Stored in .env, never in source code.
10 / 11 — Telegram and Protected Paths

Finish the operator-facing services:

▶
Telegram bot
Bot token from @BotFather goes into .env.
 
Protected paths
Generate or set the password for /screenshots/ and similar endpoints.
SecretsStored outside git
11 / 11 — Summary and Install

Review the final configuration, write .env, then hand over to the setup steps that create jails, install packages, and configure services.

▶
Summary
Operator user, SSH bootstrap, profile, code hosting, service toggles, network, and provider.
 
Installation
Environment, network, jail, mounts, register, service, verify.
ControlsDots = jump • 9s auto-cycle
@@ -377,7 +377,7 @@ npm run wizard
.2 - controlplane — AI agent runtime, glasspane console, Telegram interface + reserved — legacy compatibility slot, not an active current-main jail role
.3 @@ -396,21 +396,13 @@ npm run wizard ollama — Local LLM inference (optional)
- .7 + .101+ + workers — Jailed agent execution starts in the high range to avoid colliding with foundational services +
+
+ .150 browser — Reserved for Playwright/CDP
-
- .8 - cnc — TODO: future CNC operations jail -
-
- .9 - monitor — TODO: future observability jail -
-
- .10 - runner — TODO: future background jobs jail -
@@ -440,27 +432,31 @@ npm run wizard
Password generation and .env configuration
-

Step 1 — Credential Generation

-

- Three database passwords generated with Python secrets, - appended to .env. Passwords are visible once in the screenshot, - then read from environment variables in all subsequent steps. -

-
-
+

Step 1 — Credential Generation

+

+ Historical screenshot from the earlier prototype. Current + main generates or preserves the split-brain database + secrets in .env and rewrites the derived + SKILLS_DB_URL and MEMORY_DB_URL values + from the chosen AGENT_NAME, subnet, and passwords. +

+
+
PostgreSQL role and database creation
-

Step 2 — Database Setup

-

- PostgreSQL roles created inside the db jail via jexec: - postgres admin, clawdie_app, and strapi_user. - Passwords sourced from .env — no hardcoding. - Verified with \du and \l showing 3 roles and 2 databases. -

-
-
+

Step 2 — Database Setup

+

+ Historical screenshot from the earlier prototype. Current + main provisions a dedicated split-brain + {agent}-db jail, creates separate skills and memory + roles/databases, sets passwords from .env, binds + PostgreSQL to the jail IP, and verifies host-side connectivity to + both required databases before the step succeeds. +

+ +
ZFS snapshots for rollback safety @@ -526,25 +522,27 @@ npm run wizard Each can be invoked independently:

- 
# Full sequence after wizard
-npm run setup --step environment     # Detect platform, check prereqs
-npm run setup --step network         # Write IP configuration to .env
-npm run setup --step jail            # Create Bastille jails on ZFS
-npm run setup --step groups          # Sync Telegram groups to DB
-npm run setup --step register        # Register agent-controlled channels
-npm run setup --step mounts          # Configure nullfs mounts for jail
-npm run setup --step telegram-auth   # Authenticate with Telegram bot
-npm run setup --step service         # Create rc.d service file
-npm run setup --step verify          # Final health check
+
# Full sequence after wizard
+npm run setup -- --step environment      # Detect platform and prerequisites
+npm run setup -- --step pi-config        # Validate pi/provider configuration
+npm run setup -- --step jails --create   # Provision the default worker jail
+npm run setup -- --step db               # Provision the mandatory DB jail and databases
+npm run setup -- --step git              # Provision the default local git jail and bare repository mirror
+npm run setup -- --step cms              # Provision the cms jail, nginx, Astro, and internal Strapi seed baseline
+npm run setup -- --step hosts            # Write the managed home.arpa hosts block for host and jails
+npm run setup -- --step mounts           # Validate and configure allowed mounts
+npm run setup -- --step telegram-auth    # Verify Telegram bot token
+npm run setup -- --step service          # Create rc.d service file
+npm run setup -- --step verify           # Final health check
Jail creation

- The jail step runs Bastille with thin jails (-T) - and ZFS backing (-B). Jails are created at - /usr/local/bastille/jails/controlplane/, each with a static IP - on the warden0 bridge, a hostname like - controlplane.agent.local, and FreeBSD 15.0-RELEASE as the base. + The current jails step provisions the default + {AGENT_NAME}-worker profile from src/jail-config.ts. + The bridge name is warden0; jail naming and hostnames derive + directly from AGENT_NAME and the internal home.arpa + zone.

@@ -559,7 +557,7 @@ npm run setup --step verify # Final hea
▵

Verify Jails

-

bastille list should show controlplane and db running. Jails live at /usr/local/bastille/jails/. Access with bastille console controlplane.

+

bastille list should show your derived worker jail, typically {agent}-worker. Jails live at /usr/local/bastille/jails/. Access with bastille console <agent>-worker.

@@ -573,14 +571,14 @@ npm run setup --step verify # Final hea
▵

Glasspane Console

-

Attach with tmux attach -t clawdie to see the 3-pane console: gateway, shell, and btop.

+

Use npm run doctor after service start to check the host, pipeline, most recent jail run timestamps, and split-brain DB/artifact readiness.

▵
-

Configure nginx

-

Set up vhosts for your domain. Let's Encrypt certificates auto-renew via acme.sh.

+

Verify PostgreSQL

+

The current setup flow expects the dedicated {agent}-db jail. Confirm that SKILLS_DB_URL and MEMORY_DB_URL point at your configured database IP before you start the service for real use.

@@ -593,12 +591,13 @@ npm run setup --step verify # Final hea
Common issues -

Gateway missing: Jails created without default gateway. Fix with bastille cmd controlplane route add default 10.0.0.1

-

PostgreSQL SYSVIPC: Database jail needs allow.sysvipc=1 in /usr/local/bastille/jails/db/jail.conf. Restart jail after change.

-

Sharp/image errors: Astro builds fail on FreeBSD due to native deps. Install vips inside CMS jail: bastille pkg cms install graphics/vips

+

Wrong setup syntax: Use npm run setup -- --step ..., not npm run setup --step ....

+

Worker jail missing: The default jails step is a status check. Add --create when you actually want Bastille to provision {agent}-worker.

+

Gateway missing: If networking is incomplete inside the worker jail, verify the warden0 bridge and rerun npm run setup -- --step jails --create.

+

Astro image pipeline: For the first FreeBSD deployment, avoid sharp entirely. Keep images in public/ and use the minimal Astro template. Only if you later adopt the heavier Starlight/prototype path should you consider adding graphics/vips to the cms jail.

pf blocking: Ensure jail subnet (10.0.0.0/24) is in nat rules. Check with pfctl -s nat.

Passwords lost: All secrets live in .env (gitignored). If lost, regenerate with python3 -c "import secrets; print(secrets.token_urlsafe(32))" and update PostgreSQL roles.

-

Jail not starting: Check /usr/local/bastille/jails/controlplane/ exists. If not, re-run npm run setup --step jail.

+

Jail not starting: Check that /usr/local/bastille/jails/<agent>-worker/ exists. If not, re-run npm run setup -- --step jails --create.

diff --git a/html/clawdie/docs/split-brain.html b/html/clawdie/docs/split-brain.html index 087adbc..dd906bd 100644 --- a/html/clawdie/docs/split-brain.html +++ b/html/clawdie/docs/split-brain.html @@ -31,23 +31,24 @@

Split Brain

-

Built-in local knowledge first, dynamic user memory later

+

Agent System Skills first, User-Agent Memory kept separate

- Clawdie is moving toward a split-brain memory model. The goal is to make - first install useful before any production LLM provider is configured, while - keeping user memory flexible and separate. + Clawdie uses a split-brain runtime model so first install is useful + before any production provider is configured, while user memory stays + flexible and separate from built-in operating knowledge.

-

Brain A

+

Agent System Skills

- Brain A is the built-in local knowledge that ships with Clawdie: - install guides, operator docs, and product skills. It is prepared before - user install and imported into the db jail during bootstrap. + Agent System Skills are the built-in local knowledge that ships with + Clawdie: install guides, operator docs, product skills, and curated + support content. They are prepared before user install and imported + into the db jail during bootstrap.

  • No provider keys required for first install
    • @@ -59,10 +60,11 @@
    -

    Brain B

    +

    User-Agent Memory

    - Brain B is the dynamic side: user preferences, operator notes, and future - agent-specific memories such as mevy or bob. + User-Agent Memory is the dynamic side: user preferences, operator + notes, and future agent-specific memories such as + mevy or bob.

    • Separate lifecycle from built-in knowledge
      • @@ -76,18 +78,18 @@

      Why it matters

      - Most AI products ask for provider keys too early. Clawdie is moving - in the opposite direction: import built-in local knowledge first, then - add live provider configuration when the operator is ready. + Most AI products ask for provider keys too early. Clawdie goes in + the opposite direction: import built-in operating knowledge first, + then add live provider configuration when the operator is ready. 

      bootstrap system
-  -> import Brain A into db jail
+  -> import Agent System Skills into db jail
   -> local built-in knowledge is ready
   -> add production LLM keys later

      - The bootstrap step that imports Brain A lives in + The bootstrap step that imports Agent System Skills lives in setup/skills-memory.ts.

      diff --git a/html/clawdie/guides/nanoclaw-upstream.html b/html/clawdie/guides/nanoclaw-upstream.html index 9624679..0c6f405 100644 --- a/html/clawdie/guides/nanoclaw-upstream.html +++ b/html/clawdie/guides/nanoclaw-upstream.html @@ -35,11 +35,13 @@

      - Clawdie is built on NanoClaw - — the open source personal AI assistant framework by - Peter Steinberger, - adapted for FreeBSD. The upstream toggle lets you see what new commits are - available in the NanoClaw project and decide what to apply to your installation. + NanoClaw + is an upstream project by Gavriel in the broader OpenClaw line inspired by + Peter Steinberger's + OpenClaw. + Clawdie is the FreeBSD-first fork in that lineage. The upstream toggle lets + you see what new commits are available in NanoClaw and decide what to + apply to your installation.

      @@ -61,6 +63,16 @@

      +
      + Built on giants' shoulders +

      + OpenClaw set the broader direction. NanoClaw carried that line into a + lean upstream personal assistant. Clawdie takes the same line into + FreeBSD and the wider OSA + stack. +

      +
      +
      diff --git a/html/clawdie/index.html b/html/clawdie/index.html index 8e0c478..2ee0324 100644 --- a/html/clawdie/index.html +++ b/html/clawdie/index.html @@ -707,12 +707,13 @@ No subscription. No data leaving your server.

      - Built on NanoClaw — the open source personal AI assistant - framework originally conceived by - Peter Steinberger - — adapted for FreeBSD with native jail isolation, ZFS snapshots, - and a pi-driven setup flow. We follow NanoClaw upstream closely - and contribute FreeBSD-specific work back. + Built on giants' shoulders: Peter Steinberger's + OpenClaw set the broader direction, NanoClaw + by Gavriel carried that line into a lean personal-assistant upstream, + and Clawdie takes it onto FreeBSD with native jail isolation, ZFS + snapshots, and a pi-driven setup flow. The same stack ties into the + wider OSA + mission.

      The FreeBSD deployment path is actively being built and proven in diff --git a/html/clawdie/license.html b/html/clawdie/license.html index b308bc2..05341f4 100644 --- a/html/clawdie/license.html +++ b/html/clawdie/license.html @@ -47,12 +47,14 @@

      Why BSD-3 over MIT

      - Our upstream, + Our MIT-licensed upstream base comes from NanoClaw - by Peter Steinberger, - is MIT licensed. BSD-3-Clause is fully compatible with MIT — you can use - MIT code in a BSD-3 project without restriction. - We chose BSD-3 because it adds one thing MIT does not: + by Gavriel. NanoClaw itself sits in the broader + OpenClaw + line inspired by Peter Steinberger. + BSD-3-Clause is fully compatible with MIT — you can use MIT code in a + BSD-3 project without restriction. We chose BSD-3 because it adds one thing + MIT does not:

      @@ -196,8 +198,8 @@ BSD-2-Clause · BSD-3-Clause - NanoClaw - Peter Steinberger, 2024 + NanoClaw upstream + Gavriel, 2024 MIT — preserved in our LICENSE file @@ -261,7 +263,7 @@ 
      BSD 3-Clause License
 
 Copyright (c) 2026, Sam (Samo Blatnik) and Clawdie contributors
-Built on NanoClaw — Copyright (c) 2024 Peter Steinberger (MIT License)
+Built on NanoClaw — Copyright (c) 2024 Gavriel (MIT License)
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
diff --git a/html/docs-clawdie-si/DEPLOY.md b/html/docs-clawdie-si/DEPLOY.md
index 944c9f9..a16fa33 100644
--- a/html/docs-clawdie-si/DEPLOY.md
+++ b/html/docs-clawdie-si/DEPLOY.md
@@ -1,7 +1,7 @@
 # docs.clawdie.si Deployment
 
-**Status:** FreeBSD-first site assets ready
-**Date:** 13.mar.2026
+**Status:** Transitional static bridge deploy
+**Date:** 14.mar.2026
 
 ## Purpose
 
@@ -11,8 +11,8 @@ The site explains:
 
 - Clawdie on FreeBSD
 - the split-brain model
-- Brain A built-in local knowledge
-- Brain B user and future-agent memory
+- Agent System Skills built-in local knowledge
+- User/Agent Memory for user and future-agent memory
 - the relationship to NanoClaw upstream
 
 ## Layout
@@ -29,7 +29,20 @@ html/docs-clawdie-si/
     └── docs.clawdie.si.conf
 ```
 
-## FreeBSD deployment shape
+## Design direction
+
+This checked-in HTML deploy path is a bridge pattern, not the long-term target
+architecture.
+
+The target deployment model is:
+
+- Astro + Strapi live in the `cms` jail
+- nginx also lives in the `cms` jail
+- Clawdie does not require host nginx ownership
+- public exposure can happen through host PF, an existing reverse proxy, or a
+  direct public jail IP
+
+## Current bridge deployment shape
 
 Suggested host paths:
 
@@ -41,7 +54,7 @@ Host prerequisite:
 
 - `rsync` installed (`pkg install rsync`)
 
-## Preferred deploy path
+## Preferred bridge deploy path
 
 Run:
 
@@ -57,7 +70,7 @@ The script:
 4. runs `nginx -t`
 5. reloads nginx
 
-## Manual deploy steps
+## Manual bridge deploy steps
 
 1. Copy only public site files to `/usr/local/www/docs.clawdie.si`
 2. Install `nginx/docs.clawdie.si.conf` into `/usr/local/etc/nginx/vhosts/`
@@ -68,6 +81,7 @@ The script:
 ## Notes
 
 - This is a static site, not a reverse proxy app.
-- It is intended to be the public FreeBSD-facing documentation surface.
+- It is intended to keep the docs live while the Astro + `cms` jail refactor is
+  completed.
 - It complements the main `html/clawdie/` site rather than replacing it.
 - The homepage badge shows latest repository activity from Codeberg, not the live deploy timestamp.
diff --git a/html/docs-clawdie-si/guides/nanoclaw-upstream.html b/html/docs-clawdie-si/guides/nanoclaw-upstream.html
index ad0b498..e61dd9a 100644
--- a/html/docs-clawdie-si/guides/nanoclaw-upstream.html
+++ b/html/docs-clawdie-si/guides/nanoclaw-upstream.html
@@ -75,11 +75,13 @@

      - Clawdie is built on NanoClaw - — the open source personal AI assistant framework by - Peter Steinberger, - adapted for FreeBSD. The upstream toggle lets you see what new commits are - available in the NanoClaw project and decide what to apply to your installation. + NanoClaw + is an upstream project by Gavriel in the broader OpenClaw line inspired by + Peter Steinberger's + OpenClaw. + Clawdie is the FreeBSD-first fork in that lineage. The upstream toggle lets + you see what new commits are available in NanoClaw and decide what to + apply to your installation.

      @@ -101,6 +103,16 @@

      +
      + Built on giants' shoulders +

      + OpenClaw set the broader direction. NanoClaw carried that line into a + lean upstream personal assistant. Clawdie takes the same line into + FreeBSD and the wider OSA + stack. +

      +
      +
      diff --git a/html/docs-clawdie-si/guides/stripe-agents.html b/html/docs-clawdie-si/guides/stripe-agents.html index 8d7c473..b9c8840 100644 --- a/html/docs-clawdie-si/guides/stripe-agents.html +++ b/html/docs-clawdie-si/guides/stripe-agents.html @@ -88,6 +88,37 @@
      +
      +

      Runtime flow

      + +
      onboarding
+  -> configure Stripe now? (or skip)
+  -> write STRIPE_SECRET_KEY into .env
+
+host jail-runner
+  -> reads STRIPE_SECRET_KEY from .env
+  -> passes it to jailed runtime in stdin JSON secrets payload
+
+jailed agent runner
+  -> merges secret into SDK env only
+  -> registers Stripe MCP tools
+
+agent chat
+  -> can use customer, invoice, balance, subscription, and payment-link tools
      + +
      + Secret exposure boundary +

      + The Stripe key is entered during onboarding or added later to + .env. The host reads it, passes it to the jailed runtime + in the stdin JSON payload, and the jailed agent runner exposes it only + to the Stripe SDK/tool runtime. It is not mounted as a file into the jail. +

      +
      +
      + +
      +

      Setup

      diff --git a/html/docs-clawdie-si/license.html b/html/docs-clawdie-si/license.html index 15e4a9d..08f2e0a 100644 --- a/html/docs-clawdie-si/license.html +++ b/html/docs-clawdie-si/license.html @@ -86,12 +86,14 @@

      Why BSD-3 over MIT

      - Our upstream, + Our MIT-licensed upstream base comes from NanoClaw - by Peter Steinberger, - is MIT licensed. BSD-3-Clause is fully compatible with MIT — you can use - MIT code in a BSD-3 project without restriction. - We chose BSD-3 because it adds one thing MIT does not: + by Gavriel. NanoClaw itself sits in the broader + OpenClaw + line inspired by Peter Steinberger. + BSD-3-Clause is fully compatible with MIT — you can use MIT code in a + BSD-3 project without restriction. We chose BSD-3 because it adds one thing + MIT does not:

      @@ -235,8 +237,8 @@ BSD-2-Clause · BSD-3-Clause - NanoClaw - Peter Steinberger, 2024 + NanoClaw upstream + Gavriel, 2024 MIT — preserved in our LICENSE file @@ -300,7 +302,7 @@ 
      BSD 3-Clause License
 
 Copyright (c) 2026, Sam (Samo Blatnik) and Clawdie contributors
-Built on NanoClaw — Copyright (c) 2024 Peter Steinberger (MIT License)
+Built on NanoClaw — Copyright (c) 2024 Gavriel (MIT License)
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without