Sidecat System 0.1.0: review guide
Working draft published for review, updated 25 September 2026. This is a proposed agreement for building Sidecat applications independently while still producing one programmable, federated product. It is not an assertion that the present Gen5 system implements the agreement or that the proposed app profile has passed an interoperability trial.
The problem this draft addresses
Sidecat must help a person and several changing agents do useful work, understand why it was requested, continue across interrupted sessions and machines, and tell a proposal or report apart from an observed effect. The current coupled implementation makes it too hard for independent coding agents to understand, change and test one bounded part. Sidecat Micro explored small parts, but its brief prototype is not a replacement specification for the product's Lisp, federation, messaging, AAuth and organizational work.
The proposed System keeps the broad product and narrows what each author must hold in mind:
people and agent harnesses
│
CLI · Lisp · MCP · UI
│
typed lowering + identity
│
registry · bus · context
│
independently owned apps
│
local or federated outcomes
Small applications are an engineering focus boundary, not a request for thousands of processes, a file-count limit or a universal object schema. A resident Go host may run many separately authored handlers. A stateful app normally owns its own store; no other app reaches through to its tables. A full established Lisp, packages and marketplace, AAuth, general federation and durable conversation are part of a complete System, not deferred until after a software-development factory is built.
The first test of that boundary is deliberately ordinary: an unfamiliar agent adds one optional field to an app. Its interface and private store may change; the agent should not have to hand-edit a shared SQL layer, router, or separate CLI/MCP/Lisp interpretations. Old and new clients then exercise the published compatibility rule. The System contract says what to record and what would fail this test.
The proposed first Go author path is concrete enough to test and still open to revision:
app author: descriptor + schemas + help + Go handler + private store rules
│
public validator and author kit
│
selected module lock → generated registry → resident Go host
│
CLI · Lisp · MCP · native client → addressed call
│
app's own transaction and result
The descriptor is safe to inspect without running code. Selected native code is compiled into a new host build or admitted as a separate long-lived worker; package discovery is not hot loading. A promised retained event and the corresponding mutation share the app owner's transaction. The author profile names what each side supplies and what the independent trial still has to prove.
What is concrete now
| Review question | Draft answer | Where to inspect it |
|---|---|---|
| What do apps agree on? | Versioned operation descriptors, typed values and references, calls/outcomes, event promises, authority/effect boundaries, host behavior and conformance. Domain objects and business rules stay with the app. | System specification §§2–6 and the base author profile. |
| Does the boundary reduce agent rework? | Change one app field with the public kit, install it, and run old and new clients; record hand-edited sites outside the app and any private guidance needed. | One-field authoring test. |
| What did Gen2/Gen3 lowering teach us? | Shared domain execution across entry points is useful. Arrival provenance is separate. Nested data, explicit null and exact numbers must reach the domain call, not disappear into a retained invocation record. Ambiguous contributed names refuse instead of shadowing by install order. | System specification and historical source register. |
| How does a small app compose? | Addressed synchronous calls; signal, invalidation and retained event are different promises; a continuing job survives its initiating harness; remote effects may be unknown and must be reconciled. | System specification, base author profile, bus research. |
| What do complete-product claims cover? | Every listed Gen5 capability and feature has a proposed owner and a falsifying acceptance condition. Supplier, customer, training, research, invoice and selective-gate cases pressure the same primitives outside software work. | Coverage map. |
| What can an independent implementer inspect today? | A provisional JSON descriptor and frame schema, local authentication vector, package artifact, positive and negative frames, and a local validator. | Base author profile. |
The selected Gen2/Gen3 audit also recovered the separation of guidance from enforceable workflow rules, context-sized visiting-agent assignments, a path from unfamiliar service work to a package candidate, and the difference between simulated effects and no-save retention. The coverage map says what was documented, what this draft carries forward, and which old obligations it declines. These are proposed System behaviors, not newly qualified old implementations.
Current evidence is static source review, a crosswalk covering all 29 IDs in the pinned Gen5 feature ledger, one local validator passing 18 positive and 18 negative frames, and a rendered HTML copy with checked local links. No Sidecat daemon, independent client, full Lisp session or federated peer was built or qualified by this specification run.
The next decisions are real design work
The profile is still a candidate. A second author and client have not implemented it, and the socket subscription/acknowledgment conversation remains to be specified. The public owner of human feedback on ongoing work, exact Lisp dialect/runtime profile, federated owner-move proof, AAuth wire/profile breadth and messaging peer feature profile need trials before a freeze. Those choices must be published as named profiles with exact test results. The current fixture validator proves consistency of some proposed bytes under one implementation; it does not prove a working daemon, safe distributed behavior or product usability.
| Open decision | Next falsifying trial |
|---|---|
| Is the author agreement sufficient? | Give the descriptor, archive and fixtures to an app author and a client author who cannot read private core code. Let them implement one mutation and a lost-reply recovery independently. |
| Who accepts a person's correction to ongoing work? | Send feedback against an exact Work/Plan revision while an agent allocation is active. Distinguish the feedback owner's receipt from the Plan/occurrence owner's adoption or hold; make the resulting disposition visible to a fresh agent after restart. |
| Which full Lisp runtime and session profile? | Compare complete Racket CS and another established candidate under actual Sidecat calls, retained methods, effect-denied reopen, interruption, memory and installation footprint. |
| How does an owner move across nodes? | Move an owner while another node holds an exact reference, subscription and in-flight call; stale and new routes must not both admit a write. |
| Which federated conversation provider and breadth? | Use independently administered servers, a human and two agents for direct and room chat, source context, offline catch-up, membership change, redaction and an uncertain send. |
| What exact AAuth and selected-gate profile ships? | Exercise current-source four-party access, customer-side account binding, managed Agent Provider outage, and one authorized decision over an unchanged candidate. |
These trials are design inputs, not compatibility tests for earlier implementations. A failed trial should change the proposed profile before authors are asked to build against it.
Read the same draft through Sidecat
The complete System text exceeds one organization reference. Read system-0.1.0-working-spec-p1-20260925, then system-0.1.0-working-spec-p2-20260925; their read-back text concatenates to the local specification exactly. The older one-piece system-0.1.0-working-spec-20260925 is marked superseded. The companion references are system-0.1.0-author-profile-20260925 and system-0.1.0-gen5-coverage-20260925. All remain unapproved drafts.
For a useful review, start with the System specification, use the coverage map to challenge any omission, and inspect the author profile where two independent implementers might make incompatible assumptions. The earlier research chapters are source material and alternatives, not already adopted requirements.