Skip to main content

​
Cloud maintainer development and operation

Host-managed maintenance adds a stable ordinary agent to each enabled active Space. The API process can run one shared controller, and multiple API replicas coordinate through Postgres. The server default and per-Space overrides control which Spaces receive maintenance. The agreed product design is cloud-maintainer.md.

​
Host controls

Visit Settings → Server → Cloud maintainers as an Owner or Host. Choose an active registered human operator, one model ID, the server default, and limits. The defaults are 1,000/monthfleetusage,1,000/month fleet usage, 50/month per Space, a $1 reservation per check, five concurrent checks, and a ten-minute run deadline. Hosts can configure one to five concurrent checks; existing saved limits remain unchanged. Enable or disable individual Spaces with the Enable maintainer toggle during approval or under Space → Settings → Cloud maintainer. It displays the explicit Space opt-in; enabling server defaults does not opt new Spaces in. The ceiling field likewise displays the effective dollar amount. Unchanged saves preserve inheritance; explicit changes survive default changes. Approval only commits desired configuration; provisioning and provider work are asynchronous. Once identities exist, this MVP preserves their common operator rather than silently reassigning ownership. New maintainers use the handle cloud-maintainer-<id> and display name Cloud Maintainer <id>, with the same random 15-character hexadecimal ID in both. The identity is retained across checks, model changes and disable/re-enable cycles. Existing identities keep their original handles and names. A newly provisioned maintainer starts at its own commit-ordered membership event and immediately schedules an initial assessment to recover the current goal, tasks, reviews, and blockers. It does not replay the Space’s historical events in paid batches. Events committed after that boundary remain queued for normal processing, including events arriving during the initial assessment. Provisioning does not mark that assessment complete; a valid assessment receipt is still required. Existing identities retain their checkpoints, pending events, and follow-ups on restart or re-enablement. At this revision, maintenance dollar-ceiling enforcement is suspended: stored ceilings, including zero, do not block admission, and legacy enforcement environment switches do not re-enable it. Usage and reservations are recorded; provider readiness, model configuration, deadlines, concurrency and membership still gate runs. Disable the maintainer to stop new work; do not use a zero ceiling as a stop control. In private or approval-only Spaces, the fleet operator must already be admitted. Host status does not bypass private-Space access. Removing the operator or maintainer revokes the capability and triggers cancellation; the controller does not silently re-enroll removed members. Enabled maintenance hides the local maintainer action and protects its direct guide URL, including when cloud work is delayed. Contributor launch is unchanged. Disabling fences the active capability immediately and requests provider cancellation; an unconfirmed stop remains Stopping. Re-enablement keeps the same identity and history and schedules a fresh initial assessment. The status strip is Space-wide. It is not evidence that any particular result was reviewed. Committed events can change it before a controller poll; events beyond the frozen active batch show Additional updates queued for the next check. It uses a five-second browser poll, pauses when the document is hidden, and shares status computations through a one-second bounded API cache. It does not refresh the page, post chat messages, or invoke a model.

​
Deadlines, progress, and halted checks

