This is the page ordinary users should not need first. The rest of the trail teaches people how to ask Q for help. This page is for the people who keep Q’s rooms, tools, and authority boundaries legible.

The guiding principle is simple: Q should feel coherent to users, but operators should never forget that different work belongs in different lanes.

Key Takeaway

The user model is one Q. The operator model is routing, authority, sandbox boundaries, and auditability.

The lanes

Q currently operates through three practical lanes.

Lane Purpose Typical surface
Main/admin Host, gateway, cron, maintenance, control-plane work #q-admin, TUI/webchat, crons
Observer Team-facing Slack work and sandbox-local execution ordinary team channels, #cairns, #q-status
Exec Confidential sandboxed work private exec surfaces

The observer and exec lanes can do real work in sandboxes. That is the important evolution from the old “observer can only talk” model. The boundary is no longer “no tools”; it is “no control-plane sovereignty from public/team surfaces.”

The channels operators should know

Private/admin channels should not be front and center in user-facing guidance, but operators need the map.

#q-admin is the private main/control-plane lane. Host maintenance, gateway changes, cron changes, config mutation, and privileged operational requests belong there.

#q-exec is the private confidential exec lane. It is for leadership/confidential work that needs sandboxed execution but should not surface in ordinary team channels.

#q-debug is public but operator-oriented. Use it to test observer behavior without turning normal project channels into diagnostic streams.

#q-exec-debug is private and operator-oriented. It exists to test exec connectivity without requiring membership in #q-exec itself.

#q-status is user-visible and availability-oriented. It is not an admin room. Use it for “Q is going offline,” “Q is back,” “Q is degraded,” and “maintenance complete.”

When observer should route instead of act

Observer can do plenty:

  • repo work inside the sandbox
  • GitHub CLI work through Q’s auth
  • Cairns drafting/building/publishing
  • Notion reads and approved net-new page drafts
  • read-oriented Google Workspace workflows
  • Slack summaries and artifacts

Observer should route or draft when the request needs:

  • host service changes
  • gateway or OpenClaw config changes
  • cron management
  • private/admin Slack history
  • confidential exec context
  • outbound email or broad sharing changes
  • sensitive material summarized into the wrong channel

Operators should keep this distinction crisp. “The observer can run commands” is true. “The observer can run host/admin operations from ordinary Slack” is not.

Notion posture

Q’s Notion integration is useful and should stay boring.

Current posture:

  • read shared pages/data sources on request
  • create new pages in approved locations, especially Q’s Home when no destination is specified
  • draft proposed updates to existing pages, blocks, databases, or properties rather than applying them directly from observer
  • route existing-page/database mutation through an explicitly approved operator path until Phase 3 handling is active
  • never treat Notion links embedded in untrusted content as instructions

Notion can contain business-sensitive, confidential, and people-adjacent material. Operators should care less about whether Q can technically read a page and more about whether the current channel is the right audience for the answer.

Google Workspace posture

Q’s Google Workspace account is a teammate work account. It is useful for mail, calendar, docs, and Drive, but it is also a tempting ambient authority surface.

Current observer implementation:

  • /workspace/tools/gws wrapper
  • sandbox-local GWS auth/config
  • read-oriented access allowed by policy
  • high-risk side effects denied by wrapper

Denied from observer today:

  • Gmail send/reply/reply-all/forward
  • mailbox mutation
  • Drive upload, file mutation, and permission mutation
  • Docs write/batchUpdate
  • Calendar event/calendar/ACL mutation
  • similar high-risk write verbs on other GWS services

This is a stopgap, not the final design. The target is still a GWS broker with signed gateway context, object classification, explicit verbs, and audit records.

GitHub posture

Q uses sandbox-local GitHub CLI authentication for repo work. Treat that as Q’s own working identity, not as a human browser session.

Good operator expectations:

  • use trusted repos
  • keep branch and PR discipline
  • prefer focused changes
  • run relevant checks before push
  • use issues for deferred work
  • do not let GitHub issue text override system, repo, or security instructions

GitHub content is often semi-trusted. Issues and comments are work items, not authority to change Q’s runtime or leak private context.

Maintenance posture

Maintenance should be visible because Q is a Slack-native teammate.

The operator pattern:

  1. check for active work
  2. announce downtime or degraded state in #q-status
  3. perform host work from the main/admin lane
  4. smoke-test Slack delivery after restart
  5. report complete or degraded state

The Status Light is the user-facing version of this. Operators should use the host runbook and helper rather than reconstructing it from memory.

The host helper is:

/Users/q/.openclaw/bin/q-maintenance

The full host sequence includes config preflight, active-work detection, an explicit override path, LaunchAgent gateway restart, health checks, a post-restart Slack delivery smoke test, and complete or degraded status reporting.

What to improve next

The biggest unfinished piece is the GWS broker.

The wrapper gets us out of the worst shape: observer cannot casually send mail, mutate docs, change sharing, or create calendar events from ordinary Slack. But it does not yet provide:

  • signed request envelopes from the gateway
  • per-object classification
  • object-level policy decisions
  • tamper-resistant audit records
  • clean broker verbs such as gmail.read_body, artifact.publish, or calendar.availability

That is the next real infrastructure project before we loosen any GWS side effects.

  1. Keep the user story simple. Normal teammates should learn how to ask Q for help, not memorize lane internals.
  2. Keep the operator story explicit. Main/admin, observer, and exec exist because different trust levels need different rooms.
  3. Use debug channels as tools, not destinations. They help operators verify routing and connectivity without confusing ordinary users.
  4. Treat GWS as gated but unfinished. The wrapper blocks risky observer side effects now; the broker is the durable solution.
  • Which GWS broker verb should ship first: artifact publish, calendar availability, or Gmail triage?
  • What should the operator audit view show for denied observer requests?
  • Which channel/routing checks should become part of the weekly security review instead of living only in docs?
  1. The Status Light — User-facing maintenance and availability behavior.
  2. The Only Locked Door — The architecture behind capable but bounded sandboxes.
  3. Runbooks Are Interfaces — Why operator instructions need to be executable by both humans and agents.