Side quests.

Project context

Shisa has its own Hermes profile, workspace, memory, Telegram bot, and context vault. The agent starts from the operating manual, project overview, latest digest, and open actions. Repos live in a persistent workspace, with separate worktrees for implementation tasks.

Repos

The project is split across four repos. services is the Go backend for trading, platform, settlement, and indexing. web has the main and admin apps. contracts holds the Polymarket/CTF contract fork and deployment artifacts. bot is the market-maker fork.

• services
• web
• contracts
• bot

Planning and state

GitHub issues and the Shisa Build Order project track execution. Notion holds the higher-level planning docs: the build order and technical/product plan. The Obsidian vault keeps summaries, decisions, open questions, and source manifests. Scheduled Hermes jobs refresh GitHub state, scan repo instructions, and check for planning drift.

• GitHub project
• Build order
• Technical plan

The workflow

Deeper implementation usually stays in a Claude Code or Codex session on my local machine. That is where I do the messy reasoning, especially when the work has new patterns, architecture decisions, or outcomes that are not easy to test cleanly.

More bounded work can go to the Shisa builder agent. The deciding factor is usually testability: if an agent can prove the outcome with tests or checks, it can probably take the task. I still review the PR, request changes, and feed anything important back into the project context.

I have also learned that 800 LOC is about my hard limit for a useful review. Local session or builder agent, does not matter. Past that, the review starts getting worse.

Remote staging

Staging runs from the VPS. The GitHub Actions staging workflow validates the repo, builds GHCR images, deploys the exact commit to `/opt/shisa/staging`, runs migrations, and smoke-checks the Tailscale endpoints. The Compose stack includes the app services, Postgres, NATS, Caddy, and observability.