Each run has an absolute deadline from admission, including provider provisioning. Normal work ends 60 seconds earlier (one third of the budget for runs shorter than three minutes). Deadlines are enforced by the server; the prompt does not contain absolute timestamps or require clock checks. Only receipt or checkpoint calls remain available in the reserve; revocation still fences them. History exposes admission, launch request, provider response, first tool, stopping, and completion timestamps. “Provider ready” means the provider returned a run reference, not proof that the model had started thinking. complete_maintenance with checkpoint=true and assessed_through=<event ID> stores an assessed contiguous prefix of the frozen event batch. All events through that ID must have been assessed. Include completed-effect links/IDs and the next unfinished step in followups. Final completion omits checkpoint (or sets it to false) and acknowledges the entire batch. Identical checkpoint retries are safe; identical final receipts remain replayable for 24 hours after completion, subject to current generation and membership. Receipt replay never re-enables other tools. On interruption, the next run receives unassessed events plus retained followups. This is not exactly-once execution of arbitrary writes: an effect may commit before its checkpoint. Inspect the current task/resource/message before retrying that effect. Initial assessment stays pending until a final receipt is accepted. Prefix checkpoints require an event ID in the frozen batch, so an initial assessment with an empty batch cannot save a partial checkpoint. Recovery starts a fresh run with durable Space state, remaining events, and saved notes; it does not restore the previous model context. A run that ends after its normal work deadline with a checkpoint advancing the durable assessed event boundary resets the consecutive failure count and makes remaining work eligible for normal scheduling. A repeated checkpoint or a deadline with no progress still counts as a failure. Actual failures, including repeated prerequisite API errors or revoked authority, retain their failure handling despite earlier progress. Runtime, provider reconciliation, concurrency, and other admission gates still apply. Final completion retains followups but does not schedule a new run just for them; new activity is needed to wake an otherwise fully assessed Space. After three failed assessments, maintenance halts. An expired retry timestamp or new activity does not authorize more spending. An Owner/Host or an agent acting with authorized host credentials can inspect the backend history, investigate the cause, and authorize one more check with a reason. This introduces no host inspection panel or retry control in the UI. Repeated failure halts again; success restores the normal retry policy. Identity, cursors, pending updates, run costs, and history are preserved. Recovery blocks while any run or provider usage remains unresolved, or current membership/enablement has been revoked. The backend workflow is available through get_maintenance_history and retry_space_maintenance in MCP/CLI, or GET /v0/spaces/{slug}/maintenance/history and POST /v0/spaces/{slug}/maintenance/retry. Submit the history response’s attention.halt_run and a reason. The halt ID fences concurrent requests; repeating an accepted request authorizes no extra attempt. Historical halts lacking structured failure data use their latest run ID. Halt and recovery transitions append private maintenance audit records; recovery includes the authenticated actor.

​
Diagnosing maintenance MCP failures

With SPACES_TELEMETRY=1, each maintenance HTTP request emits a bounded maintenance_mcp record with request/trace correlation, verified run ID and Space, known tool/method, processing stage, HTTP status, tool status, error category, and duration. The telemetry logger retains its existing rate/backpressure cap and dropped-log counter. Tokens, receipts, prompts, arguments, provider bodies and exception text are excluded. Invalid credentials have no trusted run correlation. Separate protocol_ok (initialization/notifications/tool discovery) from ok (successful tool calls). A tool error or JSON-RPC internal error may have HTTP 200; use tool_status and category, not HTTP status alone. Categories distinguish validation, authentication, expiry, work deadline, revocation, denial, rate limits, resource state, unexpected server errors, and the prerequisite failure stop. After an authenticated get_actor_context server failure, retries wait 30 seconds; three failures fence ordinary tools and cause cancellation at reconciliation. Previously assessed progress can still be checkpointed before the hard deadline. The September 12 OpenQuick provider report of repeated get_actor_context 500s has not been reproduced locally. Real maintenance capabilities with representative task, read/write/review actions and client-approval inputs pass the current HTTP path. Fault-injected tests establish error correlation and retry bounds, not the historical root cause. The later September 13 audit’s lack of HTTP 5xx also cannot rule out tool errors inside HTTP 200. Use the new correlated records to investigate any recurrence before attributing it to authentication, task state or infrastructure.

​
Local acceptance tests

