@rizom/ops 0.2.0-alpha.1 → 0.2.0-alpha.100

package/templates/rover-pilot/docs/onboarding-checklist.md

@@ -1,10 +1,43 @@
 # Onboarding Checklist
 
 1. Run `bun install` so the repo uses its pinned `@rizom/ops` version.
-2. Fill in `pilot.yaml`.
-3. Add or edit `users/<handle>.yaml`.
-4. Add the user to a cohort in `cohorts/*.yaml`.
-5. Run `bunx brains-ops render <repo>`.
-6. Run `bunx brains-ops onboard <repo> <handle>`.
-7. For fleet upgrades, edit `pilot.yaml.brainVersion` and push once; CI rebuilds the shared image tag, refreshes generated user env files, and redeploys affected users.
-8. Hand the MCP connection details to the user.
+2. Run `bunx brains-ops age-key:bootstrap <repo> --push-to gh`.
+3. Fill in `pilot.yaml`.
+   - keep your pinned `brainVersion`
+   - confirm shared selectors for `aiApiKey`, `gitSyncToken`, and `contentRepoAdminToken`
+   - use different tokens for `contentRepoAdminToken` and `gitSyncToken`: admin creates/checks content repos; sync is used by runtime directory-sync
+   - confirm `agePublicKey`
+4. Run `bunx brains-ops user:add <repo> <handle> --cohort <cohort>`.
+   - Discord is enabled by default for pilot users.
+   - if the user should be an anchor there, add `--anchor-id <discord-user-id>`.
+   - the command creates `users/<handle>.yaml`, `users/<handle>.secrets.yaml`, and the cohort membership without duplicating existing entries.
+5. Edit the generated user file if the anchor profile needs richer metadata.
+   - For browser/CMS-first onboarding, add `setup.delivery: email` and `setup.email` to the user file.
+   - Ensure `SETUP_EMAIL_API_KEY` and `SETUP_EMAIL_FROM` exist as GitHub Secrets before deploying any email-setup user.
+6. Run `bunx brains-ops render <repo>`.
+7. Run `bunx brains-ops ssh-key:bootstrap <repo> --push-to gh`.
+8. Run `bunx brains-ops cert:bootstrap <repo> --push-to gh`.
+9. Keep raw user secret material locally for now (`.env.local`, file-backed env vars, or equivalent local inputs), including `CONTENT_REPO_ADMIN_TOKEN` for operator onboarding.
+10. Run `bunx brains-ops secrets:encrypt <repo> <handle>`.
+11. Commit and push `users/<handle>.secrets.yaml.age`.
+12. Run `bunx brains-ops onboard <repo> <handle>`.
+13. Verify the deployed Rover contract:
+    - all presets:
+      - `https://<handle>.rizom.ai/health` returns `200`
+      - unauthenticated `POST https://<handle>.rizom.ai/mcp` returns the expected auth failure
+      - background jobs are not repeatedly failing, except for expected missing optional integrations
+    - for `presetOverride: default` users:
+      - `https://<handle>.rizom.ai/` loads the browser/site surface
+      - `https://<handle>.rizom.ai/cms` loads the CMS/login surface
+      - initial site build completes
+      - content repo exists and runtime sync is healthy
+      - passkey setup/handoff is completed
+14. For fleet upgrades, edit `pilot.yaml.brainVersion` and push once; CI rebuilds the shared image tag, refreshes generated user env files, and redeploys affected users.
+15. For Discord users, hand the Discord setup details to the user. For email-setup users, confirm they received the setup email and completed passkey registration.
+16. Hand over the browser defaults:
+    - Dashboard: `https://<handle>.rizom.ai/`
+    - CMS: `https://<handle>.rizom.ai/cms`
+    - GitHub token guidance for CMS access to the user's private content repo
+17. If they need direct client access, use OAuth/passkey-capable clients where possible.
+18. If you are also giving them a content repo workflow, describe it as optional and frame git/Obsidian as an advanced file-based path, not the default.
+19. Send `docs/user-onboarding.md` to the user as the pilot handoff guide.

package/templates/rover-pilot/docs/operator-playbook.md

