Capability maturity

Prepared local and remote workers run bounded Work or message turns, report process state, and recover results. Status distinguishes a current process from the last observed Work state and its observation time. Explicit queued Work now reaches the first worker turn.

Turn exhaustion and cross-harness attention still sometimes need intervention. A retained observation can become stale. This is a useful mini-orchestrator, not an autonomous project manager.

Queue, start, refine instructions, report progress, finish, correct a completed result, and recover authored history. A colleague can revise queued instructions without starting the task; another prepared caller can start that same ID with the latest text. The installed workflow completed useful work.

There is no general amendment feed or automatic reconciliation of conflicting judgments. Optional revision checks remain an advanced caller choice; ordinary use does not require them.

Attributed retained messages, direct conversations, bounded catch-up and prepared worker inbox delivery carry real assignments and replies. An IRC client also exchanged useful messages with a prepared native worker and recovered the reply after reconnect. The September 11 walkthrough shows actual send output and transcript reads before and after a recipient replied.

A retained message is not the same as prompt attention. Follow-through still varies by harness and its activation mechanism. In the recorded same-node interactive exchange, a tmux attention signal was needed; it is not a federation demonstration. Node acceptance did not establish a reply or completed work; prepared worker inbox delivery is a separate activation path.

An arriving worker can recover its identity, organization guidance, project and assigned Work. Release 0.2.9 adds offline help with purposes, steps and examples. Fresh Grok and Agy processes used it for real assignments; Agy reported on an existing task without joining a session.

Preparation still involves local profiles and worker configuration. Help covers the connected onboarding, guidance, Work, planning and session topics, not every command. It is not the planned full manual; installing an update does not rewrite a manually prepared worker prompt.

Keep working agreements in native guidance and full reports or decisions as named references. Colleagues find by subject and read original text and earlier revisions. Optional selected-reader scope now works through the same commands: a fresh Grok turn found synthetic operational notes without a supplied name and produced the correct handoff. A different actor could not retrieve the reference body or discovery metadata; shared guidance and ordinary Work remained usable.

Search is literal, not semantic; reference text is limited to 64 KiB. Reader selection governs future reference retrieval, not confidentiality or OS isolation. An authorized reader can quote into shared Work, as this trial demonstrated. Existing copies cannot be retracted and known-name attempts can reveal occupancy. Retrieval does not guarantee good interpretation, and the trial still used extra Work/message-help calls.

Named sessions support invitations, notes, review and recovery after closure. In a separate Ubuntu guest, a signed-in worker completed useful work after interruption and resume, then completed a second task without reconfiguration while the first result remained readable.

The signed-in trial used an existing provider account, not fresh signup. Session recovery and demonstrated selective REPL merges do not solve every provider failure or semantic merge conflict.

Ordered backlog, selected outcomes, linked Work, reviewed dispositions and earlier wording support our development. Release 0.2.19 stores these as typed relational rows, with Work foreign keys and parent-scoped ordering. Migration preserved actual amended wording and a carried story disposition. Latest delivery is selected by a join on review decisions, independently of recent-review pagination.

This is not a general planning-history system. Reviewed agreements retain the original commitment; corrections can be explained in the review. Retained wording shares the existing agreement size limit. Connecting capability assessments and release outlook to planning remains unfinished.

Lisp evaluation performs Sidecat operations and retains definitions and configuration, with fork, selective merge, source inspection, sharing and adoption used in real work. A kept federated-analysis method survived the destination restarting. Installed 0.2.16 distinguishes failed evaluations with no possible host change from uncertain ones: clean refusals and interpreter-only errors report not_applied; an actual Work update followed by a refused read remained stored and the evaluation reported unknown.

Authoring and composition need more routine use and polish. Shell recipes still sometimes win on convenience. Failed evaluation does not roll back earlier host work; cancellation, deadlines and explicit keep failures have separate handling.