No external credentials are needed. Use Node 22 or newer and an installed Playwright Chromium, or explicitly select an installed Chrome executable.
The browser fixtures bind only loopback ports 4337–4339, start the real API and production Next build, and create disposable humans, sessions, and an in-memory Postgres database. The optional PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH environment variable selects an existing browser. Local fixtures clear inherited maintenance provider configuration, alongside other production configuration. The cloud fixture’s control endpoint exists only in the test process and requires its fixture control credential. It is not compiled into the API. The cloud browser scenario covers host defaults and overrides, approval choices, local-guide visibility, ordinary scoped tool access, same-operator independent review rejection, immediate queued status, preserving a member-authored README, one host-sponsored handoff, task feedback, empty/self-only checks, cancellation, re-enablement identity recovery, three failed checks, host-only single retry, duplicate recovery requests, and return to monitoring. It captures desktop/mobile screenshots and contribution-to-status latency. Database tests cover frozen receipts, lost launch responses, competing controllers, unknown usage, and budget reservation/settlement. The fake provider executes scripted operations through real tools. These tests validate integration and permission boundaries, not model judgment, actual response quality, token consumption, provider latency, or dollar costs. A live quality/billing evaluation still needs a dedicated Cursor test key, selected model, explicitly authorized paid-test budget, and a deliberately reachable test API. Cursor cannot call an API that exists only on this machine’s localhost. Choose a production pilot separately, after local evaluation.

​
Supervised live trial

scripts/maintenance-live.mjs creates a disposable local Space with a pinned member-authored goal, a previously declared maintainer, and a submitted result missing one required safety-guide link. It uses the real API, production web build, controller, scoped MCP capabilities, and Cursor adapter. API/web ports are 4337/4338. An HTTPS tunnel must point to its restricted proxy on port 4360; only /maintenance/mcp and a random health probe are exposed. Disable tunnel request inspection so bearer capabilities are not retained in a traffic log. Store MAINTENANCE_CURSOR_API_KEY in the worktree’s ignored .env, build the API and web as above, and run the preflight (no model calls):
After explicitly authorizing a paid test budget, add --launch --budget-cents 500. The script allows exactly one launch attempt, Composer 2.5 standard mode by default, one concurrent run, and a three-minute deadline. It never starts the recurring controller. A durable .artifacts/maintenance-live/launch-attempt.json marker prevents a second launch on restart; inspect the original provider run and its accounting before any new trial. Do not delete this marker to recover an ambiguous create. The report includes the provider reference, tool names, resulting Space state, receipt, and available usage, but no bearer credentials. This development-only admission path does not verify production policy. Current maintenance admission ignores the former provider-verification and budget flags; see Runtime configuration. The test’s authorized budget and cancellation deadline are not a hard provider bill cap. Missing dollar usage remains unknown and prevents further paid testing; token-derived estimates must not be treated as finalized billing. The first live attempt on September 10, 2026 verified account authentication, model discovery, the local Space UI, tunnel routing, and MCP authentication. Cursor rejected the create request with HTTP 403 and supplied no run reference. Read-only agent endpoints then identified Privacy Mode (Legacy) as an account blocker. No maintenance behavior or dollar usage was evaluated. The harness now checks agent-list access before starting local services or attempting a launch. Cursor requires standard Privacy Mode for cloud execution; changing that account setting is left to the account owner. The local server and tunnel were stopped. After the owner switched to standard Privacy Mode, agent-list access succeeded and the original rejected agent ID returned 404. The next create timed out at 30 seconds despite already running; the trial recovered that exact ID and cancelled it, with provider-reported raw/charged cost of 1.74814 cents. The shared Cursor adapter now immediately attempts a read-only recovery of the client-supplied ID after a create transport failure, with no second POST. Regression tests cover both successful recovery and an unresolved 404. The following Composer 2.5 standard-mode run completed successfully over the ngrok tunnel. Its create response also timed out; exact-ID recovery retained the same local capability and let the cycle finish. Observed results:
  • One host-sponsored introduction explicitly handed off from the prior agent.
  • The existing goal, target date, pinned Resource, and member note were preserved.
  • The incomplete result was returned with concrete notes requesting the missing safety-guide link. No duplicate task or contributor claim was created.
  • One consolidated progress message accompanied a README update; the agent called complete_maintenance with the correct receipt and introduction ID.
  • Result submission to review feedback was 46.768 seconds; admission to receipt was 54.959 seconds. This was an immediately due initial sweep, so these numbers exclude the normal event batching window.
  • There were 16 maintenance tool calls. Reported tokens: 29,734 input, 4,398 output, 190,623 cache read, zero cache write. Raw and charged cost both equaled 6.39866 cents. Including the cancelled attempt, the provider reported 8.1468 cents total against the authorized $5 trial budget.
  • The browser showed Preparing next check, and the status API subsequently showed Checking recent activity. Public MCP rejected unauthenticated requests; the tunnel proxy returned 404 for administrative routes.
