@rizom/ops 0.2.0-alpha.7 → 0.2.0-alpha.70

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

@@ -1,17 +1,33 @@
 # 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 ssh-key:bootstrap <repo> --push-to gh`.
-7. Run `bunx brains-ops cert:bootstrap <repo> <handle> --push-to gh`.
-8. Run `bunx brains-ops secrets:push <repo> <handle>`.
-9. Run `bunx brains-ops onboard <repo> <handle>`.
-10. Verify the deployed rover core contract:
+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`, `contentRepoAdminToken`, and `mcpAuthToken`
+   - 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.
+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 core contract:
     - `https://<handle>.rizom.ai/health` returns `200`
     - unauthenticated `POST https://<handle>.rizom.ai/mcp` returns `401`
-11. 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.
-12. Hand the MCP connection details to the user.
-13. Send `docs/user-onboarding.md` to the user as the pilot handoff guide.
+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. Hand the Discord setup details to the user.
+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, also hand over the MCP connection details.
+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

@@ -35,14 +35,21 @@ They are scaffolded from `@rizom/ops`, then versioned in this repo like any othe
 
 ## 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 ssh-key:bootstrap <repo> --push-to gh`
-2. `bunx brains-ops cert:bootstrap <repo> <handle> --push-to gh`
-3. `bunx brains-ops secrets:push <repo> <handle>`
-4. `bunx brains-ops onboard <repo> <handle>`
+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.
 
-`brains-ops cert:bootstrap` writes local cert artifacts under `.brains-ops/`, 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
 
@@ -63,6 +70,37 @@ Use these checks after deploy:
 - unauthenticated `POST https://<handle>.rizom.ai/mcp` should return `401 Unauthorized: Bearer token required`
 - a bare `GET /` may also return `401`; that is expected for rover core and does not indicate a bad deploy
 
+## 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.
+- MCP is optional and mainly for direct client access or specific testing workflows.
+- 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

@@ -2,18 +2,23 @@
 
 Welcome to the Rover pilot.
 
-This document is written for **first-time users**. You do **not** need prior experience with Rover, MCP, git, or the rest of the system to get started.
+This guide is written for **first-time 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.
 
-In this pilot, Rover is intentionally simple:
+In this pilot, the normal experience is:
 
-- you talk to it through an **MCP client**
-- **there is no website to browse**
-- Discord is optional
-- Obsidian fits through the git-sync/content-repo workflow, not as the main chat interface
+- **Discord** for chatting with Rover
+- the **Dashboard** in your browser at `https://<handle>.rizom.ai/`
+- the **CMS** in your browser at `https://<handle>.rizom.ai/cms`
+
+Optional workflows exist too:
+
+- **MCP** for direct client access from supported AI tools
+- **git** if you want to work with the underlying files directly
+- **Obsidian** if you want a nicer note-focused editor for those same files
 
 You can think of Rover as a private knowledge companion that helps you:
 
@@ -23,46 +28,184 @@ You can think of Rover as a private knowledge companion that helps you:
 - find patterns in what you have collected
 - think through questions with AI
 
+## The default mental model
+
+If you remember only one thing, remember this:
+
+- **Discord** = talk to Rover
+- **Dashboard** = browser overview
+- **CMS** = browser editing interface
+- **MCP** = optional direct client integration
+- **git / Obsidian** = optional file-based workflow
+
+Most pilot users should start with the first three.
+
 ## What you will receive from us
 
-We will send you the details you need to connect.
+We will send you the details you need to get started.
 
 That usually includes:
 
-- your Rover URL: `https://<handle>.rizom.ai/mcp`
-- your **Bearer token**
-- confirmation of whether Discord is enabled for you
+- confirmation that Discord is enabled for you, plus the invite/setup steps
+- your **Dashboard URL**: `https://<handle>.rizom.ai/`
+- your **CMS URL**: `https://<handle>.rizom.ai/cms`
+- if you will use the CMS, an invite to your **private** Rover content repo plus instructions for creating a GitHub token
+- if needed, your Rover MCP URL: `https://<handle>.rizom.ai/mcp`
+- if needed, your **Bearer token**
 - any extra instructions if we are testing a specific workflow with your cohort
 
-Treat the **Bearer token** like a password. Do not share it.
+If we give you a **Bearer token**, treat it like a password. Do not share it.
+
+## Start here: your first 5 minutes
+
+For most users, the best first setup is:
 
