Monitor is the world you listen to; Accounts are the ones you speak from. Each account here is a platform + handle, backed by a session torii holds (the same social accounts you logged in on the torii console).

Accounts: the rail of accounts you publish through, and the selected account's schedule and rules.

​
Add an account

Add → platform, handle, optional label, and the torii profile to publish through (a dropdown of the sessions torii holds for that platform). The card shows the platform’s write capability straight from torii: whether it can publish, reply, the character limit, and whether media is accepted. A platform torii cannot write to is read-only here.
Publishing needs a torii key with the write scope. With a read-only key the schedule and rules still work as dry runs — they log what they would have done and publish nothing.

​
Schedule a post

Write the text, pick a time, Schedule. A new post is disarmed: at its time it dry-runs — validated against the platform’s limits, logged, not published. Arm it to publish for real. Two switches must both be on for anything to reach the public:
  1. The deployment switch — Let automation post publicly under Settings → Deployment. Off by default on every fresh install.
  2. The item’s own arm — per post and per rule.

​
Canned replies

A rule matches new comments on your recent posts by a plain substring (deliberately not a regular expression — a rule that decides what an account says in public should be readable at a glance) and answers with a fixed reply. Each rule has enabled and armed; a disarmed rule counts what it would have answered so you can read the number before arming. Run now runs one rule immediately with the same arming semantics.

​
Honesty in publishing

  • A post is never retried automatically: a lost answer could mean it went out, and twice is worse than once.
  • The card’s session state comes from torii’s Accounts table — re-login it in torii appears only when that is truly the fix.