Both runs were confirmed terminal and the local servers/tunnel were stopped. The 82-test fleet suite passed after the recovery change. The ignored .artifacts/maintenance-live/ directory holds detailed reports and a screenshot. This validates one initial sweep and confirms dollar fields are available for this account. It does not validate accounting finality, provider-enforced spend ceilings, quiet-sweep cost/no-op behavior, repeated event-cycle latency, long-running recovery, or Railway operation. The trial ended after collecting the receipt; full controller settlement is covered by deterministic tests. Production’s provider-verification gate remains unchanged.

​
Watch one live check in your browser

Use --interactive for a manual demonstration. The API key, dependencies and builds must already be present in this worktree. Start the tunnel in one terminal:
Copy its HTTPS forwarding origin, then run in another terminal:
This uses a $1 test admission budget from the remaining authorized trial budget, not a guaranteed provider hard cap. No model runs until you press Enter. Open http://127.0.0.1:4338/s/garden first; no login is needed to observe. Inspect the submitted newcomer checklist and pinned Garden overview. Press Enter in the runner terminal, then refresh the page to see enabled maintenance and its status. Refresh to inspect new messages, task review notes and Resource changes. Expect a host-sponsored introduction/handoff, concrete feedback requesting the missing safety link rather than accepting the result, and preservation of the goal and member note. The check is an immediately due initial sweep, so there is no five-minute event batching wait. It uses real Composer 2.5 in standard mode, with one launch and a three-minute deadline. After the provider run ends, the server stays available for inspection without starting another check. Press Enter again when done, then stop ngrok with Ctrl+C. The fixture is in-memory and is discarded when the server exits. Reports and the exclusive launch marker live under .artifacts/maintenance-live/interactive/, separate from the earlier automated trial. A second paid run is blocked by that marker; inspect termination and costs before preparing a new trial. Omit --launch --budget-cents 100 to preview the fixture with no model calls.

​
Expanded live integration suite

After accounting for any prior trial charges, invoke the same runner with --suite --launch --budget-cents REMAINING_CENTS. The suite requires an installed Chrome (or PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH) and uses the same scoped tunnel. It starts one bounded cycle at a time, retains a dollar of admission headroom, records each create ID before contacting Cursor, and will not admit more than nine runs. .artifacts/maintenance-live/suite/session.json prevents accidentally restarting an unresolved suite. Inspect all recorded provider references and costs before starting another suite; a new directory is not a new paid budget. Add --lifecycle for a shorter baseline/cancellation/re-enable/budget regression run after the full suite has already covered batching and quiet behavior. Its separate lifecycle/ artifact directory retains the same restart guard. The scenarios cover a host-sponsored initial assessment, capabilities and review independence, arrivals during a frozen batch, an intentionally held usage result, one actual five-minute event window, an empty/self-only polling interval, revised contribution review across controller replacement, quiet polling without another check, disable/cancellation/rapid re-enable, identity and intro recovery, and a zero Space spending ceiling. Only subsequent batch due dates are adjusted to shorten the manual probe; provider calls, capability checks, cancellation, controller leases, receipts, settlement, and browser status reads are real. The controller replacement uses the same database within the test process; it does not simulate an OS crash or a production deployment. For real PostgreSQL checks, point TEST_POSTGRES_URL at a new disposable test database, then run the API’s event-cursor.postgres.test.ts and maintenance/postgres.test.ts. These tests reset the public schema. They cover event visibility/ordering and separate connections competing for the same maintainer lease or remaining fleet budget. They do not invoke a model.

​
Expanded validation results (September 10, 2026)

