omp

🚀 OMP + Kanban + Crons Swarm Quick-Start

Dense operator cheat sheet for OMP, Discord remote control, Pi Kanban/WebUI choices, cron scheduling, durable queues, and swarm rollout gates.

Canonical operating loop for /home/mc: OMP does the work, Kanban controls intent, cron triggers only bounded routines, and the durable swarm gateway becomes the safe control plane.

For the full architecture, data model, routes, UI/UX, integrations, and rollout contract, use Cronsban Full Blueprint .

🧠 Core model# 

Human / Discord / Cron / WebUI
  → Kanban card or durable queued job
  → policy + idempotency + lock
  → OMP session / adapter / swarm worker
  → event log + artifacts
  → verified dashboard/wiki/Discord update

Golden rule: queue first, act second, verify before Done.

🧩 What was missing#

Missing piece Correct answer
Actual Kanban WebUI choice pi-board for task/sprint Kanban; pi-kanban for Pi session/todo/subagent observability. Use both only with clear ownership.
Scheduler split OS cron/systemd for host jobs; pi-schedule-prompt for in-session Pi reminders; gateway scheduler for durable queued prompts.
Durable control plane SQLite WAL queue + append-only events before any OMP invocation.
Ownership model One owner per Discord token/channel/thread/session. No duplicate bridge listeners.
Routes/API Document launcher HTTP, Discord slash commands, WebUI REST/SSE, and cron entrypoints.
Data model Separate board tasks, schedules, sessions, jobs, events, messages, artifacts, approvals, dashboards.
UI/UX Discord cards for daily control; local WebUI for logs, metrics, setup, queue, artifacts, and multi-session inspection.
Rollout gate No production cutover until unauthorized rejection, restart recovery, stop, stream splitting, artifacts, and approvals are proven.

✅ Stack picks#

Layer Pick Role Caveat
Runtime OMP at ~/.local/bin/omp Operator/agent execution Keep --allow-home when config lives in /home/mc/.env.
Pi compatibility /home/mc/.local/bin/omp-plugin-env Child sessions spawned by Pi plugins Keep legacy PI_* names.
Discord bridge now @mporenta/pi-discord-remote Live session steering, threads, tool cards No durable queue or file relay.
Kanban WebUI pi-board Real task/sprint board, WIP limits, stats, SQLite Local board state; not the gateway queue.
Session observability pi-kanban Sessions, todos, subagents, plans, live browser view Reads Pi session JSONL; do not assume it sees OMP sessions without adapter/sync.
Prompt scheduler pi-schedule-prompt Pi-local reminders/deferred prompts Fires only while a Pi session is open in that cwd; missed runs are not queued.
Durable swarm core Node daemon + SQLite WAL Queue, events, policy, adapters, WebUI Build before replacing the live bridge.
Dashboard Discord cards + localhost WebUI Fast control + deep inspection Remote WebUI requires HTTPS + auth.
Status publishing Nexus/Hermes/wiki summaries Safe public status Never publish raw logs, sessions, tokens, or hidden runtime state.

🤖 OMP start + health# 

cd /home/mc
omp --allow-home

Managed Discord session:

/home/mc/bin/omp-discord-launcher.sh
tmux -S /tmp/tmux-omp-discord/omp attach -t omp-agent

Health:

curl -s http://127.0.0.1:8765/health

Inside OMP:

/discord-status
/discord-launcher-status

Expected state:

ready=true
secret=set

Never mash tmux and OMP together:

# wrong
tmux omp --allow-home

# right
tmux
omp --allow-home

🔐 Discord / Pi-plugin baseline#

Keep compatibility centralized in /home/mc/.env and spawned child sessions routed through the OMP wrapper:

PI_CODING_AGENT_DIR=/home/mc/.omp/agent
PI_DISCORD_ENV_FILE=/home/mc/.env
PI_DISCORD_ENABLED=true
PI_DISCORD_BOT_TOKEN=...
PI_DISCORD_CHANNEL_IDS=...
PI_DISCORD_USER_IDS=...
PI_DISCORD_LAUNCHER_SECRET=...
PI_DISCORD_SPAWN_COMMAND=/home/mc/.local/bin/omp-plugin-env
PI_DISCORD_SPAWN_ARGS=--allow-home
PI_DISCORD_THREAD_NAME_PREFIX=omp
PI_DISCORD_STEER_LABEL=[discord]

Rules:

  • Restart OMP after .env changes.
  • Use a long random launcher secret; never publish the value.
  • Keep tokens, API keys, RCON, profiles, raw sessions, and hidden runtime state out of Discord and public docs.
  • Treat allowlisted Discord users like shell users.
  • Do not run multiple Discord bridge packages against the same token/channel without single-instance ownership.

📋 Kanban discipline# 

Inbox   → raw request
Triage  → outcome/scope/risk clarified
Ready   → small, testable, owner clear
Active  → work happening now
Blocked → external prerequisite only
Verify  → proof being collected
Done    → behavior proven end-to-end

Card template:

## Title
Outcome:
Scope:
Acceptance:
Risk:
Owner:
Next step:
Verification:

Rules:

  • One card = one observable outcome.
  • No vague Active cards; split until the next action is obvious.
  • Research ends when it changes the decision.
  • Done requires proof: test, build, lint, e2e, health check, or inspected artifact.
  • Blocked means information/action truly unavailable through tools or repo context.
  • Public cards summarize status; private cards may link raw diagnostics only inside trusted systems.

🧰 Pi Kanban/WebUI choices#