-## One important idea: MCP is just the connection method
+1. join the Discord server we send you
+2. open your Dashboard at `https://<handle>.rizom.ai/`
+3. open the CMS at `https://<handle>.rizom.ai/cms`
+4. when the CMS asks for GitHub access, use a fine-grained GitHub token with access to your private Rover content repo
+5. send a first message in Discord and make one small edit in the CMS
+
+A simple first chat message is:
+
+> What can you help me do, and what should I use you for?
+
+Or:
+
+> Help me save my first note.
 
-If you have never used MCP before, the shortest explanation is:
+A simple first CMS action is:
+
+- open the **Notes** collection
+- create a short note about why you want to use Rover
+- save it
+
+If Discord is not enabled for you yet, tell us and we will share the right next step.
+
+## One important idea: Discord + Dashboard + CMS are the default, MCP is optional
+
+If you are new to Rover, the shortest explanation is:
 
 - **Rover** is the assistant
-- **MCP** is the way your AI client connects to Rover
+- **Discord** is the default chat interface
+- the **Dashboard** is the default browser view
+- the **CMS** is the default browser editing interface
+- **MCP** is an optional direct connection method for supported AI clients
+
+You do not need to understand the protocol details unless we specifically ask you to use MCP.
+
+For most users, the practical meaning is simple:
+
+- join Discord
+- open your dashboard in the browser
+- use the CMS when you want to edit structured content directly
+- start using it
+
+If your cohort is also testing MCP, we will send the URL, Bearer token, and setup help separately.
+
+## Working in the CMS
+
+The CMS is the easiest way to edit Rover content in the browser.
+
+Use it when you want to:
+
+- create notes without touching git directly
+- edit existing content in a structured form
+- browse your collections in one place
+- make quick updates from the browser
+
+### Why the CMS asks for GitHub access
+
+Your Rover content lives in a **private GitHub repo**.
 
-You do not need to understand the protocol details.
+The CMS edits that repo for you.
 
-For the pilot, the practical meaning is simple:
+That is why it asks for a **GitHub token**.
 
-- open a supported client
-- add your Rover URL
-- paste your Bearer token
-- start talking to Rover
+In practice, that means:
 
-## What to use first
+- you can use the CMS without cloning the repo locally
+- your changes still go into your private content repo
+- if you later open that repo with git or Obsidian, you are looking at the same underlying content
 
-For most users, the easiest first setup is:
+### What to expect the first time you open it
 
-- **Claude Desktop** for talking to Rover
-- **Obsidian** only if you also want to work directly with markdown files later
-- **Discord** only if we explicitly enable it for you
+When you open `https://<handle>.rizom.ai/cms`, you should expect something like this:
 
-## How to connect
+1. the CMS asks you to authenticate with GitHub
+2. you enter the GitHub token we told you to create
+3. the CMS loads your content collections
+4. you can open an entry, edit it, and save your changes
 
-Use an MCP client that supports:
+If the CMS loads correctly, that is a good sign that:
+
+- your browser access is working
+- your repo access is working
+- the token is working
+
+### What you will see in the CMS
+
+The exact collections may change over time, but a normal pilot setup includes collections for things like:
+
+- **Notes**
+- links or saved resources
+- settings or other structured content
+
+The important idea is not the exact list — it is that the CMS is the browser-based editor for your Rover content.
+
+### A good first CMS task
+
+A good first CMS task is to create a short note.
+
+For example:
+
+- open **Notes**
+- create a new note
+- title it something like `Why I’m using Rover`
+- write 3 to 5 sentences
+- save it
+
+Then go back to Discord and ask Rover something like:
+
+> What do you know about why I’m using Rover so far?
+
+That connects the browser editing workflow with the chat workflow.
+
+### When to use Discord vs CMS
+
+A good rule of thumb is:
+
+Use **Discord** when you want to:
+
+- think out loud
+- ask questions
+- capture something quickly
+- use Rover as a day-to-day assistant
+
+Use the **CMS** when you want to:
+
+- deliberately create or revise content
+- browse existing entries
+- make cleaner edits than you would in chat
+- work in a more editor-like browser interface
+
+Use both together. That is the default pilot workflow.
+
+### If the CMS feels confusing
+
+That is useful feedback.
+
+Please tell us:
+
+- what part was confusing
+- whether the problem was authentication, navigation, editing, or saving
+- what you expected to happen instead
+
+We want to improve this workflow.
+
+## Optional: direct MCP access
+
+If we have asked you to use an MCP client, use one that supports:
 
 - **HTTP / Streamable HTTP MCP**
 - **Bearer token authentication**
@@ -77,9 +220,9 @@ If the client asks for a name, use something simple like:
 
 - `Rover (<handle>)`
 
-## Claude Desktop setup
+## Optional: Claude Desktop setup
 