Shared methods cover briefs, task dispatch, reviews, test recipes and real federated data analysis. The updated publish-and-report method was shared, adopted with keep, reopened and used for a real installer publication and stored Work progress. A replay with a missing Work target preserved the successful publication and the complete reporting error without a second commit.

The library remains small and development-heavy, with incomplete curation. Updates require deliberate adoption; installing binaries does not replace an adopted method. Generic REPL replies still repeat printed and JSON values and include kept-name inventory. The measured size comparison covers one captured publication/reporting result, not all methods.

Work, sprint agreements, reviews and releases feed the public progress page through a reusable Lisp method and deterministic generator. The briefing distinguishes the latest reviewed delivery from later planning decisions and shows unfinished scope in mixed reviews. Full records preserve decisions and earlier wording. Maturity remains a separate authored assessment. The September 11 homepage explains the demonstrated remote-work use, and the showcase explains an actual message exchange alongside the historical sprint.

Maturity is not a score inferred from activity. Plans and assessments still need their authors to keep them current. The showcase and historical sprint are editorial examples, not automatically refreshed analytics. Domain-specific operator views remain incomplete.

Prepare a checkout and publish selected files through one ordinary Sidecat command, with original-key recovery within the supported runtime boundary. Native, CLI and Lisp publication results now omit the coordinator's nested transcript and provide an optional current-Action query. Installed 0.2.15 published a real installer update, and the returned query worked with the same caller. Release 0.2.18 adds sidecat source status REQUEST_KEY: read a completed, pending or absent publication without a repository directory, project or session. Installed reads matched the existing native query without resuming or changing the publication.

First commits in new repositories and shared-checkout coordination still need work. Optional details show current Action state, not a reconstruction of the old response. Publication alone does not prove deployment, installation or task completion. An unfinished Action that still needs its provider is tied to the exact daemon binary; a changed runtime currently refuses continuation with effect_definition_unavailable, even when the operation interface is unchanged. An hourly publication interrupted during the 0.2.15 upgrade remains unresolved. Completed publication results can still be read or replayed without another push; same-implementation restart recovery is a separate supported case with its original prerequisites. Do not automatically replace an uncertain publication with a new key. Start a separate publication only after confirming the original created no commit and performed no push; it does not recover or rewrite the old Action. In-flight recovery across binary upgrades remains follow-up work. Other operation results have not all been made compact.

The public Ubuntu source-build path was qualified on a clean Ubuntu 24.04 amd64 guest. Release 0.2.12 used one retained bundle to upgrade the development node, local/remote worker tools and two existing independent-store guests while retaining their identities, state and prepared peer relationship. The prepared development node and local/remote worker tools subsequently received 0.2.19. This included the planning/assessment schema migration, rehearsed first on a supported copy of the real database; installed planning and assessment reads preserved their pre-upgrade values. This was not another cold-install trial.

The cold public build was tested with 0.2.7; the 0.2.12 trial qualified supplied-bundle upgrades and focused installer checks, not another cold build. Provider installation and sign-in remain separate. There is no hosted binary installer or qualified multi-platform path. There is no node-wide drain of unfinished effects. Before a planned binary upgrade, pause known workers, scheduled jobs and other submitting clients and let active operations finish; checking one worker is not enough. Saved Work and completed results are distinct from an unfinished effect's cross-version continuation, which is not currently qualified.

Create editable Lisp package source with package init, build a portable artifact without a daemon or a separate compiler, then activate it on a prepared node. Agenda and Timebox packages perform real calculations. In 0.2.11 activation shows progress, checks current availability and no longer requires activation Work or a harness session.

Activation still targets a prepared local node and user service, not a remote node. The upgraded recipient's first Timebox activation took 32.12s; an unchanged repeat took 14.34s without restarting. These are observations, not guarantees. Package discovery, a marketplace and turning shared methods into maintained packages remain unfinished.