Need Use Command surface Data/storage
Real Kanban tasks/sprints pi-board /board; tools such as board_create_task, board_move_task, board_get_sprint_stats .pi/board.db, WebUI default http://localhost:3333, configurable PI_BOARD_PORT
Session/todo/subagent observability pi-kanban /kanban start, /kanban status, /kanban open web, /kanban session pin Reads Pi session JSONL; live browser updates via SSE
Lightweight prompt reminders pi-schedule-prompt schedule_prompt tool; /schedule-prompt overlay .pi/schedule-prompts.json plus settings JSON
Durable autonomous work Cronsban gateway /dash, /ask, WebUI REST/SSE, queued schedules Gateway SQLite WAL + event log

Install third-party Pi packages only after source review. Pi packages can execute code and influence agent behavior.

⏱️ Cron / scheduler rules#

Use cron/systemd timers for boring, bounded, idempotent routines:

collect data
refresh generated pages
enqueue scheduled prompt
run safe health check

Do not use cron for unbounded agent loops, destructive cleanup, live-service restarts, secret-dumping diagnostics, or parallel OMP spawning.

Safe host pattern:

cron/systemd timer
  → stable wrapper script
  → explicit cwd/env
  → lock to prevent overlap
  → durable log
  → idempotency key
  → visible dashboard/wiki status

Checklist:

  • Absolute paths only.
  • Explicit project root.
  • Explicit env file only when needed.
  • flock or equivalent lock.
  • Nonzero exit on failure.
  • No secrets in logs.
  • Manual dry run before enabling.
  • Success/failure visible in Nexus/Hermes/wiki summaries.

Cron syntax split:

OS cron:              */15 * * * *
pi-schedule-prompt:   0 */15 * * * *   # six fields; includes seconds

🐝 Durable swarm target# 

Discord / Cron / WebUI / Pi Board
  → adapter ingress
  → policy + authz + idempotency
  → SQLite WAL durable queue
  → per-scope FIFO workers
  → OMP/Pi/AIRI/Red adapter
  → append-only event log
  → Discord cards + local WebUI + artifacts + wiki summary

Minimum tables:

scopes
sessions
jobs
events
messages
artifacts
approvals
dashboards
schedules
policies

Non-negotiables:

  • Persist jobs before invoking OMP.
  • Per-scope FIFO; cap global concurrency.
  • Idempotency key per Discord message, interaction, schedule fire, or cron run.
  • Append-only events; derive dashboard state from tables + events.
  • Deterministic crash recovery for queued/running jobs.
  • Approval gates for destructive, out-of-workspace, secret-adjacent, or outbound-publishing actions.
  • Attachments become private artifacts before agent use.
  • Coalesce Discord streams; edit no faster than the configured interval.
  • Fake-adapter and recorded-payload tests before production cutover.

🛣️ Route cheat sheet#

Surface Routes/commands Purpose
OMP launcher GET /health, POST /new-session on 127.0.0.1:8765 Health and authenticated session spawn.
Discord /dash, /ask, /new, /session, /stop, /compact, /model, /think, /artifacts, /approve, /deny, /status Operator control and review.
Components pgw:v1:<kind>:<id>:<action> Compact custom IDs; state lives in SQLite.
WebUI REST /api/health, /api/scopes, /api/sessions, /api/jobs, /api/events, /api/artifacts, /api/approvals, /api/schedules Admin-heavy state and mutations.
WebUI live GET /events?after=<event_id> via SSE/WebSocket Replayable event stream.
Public wiki Generated safe summaries only Status without raw logs/secrets.

🧪 Production gate#

  • Bot logs in and /status works only where allowed.
  • Authorized prompt creates exactly one job.
  • Unauthorized user is ignored and audited.
  • Restart does not lose queued jobs.
  • Running job recovery is deterministic.
  • /stop aborts active work and handles queued work according to policy.
  • Dashboard edits one pinned message, not spam.
  • Large output splits safely under Discord limits.
  • Attachments download privately and hash into artifacts.
  • Artifact upload denies likely secrets.
  • Approval buttons reject unauthorized users.
  • Cron jobs cannot overlap.
  • Logs make failures obvious without exposing secrets.
  • Red/Node-RED connectors can enqueue/status without receiving Discord tokens.

🛠️ Fast fix matrix#

Symptom Likely cause Fix
OMP ignores .env change Process read env at boot Restart OMP
Launcher says no secret Secret missing at boot Set PI_DISCORD_LAUNCHER_SECRET, restart
/new opens wrong runtime Spawn command defaulted to pi Use /home/mc/.local/bin/omp-plugin-env
Child session loses config Wrong cwd/env Use --allow-home + PI_DISCORD_ENV_FILE=/home/mc/.env
Duplicate Discord replies Multiple bridges/listeners Single owner per token/channel
Cron double-runs No lock/idempotency Add flock and idempotency key
Cron works manually only Minimal cron env Use absolute paths + explicit cwd
pi-schedule-prompt missed a run No Pi session open Use gateway scheduler or OS cron for durable work
pi-kanban does not show OMP sessions It reads Pi session JSONL Add explicit sync/adapter; do not assume path parity
Board says Done but system is broken No verification gate Move card back to Verify
WebUI exposes too much Remote access or raw state Bind localhost; summarize public data only

🏁 Operator law#

Kanban defines the outcome, cron schedules bounded triggers, OMP performs reviewed work, the queue owns durability, and nothing is Done until verified.

Sources: /home/mc/docs/omp-coms.md, /home/mc/docs/omp-pi-plugin-cheatsheet.md, /home/mc/docs/discord-gateway-research/, /home/mc/wiki/content/hermes/kanban.md, /home/mc/wiki/content/operations/recurring-logs.md, https://pi.dev/packages/pi-kanban , https://pi.dev/packages/pi-board , https://pi.dev/packages/pi-schedule-prompt , https://discord.com/developers/docs/interactions/message-components , https://discord.com/developers/docs/resources/message .