Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Implementation status

The foundation, job/worktree evidence, reviewed completion, shared-record, operator-workflow, backup/restore, Linux operational controls, and MCP are implemented. Linux release acceptance and the final native Windows/Linux workstation exercise passed; see the retained evidence below. The complete release remains defined by PLAN.md; this document records current behavior.

Working now

  • Reviewer candidate shells accept both flat harness cwd files and the bounded tmp/claude-UID/cwd-ID layout. The nested directory is recreated inside the isolated tmpfs; the host harness directory stays hidden. Invalid paths, symlinks and nonregular cwd targets are refused before candidate execution, and the host target is checked again before resetting the tracked directory.

  • The integrator has a pre-cutover shadow command and queue view, with host setup and local evidence gates described in the cutover runbook. These are source behavior; the production shadow day, rulesets and ownership cutover remain operator work and are not claimed complete.

  • Dashboard project settings show the current integration owner and let a human change it after an explicit confirmation with a recorded reason; a held integration refuses the change. A per-project integrator reports page lists reports (open or all, paged) and lets a human resolve one with a note, plus allow or deny for a privilege gate. Any reader can also list and show reports through the read-only integrator-reports CLI commands and the MCP tools coordinator_integrator_reports_list and coordinator_integrator_report_get.

  • Supervisor hosts report launch cost rows and end-to-end canary results to the service per project, idempotently and attributed to the reporting principal and host, and the service aggregates them: cost per task and per day (implementer and reviewer) and canary history with the latest result per host and harness (see the API contract). agentc-supervisor sends unsent costs.jsonl rows after every poll and e2e-canary.py sends each run’s result, with the host files kept as the source and unsent rows retried (rows of a project the service reports as project_not_found are quarantined in costs.quarantined, with the reason, instead of retried); agentc-supervisor report-costs and e2e-canary.py --backfill import existing files once. The supervisor also reports its per-role daily spend caps (POST .../telemetry/caps), and GET .../telemetry/autonomy counts finished tasks, human-required interventions, review outcomes and parked tasks from the service’s own records, and GET .../telemetry/autonomy/window answers the same question for an exact [start_ms, end_ms] window (both bounds included, independent of query time) with interactive versus supervised and integrator events, reserved canary exclusions, historical stall and park episodes, human-origin throughput and latency, direct-push coverage with its denominator, and a human-required total withheld whenever a source is unavailable. The console’s per-project Autonomy view (opened from the project settings or the summary on each project card) shows the rolling figures with the digest, and links every figure to the record it comes from; it does not yet show the exact-window read.

  • Standalone agent-coordinator-mcp stdio adapter with protected, locked, atomic mutation journals and exact retry through the service. Native CLI installation is not required for coordination. Direct HTTP hosts still need their own verified persistence; see adapter requirements.

  • Optional project_name in repository bindings selects a protected project credential directory independently of worktree location. Legacy bindings keep shared lookup; explicit selection fails closed and environment precedence remains.

  • Human-controlled allow_subagent_reviews permits registered non-contributing project subagents to review parent work. Durable identity survives new sessions; helper contribution checkpoints preserve exclusion. Default principal independence and human reviews remain enforced. This is trusted harness identity, not proof of independent reasoning. See configuration and examples.

  • Anonymous /api/v1/info serves the versioned, OS-independent agent startup guide, including MCP-first connection selection, credential discovery, native fallback, automatic task claiming, recovery, and review requirements. Missing CLI does not block MCP coordination. Native session adopt-mcp verifies and saves the same quiescent MCP session for local operations, without claiming or renewing work. The short repository bootstrap needs no backlog file. Public discovery contains no private project state; authenticated orientation and tasks remain authoritative.

  • A Google Cloud installation at agents.sithbit.com uses an e2-micro in South Carolina, persistent SQLite storage, Caddy HTTPS, Cloudflare’s IPv6 proxy, and verified hourly off-server backups. Public sign-in, CSRF protection, restart, and an initial independent restore were exercised. See deployment details and the live handoff for exact package identities, free-tier limits, and capacity/recovery scope. No repository is automatically bound and no agent is automatically enrolled.

  • Authenticated stateless Streamable HTTP at /mcp with 62 typed tools routed through the existing REST authorization and mutation checks. A protected native launcher shares the exact saved harness identity with a trusted foreground MCP client and its native CLI children. See the MCP guide.

  • Axum HTTP service with embedded vanilla JavaScript/CSS dashboard; SQLite WAL, foreign keys, migrations, transactional event records and mutation receipts.

  • The dashboard refreshes in place: polls, reloads and finished mutations patch only the nodes whose data changed and keep focus, selection, open disclosures and scroll position; polling pauses in a hidden tab, behind a dialog and during a pending mutation. See Web UI refresh behavior.

  • A human operator can archive a project from its settings page or with agent-coordinator projects archive, and restore it from the Archived projects view or projects restore. Archived projects leave the project list, keep their records and refuse new claims, tasks and policy changes until restored.

  • Each main dashboard view has an address (#/projects/<id>/tasks, /completed, /archived, /task/<task id>, /settings, /reports, /sessions, /digest, /autonomy, and #/archived-projects, #/shared, #/resources, #/admin), so the browser’s Back and Forward buttons walk the views visited and a link opens its view after sign-in. Open dialogs are not part of the address. See Web UI refresh behavior.

  • The task queue and Completed tasks views filter by Kind, Origin and Delivery mode together with Status and search, in the browser over the loaded list. See Web UI refresh behavior.

  • Local administrator initialization and password sign-in; Argon2id hashes, protected browser cookies, origin/CSRF checks, bounded login attempts, and human-admin issuance/revocation of separately named agent credentials.

  • Multiple projects visible to every authenticated principal. Human operators create projects and control delegation. Agents create tasks and can change project rules when explicitly delegated; they cannot grant themselves permissions.

  • Tasks with acceptance criteria, priorities, immutable definition revisions, planned/open lifecycle, same-project prerequisites and cycle rejection. Listings are observations. A transactional claim is the only ownership grant.

  • Read-only precondition inspection for task, review, and integration claims. Task and orientation workflow subjects surface known blockers, including reviewer independence, changed task requirements (reopen or agent revise), and a local Git merge-preflight hint. An authenticated bounded long poll waits up to 30 seconds for one task status or workflow activity state token, checking at 500 ms intervals without holding a database transaction or renewing work. The service cannot inspect remote Git state or determine merge conflicts.

  • Separate harness sessions with random persisted proofs bound to the issuing credential. One current attempt per task, monotonic ownership generations, renewable deadlines, separate heartbeat/progress timestamps, and revocation checks after acquiring the database writer lock.

  • Checkpoints and release handoffs; release requeues or blocks a task and never marks it complete. Expired/revoked ownership requires a recovery claim and an explicit saved-work/job inspection record. A project can restrict recovery to humans. The human can resolve and release inspected work for an agent to claim.

  • Clean-checkout registration with workstation/identity conflict checks and readable checkout metadata. Each implementation attempt should use its own worktree. The service records client attestations; it does not inspect a remote filesystem or execute Git itself.

  • Task queue and Completed sorting in the dashboard: a Sort select (Priority then oldest, Oldest first, Newest first, Longest ready, Most recent progress, Least recent progress) orders the whole filtered list client-side, with the task id as the final tie-break and tasks without progress last for the progress sorts. Task list items carry last_progress_at (newest checkpoint time or null), so no per-task detail request is made. The choice is kept in localStorage (agent-coordinator.task-sort) and falls back to the default when storage is unavailable. scripts/test_task_sort.mjs covers it.

  • Saved task views in the dashboard: a Views control under the task toolbar saves the current status, kind, origin, delivery, search and sort under a name (at most 60 characters, 20 per project), applies, renames and deletes it (delete asks for confirmation), and marks the active view and when the toolbar differs from it. Views live in localStorage (agent-coordinator.task-views) per signed-in actor and project; every loaded value is checked against the toolbar’s options and invalid entries are ignored. They hold no task data or secrets, and applying one makes no request. When storage throws, views last for the page only and a note says so. scripts/test_task_views.mjs covers it.

  • Public authentication help and service-delivered project instructions with version acknowledgments. Task/project/event lists use bounded cursor pages.

  • Native CLI with origin-bound credentials, separate local harness sessions, JSON output, durable pending requests, and same-key retries. The dashboard supports project/task creation, task and checkpoint inspection, and credential administration; it has responsive layouts and no third-party scripts.

  • Native worktree preparation with durable intent, remote identity and clean-source checks. Repeating preparation reconciles the same checkout; it never resets or deletes existing work.

  • Global named capacity resources and atomic multi-resource reservations shared across projects. Holds survive task expiry, credential revocation, session loss, and missing observations. Ordinary release/recovery cannot bypass unresolved work.

  • Locally launched jobs with stable producer identities, a durable launch journal, bounded local logs, and a detached guardian. Reconnect observes the existing job; uncertain launch intent never authorizes another producer. Linux boot/start time and Windows process creation time distinguish process identity from a reused PID.

  • Scoped job reporter credentials, ordered idempotent observations, and optional bounded task renewal tied to a specific live harness. Observation authority and task ownership are separate. The service never launches workstation processes.

  • Dashboard resource administration and task job/hold evidence, including explicit human reconciliation with recorded termination/isolation evidence, and a per-resource History dialog (current holds, then released/resolved reservations across projects, one page at a time) backed by GET /api/v1/resources/{id}/reservations. Each job’s bounded observation history can be searched, filtered by state and downloaded as JSON from the task page (capped at 2,000 observations or 2 MiB).

  • Immutable code/general submissions pinned to task and policy revisions, with acceptance evidence, handoffs, and full Git commit/tree identities for code. Active jobs and unresolved physical holds prevent submission.

  • Independent agent, human, both, or either review. The either mode uses one shared review activity that an eligible agent or a human can claim and approve. Schema 18 preserves existing projects, review records, and history cursors; existing project policy selections are unchanged. Contributor principals and sessions cannot perform an independent agent review. Findings and decisions stay bound to the exact submission; requested changes require a new candidate and fresh reviews.

  • An explicit human-managed required-check roster with repository identity derived from supported GitHub clone URLs, preservation of saved bindings, and an administrator alias flow for custom hosts. Integration holds serialize every project sharing that repository/target pair. Projects can permit automatic integration or require a human authorization.

  • Native integration prepares a candidate-containing result in an isolated worktree, validates registered producers against its exact commit/tree and check roster, and requires fresh service authority before a compare-and-swap Git publication. Once push intent is saved, retry only observes; it cannot launch another push.

  • Code tasks become done and release dependents only after required approval, known publication, exact successful check receipts, fresh remote observation, and resource quiescence. General tasks finish after their required reviews.

  • Dashboard submission evidence, review decisions, human review/authorization, publication reconciliation, and project review/check settings. Publication reconciliation preserves the original evidence and requires a new integration activity and fresh validation; it never fabricates a successful check.

  • Revisioned lessons, facts, rejected approaches, and checkpoints; applicability, explicit cross-project sharing, provenance, usefulness feedback, and immutable revision history. Submission lessons and finalized artifact references commit atomically with the immutable submission and retain their original revisions.

  • Plain-text FTS context search with bounded records, full current binding rules, explicit budget/truncation guidance, and current scoped decisions. Rule changes record provenance and preserve policy history.

  • Scoped decisions with typed allow/deny/defer answers, required actor, exact task/policy revisions, environment, conditions, expiry, and reopening history. Blocks apply to selection, work, review, integration, and displayed authority; inspection, checkpointing, and release remain possible while work is blocked.

  • Relayed human answers: a human-only project policy switch allow_relayed_human_answers (default off) lets an agent session record the reply a human gave it for a required_actor=human decision. The answer keeps the relaying session, the verbatim prompt and response, and the enabling human principal and policy revision; the dashboard and decisions show mark it as relayed. Without the switch or the relay evidence the agent is still refused.

  • Attention budget (P3b): a decision may carry a recommendation and be marked reversible, and serve answers it with that recommendation after 24 hours unanswered (timed_out), except that a required_actor=human decision times out only when a human created or last reopened it; GET .../digest lists those decisions and the human-required interventions, which include stalled tasks (three consecutive attempts without a submission, rule repeated_attempt_failures) and a stalled queue (ready work and no task progress for more than 6 hours, rule no_progress, configurable, quiet hours excluded) and every open non-canary task the revise limit parks (code revise_limit_reached, also listed in next’s human_queue_items, gone once the task is no longer parked); tasks may declare paths and next skips a task overlapping files the integrator saw land out of band in the last 24 hours. deploy/agentc/attention.py renders and mails the digest and runs a canary that pages through ntfy once per failing check; the digest mail and the ntfy topic are host configuration, not exercised by CI. host-setup.sh installs the script with the agentc-canary (every 10 minutes) and agentc-digest (daily) systemd timers; deploy/agentc/host-setup-test.py checks the generated units and the uninstall list without root. deploy/agentc/e2e-canary.py is a daily end-to-end canary: it creates a trivial task in the host’s own canary project (canary-setup.py creates it once), waits for it to reach done within a deadline, appends the host, harness, outcome and duration to a results file and pages through ntfy on failure or timeout; host-setup.sh installs an agentc-e2e-canary@<harness> daily timer per configured harness. The task is created at E2E_PRIORITY (default 0, urgent), so a canary in the shared dogfood project is claimed before P1-P3 work. The supervisor can serve a second project, [run.canary_binding], on the same coordinator (canary project polled first, own mirror, installed binding copy, reviewer side, launch record, optional [push_helper.project_configs] entry), and integrator-host-setup.sh installs a second integrator unit template for it. The digest and its human interventions leave canary tasks out, and ledger rows of the canary project are marked. Tests cover all of this against fakes; live runs per host and harness, and a live second-project loop, are owner evidence and have not been recorded. deploy/agentc/agentc-update.py (installed as agentc-update with an agentc-update.timer) is a root-owned pull updater for Linux/systemd hosts: it fetches the latest release, verifies the SHA256SUMS asset, the build attestation and the bundle manifest, installs side by side, drains the supervisor, switches, runs preflight and the end-to-end canary and rolls back by itself on failure; harness binaries are staged and promoted only when preflight, the canary and containment-suite.sh pass. agentc-update-test.py covers it end to end against fakes. The release workflow builds native x86-64 and aarch64 core host bundles with internal and release checksums and GitHub build provenance, and publishes them only for version tags after release acceptance. --check verifies an available bundle in temporary storage without installing it. See the host release contract. A live host promotion has not been recorded; a Windows host updater is deferred.

  • Digest read tracking and the neglect page: the service stores a per-project last_read_at for the digest (digest_reads), set by a human opening the digest page in the dashboard or by the signed, expiring “I read this” link in the emailed digest; reading the digest through the API does not count. The canary pages through ntfy once when the digest has gone unread for more than ATTENTION_NEGLECT_DAYS days (default 3) and again only after a new read and another lapse; deploy/agentc/attention-test.py covers it with a fake clock. Only a human or the project’s designated digest sender (one agent principal, set by a human administrator through the API or on the host with designate-digest-sender; none by default) can obtain an ack link, so an ordinary agent credential cannot mark the digest read. The link names its minter and a read through it records that principal.

  • Target-block page: the canary reads the open integrator reports and pages through ntfy once when a fix_target report with blocks_subject (target_failing or target_unverified) has stayed open longer than ATTENTION_TARGET_BLOCK_MINUTES (default 30). The page names the project, the target revision, the failing check and the number of subjects waiting behind the block; it repeats only after ATTENTION_TARGET_REPAGE_MINUTES (default 360), and a resolved report sends one recovered note instead of a page. The digest still lists the report. deploy/agentc/attention-test.py covers it with a fake clock.

  • Human-delivered tasks: a task carries human_delivered (set at creation or with POST .../tasks/{task}/human-delivery, agent-coordinator human-delivery or the console). GET .../next never offers it to a supervised or read-only credential, a supervisor’s explicit claim is refused with human_delivery_required, and the rule holds after a changes_requested review returns the task to ready. An interactive session or a human still claims it. Existing tasks are unmarked; nothing is inferred from titles.

  • Admission control (P6): tasks record their origin (human, agent or service) and may carry an admission_class (revert, fix_target, deflake, refusal_fix); service-created reverts and revise follow-ups set it. An agent-created task without a class is admitted only while fewer than 14 (--agent-task-weekly-budget; raised from 5 on 2026-10-30) agent-originated tasks were admitted in the task’s own project in the current ISO week (the budget is per project, so one project’s tasks never use another’s); later ones are created planned, the response says why, and GET .../digest lists them as held_agent_tasks. Human tasks and classed tasks are never held. Humans and the service may set any class; an agent may set one only with admission_evidence the service verifies (a landed result for revert, a failed check receipt or fix_target report for fix_target, a flaky report for deflake) or when the operator names it in --fix-class-principals (COORDINATOR_FIX_CLASS_PRINCIPALS, empty by default; refusal_fix has no verifiable record). Otherwise the class is refused (403) and nothing is created. The request-only canary class used by e2e-canary.py: the service refuses it (403) unless the creator is an agent principal named in --canary-principals (COORDINATOR_CANARY_PRINCIPALS), and a canary task neither uses nor is held by the budget (tasks.budget_exempt). Server tests in tests/attention.rs cover seven canary tasks in a week leaving the budget untouched, an ordinary agent being refused, each fix class refused without evidence, admitted with it and set by a human, and two projects each admitting 14 tasks (the default budget) with a 15th held in only one of them.

  • Artifact links and streaming uploads with exact size/SHA-256, configurable quota and disk reserve, bounded concurrency, explicit expiry/deletion metadata, and safe storage reconciliation. Native upload journals preserve exact bytes and keys; retries reauthenticate and downloads verify digest before publishing a new file without overwriting existing output.

  • Immutable Markdown previews and human-gated historical apply. Stable source identities, event/revision conflict checks, and durable historical evidence prevent reimports from reopening completed work or completing active attempts. Bounded, snapshot-consistent Markdown exports retain complete provenance.

  • Dashboard and CLI access to lessons, decisions, context, artifact metadata, imports, and exports; the dashboard includes correction, human decision answers, rule editing/history, readable import previews, and snapshot downloads.

  • Human account creation, revision-checked access changes, self-service password changes, browser-session inspection/revocation, and audited host password recovery. Agent credential rotation preserves the agent principal and returns the new secret once.

  • Account email addresses: required when an administrator adds an account, set or changed in My account, verified through a single-use 24-hour link sent by the configured SMTP relay, with a resend action (one minute apart) that invalidates earlier links. Opening a verification link verifies the address on the initial request, without a confirmation button. Verification and password-reset emails include HTML anchor links and plain-text alternatives in a MIME multipart message. Existing administrators were recorded as verified with [email protected] by migration 42. Sign-in is not gated on verification. A Forgot password? link on the sign-in page mails a single-use link, valid for one hour, to a verified address; it opens a page that sets a new password and signs the account out everywhere (migration 43). Live delivery through Gmail has not been exercised from CI; it needs the relay settings in service.env.example and a human-delivered check.

  • Passkey sign-in for human accounts (migration 45). My account lists an account’s passkeys, creates one through the browser’s WebAuthn prompt, and removes one. The sign-in page has Sign in with a passkey, which starts the same browser session as a password sign-in, and offers to sign in with the password and then set a passkey up; a browser that already created one starts the passkey prompt when the page opens signed out. The service accepts ES256 credentials with user verification, requests no attestation, keeps only the public key, and uses a one-time challenge valid for five minutes. It needs the configured public origin’s host to be the relay party id, so a browser must open the service at that origin. Verified by crates/server/tests/passkey.rs and by scripts/passkey_smoke.mjs in headless Chrome with a virtual authenticator; hardware and synced-passkey providers have not been exercised.

  • Full policy editing, planned-task admission, inspected human recovery and blocker resolution, with matching native task, policy, objective, and history commands.

  • Objectives with required/optional children, revisioned membership frozen once work starts, combined dependency-cycle checks, and their own acceptance/review workflow.

  • Complete task evidence pagination across 12 record kinds, including associated review/integration activities, with bounded pages and scoped insertion snapshots.

  • Linux systemd and Caddy examples, locked dependencies, and Linux/Windows CI.

  • Online SQLite/artifact backups with exact digest and database verification, self-contained snapshots, 24 hourly/30 daily retention, and hourly systemd units.

  • Fresh-directory restore invalidates credentials, passwords, sessions, reporters, ownership, and integration authorization before publication. A pause requires hold inspections, old-installation fencing, and post-snapshot gap reconciliation. Unknown jobs and physical/integration holds remain preserved. The dashboard records the checklist and can issue a fresh token for the same agent identity.

  • Durable clock rollback detection expires task and reporter authority while preserving physical and integration holds. The dashboard and host command record time reconciliation; restored snapshots preserve their creation-time cutoff. Concurrent read authentication can share a newly committed clock sample, while every mutation retains its own writer-lock time and ownership checks.

  • Bounded host maintenance compacts expired receipt results and redundant old running-observation summaries. Permanent request identities and semantic history remain intact. Daily systemd units provide scheduled maintenance. Maintenance also closes agent sessions idle for longer than 7 days (configurable, 0 disables) that hold no attempt, job, reporter, reservation or open subagent, recording an event for each; the native CLI reconnects with a fresh session.

  • Known-prefix version-1 snapshots from schema 12 onward verify without source changes and migrate only inside a private restore copy. Native release tooling verifies package checksums, offline links, systemd/HTTPS installation, and reproducibility. The packaged server passed the sustained constrained workload below.

Deliberate limits of this milestone

Completion is enforced through workflow activities; there is no unrestricted status edit. Configure at least one required check; repository identity is derived or reused before submitting code. Check identity, version, and environment are registered metadata, and all workstation evidence remains a client attestation. A malicious credential can lie about source or a producer; this service is not remote attestation. Independent review rejects every contributing principal as well as its sessions; it cannot establish whether separately enrolled credentials use the same model.

Jobs and submissions require clean committed source snapshots. The CLI does not upload source: publish candidate checkpoints to an appropriate Git remote and fetch them on the receiving workstation before review or integration. Logs remain bounded on the workstation and can be uploaded explicitly as service artifacts; publishing source checkpoints remains a Git operation. A guardian lost after launch may leave an unknown result even if the process has exited. Reconnection never invents an exit result; inspect the journal, surviving process, and physical resource before reconciliation.

Lifecycle-hook adapters remain later work. Workstation reports are client attestations, not remote filesystem inspection or hardware fencing. Supported commands do their work in the foreground; a launcher exiting does not verify completion of detached child or external work. Retain holds for that work.

Human administrators manage human access and agent credentials through the dashboard. Host recovery requires access to the service host and records the supplied reason. A lost token response never replays the secret: rotate the replacement credential again using its returned identity. Account-creation retries retain their original key and require the original password, which the dashboard never persists; the same administrator can authenticate again to reconcile that request safely.

A human can complete an open, unowned task whose change the owner landed outside the coordinator (scripts/ship.py) with POST .../tasks/{task}/complete-external. The task ends done, and the delivered revision, target branch and required-check results are recorded as the human’s attestation (the service does not reach the repository). Agents are refused with the task_external_completion human gate, so the manager’s task detail page offers a human-only Complete as delivered externally control (delivered revision, target branch, reason, roster-prefilled check results, service refusal codes shown); the CLI cannot reach the route.

Instruction version 7 added clock reconciliation and receipt-retention guidance. Instruction version 8 clarifies automatic non-contributing subagent review, explicit-only scope narrowing, and mandatory parent continuation after child review results. Instruction version 9 adds agent revise, unblock and cancel under the project’s delegation switches and the required_actor: "human" labels. Instruction version 10 adds the agent archive, restore and delete guidance: an agent session may use them, and cancel, on tasks whose origin is agent or service, and tasks show prints the origin. Instruction version 11 drops the human-only exception for revert tasks: they follow the same origin rule (an agent or service-origin revert may be canceled, archived, restored and deleted by an agent). Instruction version 12 adds that an agent that contributed to the reverted change, or shares a launch with a contributor, is refused canceling or archiving the revert (revert_author_conflict); an independent agent or a human does it. Existing sessions must fetch and acknowledge the new instructions before new claims.

JSON requests default to 1 MiB and can be configured lower; artifact bytes use a separate 16 MiB hard limit. Task details return the latest 50 attempts, 100 checkpoints, 50 checkouts, and bounded job/resource evidence; old records remain stored, with complete history pagination available separately. Mutation receipts replay for 30 days; expired keys remain reserved so a late retry cannot duplicate an old operation. Artifact retention cleanup and storage quota enforcement are implemented; host maintenance compacts replay payloads and redundant old health summaries. Permanent semantic events, task/handoff/lesson history, and request identities are retained; this bounds maintenance work, not total historical storage.

Lease timing uses protected service time. Hosts should maintain synchronized time; a material rollback pauses new authority until reconciliation, and a restore invalidates existing authority. A rollback during downtime that remains above the last durable observation cannot be detected without a trusted external clock. The selected Google Cloud host, public hostname, and off-server destination are recorded in the deployment guide. Additional installations still require their own operator choices. The native Windows workstation acceptance used a disposable Linux service and temporary HTTPS tunnel; it does not establish those production choices.

Evidence and next work

The server tests cover authentication boundaries, revocation, session isolation, instruction versions, project boundaries, dependency-cycle rollback, a concurrent claim race, exact deadline expiry, recovery fencing, stale response replay, and ownership persistence across restart. The combined smoke exercise tests the built CLI and service with two independent harnesses and two projects, isolated worktree preparation, duplicate-free reconnect, job evidence, and explicit capacity release. Job tests exercise global capacity, reporter authority after task/session loss, parent revocation, bounded renewal, terminal observations, and human reconciliation.

Workflow regressions also exercise independent review, concurrent conflicting review decisions, exact-source checks, a cross-project integration claim race, revoked ownership, manual recovery at the deadline, and complete publication reconciliation followed by a replacement integration and fresh checks.

The dashboard was checked with disposable data at desktop and phone widths: human review and completion, code review and authorization, check-roster editing, stale-candidate recovery, preserved history, responsive layout, and sign-out.

Linux workspace checks, the real service/CLI smoke exercise, native Windows client/CLI/local-runner tests, and the locked dependency audit passed for workflow implementation commit 5e6f19b in CI run 34424382043. The same revision passed all 84 local workspace tests, warnings-denied Clippy, formatting, JavaScript syntax checks, and the complete smoke exercise. No production deployment or actual off-server transfer is claimed. Later capacity and recovery evidence appears below.

Use automatic agent startup to discover and claim current work from the authenticated service. Implementation history and HANDOFF.md retain historical evidence, not the task queue.

Shared-record review evidence

All 114 workspace tests pass locally (the full suite plus focused checks after the final context/selection additions), along with warnings-denied Clippy, formatting, JavaScript syntax, workspace build, and the final service/CLI smoke. The combined workspace tests cover atomic submission lessons/artifacts, scoped work selection, decision expiry and stale authority replay, knowledge correction and feedback, FTS applicability, historical import conflicts and reimports, export bounds/provenance, artifact quota/expiry/revocation/concurrent cleanup, and native transfer integrity. The complete built smoke exercise also covers knowledge correction/context, human-required decisions, historical apply, provenance-bearing export, exact upload retry, and download bytes/no-overwrite.

Browser verification with disposable data covered literal HTML as inert text, lesson revision 2 and feedback, denied/reopened/allowed decisions, policy-change invalidation, planned/done imported task states, context search, rule provenance, artifact links, export, project selection, and responsive layout without horizontal overflow at approximately 390 CSS pixels. No browser errors were reported. Implementation commit ca59ee0 passed Linux format/Clippy/tests/build, the full service/CLI exercise, native Windows client/CLI/local tests, and the locked dependency audit in CI run 34431398271. The earlier CI link above applies to the prior milestone.

The operator-initiated native Windows workstation acceptance in item 7 is complete.

Operator-workflow review evidence

All 129 workspace tests pass, along with warnings-denied Clippy, formatting, JavaScript syntax checks, the workspace build, and the complete built service/CLI smoke exercise. Additional regressions cover account access races, the last administrator, password/session invalidation, same-principal token rotation, reauthenticated account-creation replay, objective gates/cycles/revisions, and complete history pagination with exact workflow evidence and credential redaction.

Browser checks covered policy changes, task admission, history revisions, objective membership, inspected recovery, blocked release and human resolution, account disabling, token rotation, session revocation, password change and new sign-in. A proxy dropped an account-creation response after commit; after session expiry and reauthentication, re-entering the original password recovered exactly one account and one receipt. Final embedded assets matched their source, no browser errors were reported, and the phone view fit 375 CSS pixels without overflow.

History cursors use insertion row identifiers. Future database maintenance must preserve those identifiers or explicitly invalidate outstanding cursors; never silently reuse them after an in-place VACUUM or a restore.

Implementation commit 865365d passed Linux workspace checks and smoke, native Windows client/CLI/local-runner tests, and the dependency audit in CI run 34440915688. The final audit clarification labels host password recovery’s initiator separately from its target account and passed a focused regression and workspace Clippy.

Backup and restore review evidence

All 140 workspace tests pass, along with warnings-denied Clippy, formatting, JavaScript checks, the workspace build, and the full existing smoke exercise. New regressions cover exact manifest/database artifact membership, digest damage, missing and symlinked files, retention buckets, artifact cleanup locks, repository overlap rejection, standalone verification without parent mutation, atomic no-overwrite publication, and read-only backup schema checks.

Restore tests cover old credential/session/reporter rejection, globally reserved pre-restore mutation keys, repeated restore of a paused snapshot, preserved holds and unknown jobs, complete reconciliation gates, and fresh manual integration authorization with prior evidence retained. Independent source review found no remaining authority blocker; the main agent reviewed and tested the combined code.

The built service/CLI restore exercise completed in 6.9 seconds after the final storage changes. It captured a live database and pinned artifact, verified a copied bundle, refused an existing destination, stopped the original service, restored into an absent directory, rejected old access, recovered the administrator, preserved a checkpoint and hold, completed reconciliation, and reconnected the same agent principal with a fresh token/session and a higher recovery generation. The copied bundle was another local directory, not a real off-server destination.

Browser checks covered task evidence links, multiline inspection evidence, both reconciliation attestations, resuming coordination without releasing a hold, and same-agent credential replacement with the secret cleared before inspection. The layout fit 375 CSS pixels without horizontal overflow; no browser errors were reported. The fixture and browser tab were closed afterward.

Snapshots are full independent copies and can consume roughly 53 times live database/artifact storage, plus working space. Engine limits and the cooperative 45-minute deadline are documented in the backup contract. The rehearsal is not a production-size restore benchmark or proof of host-loss protection. Installation requires destination-side verification and a measured recovery exercise.

Backup/restore implementation 283d9d0 passed Linux workspace checks and both smoke exercises, native Windows client/CLI/local-runner tests, and the dependency audit in CI run 34445152452.

Linux operations acceptance evidence

Candidate a16d879 passed all 160 workspace tests, formatting, warnings-denied Clippy, build, both service/CLI smoke exercises, native Windows client/local-runner checks, and dependency audit in standard CI. Release CI passed byte-identical native Linux/Windows packages, Ubuntu 24.04 systemd/HTTPS installation, restart/reconnect, both timers, and verified backup.

The capacity job downloaded the accepted Linux package and verified its archive and executable identities. That exact server completed 90,000 requests over 30 minutes at 50 requests/second with 20 projects, 50 sessions, and 100,000 historical tasks. Overall p95 was 20.974 ms and p99 was 21.695 ms. Every operation met the 500 ms p95 limit; there were no unexpected errors, all 50 sessions renewed 360 times, and exact ownership and artifact checks passed. The shared two-CPU / 4-GiB / no-swap scope peaked at 664.1 MiB; server RSS peaked at 84.6 MiB. The concurrent upload and online backup overlapped during traffic. The captured snapshot restored with integrity, history, and authority invalidation verified in 6.511 seconds; that measurement stops at the reconciliation pause.

The actual prior executable upgraded a schema-12 database to schema 16 while preserving principals, credentials, sessions, an active attempt, and checkpoints. Instruction version 6 was rejected for new claims until version 7 acknowledgment. Its old snapshot verified unchanged and restored with the new executable while invalidating old credentials, sessions, and ownership. Historical search remained available. The separate small end-to-end restore smoke passed in 7.3 seconds. Browser checks covered clock pause, multiline recovery evidence, reconciliation, and a 375-pixel layout without console errors or overflow.

Main-agent review is complete. The retained acceptance evidence includes the complete sanitized capacity report and its identity. The mdBook consolidation and actual native Windows workstation exercise are complete; CI did not replace the workstation exercise. Production deployment, off-server transport, and full operator-led recovery remain installation checks.

MCP review evidence

Candidate cd9a633 passed all 182 workspace tests, formatting, warnings-denied Clippy, workspace build, and both smoke exercises. Official rmcp 3.2.0 clients exercise modern discovery and legacy initialization over real TCP. Twelve wire regressions cover authentication, revocation after admission, policy, independent review, competing claims, exact shared REST receipts, session/generation guards, and clock/lease semantics. The live launcher exercise shares one saved harness with native CLI commands and MCP, writes a checkpoint, rejects a second launcher, and verifies that connection traffic does not renew ownership.

Main-agent review is complete. Linux workspace checks and smoke, native Windows client/CLI/local-runner tests, and the dependency audit passed in CI run 34468585302. Compatibility is established for the exercised protocol and SDK paths, not every vendor GUI. OAuth-only clients lacking protected custom headers cannot connect directly. Git, job launch/reporting, and binary transfer remain native operations; the service does not execute workstation commands.

Documentation review evidence

The server embeds its pinned mdBook output and serves it at /documentation/. The dashboard’s main navigation links to this public book; no runtime filesystem directory or external documentation site is required. Inline initialization scripts are emitted as local assets at build time, preserving the console’s strict script policy. Documentation permits inline styles and local fonts for the mdBook theme; the dashboard’s security policy remains unchanged. This describes the source implementation, not confirmation that a production rollout has occurred.

The 35-chapter mdBook consolidates the canonical guides and preserved design records. Root live records are included at build time; prior document paths retain compatibility links. Pinned mdBook 0.5.4 checks verify exact chapter coverage, source/include rules, generated targets, fragments, and assets. Main-agent browser review covered navigation, search, live handoff content, desktop layout, and a 390-pixel phone view without page overflow or JavaScript errors.

Package checks verify checksums, offline Markdown links, bounded member counts and expanded size, and a complete book build from an extracted archive. The final local structural fixture used stripped copies of the current debug binaries; it does not replace the retained Linux release/capacity evidence. Documentation CI passed on main commit ebf72f7 in documentation run 34487173043. The same commit passed Linux formatting, warnings-denied Clippy, all workspace tests, the workspace build, both service/CLI smoke exercises, native Windows client/CLI/local-runner tests, and the locked dependency audit in coordination run 34487175859. The earlier billing-blocked attempts ran no steps and are superseded by these passing runs. Main review and the hosted validation follow-up are complete. The operator-initiated Windows workstation exercise in final item 7 is complete. Local-file book navigation and search passed with networking disabled.

Native Windows workstation acceptance evidence

The accepted agent-coordinator 0.1.0 Windows x86-64 CLI from release run 34459987847 ran natively on workstation MINIAIR against a disposable service on Linux workstation mxmini through a temporary Cloudflare HTTPS tunnel. The archive SHA-256 was be5e96ec6f8843a63c8be319d9b4f9745f4e0870bebbbc160c2c24f69dc32a1d, matching the downloaded checksum, and the exercised executable SHA-256 was 40240c59aeaf012aba6721f378e9dec57419ceb8833aec0187391c3bccb1111d.

Distinct Windows and Linux principals and sessions exercised two isolated projects. Windows completed a claim, checkpoint, and general submission in the second project. The contributing Windows principal could not perform its own independent agent review; the Linux principal reviewed and approved the exact submission, which completed the subject while the first project’s race task remained isolated.

For the cross-workstation race, Linux and Windows submitted an ordinary claim for the same task and revision at a published barrier. Linux received generation 2 ownership and Windows received claim_conflict against that existing attempt. Linux checkpointed the observed one-owner result and released the task ready. For recovery, Windows checkpointed a separate task and closed its dedicated session; Linux then claimed recovery, recorded its inspection, and released the task ready without reviving the closed Windows session. Session and credential counts remained stable through Linux completion.

The sanitized rendezvous and completion records are retained in commit c017a69. The one-time encrypted credential handoff was deleted after use, and the disposable public service and tunnel were shut down after the exercise. This evidence is specific to the exercised workstations, accepted package, temporary route, and disposable data. It is not a claim of production deployment, permanent network exposure, hardware attestation, or off-server backup protection.