The daemon supports sustained multi-agent work. Removing ordinary-start history and schema-reconstruction work produced recorded normal startup samples around 7.5 seconds, including 7.47 seconds for the final 0.1.54 installation.

These are observed samples in the prepared environment, not a universal under-ten-second guarantee or proof that every large read is fast. Schema-changing upgrade time is a different measurement.

Durable state supports daily work. GORM supplies project-model metadata and generated schema changes. Release 0.2.19 corrects the earlier design in which planning and assessment models still stored useful structured data in JSON columns: backlog entries, sprint fields, links, reviews, wording and assessment collections are now typed rows. A transactional migration compared all converted values on a real copy containing two boards, 54 sprints and 12 assessments before the live upgrade.

The wider ORM conversion is incomplete; older hand-managed persistence remains. Empty legacy planning/assessment table declarations remain for migration history, with no ordinary JSON reader or writer. A supported backup of the roughly 2 GB development store took about 71 minutes; backup speed and progress reporting need improvement. This migration did not redesign backups or raw-document storage.

Distinct authenticated agents, attributed changes, organization membership, and inherited working context support collaboration in our prepared environment.

Preparing new environments and identities is less convenient than ordinary use. Organizational coordination is not a substitute for OS or infrastructure isolation.

Substantial bounded journeys cover identity, authorization, sessions, enrollment and refresh, revocation, R3, and parts of the companion specifications. Its repository records cross-implementation exercises.

Specification coverage is deliberately incomplete. Newly reported editor-draft changes were not checked in this assessment; the next alignment pass must reconcile the existing feedback register. No official conformance or affiliation is claimed.

The installed independent-node path uses aauth-go HTTP signatures for requests and responses, with an explicitly admitted signer and source caller mapped to B's local actor and allowed native operations. This authenticated path carried actual remote work; Tailcat provides the connection, not the operation permission.

This demonstrates bounded HTTP-signature consumption and prepared grants, not full Resource, provider or delegated authorization flows. An independent library's maturity still does not establish complete Sidecat integration.

Two isolated Ubuntu nodes with separate stores used a native Tailcat connection and signed caller admission for command.run, guidance, references and Work reads through shared native handlers. No B login key was given to A's worker. B withdrew admission and refused both reads and commands; stop/restart retained the same relationship.

The qualified scope is an explicitly prepared pair and six operations. It is not automatic peer discovery, organization synchronization, remote ordinary writes or complete delegated federation. Network access to the selected relay is required. Silent partitions during established long calls still need a caller deadline. Preserving the peer relationship and making fresh calls after restart does not establish interrupted-command recovery. command.run has no durable result lookup or automatic retry. Action-based effects, including source publication, separately require the saved implementation definition; transport connectivity does not make them resumable after a daemon binary change.

A signed-in worker in A used B's guidance and a retained Lisp recipe to sort and count B-side datasets, reporting useful results. B ran only sidecatd, without an agent. Commands returned B's user/directory, real exit status, separate binary streams, truncation and timeout state. On final 0.2.12, stopping B during an accepted command returned a structured unknown outcome; a fresh read and the kept analysis worked after restart without re-pairing.

Programs use B's daemon OS privileges; VMs, containers or machines provide isolation, not the working-directory default. This is bounded execution, not an interactive terminal, detached job or durable result service. Lost outcomes are not automatically retried. Silent partitions during established calls remain a caller-deadline limitation.

A prepared operator used an existing IRCv3 client to send a useful request, receive a native worker's reply and recover it after reconnect. The optional public adapter is implemented.

The qualified path is loopback, one prepared actor per adapter and a recent replay window. Complete roster/presence and federation remain absent. After daemon turnover, restart the adapter and reconnect the client.

Work, sessions, messages, reusable methods, and extensible records are not inherently software-specific.

Our strongest practical experience is our own development. Research, operations, and other professional work need their own useful methods and operator views, not merely renamed coding workflows.