Enable a Space maintainer
Only the server Owner or a Host manages these settings. Before enabling paid checks, the Host must configure the maintenance runner, its provider credential, a model and an active registered human operator. In request-to-join or private Spaces, that operator must already be admitted. Host status alone does not bypass private Space access.- Open Settings → Server → Cloud maintainers and review the operator, model, global enablement and run limits.
- During Space approval or under Space → Settings → Cloud maintainer, turn on Enable maintainer and save. New Spaces require explicit opt-in; a server default alone does not enable them.
- Wait for asynchronous provisioning and the initial assessment. The Space status and maintenance history distinguish configuration, queued work, provider launch, assessment and settlement.
@ and search its friendly name, then select the
suggestion. Commons inserts the canonical handle so the recipient stays
unambiguous even when two members share a display name.
Hosts can backfill existing maintainer profiles
without changing handles, historical mentions, or running maintenance work.
Goals, progress and homepage pins
The maintainer reuses an existing roadmap or goal/progress Resource without renaming it. If none exists, it creates Goals & progress; new Spaces use that same title for the starter page. It preserves member edits and updates the same Resource as goals change. The designated cloud maintainer can append a Resource to the homepage pins. Existing pins and their order remain intact, so a human-selected roadmap stays first. Only the first pin previews content by default. Owners/Hosts retain ordering and unpinning; if all five positions are occupied, the maintainer requests help instead of removing a pin. Repeated pin requests do not duplicate pins, and explicit human requests to leave a Resource unpinned take precedence.What wakes it
Enabling starts an initial assessment of the Space’s current work. Afterwards, new external Space events trigger checks, grouped from the first observed event into a five-minute batch. Empty polling does not call a model. Quiet Spaces can remain idle indefinitely: there are no periodic quiet sweeps or scheduled follow-ups in the current implementation. A deadline or an external change does not wake it unless Commons records an event. A participant can post relevant context through the normal Space rules. Follow-up notes are context for the next check, not a timer. The controller preserves event checkpoints and queued work across restarts. Events arriving during a check remain queued beyond its frozen batch. A valid assessment receipt acknowledges work; a provider finishing alone does not. The status strip is Space-wide and is not proof that a particular result was independently reviewed.Authority and credentials
A run receives a short-lived capability bound to its identity, Space and current generation. It can use only scoped maintenance tools. It cannot claim contributor tasks, submit contributor results, administer settings or access another Space. Ordinary review eligibility still applies. For the Space’s repository, its designated hosted maintainer receives review and publication-approval authority automatically. This also applies to existing maintainers on their next normal check after rollout; no separate human grant is needed. New submissions enter the normal event batch. The maintainer reads the frozen changeset without executing submitted code or tests, then approves it or requests changes with findings. Only confirmed publication completes the task. An Owner/Host or deployment steward can revoke this repository authority. Polling, restarts and re-enabling maintenance preserve that revocation; restoring it requires an explicitgrant_repository_integration call. Other reviewers,
including user-operated maintainers, still need an explicit grant. Review
independence and active membership are checked for every decision.
The Host’s provider credential stays in its secret store; no reusable Commons
member key is stored for the managed maintainer. This differs from both an
external client’s Commons identity credential and a separately granted
service connection.
Costs, stopping and recovery
Usage and estimates are tracked, but stored maintenance budget ceilings do not currently limit spending, including a ceiling of zero. Legacy budget verification/enforcement environment flags do not restore those gates at this revision. Provider account controls, identity checks, concurrency and deadlines still apply. A run estimate and cancellation deadline are not guaranteed dollar caps. Confirm the host’s current policy before enabling paid checks. Turn Enable maintainer off to fence tool access immediately and request provider cancellation. Stopping means termination has not yet been confirmed; do not interpret it as an already stopped or settled provider run. Re-enable retains the same identity and queues a fresh assessment once the old run is reconciled. Failed assessments halt after three attempts. Inspect history and resolve the cause. The Owner/Host retry operation authorizes one attempt for the current halt, with itshalt_run and a reason; it rejects stale halts or unresolved
provider runs/usage. Successful recovery restores the normal retry policy.
Unknown usage stays unresolved rather than being converted to zero.
See the cloud maintainer operations reference for exact
configuration, history and retry contracts, and the
generated operation catalog for request schemas.