Planning: wp-opencode setup tool

[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

• wp-openclaw — similar tool for OpenClaw-based agents (different runtime)
• Kimaki — Discord ↔ OpenCode bridge
• OpenCode — AI coding agent (opencode.ai)
• Data Machine — WordPress AI automation plugin
• Homeboy — Fleet ops CLI
• Beeper Desktop API — Local API for multi-platform messaging

[chubes4]

Closing as superseded.

This was the original scoping doc from when the repo was still named wp-opencode. Since then:

• Core stack is shipped via setup.sh (WordPress, Data Machine, OpenCode, Homeboy all wired up).
• Chat interface layer went pluggable: kimaki, cc-connect, and telegram are all supported bridges, auto-detected by upgrade.sh and setup.sh.
• Multi-runtime landed: opencode, claude-code, studio-code runtimes under runtimes/.
• Local + VPS parity shipped in fix(upgrade): make upgrade.sh + skill env-agnostic for local installs #47 / fix(upgrade): add cc-connect + telegram chat-bridge support (closes #48) #49 — upgrade.sh handles both environments.
• Repo was renamed to wp-coding-agents to reflect that it's no longer opencode-specific.

Remaining strategic conversations (kimaki+opencode bias, runtime investment, session ingestion) are tracked in newer issues: #40 (runtime invest), #41 (session ingestion), #50 (chat-bridge refactor).