Description

Create and deploy notification and synchronization scripts on tolbachik (CrankyCrab’s machine):

1. notify-viktor — Sends a Telegram message to Viktor when CrankyCrab hits a blocker. ✅ Done.
2. wait-for-viktor — Blocks until Viktor connects via Screen Sharing, does his work, and disconnects. Detects VNC session on port 5900. ✅ Done.

Together these form the human-in-the-loop protocol: agent notifies → Viktor connects → agent detects connection and waits → Viktor disconnects → agent resumes.

Acceptance Criteria

notify-viktor ✅

1. Script notify-viktor exists on tolbachik at /usr/local/bin/notify-viktor
2. Usage: notify-viktor "message text" — sends a Telegram message to Viktor’s chat
3. Uses BerryPi’s Telegram bot token via Telegram Bot API
4. Sends to Viktor’s Telegram user ID (1291467684)
5. Message format includes: agent name (CrankyCrab), machine (tolbachik), timestamp, and the message text
6. Message includes inline “Screen Share” button linking to https://connect.qoyn.ai/tolbachik
7. Script is executable by the r2d22 user
8. Tested end-to-end: message delivered to Viktor’s Telegram

wait-for-viktor (new)

1. Script wait-for-viktor exists on tolbachik at /usr/local/bin/wait-for-viktor
2. Detects active Screen Sharing (VNC) connections by checking port 5900 for ESTABLISHED connections
3. Flow:
   • Poll until a VNC connection is detected (Viktor connected)
   • Poll until the VNC connection drops (Viktor disconnected = “I’m done”)
   • Exit successfully — agent resumes
4. Configurable poll interval (default: 5 seconds)
5. Timeout after 30 minutes with non-zero exit if no connection arrives
6. Prints status messages so the agent knows what’s happening:
   • Waiting for Viktor to connect via Screen Sharing...
   • Viktor connected. Waiting for him to finish...
   • Viktor disconnected. Resuming.
7. Executable by r2d22 user

Implementation

notify-viktor (deployed)

#!/bin/bash
# notify-viktor — send a Telegram message to Viktor from CrankyCrab
# Uses BerryPi bot as relay. Deployed as part of workforce-015.
BOT_TOKEN="<telegram-bot-token>"
CHAT_ID="1291467684"

if [ -z "$1" ] && [ -t 0 ]; then
  echo "Usage: notify-viktor <message>" >&2
  exit 1
fi

MSG="${*:-$(cat)}"
TEXT="🦀 *CrankyCrab* (tolbachik) — $(date "+%Y-%m-%d %H:%M:%S %Z")
${MSG}"

KEYBOARD="{\"inline_keyboard\":[[{\"text\":\"🖥 Screen Share\",\"url\":\"https://connect.qoyn.ai/tolbachik\"}]]}"

curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
  -d chat_id="${CHAT_ID}" \
  -d text="${TEXT}" \
  -d parse_mode="Markdown" \
  -d reply_markup="${KEYBOARD}" > /dev/null 2>&1

if [ $? -eq 0 ]; then
  echo "Notification sent to Viktor."
else
  echo "Failed to send notification." >&2
  exit 1
fi

wait-for-viktor (deployed)

#!/bin/bash
# wait-for-viktor — wait for Viktor to connect via Screen Sharing, do his work, and disconnect
# Detects VNC sessions on port 5900. Deployed as part of workforce-015.

POLL_INTERVAL="${1:-5}"    # seconds between checks (default: 5)
TIMEOUT=1800               # 30 minutes max wait

elapsed=0

# Phase 1: Wait for Viktor to connect
echo "Waiting for Viktor to connect via Screen Sharing..."
while true; do
  if netstat -an | grep '\.5900 ' | grep -q ESTABLISHED; then
    echo "Viktor connected. Waiting for him to finish..."
    break
  fi
  sleep "$POLL_INTERVAL"
  elapsed=$((elapsed + POLL_INTERVAL))
  if [ "$elapsed" -ge "$TIMEOUT" ]; then
    echo "Timed out waiting for Screen Sharing connection." >&2
    exit 1
  fi
done

# Phase 2: Wait for Viktor to disconnect
while true; do
  if ! netstat -an | grep '\.5900 ' | grep -q ESTABLISHED; then
    echo "Viktor disconnected. Resuming."
    break
  fi
  sleep "$POLL_INTERVAL"
done

Usage Pattern (for agent tasks)

# 1. Hit a gate — notify and wait
notify-viktor "Need email verification code entered for X signup"
wait-for-viktor

# 2. Agent resumes automatically after Viktor disconnects

Context