@@ -33,6 +33,24 @@ When a push changes only deploy contract files and no generated `users/<handle>/
 
 They are scaffolded from `@rizom/ops`, then versioned in this repo like any other deploy contract.
 
+## Bootstrap flow
+
+For this fleet, operator-local secret material remains the source of truth during onboarding and rotation. The repo stores encrypted per-user secrets, not raw values.
+
+For a new pilot user, the operator bootstrap order is:
+
+1. `bunx brains-ops age-key:bootstrap <repo> --push-to gh`
+2. `bunx brains-ops ssh-key:bootstrap <repo> --push-to gh`
+3. `bunx brains-ops cert:bootstrap <repo> --push-to gh`
+4. `bunx brains-ops secrets:encrypt <repo> <handle>`
+5. `bunx brains-ops onboard <repo> <handle>`
+
+`age-key:bootstrap` keeps a repo-local canonical age identity under `.brains-ops/age/identity.txt`, writes the matching public recipient to `pilot.yaml.agePublicKey`, and can push the private key to GitHub as `AGE_SECRET_KEY`.
+
+The shared cert bootstrap writes local cert artifacts under `.brains-ops/certs/shared/`, which stays repo-local and ignored by git.
+
+Preview hosts use the shape `<handle>-preview.rizom.ai`, so one wildcard origin cert for `*.rizom.ai` covers both the primary and preview hosts for every pilot user.
+
 ## Upgrading operator behavior
 
 When `@rizom/ops` changes the scaffolded deploy contract:
@@ -42,6 +60,128 @@ When `@rizom/ops` changes the scaffolded deploy contract:
 3. review the resulting changes to `.env.schema`, `deploy/scripts/`, and workflows in git
 4. commit the updated deploy artifacts together
 
+## Rover verification notes
+
+Use the verification script after deploy:
+
+```sh
+bunx brains-ops verify-user . <handle>
+```
+
+It checks every Rover preset:
+
+- `https://<handle>.rizom.ai/health` should return `200`
+- unauthenticated `POST https://<handle>.rizom.ai/mcp` should return the expected auth failure
+- background jobs should not be repeatedly failing, except for expected missing optional integrations
+
+Additional `rover:core` note:
+
+- Rover core is MCP-only; a bare `GET /` may return `401`, which does not indicate a bad deploy.
+
+For `preset: default`, the script also checks:
+
+- `https://<handle>.rizom.ai/` loads the browser/site surface
+- `https://<handle>.rizom.ai/cms` loads the CMS/login surface
+
+Manual checks that remain:
+
+- initial site build is correct for the expected content/theme
+- content repo exists and runtime sync is healthy beyond the basic `/health` response
+- passkey setup/handoff is completed from the setup email
+
+## One-user `rover:default` baseline canary
+
+Run this before adding custom site/theme packages or rolling a larger browser/CMS-first cohort.
+
+1. Create or choose a canary cohort with the default preset:
+
+   ```yaml
+   presetOverride: default
+   ```
+
+2. Add exactly one canary user to that cohort.
+3. For browser/CMS-first onboarding, configure setup email in `users/<handle>.yaml`:
+
+   ```yaml
+   setup:
+     delivery: email
+     email: user@example.com
+   ```
+
+4. Encrypt the user's secrets and commit only the `.age` file.
+5. Run `bunx brains-ops onboard . <handle>`.
+6. Run `bunx brains-ops verify-user . <handle>` with no custom site/theme overrides.
+7. Ask the user to complete passkey setup from the setup email.
+8. Continue to visual customization only after the canary is healthy.
+
+Rollback:
+
+- move the canary back to a core cohort, or remove `presetOverride: default` from the cohort
+- reconcile generated outputs
+- rebuild/redeploy the affected user
+
+## Setup email checklist
+
+Use this for browser/CMS-first users who should receive their own first-passkey setup link by email.
+
+1. Add setup delivery to the user file:
+
+   ```yaml
+   setup:
+     delivery: email
+     email: user@example.com
+   ```
+
+2. Configure these GitHub Secrets before deploy:
+   - `SETUP_EMAIL_API_KEY`
+   - `SETUP_EMAIL_FROM`
+
+3. Reconcile/deploy the user or cohort:
+   - `bunx brains-ops onboard . <handle>`
+   - or `bunx brains-ops reconcile-cohort . <cohort>`
+
+4. Verify the generated `users/<handle>/brain.yaml` contains `auth-service.setupEmail` and `email-resend` config.
+5. Ask the user to complete passkey setup from the email link, then use:
+   - Dashboard: `https://<handle>.rizom.ai/`
+   - CMS: `https://<handle>.rizom.ai/cms`
+
+Notes:
+
+- The setup URL is generated and sent by the running brain; operators should not scrape logs or SSH into the instance to retrieve it.
+- The auth service owns setup email dedupe. It should not resend for the same persisted setup token after restart, but should retry failed delivery and resend after token rotation.
+- `SETUP_EMAIL_FROM` is not marked required because fleets without email setup can omit it, but it is required for users with `setup.delivery: email`.
+
+## Discord bot token checklist
+
+Use this when enabling Discord for a pilot user.
+
+1. Pick the user handle (for example `smoke`).
+2. Open the Discord Developer Portal.
+3. Create a **new application** for that user's rover.
+4. Add a **Bot** to the application.
+5. Copy the bot token.
+6. Put that value in `.env` or `.env.local` in this repo as `DISCORD_BOT_TOKEN=...` while onboarding that user.
+7. Keep `discord.enabled: true` in `users/<handle>.yaml` unless you explicitly want to disable the primary pilot interface.
+8. Encrypt the current per-user secret payload:
+   - `bunx brains-ops secrets:encrypt . <handle>`
+9. Reconcile/deploy the user or cohort:
+
+- `bunx brains-ops onboard . <handle>`
+- or `bunx brains-ops reconcile-cohort . <cohort>`
+
+11. In the Discord Developer Portal, generate an install URL and invite the bot to the right server.
+12. Send a test message in Discord and confirm the rover responds.
+
+Notes:
+
+- Use **one bot token per user/rover**.
+- Do not reuse the same Discord bot token across multiple pilot users.
+- Discord is the default pilot interface moving forward.
+- The encrypted `users/<handle>.secrets.yaml.age` file is the durable checked-in deploy input; your local env is only the operator staging source.
+- Direct MCP client access should use OAuth/passkey-capable clients where possible.
+- When explaining the content workflow, describe it first as a normal **git repo** of **markdown/text files**.
+- Position **Obsidian** as optional: it is just one possible editor for those same files, not the default requirement.
+
 ## Recovery notes
 
 Document known failure modes, recovery steps, and operator notes here.

