Coverage of Gen5 and other kinds of work
Status: review companion to Sidecat System 0.1.0, updated 25 September 2026. Source inventory: Sidecat features.yml at fe64557720bd4f84e553dd559b3500d4fae30a67 and the current VISION.md at the same revision. “Covered” means the new contract has a place for the outcome; it does not mean a new implementation or conformance trial exists. Gen5 architecture and code are comparators, not data or compatibility requirements.
Gen5 capabilities
| Gen5 capability | System 0.1.0 place and required behavior |
|---|---|
| C-001 Daemon-owned durable execution | §§3–4, 7–8: a resident runtime admits calls; continuing work has a durable owner and read/cancel/recovery operations. App-owned workflows may implement the domain state while the daemon routes and schedules. |
| C-002 Exact semantic identity and history | §§2, 5: owner-qualified current addresses, compare tokens, exact revisions and snapshot/blob references have different meanings. History is promised only by an owner that advertises it. |
| C-003 One typed operation model across clients | §§3–4, 7: one public interface, typed boundary normalization and equivalent semantics through CLI, Lisp, native and MCP. |
| C-004 Governed effects and evidence custody | §§4, 6: effect owner, AAuth check at consequence, separate proposal/decision/attempt/outcome, selectable stronger custody with truthful application. |
| C-005 Durable Work, continuation and scheduling | §§2, 4, 8: reusable Work, app-owned Plan/occurrence, accepted continuation, workflow/scheduler applications and human recovery. A finished occurrence retains the definition revision or resolved criteria against which it was judged. |
| C-006 Bounded Lisp and package composition | §§4, 7: full general-purpose Lisp with bounded runtime admission, session methods, exact packages, role/domain extensions. This intentionally exceeds the older bounded dialect. |
| C-007 Bounded context selection and delivery | §§3, 7: selected working set and source/freshness/omission-aware context; complete catalog stays pageable. |
| C-008 Managed agent calls and selective outcome delivery | §§4, 7: managed model invocation, finish/partial reporting, continuation, recipient-specific result and declared retention. |
| C-009 Federation and placement-independent execution | §§4, 8: owner identity is route-independent; peers negotiate profiles; foreign references, selective sharing, change feeds, remote calls, package distribution and local-first partition behavior are separate capabilities. A fenced owner move preserves exact references. |
| C-010 Package-defined institutional records and relations | §§3, 5, 7–8: app-owned types, current and exact reads, relations with declared creation/revision/retraction/recovery, facets and semantics; package distribution and installation. |
| C-011 Discoverable project architecture and development state | §§3, 5, 8: typed organization/project, decision, research and architecture applications can expose current state and history through ordinary discovery. The software-specific vocabulary stays in its suite. |
| C-012 Durable messaging and coordination | §§4, 8: retained conversation, membership, source context, bounded history/catch-up and cross-peer delivery; a distributed room's provider view need not invent global total order. Bus signals remain distinct. |
| C-013 AAuth authority interoperability | §6: named source-pinned role/flow matrix, host-verified identity binding, resource/operation authorization and effect-time checks. Local harness proof and AAuth are explicitly distinct. |
| C-014 Authenticated agent principal enrollment | §6: an identity application enrolls, binds, rotates and revokes agents and harnesses; the model name is not the authority. |
| C-015 Runtime allocation and delegation provenance | §§4, 6–8: resource-class scheduling, represented actor and scoped delegation, managed agent calls, and exact allocation identity. Requested capability, observed provider/worker, reporting source, authenticated principal when established and fence remain distinct; a parent's worker report is not independent authentication. |
Gen5 named features
This is a requirement crosswalk, not an installed-feature claim. The middle column names the responsible System or app boundary; the last column states a check that would expose a hollow substitution.
| Feature | Required owner and behavior | Acceptance condition or unresolved binding |
|---|---|---|
| F-001 Fresh-checkout project orientation | Published main contains accepted architecture, maturity, capability/feature intent, proposals and contributor procedures; orientation apps compose these with separately sourced live state. Generated repository views identify their canonical source. |
A fresh contributor finds the accepted maps and contributor path from the checkout alone, then can distinguish live Work from repository intent. |
| F-002 Federated programmable runtime | Runtime, federation and workflow owners route a package operation through the nearest daemon while independently owned stores continue work. §8 additionally requires discovery, foreign refs, selective sharing, change reconciliation, package/method exchange, cross-organization work and disconnected local behavior. | Three serving nodes exercise disconnect, restart, partition, effect reconciliation and a fenced owner move; owner-route proof remains open. |
| F-003 Gen5-primary development | Work, messaging, orientation and Git effect apps form one installed development suite. | Developers use the suite for ordinary Work, exact governed commit/push/parity and restart-safe daily work without an unrelated fallback. |
| F-004 Claims-centered research program | Research, claim, budget, assessment and publication apps keep a long-running multi-agent program's state. | Literature, negative results, evidence-linked decisions and publication survive agent replacement without chat reconstruction. |
| F-005 Attestation-conditioned progress | A workflow owns a named criterion; the consequence owner checks current scoped attestation and exact candidate before effect. | Exceptions and historical validity are explicit; stale or unavailable required assurance refuses before the transition. |
| F-006 Standalone AAuth consumption | A portable AAuth Go implementation remains a separate release deliverable usable outside Sidecat; the Sidecat adapter consumes its public verified mode, issuer, representing Person Server, subject/key where present, Resource account, operation scope, expiry and revocation state. Enrolled bootstrap and renewal do not require reusable AAuth bearer tokens in launch profiles. Go is this Gen5 product binding, not a universal language requirement on System apps. | An independently administered four-party grant controls one exact Sidecat operation; renewal survives independent Sidecat/Person Server restart without profile token custody. Useful local work proceeds with governance off and a selected exact gate is tested separately. The named profile is checked against pinned current author-source bytes, not inferred from an old Go example. |
| F-007 Package-owned Git repository targeting | A Git package owns exact repository records and the Git effect app derives its target from the bound record. | A caller cannot redirect a governed commit/publish by an unrelated raw path or bootstrap record. |
| F-008 First-party package distribution | Release assembly selects exact official package artifacts and provenance via the same public path as community packages; public deactivation stops new admission and declares disposition of pending work. | Package source, semantics, tests and installation qualification build separately from core; deactivate, restart and reactivate or replace with explicit state compatibility, with no private core edit. |
| F-009 Organization-owned development environment | Organization apps own direction, proposals/disposition, roadmap revisions with lineage and qualified work cycles. | A local admitted package can recover and advance these without hand-maintained project maps. |
| F-010 Authenticated target-oriented messaging | Messaging app owns separate direct-query and channel histories with stable local target-scoped order/cursors and declared federated views, server-derived sender, target backlog/search coverage, exact context stamps and attachment refs. Membership/policy/context/authorization epochs fence send, read, wait, acknowledgment and response; attention expiry changes current context without erasing history. | Two agents sharing a Unix account retain distinct identity; a targeted catch-up does not concatenate unrelated channels. A stale epoch cannot advance a send/read/response state, and expired low-priority attention leaves current context while retained history remains. The selected provider demonstrates direct and room delivery across independent servers; exact peer protocol remains open. |
| F-011 Authenticated harness enrollment | Identity app owns distinct harness principals under one Unix account; stable actor/enrollment and identical retry survive credential rotation. Suspension/revocation invalidate sessions and fence not-yet-attempted effects, while in-flight outcomes remain honest. | Forged caller names, rotation replay and late work from a suspended harness exercise these rules; the cooperative same-UID limit remains explicit. |
| F-012 Sidebird State orientation | Orientation projection app resolves a stable alias to bounded current summary and needed detail, with source, freshness and omissions. | Agent B after restart sees the person's correction to Agent A's exact work and changes its next action; no default recursive graph traversal or second authority is needed. |
| F-013 Daemon-owned turn orchestration | Resident runtime repeatedly allocates bounded tranches; workflow app owns durable state, current context, budgets and fenced results; allocation distinguishes requested and observed worker facts. | Replace the lead harness and worker across a restart; the daemon still wakes, delegates and advances Work. A conflicting parent report cannot authenticate a fictitious worker or overwrite the actual allocation. |
| F-014 Managed AAuth Agent Provider | A managed-provider profile issues short-lived portable Agent identity; customer daemon verifies locally and maps to a local actor. Agent/issuer/person/Resource roles stay distinct even when one deployment hosts several. | Signed revocation is consumed when delivered; during provider outage local operation remains bounded by stated expiry and no provider holds customer service credentials. Direct Agent-token Resource revocation beyond base AAuth is named as a Sidecat extension. Exact provider profile is open. |
Selected Gen2 and Gen3 recovery
This is a selected historical source audit, not a claim that every old feature was implemented or that the old designs govern System 0.1.0. Exact archive pins and retrieval locations are in the source register. A past document saying “locked” or “required” describes its own generation; the current operator direction still decides what belongs in this System.
| Historical source and maturity | Carried into the proposed contract | Deliberate limit or remaining test |
|---|---|---|
Gen2 sidecat-skills.md described a feature-flagged documentation-maintenance slice and a broader proposed skill model. |
§7 lets a package contribute selected human/model guidance separately from a machine-readable workflow definition; installation of one does not enforce the other. | Retrieval is not proof a model followed guidance. A gate must be separately selected and tested; no universal evidence contract comes from installing a skill. |
Gen2 planning-objects.md documented an initial local file-backed planning store, human keys, typed external links and adjacent proposal authority. |
§§2, 5 and 8 keep reusable Work, Plan occurrences, names, external observations and owner decisions distinct. | Linear-shaped issue status and that file-backed store are not universal Work requirements. |
| Gen3 package-development requirements proposed context-sized visitor contracts. | §7 gives a coordinator a bounded public assignment with selected sources, budget, stop/ask rule, return owner and assessment. | A fixed big/medium/small taxonomy and a sealed sandbox are not required; a fresh visiting-agent trial remains to run. |
| Gen3 unknown-service learning was a proposed user story. | §7 lets selected exploratory findings become a revisable app or Lisp package candidate, tested by a second agent on another case. | A first probe does not become verified service knowledge, package authority or compulsory capture of every call. |
| Gen3 ephemeral guardrails were provisional analysis. | §6 separates simulated effect backing from no-save retention. | The old mandatory marker for even ephemeral forms conflicts with progressive assurance; an optional simulation profile needs an installed effect-boundary test. |
| Gen3 command language documented a parser and proposed short visible intent; lowering Part B described a shared text/structured path. | §§3 and 7 retain one semantic lowering path, structured results, a generic exact CLI call and collision-checked shorter names. | Arrays, objects and null cannot be left only in invocation evidence. The specific first CLI profile and cross-surface property trial still need qualification. |
Pressure from other domains
This matrix tests the shared primitives against ordinary nonsoftware shapes. It does not require these applications to ship as one suite or force their objects into the System core.
| Domain pattern | What the System must let its owner express |
|---|---|
| A supplier quality case spans two companies and a chat room | A sourced request cites a permitted message range; a quality app owns findings and decisions; each company keeps its own authority; federation may fail or delay without erasing local work. |
| A customer appears in several projects or account teams | One customer identity can have several context-owned memberships and typed roles. A global status field on the customer cannot stand in for all project placements. |
| Employee training repeats each year across departments | A reusable training definition is referenced by many plan occurrences. Completion belongs to the employee/year/department scope and can carry an independently assessed result against a fixed definition revision; a later change cannot rewrite that judgment. |
| A research group weighs contested claims | Source documents, assertions, tests, authorship, inference and publication are separate records. Derived confidence does not mutate an underlying source or turn an agent summary into evidence. |
| An invoice has ordered lines and conditional business fields | An app can own ordered child entries, contextual validation and external references; the common relation/facet model must not erase order or assume every value is an unordered set. |
| An incident needs a policy gate only for one effect | The ordinary record and discussion remain usable; a selected assessment checks exact candidate/action state before the consequential transition and records an applied/refused/unknown result. |
The source comparisons behind these rows include official GitHub, Linear, Jira, Asana, HubSpot, Slack and QuickBooks API documents listed in value-contract/14-cross-domain-object-shapes.md. Their shapes do not dictate Sidecat's own Work, customer or invoice type. They test whether the common values, relationships, ownership and lookup rules are sufficiently general.
Gaps this draft still exposes
The provisional base author profile now proposes a descriptor grammar, local frame and JSON values with checked fixtures; no second implementation or independent author has qualified it. Local owner minting is proposed; federated relocation proof, full Lisp dialect, AAuth timing profile and federated messaging feature profile remain open. These are real interface choices, not an invitation to replace the current spec with another inventory. An independent author trial should close the first three together; selected language/peer trials should close the rest. The Gen5 rows above are coverage obligations, not claims that the current or replacement product passed them.