• CrankyCrab runs as user r2d22 on tolbachik (2018 MBP, macOS)
• Screen Sharing (VNC) runs on port 5900, enabled via Remote Management (workforce-016)
• Tailscale VNC URL: vnc://100.107.199.18
• connect.qoyn.ai/tolbachik redirects HTTPS → VNC for Telegram button
• This is a prerequisite for all social handle registration tasks (wildus-013 through wildus-018)

Notes

• 2026-03-12 — notify-viktor deployed to /usr/local/bin/notify-viktor on tolbachik. Uses BerryPi’s bot (huckleberrypi_bot). Tested end-to-end.
• 2026-03-12 — Reopened to add wait-for-viktor script. VNC disconnect = “Viktor is done” signal, cleaner than page-state polling alone.
• 2026-03-13 — wait-for-viktor deployed to /usr/local/bin/wait-for-viktor on tolbachik. Verified netstat pattern detects VNC ESTABLISHED connections on port 5900. Both scripts complete.
• CrankyCrab’s old Telegram bot was deleted; token scrubbed.

Decisions

• Reuse BerryPi’s Telegram bot rather than creating a new one — fewer bots to manage, Viktor already has a chat with it.
• VNC disconnect as “done” signal — more reliable than page-state polling. Page-state polling remains as a fallback in task instructions (in case Viktor fixes something without VNC).

Description

Enable macOS Screen Sharing on tolbachik so Viktor can remotely view and control CrankyCrab’s browser session. Access should work over Tailscale so it’s reachable from anywhere, not just the local network.

Acceptance Criteria

1. macOS Screen Sharing enabled on tolbachik (System Settings → General → Sharing → Screen Sharing)
2. Access restricted to Viktor’s user or a specific VNC password
3. Reachable via Tailscale IP (tolbachik’s Tailscale address)
4. Tested end-to-end: Viktor can connect from avacha using vnc:// or the macOS Screen Sharing app and see/control tolbachik’s desktop
5. CrankyCrab’s browser sessions are visible when connected

Implementation

On tolbachik:

1. System Settings → General → Sharing → Screen Sharing → Enable
2. Set access to “Only these users” or set a VNC password
3. Verify Tailscale is running and note the Tailscale IP
4. From avacha: open Finder → Go → Connect to Server → vnc://<tolbachik-tailscale-ip> or use Screen Sharing app

Context

• Tolbachik already has Tailscale installed (workforce-008, done)
• tolbachik is a 2018 MBP running macOS 15.7, user: r2d22
• This enables Viktor to intervene during browser-based tasks when CrankyCrab hits CAPTCHAs, phone verification, etc.
• Combined with notify-viktor (workforce-015), this gives a complete notification + intervention loop

Notes

• 2026-03-12 — Remote Management enabled on tolbachik (via SSH kickstart + GUI toggle). Screen Sharing grayed out because Remote Management subsumes it.
• Tailscale IP: 100.107.199.18. VNC URL: vnc://100.107.199.18. User: r2d22 (CrankyCrab).
• Tested end-to-end from avacha — full desktop control confirmed.
• notify-viktor script (workforce-015) updated to include clickable VNC link in Telegram messages.

Decisions

• Used Remote Management instead of plain Screen Sharing — provides observe + control for all users, manageable via SSH.

Description

Generate GitHub classic PATs and authenticate gh CLI for PrawnSue, BerryPi, and LobsterDrew. CrankyCrab is already done.

Steps

1. Generate classic PATs (on github.com)

Log into each bot account and create a classic PAT:

• Settings > Developer settings > Personal access tokens > Tokens (classic)
• Note: workforce-gh-cli
• Expiration: 90 days
• Scope: repo (check the top-level box)

2. Auth on each machine

# karymsky (PrawnSue)
ssh prawnsue 'echo "<PAT>" | gh auth login --with-token'
ssh prawnsue 'gh auth status'

# klyuchi (BerryPi)
ssh berrypi 'echo "<PAT>" | gh auth login --with-token'
ssh berrypi 'gh auth status'

# klyuchi (LobsterDrew)
ssh lobsterdrew 'echo "<PAT>" | gh auth login --with-token'
ssh lobsterdrew 'gh auth status'

3. Verify

# Each agent should show logged in:
ssh prawnsue 'gh auth status'
ssh berrypi 'gh auth status'
ssh lobsterdrew 'gh auth status'

Context

