Skip to content

Planning: wp-opencode setup tool #1

@chubes4

Description

@chubes4

Vision

wp-opencode is a setup tool that bootstraps a WordPress + Data Machine + OpenCode stack on a VPS, with a pluggable chat interface layer. The goal: run one script and get a fully operational AI-managed WordPress agent that you can talk to from anywhere.

Core Stack (always installed)

  • WordPress — the site
  • Data Machine — the brain (scheduling, memory, tools, publishing)
  • OpenCode — the hands (coding agent)
  • Homeboy — fleet ops CLI

Chat Interface Layer (pluggable)

The chat bridge is how you talk to your OpenCode agent. Pick one (or more):

Flag Bridge Platform Status
--chat kimaki Kimaki Discord ✅ Working (chubes-bot reference)
--chat telegram opencode-telegram-bot Telegram 🔍 Evaluating (44 ⭐)
--chat imessage TBD iMessage 🔜 Needs building
--chat sms TBD SMS/Text 🔜 Needs building
--chat slack TBD Slack 🔜 Needs building
--chat beeper TBD All (via Beeper) 💡 Possible shortcut — one bridge for everything

Each bridge follows the same pattern as Kimaki: receive message from platform → pipe to OpenCode → return response. The bridges are independent — swap or stack them without touching the core stack.

Reference Implementation

chubes-bot (178.156.237.104 / chubes.net) is the working reference using Kimaki (Discord).

Kimaki systemd service (/etc/systemd/system/kimaki.service):

[Unit]
Description=Kimaki Discord Bot
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/var/www/chubes.net
Environment=HOME=/root
Environment=PATH=/root/.bun/bin:/usr/local/bin:/usr/bin:/bin
Environment=BUN_INSTALL=/root/.bun
ExecStart=/usr/bin/kimaki --data-dir /root/.kimaki --auto-restart --no-critique
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

OpenCode config (/var/www/chubes.net/opencode.json):

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-opus-4-6",
  "small_model": "anthropic/claude-haiku-4-5",
  "agent": {
    "build": {
      "mode": "primary",
      "model": "anthropic/claude-opus-4-6",
      "prompt": "{file:./AGENTS.md}\n{file:./wp-content/uploads/datamachine-files/agent/SOUL.md}\n{file:./wp-content/uploads/datamachine-files/agent/MEMORY.md}"
    },
    "plan": {
      "mode": "primary",
      "model": "anthropic/claude-opus-4-6",
      "prompt": "{file:./AGENTS.md}\n{file:./wp-content/uploads/datamachine-files/agent/SOUL.md}\n{file:./wp-content/uploads/datamachine-files/agent/MEMORY.md}"
    }
  }
}

Key facts from chubes-bot pilot:

  • OpenClaw stopped & disabled (DM replaces it for crew agents)
  • Kimaki --memory disabled — Data Machine manages all state/memory
  • ai-http-client is bundled in Data Machine, not a separate plugin
  • DM stores API keys in chubes_ai_http_shared_api_keys wp_option
  • gh CLI authenticated for GitHub operations
  • Agent files (SOUL.md, MEMORY.md, USER.md) live in DM agent files directory
  • OpenCode v1.2.2 (anomalyco/opencode)

What wp-opencode should do

Core setup (setup.sh)

  1. System deps — Install Node.js/Bun, PHP, MySQL/MariaDB, Nginx, Composer, git, gh CLI
  2. WordPress — Install WP-CLI, download WordPress, configure wp-config.php, create database
  3. Data Machine — Clone/deploy plugin, activate, configure API keys
  4. OpenCode — Install, generate opencode.json with DM agent file paths
  5. Homeboy — Install binary, register as component/project/server
  6. Agent files — Bootstrap SOUL.md, MEMORY.md, USER.md, AGENTS.md templates
  7. Nginx — Configure vhost with SSL (Let's Encrypt)
  8. Security — fail2ban, UFW, SSH hardening, non-root service user
  9. Chat bridge — Install selected bridge(s) based on --chat flag

Non-root by default

chubes-bot runs everything as root. wp-opencode should:

  • Create a dedicated service user (e.g. opencode or agent)
  • Run chat bridge systemd service as that user
  • WordPress owned by www-data, agent user in www-data group
  • OpenCode runs as the service user
  • SSH keys for the service user (fleet access)
  • Homeboy config in service user home dir

Chat Bridge Interface

Each bridge should implement a common pattern:

  1. Receive message from platform
  2. Invoke OpenCode with the message (via opencode run or server mode)
  3. Return OpenCode's response to the platform
  4. Handle threads/sessions for context continuity

Bridges are installed as systemd services alongside the core stack.

Configuration

The setup script should accept or prompt for:

  • Domain name — for Nginx/SSL
  • Chat bridge — which platform(s) to install
  • Platform credentials — Discord bot token, Telegram bot token, etc.
  • API keys — Anthropic (OpenCode), OpenAI (Data Machine)
  • GitHub token — for gh CLI auth
  • Agent identity — name, role
  • Fleet registration — Command server IP for fleet membership

Templates

Ship workspace templates:

  • SOUL.md — agent identity template
  • MEMORY.md — initial memory structure
  • USER.md — captain/user context template
  • AGENTS.md — coding standards and agent instructions
  • opencode.json — OpenCode config template with DM agent file paths

Open Questions

  • Does OpenCode have a server/API mode for programmatic invocation? Or do bridges need to shell out to opencode run?
  • Beeper Desktop API requires Beeper Desktop running locally — works on desktop but not headless VPS. Is there a server-side Matrix approach?
  • Should we build individual bridges or contribute upstream to Kimaki to make it multi-platform?
  • How to handle Kimaki's interactive setup wizard non-interactively?
  • Should wp-opencode handle WordPress plugin installation (WooCommerce, etc.) or just the base stack?
  • Data Machine plugin deployment — clone from git or use Homeboy deploy from Command?
  • Kimaki role bypass for bot-to-bot communication — depends on Feature: Allow trusted bot messages (multi-agent Discord orchestration) remorses/kimaki#45

Phases

Phase 1: Core setup script

setup.sh that provisions WordPress + Data Machine + OpenCode + Kimaki on a fresh Ubuntu VPS.

Phase 2: Templates & agent files

Workspace templates, AGENTS.md, opencode.json generation.

Phase 3: Fleet integration

Auto-register with Command server, Homeboy project/server/component setup, SSH key exchange.

Phase 4: Non-root hardening

Dedicated service user, Plasma Shield integration, fail2ban whitelisting.

Phase 5: Additional chat bridges

Telegram, iMessage, SMS, Slack bridges — following the Kimaki pattern.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions