Services and operators

The web app serves pages and short HTTP requests. The ops service runs the work that must continue between requests: trading loops, game rooms, event projection and mention polling.

Long-running actors

The full entry point starts all of these:

pnpm --filter @masayume/ops start

Use it only with an intentional operator configuration. For one creator's bot, use start:runner instead.

Explicit execution modes

Set the mode explicitly for each deployment. X_POSTING_ENABLED controls replies, not X trade execution. Starting a configured relay while reply posting is off can still place trades.

Server services inside web

Sensei and Dry read use the model credential. The sponsor validates requests then spends its own STT. PrivateDesk verifies signed owner instructions and signs desk operations. X sign-in holds the OAuth application secret and session-signing secret.

These keys are server-only. A statement that all operator keys live exclusively in ops would be inaccurate for the current app.

Game deployment dependencies

Web and room must share ROOM_TOKEN_SECRET; web needs GAME_ROOM_PUBLIC_URL. The room requires a secret of at least 16 characters and a known arena. Deck creation requires GAME_DECK_KEY and a writable, persistent journal path.

The journal is written before the deck commitment is published. Persist it outside an ephemeral container filesystem if the operator expects restart recovery. Keep the encryption key separately from the database containing encrypted decks.

The projector starts at a saved cursor or deployment block and catches up in bounded log spans. Without a database it can feed rooms, but history and its cursor do not persist. The settler needs a database worklist and idles without it.

Observe before assuming

• Heartbeats explain why an actor traded, held or could not run.
• Contract receipts establish what actually landed.
• Stored history shows the projection, which may lag or be unavailable.
• Public Status checks core dependencies; it is not a complete attestation of every operator key or background loop.

X reports mention polling, execution recovery and reply delivery separately. Catch-up drains up to 50 pages of 20 mentions while preserving the saved cursor on an incomplete drain. Its durable execution recovery does not replay an instruction or automatically repost an ambiguous reply. See the X execution path for those boundaries.

The X relay verifies its authenticated account and excludes its own replies before command claiming. A startup sweep and repeated database checks suppress unfinished recursive deliveries. If a live reply loop appears, pause reply posting while investigating; separately verify whether any new trade happened and whether execution authority should be revoked.

The strategy runner requires durable decision and execution records before new trades, and holds all submissions by its key while an earlier attempt remains unresolved. Once evidence is readable, paused strategies can still settle their earlier positions to the owner. Current refunded-duel recovery may require manually settling outstanding cards; that is a separate actor's limitation.