package/templates/rover-pilot/docs/user-onboarding.md

@@ -0,0 +1,339 @@
+# Rover Pilot User Onboarding
+
+Welcome to the Rover pilot.
+
+This guide is for first-time Rover users. You do not need prior experience with Rover, MCP, git, GitHub, or Obsidian to get started.
+
+## What Rover is
+
+Rover is your private AI assistant for working with your own notes, links, and ideas.
+
+For the current pilot, the normal core experience is:
+
+- **Passkey setup email** — your secure first step
+- **Discord** — the main chat interface when enabled for your pilot
+- **Dashboard** — your browser overview at `https://<handle>.rizom.ai/`
+- **MCP** — optional direct access from OAuth/passkey-capable AI clients
+
+Some users may also receive:
+
+- **CMS** access at `https://<handle>.rizom.ai/cms`
+- **GitHub/content repo** access for editing the underlying markdown files
+- **Obsidian** instructions for a local file-based workflow
+
+If we did not explicitly give you CMS, GitHub, MCP, or Obsidian instructions, you can ignore those sections for now.
+
+## Start here: setup
+
+1. Open the setup email from Rover.
+2. Click the passkey setup link.
+3. Register a passkey in your browser.
+4. Open your Dashboard: `https://<handle>.rizom.ai/`.
+5. If Discord is enabled for you, send Rover a first message there.
+6. If we asked you to test MCP, use the separate MCP connection instructions we sent for your pilot.
+
+## Your setup email
+
+The setup email contains a single-use passkey setup link.
+
+Treat that link like a temporary password:
+
+- do not forward it
+- use it once
+- expect it to expire
+- ask us for help if it has expired or does not work
+
+After you register your passkey, the setup link closes. Your passkey becomes the sign-in method for Rover's browser and OAuth-capable client flows.
+
+If your Rover already existed before you received this email, nothing is being reset. The email is just the secure handoff for registering your own passkey so you can sign in yourself.
+
+## Your first Rover session
+
+Start in **Discord** if it is enabled for your pilot. That is the normal first interface.
+
+### 1. Say hello
+
+Send:
+
+> What can you help me do, and what should I use you for?
+
+Rover should answer with a short overview of what it can do.
+
+### 2. Create your first note
+
+Ask Rover to save a simple note:
+
+> Save a note: I am trying Rover because I want a better way to collect ideas, links, and questions in one place.
+
+Or:
+
+> Help me save my first note.
+
+### 3. Add your first link
+
+Send Rover a link you want to remember:
+
+> Save this link and tell me why it might be useful later: https://example.com
+
+Or:
+
+> Add this as a link about tools I want to revisit: https://example.com
+
+Rover should save the link and, when possible, keep a short description of why it matters.
+
+### 4. Upload an existing Markdown doc
+
+If you already have notes or docs in Markdown, you do not need to retype them.
+
+Upload a `.md` file and ask Rover to save or import it:
+
+> Save this Markdown doc in my notes.
+
+Or:
+
+> Import this doc and tell me what it is about.
+
+This is often the fastest way to give Rover useful context.
+
+### 5. Ask Rover about what you just added
+
+After you have saved a note, link, or Markdown doc, ask Rover to reflect it back:
+
+> What have I added so far?
+
+Or:
+
+> What do you know about what I am interested in so far?
+
+This is the basic Rover loop: add material, then ask Rover to help you think with it.
+
+### 6. Try a more useful task
+
+Once Rover has a little context, try one of these:
+
+> Summarize my notes so far.
+
+> What themes do you see in what I have added?
+
+> Turn my rough note into a clearer paragraph.
+
+> Help me make a small reading list from the links I saved.
+
+These examples show the main scope of Rover: saving material, organizing it, reflecting on it, and helping you make something from it.
+
+### 7. Ask another agent
+
+If your pilot has agent-to-agent access enabled, we will tell you which other agents you can address and how to talk to them. Otherwise Rover should clearly say that this workflow is not available yet.
+
+## The default mental model
+
+If you remember only one thing, remember this:
+
+- **Discord** = talk to Rover, when enabled
+- **Dashboard** = browser overview
+- **MCP** = optional direct client integration through OAuth/passkey login
+- **CMS / git / Obsidian** = optional content-editing workflows when we enable them for you
+
+## What you will receive from us
+
+Depending on your pilot cohort, we will send you some or all of these:
+
+- a passkey setup email from Rover
+- this onboarding guide, or a link to it
+- confirmation that Discord is enabled for you, plus the invite/setup steps
+- your **Dashboard URL**: `https://<handle>.rizom.ai/`
+- CMS URL and GitHub token instructions, if CMS editing is enabled
+- private content repo access, if file-based editing is enabled
+- separate MCP connection instructions, if MCP testing is enabled
+- any extra instructions if we are testing a specific workflow with your cohort
+
+Keep setup links, GitHub tokens, and any MCP credentials separate. Do not paste the passkey setup link into an MCP client.
+
+## Discord
+
+Discord is the default chat interface when it is enabled for your pilot. It is separate from the passkey setup email: the email sets up browser/client identity, while Discord is where many users chat with Rover day to day.
+
+Use it to:
+
+- save quick notes
+- drop in links
+- ask questions
+- use Rover day to day without setting up a separate client
+
+If Discord is enabled, we will send the exact invite/setup steps separately.
+
+## Dashboard basics
+
+The Dashboard is the browser landing page for your Rover.
+
+Open it at:
+
+```text
+https://<handle>.rizom.ai/
+```
+
+Use it to confirm your Rover is up, see available endpoints, and orient yourself before using optional tools. This is not meant to be a public marketing website.
+
+## Optional: Working in the CMS
+
+If CMS is enabled for you, open:
+
+```text
+https://<handle>.rizom.ai/cms
+```
+
+The CMS is a browser editor for your Rover content. It may ask for GitHub access because your content lives in a private GitHub repo.
+
+Use the CMS when you want to:
+
+- create or edit notes in the browser
+- add existing Markdown docs
+- browse structured content collections
+- make cleaner edits than you would in chat
+
+A good first CMS task is:
+
+1. open the **Notes** collection
+2. create a note titled `Why I’m using Rover`
+3. write 3 to 5 sentences
+4. save it
+5. refresh the CMS and confirm the note is still there
+
+If the CMS asks for GitHub access, use the fine-grained GitHub token for your private Rover content repo. If you were not given CMS/GitHub instructions, skip this section.
+
+## Optional: direct MCP access
+
+MCP is an optional way to connect Rover directly to an AI client that supports remote HTTP MCP.
+
+Use MCP only if we ask you to test it or if you already use a client that supports remote HTTP / Streamable HTTP MCP servers.
+
+We will send MCP connection details separately when MCP testing is enabled. The normal hosted MCP path is `https://<handle>.rizom.ai/mcp`, but use the exact server URL we send for your pilot.
+
+### What the MCP login flow looks like
+
+If your client supports OAuth / browser login, the normal flow is:
+
+1. In your MCP client, add a remote MCP server.
+2. Enter the Rover MCP server URL we sent you.
+3. The client discovers Rover's OAuth settings automatically.
+4. The client opens a browser window for Rover login.
+5. You sign in with your passkey.
+6. Rover asks you to approve client access.
+7. The client receives an access token automatically.
+8. You can use Rover tools from that client.
+
+You should not need to copy a setup link into the client. The setup link is only for registering your first passkey.
+
+If your client asks for a token or other credential, use only the MCP instructions we sent separately. Treat any MCP credentials like a password. Do not share them.
+
+### Client-specific notes
+
+Different MCP clients support remote HTTP and OAuth at different speeds. If you are using Claude Desktop, Cursor, VS Code, MCP Inspector, or another client, tell us the exact version before assuming it should work.
+
+### If MCP does not work
+
+Send us:
+
+- the client name
+- the client version
+- the exact error message
+- a screenshot if possible
+- the server URL you entered, without any secret token
+
+Do not paste your passkey setup link into an MCP client.
+
+## Optional: git, text files, and Obsidian
+
+Rover content can also live as normal markdown/text files in a private GitHub repo.
+
+This workflow is optional. Use it only if we explicitly enabled it for you or if you want more control.
+
+If enabled, we will:
+
+1. create or confirm your private content repo
+2. invite your GitHub account to that repo
+3. send you the repo URL
+4. explain whether to use GitHub Desktop, command-line git, Obsidian, or the CMS
+
+You do not need GitHub repo access just to use Rover in Discord.
+
+## Wishlist: when Rover cannot do something yet
+
+Rover has a built-in wishlist.
+
+If you ask for something Rover cannot do yet, it should explain the limitation and save the request as a wish. This helps us see which missing capabilities matter most.
+
+## What to expect in the pilot
+
+This is a real working system, but it is still an early pilot. Expect some rough edges, setup steps that may still be a bit manual, and improvements during the pilot.
+
+## Privacy and boundaries
+
+For the pilot:
+
+- your Rover is deployed specifically for you
+- browser/client access uses passkeys/OAuth where supported
+- if you are using MCP, we will send separate access instructions
+- your content repo is private when repo access is enabled
+- avoid putting highly sensitive material into the pilot unless we have explicitly agreed that it is in scope
+
+If you are unsure whether something belongs in Rover, ask us first.
+
+## Troubleshooting
+
+### I did not receive the setup email
+
+Check spam/promotions first. If it is not there, tell us which email address we should use.
+
+### The setup link expired or does not work
+
+Reply to your Rover operator. We can rotate/reissue setup.
+
+### I opened the domain and it does not look like a normal public site
+
+That is expected. The root URL is your Dashboard, not a public marketing site.
+
+### The browser asks me to use a passkey
+
+That is expected after setup. Use the same passkey you registered from the setup email.
+
+### My MCP client cannot connect
+
+Send us the client name, version, exact error message, and a screenshot if possible.
+
+### The CMS asks for GitHub auth and I am not sure what to do
+
+That is expected only if CMS is enabled for you. Use the GitHub token instructions we sent for your private Rover content repo. If you did not receive those instructions, ask us before continuing.
+
+## What feedback helps us most
+
+We especially want to hear:
+
+- what was confusing during setup
+- whether the setup email and passkey flow made sense
+- whether Discord and Dashboard made sense
+- what felt useful immediately
+- what felt weak, awkward, or unclear
+- what you expected Rover to do but could not get it to do
+- whether you would keep using it after the pilot
+
+Short, honest feedback is perfect.
+
+## Quick handoff template
+
+When we onboard you, the message will look roughly like this:
+
+```text
+Setup email: sent to <email>
+Onboarding guide: attached / linked
+Dashboard URL: https://<handle>.rizom.ai/
+Discord enabled: yes/no
+Discord setup: <invite link or setup steps>
+MCP access: optional / enabled / not enabled
+MCP setup: sent separately if enabled
+CMS enabled: yes/no
+CMS URL: https://<handle>.rizom.ai/cms
+Content repo access: yes/no
+```
+
+If anything is unclear, reply with the exact error text or a screenshot and we will help.