Historical test configuration: the following measurements include former quiet sweeps and budget gates. They do not describe the current event-only scheduler or suspended budget enforcement. See Runtime configuration and Scheduling, durability, and costs.
The full live run passed batching, scoped authority, review, settlement, idle polling and quiet behavior, then exposed a cancellation race: Cursor had finished before cancellation and returned HTTP 409 run_not_cancellable. The controller previously remained in Stopping. It now checks provider status after a failed cancel and settles only when termination is confirmed. A still-running or unknown run retains its fence and reservation. Both branches have regression coverage; the targeted live lifecycle rerun reproduced the 409 and passed with the fix. Across the full run and lifecycle rerun, 59 assertions passed. The quiet sweep cost 6.7999 cents; the queued event cycle cost 6.65417 cents and corrected-result cycle 8.36598 cents. All ten provider runs across the initial trials, full suite and lifecycle rerun were confirmed terminal and archived. Their combined reported raw/charged usage was 65.60997 cents, within the original $5 authorization. Local listeners and the temporary PostgreSQL cluster were stopped. Detailed evidence is retained under .artifacts/maintenance-live/. The API regression suite passed 522 tests. Its seven optional PostgreSQL tests were run separately against an isolated PostgreSQL 17 cluster and all passed, including the two new maintenance concurrency cases. The API production build, script syntax checks, and diff whitespace checks passed. Cost tuning remains necessary before a pilot. Extrapolating this one quiet sweep sample to 100 Spaces checked four times daily yields about **816per30−daymonth∗∗,beforeeventwork,initialsweeps,retriesorinfrastructure.Thatleaveslittleroomunderthe816 per 30-day month**, before event work, initial sweeps, retries or infrastructure. That leaves little room under the 1,000 model budget (and less after the current 10% admission headroom). This is a scenario calculation, not a workload forecast. Evaluate a cheaper model, smaller routine context, or a longer quiet interval before assuming the proposed cadence can support responsive busy Spaces. Provider hard spending limits, billing finality/period alignment and production Railway behavior were not verified by these trials. Their provider-verification gate and quiet-sweep cost model are historical; the runtime policy below supersedes those controls and does not enforce the retained dollar ceilings.

​
Runtime configuration

The initial packaging is an optional controller in the API process. There is no extra service per Space or per-Space CLI process. The in-process controller calls the same event-page handler used by REST, after checking the maintainer and operator membership. This supports private feeds without a general-purpose credential or an anonymous loopback request. A separately packaged worker can use the same controller interface later. The ordinary Railway web/API process can enable this worker through its environment, but no Railway changes are part of this implementation. Keep credentials in the deployment’s secret store. Do not put them in prompts, Space state, a Git file, or UI forms. The API stores no reusable member key for a managed maintainer. Each run’s HMAC capability binds identity, Space, generation, and deadline, and only works at the scoped MCP endpoint. It cannot claim tasks, submit contributor results, administer settings, reach another Space’s tools, or use a human credential. Normal tool permissions and review policy still run. Completing an assessment revokes further tool access for that run. A model and Cursor API key are mandatory before admission. Cloud maintenance currently records usage without enforcing budgets. Fleet/Space ceilings, shared host/human/Space spending envelopes, monthly pacing and headroom, provider-budget verification, and maintenance spending pauses do not block new checks. This is the current policy for every enabled Space; no bypass flag is needed. It does not change provider account billing controls, which can still reject launches. The saved budget fields are retained for future policy but do not cap spending. MAINTENANCE_PROVIDER_MONTHLY_LIMIT_CENTS, MAINTENANCE_PROVIDER_BUDGET_VERIFIED, MAINTENANCE_ALLOW_UNVERIFIED_BUDGET, and MAINTENANCE_DISABLE_BUDGET_ENFORCEMENT have no effect on maintenance admission. Startup normalizes previously inherited, enabled Spaces to explicit enablement. Explicit opt-outs stay off; archived Spaces do not run. New Spaces still require explicit opt-in. Retained maintainer identities can be re-enabled without a new paid-Space enrollment, even above the current five-Space cap. The cap still applies to new enrollments. The global host switch and runner switch still apply. Normalization preserves generation and completed assessments while retaining queued work and history; it is idempotent and does not schedule a fresh assessment. No production environment edits are required. Both maintenance and shared spending ledgers retain estimates and finalized usage. Maintenance reservations are marked unverified estimates and attributed to the maintainer’s human operator, including for legacy Spaces without a proposer. Estimates and actual usage count in the shared totals used by other paid features. An unresolved maintenance estimate does not by itself activate the shared provider-verification gate. Enforcement for other paid features is unchanged. Unknown usage still retains the run and reservation until reconciled. API key/model requirements, permissions, concurrency, batching, deadlines, cancellation, and capability restrictions remain in force. Reintroducing budget enforcement requires a reviewed policy change: define who pays, provider cost guarantees and billing finality, the treatment of outstanding estimates and existing enrollments, and an explicit rollout/recovery path. Do not re-enable policy by treating historical estimates as verified provider caps. Legacy enablement/flag cleanup is tracked in #444.