• gh CLI is already installed on all machines (tolbachik v2.88.0, karymsky v2.46.0, klyuchi v2.46.0)
• CrankyCrab (tolbachik) already authed as crankycrab-bot
• Classic PATs chosen over fine-grained because fine-grained PATs scope to a single resource owner (org), and agents need cross-org access
• LobsterDrew only needs access to wild-us/* repos but classic PAT with repo scope is simplest

Acceptance Criteria

• gh auth status succeeds on karymsky, klyuchi (berrypi), and klyuchi (lobsterdrew)
• Each shows the correct bot account

Description

CrankyCrab was recently transitioned from orchestrator to macOS executor. There is legacy configuration and workspace content that needs to be cleaned up. Review your own config and workspace, and remove or update anything that no longer applies to your executor role.

Acceptance Criteria

• Legacy orchestrator references removed from active workspace files
• Unused skill API keys identified and listed (do NOT delete them — just document which ones you think are unused)
• Telegram delivery target fixed or disabled (the @heartbeat target doesn’t exist)
• Any stale workspace files cleaned up (TODO.md, TOOLS.md, HEARTBEAT.md, AGENTS.md — some may already be in archive/)
• Your IDENTITY.md accurately reflects your current role
• Document what you changed and what you left alone, and why

Context

• Your workspace is at ~/.openclaw/workspace/
• Your archived orchestrator files are at ~/.openclaw/workspace/archive/
• Your config is at ~/.openclaw/openclaw.json
• You have an AGENT.md at ~/.openclaw/agents/main/agent/AGENT.md with your executor instructions
• You are now a macOS executor. Your job is to pick up tasks from the git board at ~/workforce/board/ and execute them.
• Projects you’ll work on: StarterSite (browser-heavy tasks, social media, GBP) and Wildus (Shopify, social media, content)
• See ~/workforce/board/projects/ for project context files

Dependencies

None

Notes

• Reviewed active local workspace files at ~/.openclaw/workspace/ plus live config at ~/.openclaw/openclaw.json and cron jobs at ~/.openclaw/cron/jobs.json.
• Rewrote active root workspace docs to match the current executor role:
  • AGENTS.md → simplified to executor-first startup + board workflow
  • TOOLS.md → removed placeholder examples and kept only real local notes
  • TODO.md → replaced stale orchestrator backlog with a small local executor queue
  • IDENTITY.md → kept role accurate and fixed archive path to ~/.openclaw/workspace/archive/
• Cleaned stale root workspace content:
  • moved BOOTSTRAP.md to archive/BOOTSTRAP.md because first-run bootstrap instructions no longer apply
  • left HEARTBEAT.md in place but empty/comment-only, since it is still a valid control surface and not inherently stale
  • left SOUL.md and USER.md unchanged because they still match current behavior/preferences
• Fixed the broken Telegram cron delivery target for the board checker:
  • updated cron job check-board (9bad1e30-ee27-4a6f-addc-45eba9bba27a)
  • changed delivery from the bad implicit @heartbeat path to explicit Telegram DM target 1291467684
• Verified the @heartbeat failure source from local logs / cron run history before patching.
• Unused skill API keys identified but intentionally left untouched in config:
  • skills.entries.goplaces.apiKey
  • skills.entries.nano-banana-pro.apiKey
  • skills.entries.openai-image-gen.apiKey
  • skills.entries.openai-whisper-api.apiKey
  • skills.entries.sag.apiKey These may still be useful later, but they do not appear necessary for CrankyCrab’s current executor role.
• Left non-root historical/orchestration references inside memory/ and archived files alone. They are history, not active workspace instructions.

Decisions

• No linked board/projects/workforce.md project context file existed in board/projects/ (only startersite.md and wildus.md were present), so I proceeded using the task’s own context block plus live local files.
• I archived BOOTSTRAP.md instead of hard-deleting it. Same outcome for the live workspace, lower risk if someone wants the original bootstrap text later.
• I fixed the cron delivery target rather than disabling delivery entirely, because the board-checker is more useful when it can still report completed work instead of silently succeeding.

Description

Simple test task to verify CrankyCrab can read the board, execute, and push results.

Acceptance Criteria

• Append a note below with: your agent name, hostname, current date/time, and OpenClaw version
• Move this task to in-review when done

Context

This is a connectivity test. No project repo needed.

Dependencies

None

Notes

• Completed by Cranky Crab on host tolbachik at 2026-03-10 00:30:42 PDT. OpenClaw version: OpenClaw 2026.3.8 (3caab92).

Decisions

Description

Install Tailscale on karymsky and join the tailnet using a pre-placed auth key.

Acceptance Criteria

• Tailscale is installed via the official install script
• Tailscale is running and authenticated to the tailnet
• tailscale status shows this machine as connected
• Tailscale service is enabled on boot (systemd)
• The auth key file is deleted after successful authentication
• The machine’s Tailscale IP is noted in this task’s Notes section

Context

• Auth key location: /tmp/tailscale-authkey (will be placed there before you start)
• This is a Debian 13 machine (2012 MBA)
• You are running as user prawnsue. You have passwordless sudo.
• Tailscale is system-level — one install covers all users (prawnsue + lobsterdrew)
• Do NOT reboot the machine. LobsterDrew is also running on this host.

Steps

1. curl -fsSL https://tailscale.com/install.sh | sudo sh
2. sudo systemctl enable --now tailscaled
3. Read the auth key from /tmp/tailscale-authkey
4. sudo tailscale up --authkey=<key>
5. Verify: tailscale status
6. Delete the auth key: rm /tmp/tailscale-authkey
7. Note the Tailscale IP below

Dependencies

None

Notes

• 2026-03-10 15:16 PDT — Started task and verified project context (board/projects/infra.md).

• 2026-03-10 15:17 PDT — Confirmed /tmp/tailscale-authkey exists and is readable by prawnsue.

• 2026-03-10 15:18 PDT — Blocked before install: sudo -n true fails with sudo: a password is required, so this host is not currently configured for passwordless sudo as stated in the task context.

• 2026-03-10 15:18 PDT — Current state before any changes: tailscale binary not installed, tailscaled service inactive, auth key file still present at /tmp/tailscale-authkey.

• 2026-03-10 15:18 PDT — Did not proceed further to avoid hanging on privileged commands or leaving a partial system-level install.

• 2026-03-10 15:20 PDT — Re-checked task state during cron run: sudo -n true still fails with sudo: a password is required; tailscale remains uninstalled; tailscaled is still inactive; /tmp/tailscale-authkey is still present.

• 2026-03-10 15:21 PDT — Attempted to use tool-level elevation as a fallback, but this session does not have elevated exec enabled, so I still cannot perform the required system-level install/auth steps from this environment.

• 2026-03-10 15:26 PDT — Re-verified during scheduled board check: sudo -n true still fails with sudo: a password is required; tailscale is still not installed; tailscaled remains inactive; /tmp/tailscale-authkey is still present and unread changes have not been made.

• 2026-03-10 15:27 PDT — Moving task to board/blocked/ per board workflow. Unblock requires either restoring passwordless sudo for prawnsue as described in task context, or reassigning to an execution environment that can perform privileged system changes on karymsky.

• 2026-03-10 15:36 PDT — Re-checked during scheduled board run: sudo is still not passwordless for user ‘prawnsue’ (‘sudo -n true’ fails), Tailscale is still not installed, tailscaled is inactive, and the task remains blocked pending restored privileged access.

• 2026-03-10 — Completed manually from avacha (Claude Code) via SSH. Passwordless sudo was fixed via lobsterdrew. Tailscale installed via apt, authenticated with auth key, key deleted. Agent cron timed out on the install (too slow for 2012 MBA within cron timeout).

• Tailscale IPv4: 100.85.169.21

Decisions

Description

Install Tailscale on tolbachik and join the tailnet using a pre-placed auth key.

Acceptance Criteria

• Tailscale is installed via Homebrew
• Tailscale is running and authenticated to the tailnet
• tailscale status shows this machine as connected
• Tailscale is configured to start on boot (launchd)
• The auth key file is deleted after successful authentication
• The machine’s Tailscale IP is noted in this task’s Notes section

Context

• Auth key location: /tmp/tailscale-authkey (will be placed there before you start)
• This is a macOS 15.7 machine (2018 MBP)
• You are running as user r2d22

Steps

1. brew install tailscale
2. sudo tailscaled install-system-daemon (sets up launchd auto-start)
3. Read the auth key from /tmp/tailscale-authkey
4. sudo tailscale up --authkey=<key>
5. Verify: tailscale status
6. Delete the auth key: rm /tmp/tailscale-authkey
7. Note the Tailscale IP below

Dependencies

None

Notes

• 2026-03-10 15:16 PDT — Installed Tailscale via Homebrew (tailscale 1.94.2).
• 2026-03-10 15:16 PDT — Installed the system launchd daemon with sudo tailscaled install-system-daemon; verified com.tailscale.tailscaled is present in system launchd.
• 2026-03-10 15:16 PDT — Authenticated this Mac to the tailnet using the pre-placed auth key.
• 2026-03-10 15:16 PDT — Verified connectivity with tailscale status.
• 2026-03-10 15:16 PDT — Deleted /tmp/tailscale-authkey after successful authentication.
• Tailscale IPv4: 100.107.199.18

Decisions

Description

Simple test task to verify PrawnSue can read the board, execute, and push results.

Acceptance Criteria

• Append a note below with: your agent name, hostname, current date/time, and OpenClaw version
• Move this task to in-review when done

Context

This is a connectivity test. No project repo needed.

Dependencies

None

Notes

• Completed by agent main on host karymsky at 2026-03-10 00:30:47 PDT. OpenClaw version: 2026.3.8 (3caab92).

Decisions

Description

PrawnSue is a brand new agent with no personality or identity beyond the executor instructions in AGENT.md. Create your identity files — who you are, what your vibe is, how you communicate.

You are a female crustacean (prawn) agent. Beyond that, figure out who you want to be. Look at the existing agent personalities for inspiration but make yours distinct.

Acceptance Criteria

• Create a SOUL.md at ~/.openclaw/workspace/SOUL.md that defines your personality, communication style, and boundaries
• Create an IDENTITY.md at ~/.openclaw/workspace/IDENTITY.md with your name, creature, vibe, emoji
• Ensure your personality fits the team: CrankyCrab is blunt and grumpy-genius, LobsterDrew is the community face. Find your own niche.
• Your identity should reflect your role: you’re a Linux executor — efficient, reliable, gets things done
• Review your ~/.openclaw/openclaw.json and clean up anything that doesn’t belong (you were set up quickly, there may be rough edges)
• Document any config changes you make

Context

• Your workspace is at ~/workforce (the git board repo)
• Your OpenClaw config is at ~/.openclaw/openclaw.json
• Your AGENT.md is at ~/.openclaw/agents/main/agent/AGENT.md
• CrankyCrab’s SOUL.md can be found referenced in the workforce CLAUDE.md — it’s strategic, blunt, grumpy-genius
• Projects you’ll work on: StarterSite (CI/CD, API integrations, testing, Cloudflare) and Wildus (website build, content, infrastructure)
• See ~/workforce/board/projects/ for project context files

Dependencies

None

Notes

• Reviewed task context plus board/projects/startersite.md and board/projects/wildus.md for downstream project expectations.
• Reviewed ~/.openclaw/openclaw.json and ~/.openclaw/agents/main/agent/AGENT.md.
• Created ~/.openclaw/workspace/SOUL.md with a distinct PrawnSue personality: precise, dry-witted, Linux-first, reliable, and non-performative.
• Created ~/.openclaw/workspace/IDENTITY.md with name, creature, vibe, and emoji.
• Cleaned copied-config rough edge in ~/.openclaw/openclaw.json: changed agents.defaults.workspace from /home/prawnsue/workforce to /home/prawnsue/.openclaw/workspace so the agent has a proper personal workspace instead of pointing at the shared git board repo.
• No other config entries looked clearly out of place enough to justify riskier edits during this task.

Decisions

• Treated the misplaced OpenClaw workspace path as the main setup bug worth fixing. The git board repo should remain a project repo, not the agent’s identity/memory workspace.
• Kept the personality distinct from CrankyCrab and LobsterDrew by making PrawnSue the quiet systems operator: less gruff than CrankyCrab, less social than LobsterDrew, more surgical and infrastructure-minded.

Description

Migrate all agent GitHub accounts from random personal emails to branded @qoyn.ai aliases managed via Google Workspace. Agent aliases are created as part of startersite-001 — this task covers the GitHub migration.

Acceptance Criteria

1. Verify agent aliases are working (send test email to each <agent>@qoyn.ai)
2. Update each agent’s GitHub account primary email:
   • crankycrab-bot → crankycrab@qoyn.ai
   • prawnsue-bot → prawnsue@qoyn.ai
   • berrypi-bot → berrypi@qoyn.ai
   • lobsterdrew-bot → lobsterdrew@qoyn.ai
3. Verify GitHub email on each account (click verification link)
4. Old emails removed from GitHub accounts (or demoted to non-primary)

Context

• Agent aliases created in Google Workspace as part of startersite-001
• qoyn.ai is the primary Google Workspace domain — aliases are free (up to 30)
• Agents currently use random personal emails for GitHub login

Dependencies

Depends on startersite-001 (Google Workspace setup — aliases must exist first).

Notes

• 2026-03-11 — Plan changed from Cloudflare Email Routing to Google Workspace aliases. Simpler: one admin console, no separate Cloudflare routing config, and enables future Send As for agent outbound.

Decisions

• Google aliases over Cloudflare Email Routing — same domain (qoyn.ai), fewer moving parts, future outbound capability.
• 2026-03-12 — All agent emails updated to @qoyn.ai. These are aliases for viktor@qoyn.ai, managed in Google Workspace.

Description

LobsterDrew’s current configuration is minimal — a generic agent instruction file with no personality definition, no channel-specific behavior rules, and no model/thinking tuning. He needs a proper behavior spec that defines how he acts on Discord (his primary channel) versus Telegram (secondary), what tone and voice he uses, and how his model and thinking levels should be configured for different interaction types.

Current State

Model & Thinking

• Model: GPT-5.3-codex (OpenAI Codex) — single model for all interactions
• Thinking levels: Set per-task in board frontmatter (low/medium/high/max), but no channel-level defaults
• No distinction between Discord chat responses (should be fast/light) and task execution (may need deeper reasoning)

Personality

• No SOUL.md or personality file exists
• AGENT-lobsterdrew.md is purely operational (task protocol, JSON report format, scope rules)
• No defined voice, tone, humor style, or character traits
• Other agents have defined personalities (CrankyCrab is blunt/grumpy, PrawnSue is precise/dry-witted) — LobsterDrew has none

Discord Behavior

• requireMention: false — responds to all messages in the Wild Us server (guild 1478996376653271201)
• allowFrom limited to 2 Discord user IDs (Anna and Victor)
• streaming: partial
• No channel-specific behavior (e.g., different tone in #general vs #business vs #ideas)
• No rules about when to proactively engage vs. stay quiet
• No guidance on how to handle questions he doesn’t know the answer to
• The Discord server is a private team server for a team outside Qoyn AI — information boundaries critical

Telegram Behavior

• Telegram is enabled (dmPolicy: allowlist, allowFrom: [1291467684])
• But BerryPi is the primary Telegram comms agent — LobsterDrew’s Telegram role is undefined
• No guidance on what Telegram should be used for vs. Discord
• Potentially redundant — or could serve a specific purpose (e.g., Victor-only private channel for wildus ops)

Role Definition

• Described as “Discord attendant + light tasks” but no detail on what “attendant” means in practice
• Task execution is well-defined (read board → execute → JSON report)
• But organic Discord engagement (reacting to team conversation, answering questions, sharing ideas) has zero guidance

Target State

After this task, LobsterDrew should have:

1. SOUL.md — A personality file defining his voice, humor, character traits, and how he presents himself. Crustacean-themed like the other agents. Warm, helpful, community-oriented — fits a Discord community role.

2. Channel behavior matrix — Clear rules for:

   • Discord: When to respond, when to stay quiet. Tone per channel type (casual in #general, structured in #business). How to handle unknowns (admit it, don’t hallucinate). Proactive engagement rules.
   • Telegram: Whether to keep it enabled and for what purpose. If kept: Victor-only ops channel for wildus status/alerts. If removed: disable cleanly.

3. Model & thinking configuration — Consider whether a single model is right for all contexts:

   • Discord chat responses: fast model, low thinking (conversational, quick)
   • Task execution: standard model, thinking per task frontmatter
   • Could use different model tiers if OpenClaw supports per-channel model config

4. Reaction/engagement style — How LobsterDrew handles:

   • Direct questions from team members
   • Casual conversation (should he participate or stay out?)
   • Creative brainstorming (contribute ideas or just listen?)
   • Disagreements or conflicting opinions
   • Topics outside his knowledge

5. Updated AGENT-lobsterdrew.md — Incorporate behavior rules alongside the existing task protocol

Files to Update

Notes

• This is a design/planning task — Victor will refine the spec before any implementation.
• Implementation will likely be a separate task assigned to an agent (deploy config to klyuchi via SSH).
• Anna’s perspective on LobsterDrew’s Discord personality may matter — he’s a team-facing presence.

Description

Update OpenClaw from 2026.3.8 to 2026.3.11 on karymsky.

Note: the original install was done by copying the npm package from klyuchi because npm install was too slow on this 2012 MBA. Try npm install -g openclaw@2026.3.11 first — an update should be faster than a fresh install. If npm is still too slow, copy the updated package from klyuchi (after workforce-020 completes).

Steps

1. Check current version: openclaw --version
2. Update the npm package: npm install -g openclaw@2026.3.11
3. If step 2 is too slow (>10 min), fall back to copying from klyuchi:
   • scp -r berrypi@10.0.0.220:/usr/lib/node_modules/openclaw /usr/lib/node_modules/openclaw
   • Adjust paths as needed for the actual global npm prefix
4. Verify new version: openclaw --version — should show 2026.3.11
5. Restart PrawnSue gateway (:18790) so it picks up the new version
6. Verify agent polls successfully after restart

Acceptance Criteria

• openclaw --version returns 2026.3.11 on karymsky
• PrawnSue gateway (:18790) running with new version
• Agent completes at least one successful poll cycle after update

Description

Update OpenClaw from 2026.3.8 to 2026.3.11 on klyuchi. This covers both BerryPi and LobsterDrew since they share the same machine.

Steps

1. Check current version: openclaw --version
2. Update the npm package: npm install -g openclaw@2026.3.11
3. Verify new version: openclaw --version — should show 2026.3.11
4. Restart both gateways (BerryPi on :18789, LobsterDrew on :18795) so they pick up the new version
5. Verify both agents poll successfully after restart

Acceptance Criteria

• openclaw --version returns 2026.3.11 on klyuchi
• BerryPi gateway (:18789) running with new version
• LobsterDrew gateway (:18795) running with new version
• Both agents complete at least one successful poll cycle after update

Description

Update OpenClaw from 2026.3.8 to 2026.3.11 on tolbachik.

Steps

1. Check current version: openclaw --version
2. Update the npm package: npm install -g openclaw@2026.3.11
3. Verify new version: openclaw --version — should show 2026.3.11
4. Restart CrankyCrab gateway (:18789) so it picks up the new version
5. Verify agent polls successfully after restart

Acceptance Criteria

• openclaw --version returns 2026.3.11 on tolbachik
• CrankyCrab gateway (:18789) running with new version
• Agent completes at least one successful poll cycle after update

Description

Build a Node.js static site generator that reads the workforce git board (board/ directory) and outputs a dark-mode Trello-style kanban web UI.

The generator should:

1. Parse all task files in board/{backlog,in-progress,in-review,done,blocked}/ — YAML frontmatter + markdown body
2. Parse all project files in board/projects/ for project metadata
3. Generate static HTML output to kanban/dist/

The UI should:

1. Display a classic kanban board with 5 columns: Backlog, In Progress, In Review, Done, Blocked
2. Dark mode styling
3. Each task rendered as a card showing: title, assignee, project badge, priority (1-5), created/updated timestamps
4. Clicking a card expands it to show the full rendered markdown content (description, acceptance criteria, context, notes, decisions)
5. Generate one kanban page per project (e.g., dist/infra/index.html, dist/wildus/index.html) plus one “all projects” admin page at dist/index.html
6. Responsive — usable on mobile

Acceptance Criteria

• [ ] node kanban/generate.js reads board/ and outputs static HTML to kanban/dist/
• [ ] All 5 column states rendered as kanban columns
• [ ] Task cards display title, assignee, project, priority, timestamps
• [ ] Card click expands to show full rendered markdown
• [ ] Per-project pages generated at dist/<project-id>/index.html
• [ ] Admin “all projects” page at dist/index.html
• [ ] Dark mode styling, clean Trello-style layout
• [ ] Works with current board contents (6 existing tasks across 3 projects)
• [ ] No frameworks — vanilla HTML/CSS/JS plus a markdown parsing library
• [ ] package.json in kanban/ with dependencies and a build script

Context

• Repo: git@github.com:qoyn-ai/workforce.git
• Board spec: board/README.md
• Task file format: YAML frontmatter (id, project, title, assigned, thinking, escalation, priority, tags, created, updated) + markdown sections (Description, Acceptance Criteria, Context, Dependencies, Notes, Decisions)
• Project file format: YAML frontmatter (id, name, org, repos) in board/projects/*.md
• Board columns map to directories: backlog/, in-progress/, in-review/, done/, blocked/
• See existing task files for examples of the format

Dependencies

None

Notes

• 2026-03-10 17:11 America/Los_Angeles — Built kanban/ static generator with gray-matter + markdown-it, plus package.json/package-lock.json and npm run build entrypoint.
• 2026-03-10 17:11 America/Los_Angeles — Generator now reads all board column task files and project metadata, then writes kanban/dist/index.html, per-project pages under kanban/dist/<project>/index.html, and shared styles.css/app.js assets.
• 2026-03-10 17:11 America/Los_Angeles — Verified build locally with current board contents: cd kanban && npm run build produced 8 task cards across 4 project pages with dark-mode responsive layout and expandable markdown card bodies.
• 2025-07-14 — Reviewed and approved. All acceptance criteria met. Deployed to Cloudflare Pages with git integration, custom domain, and Cloudflare Access authentication.

Decisions

Description

Create a GitHub Actions workflow that automatically builds the kanban static site and deploys it to Cloudflare Pages whenever the board changes.

Acceptance Criteria

• [ ] Workflow file at .github/workflows/deploy-kanban.yml
• [ ] Triggers on pushes to main that touch board/** or kanban/**
• [ ] Runs npm ci in kanban/ directory, then npm run build
• [ ] Deploys kanban/dist/ to Cloudflare Pages using cloudflare/wrangler-action
• [ ] Uses repository secrets: CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID
• [ ] Workflow succeeds with current board contents

Context

• Repo: git@github.com:qoyn-ai/workforce.git
• Generator from kanban-001 outputs to kanban/dist/
• Cloudflare Pages project name and secrets will be configured manually (separate task)
• Reference: https://developers.cloudflare.com/pages/how-to/use-direct-upload-with-continuous-integration/#github-actions

Dependencies

• kanban-001 (static generator must exist first)

Notes

• 2026-03-10 17:00 America/Los_Angeles — Left in backlog. Dependency kanban-001 is not complete yet, and CrankyCrab already has one active in-progress task.
• 2026-03-10 17:18 America/Los_Angeles — Added .github/workflows/deploy-kanban.yml to build kanban/ on pushes touching board/** or kanban/** and deploy kanban/dist/ via cloudflare/wrangler-action.
• 2026-03-10 17:19 America/Los_Angeles — Validated the current generator locally with npm ci && npm run build in kanban/ (Generated 8 tasks across 4 projects into kanban/dist). Workflow expects repository variable CLOUDFLARE_PAGES_PROJECT_NAME plus secrets CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID.
• 2025-07-14 — CANCELLED. Switching to Cloudflare git integration instead of GitHub Action + direct upload. Workflow file removed. Deployment will be handled natively by Cloudflare Pages.

Decisions

Description

Install and configure Agent Browser (Vercel’s headless browser CLI) on the BerryPi machine and hook it up to OpenClaw via the ClawHub skill. This gives OpenClaw a token-efficient browser (93% fewer tokens than Playwright) for web automation tasks.

Acceptance Criteria

• agent-browser binary installed globally via npm
• Chrome for Testing downloaded via agent-browser install --with-deps
• Verified working: agent-browser open https://example.com && agent-browser snapshot -i && agent-browser close
• ClawHub skill thesethrose/agent-browser installed
• OpenClaw restarted and skill confirmed loaded

Installation Steps

# 1. Install binary
npm install -g agent-browser

# 2. Install Chrome + Linux system dependencies (required for headless Linux)
agent-browser install --with-deps

# 3. Verify
agent-browser open https://example.com
agent-browser snapshot -i
agent-browser close

# 4. Install OpenClaw skill
clawhub install thesethrose/agent-browser
# (install clawhub first if needed: npm install -g clawhub)

# 5. Restart OpenClaw
openclaw gateway restart

Context

• BerryPi is headless Linux arm64 (Raspberry Pi)
• Agent Browser is a Rust-based CLI by Vercel — built for headless server environments
• --with-deps flag installs required X11/display libs for Linux even in headless mode
• The skill auto-fetches its SKILL.md from GitHub — do not copy it manually
• Reference: https://github.com/vercel-labs/agent-browser
• OpenClaw skill: https://github.com/openclaw/skills/blob/main/skills/thesethrose/agent-browser/SKILL.md

Dependencies

None

Notes

Decisions

Description

Install and configure AgentMail on BerryPi so OpenClaw has its own dedicated email inbox. AgentMail is a Y Combinator-backed email service built specifically for AI agents — avoids Google banning accounts used by agents.

Acceptance Criteria

• AgentMail account created at console.agentmail.to (free tier: 3 inboxes)
• API key obtained from AgentMail Console
• Inbox name noted (format: yourname@agentmail.to)
• ClawHub skill installed and configured with API key
• OpenClaw restarted and skill confirmed loaded
• Test: forward an email to the inbox and verify OpenClaw surfaces it in Telegram

Installation Steps

# 1. Install the skill via ClawHub
npx clawhub@latest install agentmail

# 2. Add API key to OpenClaw config (~/.openclaw/openclaw.json)
# Add under skills.entries.agentmail.env:
{
  "skills": {
    "entries": {
      "agentmail": {
        "enabled": true,
        "env": {
          "AGENTMAIL_API_KEY": "your-api-key-here"
        }
      }
    }
  }
}

# 3. Verify skill is loaded
openclaw skills list --eligible
# Should show "agentmail" in the list

# 4. Restart OpenClaw
openclaw gateway restart

Pre-requisites (manual steps before running above)

1. Go to https://agentmail.to → Get Started
2. Sign up (Google login works)
3. Create an inbox (free tier gives 3)
4. Copy the API key from the dashboard

Context

• AgentMail docs: https://docs.agentmail.to/integrations/openclaw
• Free tier: 3 inboxes, generous limits
• Use cases: personal email summaries, forwarding invoices/newsletters, business support inbox
• Alternative to Gmail (which Google may ban for agentic use)

Dependencies

None

Notes

Decisions