package/templates/rover-pilot/package.json

@@ -3,6 +3,9 @@
   "private": true,
   "type": "module",
   "packageManager": "bun@__BUN_VERSION__",
+  "dependencies": {
+    "age-encryption": "^0.3.0"
+  },
   "devDependencies": {
     "@rizom/ops": "__BRAINS_OPS_VERSION__"
   }

package/templates/rover-pilot/pilot.yaml

@@ -6,3 +6,6 @@ contentRepoPrefix: rover-
 domainSuffix: .rizom.ai
 preset: core
 aiApiKey: AI_API_KEY
+gitSyncToken: GIT_SYNC_TOKEN
+contentRepoAdminToken: CONTENT_REPO_ADMIN_TOKEN
+agePublicKey: age1replace-with-your-public-key

package/templates/rover-pilot/users/alice.yaml

@@ -1,3 +1,7 @@
 handle: alice
+anchorProfile:
+  name: Alice Example
+  description: Replace this with Alice's real public profile summary.
 discord:
-  enabled: false
+  enabled: true
+  # anchorUserId: "123456789012345678"

package/dist/user-secret-names.d.ts

@@ -1,6 +0,0 @@
-export interface UserSecretNames {
-    gitSyncTokenSecretName: string;
-    mcpAuthTokenSecretName: string;
-    discordBotTokenSecretName: string;
-}
-export declare function deriveUserSecretNames(handle: string): UserSecretNames;