-If your Claude Desktop version supports connecting to a **remote HTTP / Streamable HTTP MCP server**, enter:
+If we ask you to connect through Claude Desktop and your version supports a **remote HTTP / Streamable HTTP MCP server**, enter:
 
 - **Server URL:** `https://<handle>.rizom.ai/mcp`
 - **Authentication:** Bearer token
@@ -95,45 +238,108 @@ Or:
 
 If your Claude Desktop version only supports local MCP servers and not remote HTTP MCP cleanly, tell us what version you are using and we will help you.
 
-## Your first 5 minutes
+## Optional: git, text files, and Obsidian
 
-Once you are connected, try this sequence:
+The underlying content workflow is still a normal **git repo** with normal **markdown/text files**.
 
-### 1. Check that Rover responds
+But for this pilot, treat that as **optional**.
 
-Ask:
+Use direct git or file-based workflows only if you want more control.
 
-> What can you help me do?
+Obsidian is optional. It is just one possible editor for those files.
 
-### 2. Save a first note
+That means:
 
-Ask:
+- use **Discord** as the main way to talk to Rover
+- use the **Dashboard** and **CMS** as the normal browser workflow
+- use a normal editor plus **git** only if you want to browse, draft, and edit your files directly
+- use **Obsidian** only if you want a more note-focused interface for the same files
+- Rover can pick up those file changes through the normal git-sync / directory-sync flow
 
-> Save a note: I want to use Rover to collect ideas from my work, reading, and conversations.
+### Important: your content repo is private
 
-### 3. Save a useful link
+If you use the git/text-file workflow, you will be working in your own **private** GitHub repo.
 
-Ask:
+That means:
 
-> Save this link and note why it matters to me: <paste URL>
+- you do **not** need repo access just to use Rover in Discord
+- you **do** need GitHub access if you want to clone, edit, and push to your content repo
+- we will invite you only to **your own** content repo, not to the operator repo and not to other users' repos
 
-### 4. Ask Rover to reflect back what it knows
+### How you get access
 
-Ask:
+If you want the git/text-file workflow, we will:
 
-> Based on what I’ve stored so far, what themes are starting to emerge?
+1. create or confirm your private content repo
+2. invite your GitHub account to that repo
+3. ask you to accept the GitHub invite
+4. send you the repo URL
 
-### 5. Use it as a thinking partner
+### Authentication options
 
-Ask:
+To work with a private repo or the CMS, you need GitHub authentication.
 
-> I am thinking through a problem in my work. Help me structure the question and identify what context is missing.
+Usually the easiest order is:
+
+1. **GitHub sign-in** to accept the private repo invite
+2. a **fine-grained personal access token** for the CMS, with access to your private Rover content repo
+3. **GitHub Desktop** or normal git auth if you also want to clone the repo locally
+4. **SSH key** only if you already use git that way
+
+You do **not** need a GitHub token just to use Rover in Discord.
+You do **not** need an MCP Bearer token unless we explicitly ask you to use MCP.
+
+### If you want the local file workflow
+
+If we have already shared your content repo workflow with you, the normal setup is:
+
+1. clone your Rover content repo locally
+2. edit the markdown/text files in your normal editor, or open that same folder as an Obsidian vault if you prefer
+3. optionally install the **Obsidian Git** plugin if you want in-app commit/push/pull support
+4. edit or organize your notes there
+5. commit and push your changes through normal git, GitHub Desktop, or the Obsidian Git plugin
+6. let the normal git-sync flow carry those changes into Rover
+
+If we have **not** given you a direct content repo workflow yet, that is fine. You can ignore git, text files, and Obsidian for now and use Rover in Discord and the CMS. If we have also asked you to test MCP, you can use that too.
+
+## Discord (default chat interface)
+
+Discord is the default chat interface for this pilot.
+
+Think of it as the main place to:
+
+- save quick notes
+- drop in links to save
+- ask short or long questions
+- use Rover day to day without setting up a separate client
+
+Important:
+
+- **Discord is the main pilot chat interface**
+- the **Dashboard** and **CMS** are the main browser interfaces
+- MCP is **optional**
+- if Discord is enabled, we will send the exact invite/setup steps separately
+- for some pilot setups, Discord-enabled users may need to supply their own bot token
+
+If Discord is **not** enabled for you yet, ask us and we will tell you whether your cohort is on the Discord-first workflow.
+
+## Dashboard basics
+
+The Dashboard is the browser landing page for your Rover.
+
+Use it when you want to:
+
+- confirm the instance is up
+- see the browser-side operator surface
+- jump into the CMS quickly
+
+This is not meant to be a public website. It is part of your Rover control surface.
 
 ## Wishlist: when Rover cannot do something yet
 
 Rover has a built-in **wishlist**.
 