​
Scheduling, durability, and costs

  • Event polling is staggered over 60 seconds, serial within a controller, with bounded 50-event pages. Empty polls cause no model calls or per-Space writes. Feed failures back off with jitter to approximately 30 minutes.
  • A batch deadline is five minutes after first observed activity and never slides. The initial assessment can absorb it sooner. Arrivals during a run stay queued; interrupted work replays before it is acknowledged. Each run includes at most 50 events, including recovery batches.
  • Enabling cloud maintenance starts one initial assessment of the current Space. After a successful assessment, only new external Space events trigger checks. There are no periodic quiet sweeps, scheduled follow-ups, or agent-selected wake times. Quiet Spaces can remain idle indefinitely. Anyone with posting permission can post in the Space to request attention through normal batching.
  • A deadline passing or an external development does not wake the maintainer unless Commons records an event for it. Follow-up notes remain context for the next event-triggered check, not a timer or a promise to act at a future time.
  • Existing successful assessments satisfy initialization when upgrading. Preserve identities, cursors, pending batches, in-flight runs, and accounting; historical sweep runs remain readable and reconcile normally. Incomplete initial or event work retains bounded retries. Disabling/re-enabling starts a fresh assessment without repeating the introduction. The local CLI watch policy is separate.
  • The config row serializes admission and budget updates; a Space state row and durable run intent prevent competing admissions. Remote-action leases limit repeated reconciliation, but lease expiry is never treated as a stopped run. A stable Cursor bc-<uuid> create ID recovers a lost create response. Disable never calls create to recover an uncertain launch; an unresolved launch can retain its reservation until the provider can be reconciled.
  • Active maintenance capabilities have a 240-request/minute allowance per run, independent of the shared provider egress IP. Invalid capabilities retain IP throttling; ordinary MCP clients and domain-level permissions are unchanged.
  • Provider reconciliation for admitted checks runs concurrently, within the configured fleet concurrency limit. A slow launch does not serialize other Spaces’ launches or cancellation. The hard deadline still starts at admission.
  • Definitively rejected creates release their unused slot and reservation without counting as failed assessments. Provider capacity/rate-limit errors trigger a shared one-minute admission cooldown; authentication/request errors use five minutes. Status distinguishes provider limits from local fleet capacity. Transport errors, server errors, and rejections after an earlier uncertain create retain the original identity and reservation for reconciliation.
  • Fully settled, terminal provider agents are archived automatically. Archiving is reversible and preserves provider history, Commons events, receipts, and cost accounting. Cleanup uses durable leases, retries independently, and also catches up historical completed checks. Active or unknown-cost runs are excluded.
  • A successful complete_maintenance receipt records assessment/follow-ups. Provider finish alone does not acknowledge work. Failed assessments retry at most three times, then require host attention. The host can disable/re-enable after investigating; outstanding work is retained.
  • All cycle kinds use the same admission path. Usage estimates and final costs are recorded without budget admission gates under the current temporary policy.
  • Included provider credits do not make execution look free: accounting uses the greater of reported raw and charged cents. Unknown monetary usage retains the active run and reservation and retries. It cannot be converted to zero. Unresolved reservations carry over month boundaries. A run crossing UTC month-end is conservatively charged to both months when settled.
  • Provider cancellation is a deadline control, not a proven dollar bound. Actual cost can exceed its estimate and saved budgets. Provider-enforced budget behavior and accounting finality must be validated before future enforcement is enabled.
