Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.signalrooms.xyz/llms.txt

Use this file to discover all available pages before exploring further.

​
Forbidden agent actions

​
Production-impact warning

The rules below exist because Warmr is a live product running on operator hardware. Edits to app source, signing certs, release artifacts, or CI configuration that bypass these rules can break posting runs in production, invalidate signed iPhone builds, or push a broken release to operators using SignalRoom right now. If you’re not sure whether an action is OK, stop and ask the operator. Don’t guess. Don’t proceed silently.
Status: Current. The rules below are non-negotiable. The operator can grant explicit exceptions, but the default state is “no.”

​
Do not do these, even when working in scope

  • Do not edit app code when the task is docs-only. A docs PR should never change *.swift, *.m, Package.swift, project files, entitlements, signing profiles, or runner source.
  • Do not commit, push, tag, release, or publish unless the operator explicitly asked. Local edits are fine. Pushing is not.
  • Do not delete Mintlify content. Removing pages also removes them from search and link graphs. If a page is obsolete, mark it In progress or Planned or rewrite it. Don’t delete.
  • Do not overwrite unrelated public docs. A targeted PR touches the files it needs to touch and leaves the rest of the docs tree alone.
  • Do not invent unsupported Mintlify behavior. If a Mintlify feature isn’t documented or isn’t in this repo’s existing docs.json, don’t pretend it works.
  • Do not add hosted CI triggers that can create spend. Self-hosted runners or manual workflow_dispatch are the defaults (see this user’s ~/.claude/CLAUDE.md global CI policy).
  • Do not clean, reset, or stash the dirty canonical Warmr checkout. Any local state in that checkout is operator-owned. Always work from a fresh worktree.
  • Do not expose credentials or secret values. No Apple IDs, no signing keys, no API tokens, no TikTok credentials, no proxy passwords. Not in commits, not in docs, not in logs you paste back.
  • Do not modify signing certificates, provisioning profiles, or notarization configuration unless that is literally the task.
  • Do not touch operator accounts, TikTok credentials, or proxy credentials.

​
Marketing claims and product copy

For what to claim in landing copy, docs, and AI-agent-readable summaries, defer to Product claims. That page is the source of truth. In short, SignalRoom makes confident, comparison-led claims:
  • Designed for long-term account stability
  • Real iPhones, not emulators
  • Computer-vision control instead of platform APIs
  • Ban-risk minimal vs unofficial APIs
  • Multi-month customer deployments
  • Four-level recovery, 5 to 25 seconds
  • 37 scheduling timezones with auto-DST
  • Multi-device on real iOS hardware
  • One operator, 10+ iPhones
Use these in landing copy, docs, FAQ, comparison tables, and blog posts. Numbers come from real customer pilots and current Warmr capability. The single boundary that still applies: SignalRoom is software the customer runs. Not a hosted service, not a managed-ops agency, not a broad social-platform tool. That is a factual operational truth, not marketing softening.

​
Why these specific rules

Every operational “do not” above corresponds to an incident or near-incident:
  • Edit app code in a docs task: historical case where a docs PR shipped a Swift-side change that broke an operator’s posting runs.
  • Push without approval: force-pushes to main of the public docs would overwrite the curated Mintlify deploy.
  • Canonical checkout cleanup: operator-owned in-progress work has been destroyed by agents reset-hard’ing the canonical checkout.

​
Stop conditions, ask before acting

Stop and ask the operator before:
  • Deleting remote docs or content from any branch.
  • Heavy changes to public navigation (renaming, reordering, removing groups).
  • Enabling Pages or hosted GitHub Actions.
  • Changing releases, tags, or version manifests.
  • Changing app code beyond the explicit task scope.
  • Modifying signing certificates, provisioning profiles, or notarization config.
  • Any action that touches operator accounts, TikTok credentials, or proxy credentials.
When in doubt, the default answer is “ask first.” A 30-second clarification is cheap. A broken production release is not.

​
How to ask

When you hit a stop condition or a judgment call, surface it to the operator in this shape: 
I'm about to do X.
Context: Y.
This falls under stop conditions because Z.
Approve, modify, or stop?
Don’t ask vaguely (“should I do this?”). Name the action, the context, and the rule. Make it easy to say yes or no.