-This is important for first-time users because Rover will not be able to do everything yet.
+This matters because Rover will not be able to do everything yet.
 
 If you ask for something Rover cannot do, it should add that request to the wishlist instead of just failing silently.
 
@@ -185,52 +391,6 @@ If Rover cannot do what you asked, a good response from Rover is something like:
 
 If that does **not** happen, that is useful feedback for us too.
 
-## Obsidian
-
-Obsidian is part of the pilot through the **git-synced content repo workflow**, not through MCP.
-
-That means:
-
-- use **Claude Desktop** as the main way to talk to Rover
-- use **Obsidian** if you want to browse, draft, and edit markdown files directly
-- Rover can pick up those file changes through the normal git-sync / directory-sync flow
-
-A simple mental model:
-
-- **Claude Desktop** = talk to Rover
-- **Obsidian** = edit the underlying notes
-
-If we have already shared your content repo workflow with you, the simplest setup is:
-
-1. clone your Rover content repo locally
-2. open that folder as an Obsidian vault
-3. optionally install the **Obsidian Git** plugin if you want in-app commit/push/pull support
-4. edit or organize your markdown notes there
-5. commit and push your changes through normal git or the Obsidian Git plugin
-6. let the normal git-sync flow carry those changes into Rover
-
-If we have **not** given you a direct content repo workflow yet, that is fine. You can ignore Obsidian for now and use Rover purely through MCP.
-
-## Discord (optional)
-
-Discord is optional in this pilot.
-
-If it is enabled for you, think of it as a lightweight secondary interface for:
-
-- quick note capture
-- dropping in links to save
-- short questions when you do not want to open Claude Desktop
-
-Important:
-
-- **MCP remains the main interface**
-- Discord is **off by default**
-- if you want Discord, tell us explicitly
-- for this pilot, Discord-enabled users may need to supply their own bot token
-- if Discord is enabled, we will send the exact invite/setup steps separately
-
-If Discord is **not** enabled for you, that is completely normal.
-
 ## What to expect in the pilot
 
 This is a real working system, but it is still an early pilot.
@@ -250,18 +410,43 @@ That is normal. The point of the pilot is to learn from real use.
 For the pilot:
 
 - your Rover is deployed specifically for you
-- access to `/mcp` is protected by your Bearer token
+- if you are using MCP, access to `/mcp` is protected by your Bearer token
+- your content repo is private
 - you should 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 opened the domain and it does not look like a normal site
+### 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 website. The CMS lives at `/cms`. Rover also runs through Discord and, optionally, a direct MCP endpoint.
+
+### The CMS asks for GitHub auth and I am not sure what to do
+
+That is expected.
+
+Use the GitHub token we told you to create for your **private Rover content repo**.
 
-That is expected. In this pilot, **there is no website to browse**. Rover core is MCP-first.
+If you are missing one of these pieces, tell us:
 
-### I got an authentication error
+- you did not get the repo invite
+- you did not accept the repo invite yet
+- you are not sure how to create the token
+- the token was accepted but the CMS still does not load
+
+### The CMS loads, but I am not sure whether my change worked
+
+A good quick test is:
+
+1. edit a short note in the CMS
+2. save it
+3. refresh the CMS and confirm the change is still there
+4. ask Rover in Discord about that note
+
+If anything in that loop feels unclear, tell us exactly where it became confusing.
+
+### I got an authentication error in MCP
 
 Usually this means one of three things:
 
@@ -291,6 +476,7 @@ If that happens, send us:
 We especially want to hear:
 
 - what was confusing during setup
+- whether Discord, Dashboard, and CMS each 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
@@ -303,10 +489,17 @@ Short, honest feedback is perfect.
 When we onboard you, the message will look roughly like this:
 
 ```text
-Rover URL: https://<handle>.rizom.ai/mcp
+Discord enabled: yes/no
+Discord setup: <invite link or setup steps>
+Dashboard URL: https://<handle>.rizom.ai/
+CMS URL: https://<handle>.rizom.ai/cms
+CMS auth: GitHub token with access to your private Rover content repo
+MCP access: optional / enabled / not enabled
+
+If MCP is enabled:
+MCP URL: https://<handle>.rizom.ai/mcp
 Auth type: Bearer token
 Bearer token: <token>
-Discord enabled: 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,7 @@ contentRepoPrefix: rover-
 domainSuffix: .rizom.ai
 preset: core
 aiApiKey: AI_API_KEY
+gitSyncToken: GIT_SYNC_TOKEN
+contentRepoAdminToken: CONTENT_REPO_ADMIN_TOKEN
+mcpAuthToken: MCP_AUTH_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