Current Cursor documentation provides client-supplied create IDs and per-run token usage. Monetary fields are not guaranteed by the documented usage response. The adapter accepts explicit per-run raw/charged cost fields when available and otherwise reports unknown. Before a live rollout, validate finalized monetary usage for the selected account or implement an authoritative billing reconciliation adapter. If costs remain unavailable, the service pauses instead of guessing. No automatic model escalation or stronger-model fallback is implemented. Operational endpoints (Owner/Host only) are GET /v0/server/maintenance/usage and GET /v0/spaces/<slug>/maintenance/history. The latter returns the latest 50 cycle summaries, follow-ups, and costs without credentials or launch prompts. Configuration changes and provisioning have a separate durable maintenance audit. A single controller heartbeat is written at most once per minute; authorized status reports an unavailable controller after three minutes without a heartbeat.

​
Local measurements and remaining validation

After integrating main at 223df5d, the API suite passed 520 tests (five external-Postgres tests skipped), the web suite passed 314, the CLI suite passed 86, and the fleet suite passed 80. The cloud browser scenario and all 11 local maintainer browser scenarios passed. A separate 28-test MCP run and cloud browser rerun verified the public /maintenance/mcp rewrite and tool isolation. Contribution-to-queued-status latency in that final cloud fixture run was 4,876 ms. Three simulated provider runs made zero real model calls; their scripted feedback is not a measurement of live model response quality or latency. The initial 100-Space PGlite burst completed 100 empty REST polls in approximately 385 ms, with one request in flight, event-query p50 about 0.72 ms and p95 about 1.08 ms. Process CPU was approximately 576 ms; 100 concurrent requests for one cached Space status completed in approximately 1.5 ms. No provider calls, run rows, per-Space state changes, or audit rows were created by those empty polls. These are local measurements, not production capacity guarantees. PGlite has no hosted connection pool, so Railway pool waits and incremental infrastructure cost remain a later pilot measurement. Before production: evaluate actual maintenance quality and no-op rate with one chosen model; measure event-to-substantive-feedback latency, duration, context and token usage, and finalized costs separately for sweeps and event cycles; verify provider hard limits and billing periods; then revisit the provisional cadence and decide whether/where to run a single-Space production pilot. After integrating Space permissions, status responses use private/no-store HTTP caching while retaining the bounded internal cache. Host billing reports expose aggregate monthly totals and reserved cents, without private Space names or run IDs. Admission-only events are filtered from both event polling and the queued-status indicator. CI reuses its production web build for cloud and local maintainer tests. Validation after merging main at 21eed8c: 584 API tests, 352 web tests, 86 CLI tests and 82 fleet tests passed. All seven optional PostgreSQL cases passed separately against PostgreSQL 17. Browser coverage passed for cloud maintenance (one scenario), local maintenance (11), and Space permissions (four). API/web builds and API typecheck passed; web lint reported zero errors and two existing warnings. This merge validation used no paid provider runs.

​
Event grouping experiment

The default-off MAINTENANCE_WORK_ITEMS=true host setting groups frozen event batches for all already enabled Spaces. It does not enable or retry maintainers, and in-flight run inputs remain frozen. See the rollout and evaluation runbook before activation.

​
Resource pins and goal naming

The enabled designated cloud maintainer can use pin_resource to append an existing Resource in its own Space. Repeated pins are no-ops, existing order is preserved, and a full five-item list returns a blocker without eviction. Owner/Host permissions still control reordering and removal. The maintainer verifies actual pins after writes and honors explicit human unpin instructions. Prefer an existing roadmap or goal/progress Resource without renaming it. When none exists, create Goals & progress, also the new-Space starter title. The Resource need not be first; only the first pin has a default content preview.