package/templates/rover-pilot/.kamal/hooks/pre-deploy

@@ -1,9 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-BRAIN_FILE="${BRAIN_YAML_PATH:-brain.yaml}"
-SSH_USER="$(ruby -e 'require "yaml"; config = YAML.load_file("deploy/kamal/deploy.yml") || {}; puts(config.dig("ssh", "user") || "root")')"
-IFS=',' read -ra HOSTS <<< "$KAMAL_HOSTS"
-for host in "${HOSTS[@]}"; do
-  scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null "$BRAIN_FILE" "${SSH_USER}@${host}:/opt/brain.yaml"
-done

package/templates/rover-pilot/deploy/Dockerfile

@@ -1,15 +0,0 @@
-ARG BUN_VERSION=1.3.10
-FROM oven/bun:${BUN_VERSION}-slim
-
-ARG BRAIN_VERSION
-WORKDIR /app
-
-RUN test -n "$BRAIN_VERSION" \
- && printf '{"name":"rover-pilot-runtime","private":true}\n' > package.json \
- && bun add @rizom/brain@$BRAIN_VERSION
-
-ENV XDG_DATA_HOME=/data
-ENV XDG_CONFIG_HOME=/config
-RUN mkdir -p /app/brain-data /data /config && chmod -R 777 /app/brain-data /data /config
-
-CMD ["sh", "-c", "exec ./node_modules/.bin/brain start"]

package/templates/rover-pilot/deploy/kamal/deploy.yml

@@ -1,39 +0,0 @@
-service: rover
-image: <%= ENV['IMAGE_REPOSITORY'] %>
-
-servers:
-  mcp:
-    hosts:
-      - <%= ENV['SERVER_IP'] %>
-
-proxy:
-  ssl:
-    certificate_pem: CERTIFICATE_PEM
-    private_key_pem: PRIVATE_KEY_PEM
-  hosts:
-    - <%= ENV['BRAIN_DOMAIN'] %>
-  app_port: 3333
-  healthcheck:
-    path: /health
-
-registry:
-  server: ghcr.io
-  username: <%= ENV['REGISTRY_USERNAME'] %>
-  password:
-    - KAMAL_REGISTRY_PASSWORD
-
-builder:
-  arch: amd64
-
-env:
-  clear:
-    NODE_ENV: production
-  secret:
-    - AI_API_KEY
-    - GIT_SYNC_TOKEN
-    - MCP_AUTH_TOKEN
-    - DISCORD_BOT_TOKEN
-
-volumes:
-  - /opt/brain-data:/app/brain-data
-  - /opt/brain.yaml:/app/brain.yaml