# Sidecat Version 1: proposed agreement

**27 September 2026 · candidate 1 · awaiting operator agreement**

This is the recommended product contract and development agreement. Acceptance
would establish what we build toward and how we decide that work is ready. It
would not claim that the product or the development controls already exist.
The implementation hold remains in force until the operator agrees to resume.

The [earlier review](https://sidecat.dev/version-1.html#earlier-review) retains the research,
existing-call inventory, implementation audit and reuse analysis. This agreement
turns that review into requirements, recommendations and named decision owners.
The ratified [VISION.md](https://gitlab.com/sidecat-dev/sidecat/-/blob/c1d179534fcf63622df1d3c9fe4882df328e3e4b/VISION.md) remains the product direction. Current
assignments and evidence belong in Sidecat; these documents are the contract,
not a second task queue.

Compared with the earlier review, this candidate recommends concrete answers for
Work/Plan, content references, storage ownership and reuse; makes provider-neutral
responsibilities and on-demand agent activation explicit; and defines the selected
development workflow and its review accountabilities. It recommends controlled
partial Lisp execution as a Version 1 capability, with its exact semantics still
subject to component design and qualification. Those are recommendations for
acceptance, not claims that every earlier alternative was already decided.
Following independent review, Message and Work now use one content-owner access
contract; the earlier option of a separate Message-owned body is narrowed to an
internal storage optimization. The requirement below concerns the replacement
product. Publishing this document does not change commands on the running node.

## What we are building

Sidecat is a programmable, federated working environment for people and agents.
It preserves organizational intent and authority, makes shared work and reusable
methods accessible, coordinates execution, and lets people inspect and challenge
what happened. A fresh agent should be able to join useful work without a private
briefing from the agent that preceded it.

Its application architecture must make it practical for many coding agents to
build and maintain separate parts in parallel. An agent should need its component,
the common contract and its neighbors' public interfaces. It should not need to
understand the whole product's private database or load months of conversation.
This is a development reliability requirement, not a line-count or process-count
target.

Software development is an internal proving ground. Research, operations,
organizational planning and other domains must work through the same foundation.
Sidecat.ai may provide a commercial multi-department experience; the open-source
system must remain independently useful. The company and open-source publication
estates retain their existing separation.

## Version 1 requirements

Each requirement needs a responsible component owner, an acceptance scenario and
evidence against a named installed candidate. A missing requirement stays visible
as incomplete; it cannot disappear when a sprint or model changes.

| ID | Required result | Acceptance must demonstrate |
| --- | --- | --- |
| V1-01 | Organizational context | A fresh agent finds purpose, values, principles, structure, products/projects, commitments and relevant work. Company, department and workspace scopes can coexist without imposing one organizational method. |
| V1-02 | Identity, authority and resources | AAuth-based authority, using the independently maintained `aauth-go` library, supports scoped delegation, missions, conditional/expiring approval, revocation and resource allocation. A mediated remote effect checks effective authority. Independent nodes cannot spend the same reserved allowance twice. |
| V1-03 | Records and source references | Versioned text, names, blobs, original requests, decisions and typed references can be reused without copying their bodies. A permitted reader can follow a Work description to the exact originating content; an unauthorized reader cannot gain access through that link. |
| V1-04 | Work and planning | Reusable Work definitions are distinct from scheduled/assigned occurrences. Agents can refine, plan and coordinate work across projects/products/departments; returning agents see what is pending and why. Backlogs, boards and facets have explicit contextual owners. |
| V1-05 | Collective messaging | Direct and shared-room communication supports threads, structured attachments, bounded catch-up, meaningful attention state and offline return. Work discussions remain discoverable when their original participants disappear. An agent need not ingest the full message log. |
| V1-06 | Lisp and composition | A full documented Sidecat Lisp environment supports interactive composition, retained sessions/results, reusable methods and controlled partial execution. A fresh agent can inspect and continue a composed task after restart. One language meaning applies across call surfaces. |
| V1-07 | Applications and distribution | Admitted packages extend ordinary Sidecat use with applications, Lisp, workflows and related resources. Marketplaces support experimental/testing/stable tracks, exact versions, discovery, installation, activation and replacement with explicit handling of pending work. |
| V1-08 | Semantic discovery | Authors can discover object/operation/facet meanings, reuse shapes and declare explicit mappings. Validation and semantic alignment do not require every app to use one universal object store or ontology engine. |
| V1-09 | Executable procedures | Typed routines compose operations and subroutines. Durable workflows retain selected revisions, values, checkpoints, waits, decisions, cancellation/retry state and next eligible actions across harness replacement and restart. Prose guidance is identifiable as guidance. |
| V1-10 | Managed agent work | Responsibilities and reusable agent definitions remain independent of model/harness. Named assignees can receive work while offline and activate on demand. Adapters preserve actual execution attribution, delivered context, finish reasons, partial output, resource use and uncertainty. Selection and routing vary by task without changing workflow semantics. |
| V1-11 | Controlled execution | Local and prepared remote nodes run permitted commands, model work and connector effects, with deduplicated submission, cancellation, results and actionable unknown outcomes. A remote executor needs no model login or interactive CLI session. |
| V1-12 | Shared bus and federation | Applications register typed operations/events. Addressed calls, durable events, transient notifications, subscriptions and bindings have distinct contracts. Independently administered nodes can cooperate through explicit ownership, permission and recovery; no global database or total event order is assumed. |
| V1-13 | Feedback and improvement | A correction or finding identifies what it concerns, retains its source, gets an explicit disposition, and can be connected to a later change and outcome. Cost/time by task category and alternatives can be compared using actual observations. |
| V1-14 | Usable interfaces and integrations | CLI, MCP and Lisp expose coherent tasks and results. Supported Linux/macOS installations, help, man pages and examples work from published instructions. At least one real issue-tracker synchronization demonstrates explicit field ownership, duplicate suppression and conflict handling. Human review can be presented through local or hosted interfaces. |
| V1-15 | Operational durability and scale | Restart/logout survival, backup/recovery, bounded queues, retention, contention and resource use are tested. Multi-node concurrency, hot writers, slow subscribers and absent agents are included. Supported limits are published with measured hardware/workloads, not inferred from goroutine counts or small tests. |

The retained organization-scale target remains roughly 25,000 concurrent agents,
with activity concentrated in different groups of applications. Initial capacity
qualification starts with a defined 500-caller multi-node workload and advances
through department and organization workloads. This is a qualification sequence,
not a promise that one machine or writer serves that population. The release
profile must state the scale actually qualified and disclose any remaining gap
to the target. A lower launch scope requires an explicit product decision.

Internal catfooding, a public preview and a full Version 1 release are separate
decisions. The full release needs all requirements above; an earlier build must
state what it does and what it has not yet qualified. Dates and effort spent do
not change those meanings.

## Recommended decisions to adopt

These are the recommended answers to the material choices in the review. They
become decisions when this agreement is accepted.

| Decision | Recommended rule |
| --- | --- |
| Work and Plan | Work owns a reusable purpose/question/outcome and description reference. It has no universal `closed` state, schedule or assignee. A Plan occurrence owns an attempt's assignment, sequence, dates, progress and completion judgment. An occurrence pins the Work revision it judges. |
| Note and Message | Note is a revisioned authored text object. Message is a communication event with sender, destinations, thread/context and an exact content reference. Message and Work always refer to content through the same content owner's retrieval and access contract. A send call can accept text as convenience input, but stores a content reference. Inline storage is private to that owner, never a second Message-owned body/access path. Measure batching/co-location choices without exposing different semantics. |
| Records and databases | Stateful owners normally have separate SQLite databases and local transaction boundaries. Stateless apps need none. Related types may share one explicitly defined owner when their invariants require it. Other owners never read private tables or depend on their migrations. No shared universal database package grows to own every application. |
| Runtime | Use Go and resident execution. Many logical apps may share a host; isolation is selected for trust, failure or workload reasons. Do not start a process for every micro-app invocation. Package loading must support independently distributed contributions without requiring every domain app to be compiled into `sidecatd`. |
| Lisp and packages | Keep and qualify the useful general Lisp interpreter unless a named requirement defeats it. Retained methods and packages are central product capabilities. Package admission/activation is distinct from discovery; a track label does not grant trust or authority. |
| Bus and federation | Use one transport-independent operation meaning and explicit owner-qualified references. Calls, events and bindings compose owners. Durable events are recorded with the owning change and delivered with declared retry/acknowledgement/gap behavior. Use bounded queues and fan-out; no hidden distributed transaction. |
| Authority and custody | Identity and permission are meaningful at the actual effect boundary. Stronger evidence preservation, reviews and gates are configurable, designed-in capabilities. Ordinary startup, messaging and work do not acquire a compulsory historical audit chain. Our development workflow can select stricter checks without imposing them on every Sidecat user. |
| Workflows | A workflow is executable, versioned procedure state owned by Sidecat orchestration. The harness is replaceable. A workflow's completion is tied to its actual inputs/effects/results; prose or an agent's completion claim is insufficient. Ordinary calls remain available outside workflows. |
| Call surface | Use clear domain nouns, consistent verbs and one typed operation definition projected into argv/MCP/Lisp. Work completion belongs to a Plan occurrence; remove the ambiguous universal `work finish` meaning. Default discovery is relevant and compact; the complete catalog remains inspectable. Current Gen 5 names are inventory, not compatibility obligations. |
| Reuse and replacement | Reuse execution, auth, Lisp and other bounded pieces when they meet the contract at lower total cost. Design fresh record/planning owners rather than carrying forward the central schema ladder. No old component is entitled to survive. No new implementation is entitled to replace a working one merely because it is new. |
| Existing data | Preserve useful unfinished work through export and checked repopulation. Keep an archive and a controlled cutover. We have no external users requiring compatibility with existing pre-release data or calls. Production upgrade support is separately designed for versions we actually release. |

### Engineering choices delegated within this contract

The product agreement should not pretend that all implementation choices are
already known. These choices have owners and a deadline defined by the work they
enable. They cannot be left implicit in a coding agent's assumptions.

| Choice | Responsible agent and required decision point |
| --- | --- |
| Exact common wire profile | Systems integration agent with affected owners and QA publishes the versioned shared contract before implementation relies on it. Resolve version/schema selection, timing, unknown-outcome lookup, immutable schemas, event identity and subscription lifecycle. Authors implement/test declared capabilities independently against it; they need not await implementation of unused features. A call-only proof does not qualify event-driven messaging or Work notifications. Qualify with separately authored app and client. |
| Go contribution hosting | Runtime and package agents, before the first external Go package is admitted. Compare resident handler and supervised worker profiles against independent authoring, installation, load and failure isolation. No runtime-plugin ABI is assumed. |
| Messaging provider/Matrix integration | Messaging and federation agents, before provider-specific implementation. Choose a backend/adapter that passes Sidecat's durable conversation, access, authority and return-after-absence scenarios. A working Matrix connection alone does not qualify messaging. |
| Physical storage, indexes and blobs | Each component agent, before its persistence implementation. Supply access patterns, transaction invariants, growth/retention and contention tests. Git/content-addressed storage is a candidate for suitable artifacts, not a mandatory synchronous database for all records. |
| Platform and supported capacity profile | QA, runtime and release agents, before release qualification. Declare workloads, hardware, limits and failure thresholds before seeing final results. Product manager resolves a scope shortfall with the operator rather than silently reducing a requirement. |

## The agents we should define and register

The [agent-definition research](https://sidecat.dev/version-1.html#agent-research) compares actual
harness behavior, A2A, OASF/Directory, Agent Skills and Open Agent Spec with
Sidecat's existing concepts. It supports the model below and specifies the first
proof. None of these standards alone supplies our business assignment and
authority semantics.

The business responsibility exists independently of the model that performs it.
Requirements, policies, procedures and component contracts remain their own
records. An agent definition references them; it does not copy them into a private
prompt that becomes a competing source of truth.

| Object | Meaning |
| --- | --- |
| Responsibility / reusable agent definition | Purpose, required knowledge and capabilities, methods, output expectations and escalation rules. This business duty remains addressable independently of its holder and can be distributed in a package. It does not hard-code a vendor/model/harness as its identity. |
| Registered agent and responsibility binding | A durable named assignee in an organization, bound to a responsibility, definition revision, resources and assignment endpoint. It exists while no model is running. Several registrations may use one definition in different scopes. The dated, authorized binding can change without erasing the responsibility or outstanding work. |
| Agent run | One activation for particular work, with the exact definition and input revisions, selected model/harness, runtime principal, granted permissions, delivered context and execution history. A later activation can use a different eligible implementation. |

Registration establishes the assignee and its bindings; it does not launch a
model or grant authority. Planning can assign work to a responsibility, resolving
its current eligible holder at claim, or deliberately to a particular agent.
Orchestration observes eligible work, checks resource/authority requirements and
requests activation through execution. Completion or a request for review returns
to the workflow. A crashed or unavailable model does not erase the assignment.
The selected workflow governs retry/reassignment and any unknown effects. A bus
wake is not the only retained copy of ready work. Existing assignment/claim and
execution records should provide this lifecycle, rather than a duplicate private
task queue. One-off subagents need not become permanent registered assignees.

Agent definitions and bindings are a bounded application responsibility behind
the common contract. Planning, orchestration, auth and execution retain their own
responsibilities. First test whether existing actors, references and assignment
mechanisms can carry the binding; add only missing semantics. This does not require
another mandatory daemon, a second identity system, or new agent lifecycle tables
inside the central organization database.

Model suitability is task-specific. A definition can require a capability profile
such as Go concurrency review, supported tools, usable context capacity and
successful evaluation on representative tasks. A separate execution registry maps
model/harness/version combinations to observed capabilities, cost and availability.
Separate hard technical/authority eligibility, observed task suitability and cost
or latency preferences. Unknown suitability is explicit. Self-described strength, a provider's tier name or
one global intelligence score does not establish qualification. Selection can
change without rewriting the responsibility; each run records the actual choice.
Policy can admit a new implementation to a bounded supervised trial to acquire
evidence; lack of prior observations is not a permanent ban. The trial still needs
the required technical support and actual authority.

The definition supplies standing obligations. The assignment supplies the exact
component, contract revision, source candidate, task, budget and deliverable.
The runtime supplies actual identity, environment and granted permissions.
Text saying an agent has permission does not itself grant permission.
An agent may hold several responsibilities, but initially an activation selects
one task/responsibility scope; it does not automatically union their grants.
Provider-specific session handles are adapter details, not the agent's identity.

Orchestration's context assembler makes these items available for a launch,
using the selected assignment, definition and component contract:

1. Agent-definition identity and revision, role and component scope.
2. The accepted product-contract revision and the relevant requirement IDs.
3. Current Sidecat assignment, outcome, applicable source revision and workspace.
4. The component's public contract and directly relevant dependency versions; task-linked decisions and defects are retrieved as needed.
5. Allowed effects and actual granted tools/resources; explicit review-only or implementation mode.
6. Expected outputs, evidence rules, budget/timebox, escalation conditions and continuation location.

The instance first confirms its assignment and identifies any material mismatch.
That is an orientation check, not a ritual essay. On interruption it leaves the
current candidate, observations, unfinished action and next useful step in shared
Sidecat state. Reassignment must identify the new owner and prevent two agents
from unknowingly editing the same working tree. Roles are independent of a
vendor, subscription account, permanent process or a repeated launch-profile flag.

The initial packet contains the role/definition reference, assignment and acceptance,
effective authority summary, component contract or required excerpts, and exact
source target. The assembler applies an explicit token/byte budget compatible with
the selected runtime. It does not paste all known defects, decisions or history.
Required constraints cannot be silently truncated: resolve references selectively
or report that the requested packet cannot fit. Available information and actually
delivered context are distinguishable under the selected retention policy.

### Component agents

This is an initial responsibility map, not a requirement for all agents to run
continuously. Each activation focuses on one bounded assignment. A large area
may delegate to narrower agents using the same public contract; expanding the
component's private scope requires review.

| Agent definition | Primary responsibility | Boundary it must protect |
| --- | --- | --- |
| Node and bus | Registry, local dispatch, supervision, event/subscription contracts and bounded delivery | Does not absorb domain records or run domain-specific SQL. A new app uses registration instead of daemon surgery. |
| Federation | Peer identity/addressing, remote calls, delivery/recovery and independent administration | A remote call retains its operation meaning and authority; connectivity does not confer access. |
| Authorization and resources | AAuth integration, policy/approval decisions, delegation, budget reservation and reconciliation | Resources have a named authority/accounting owner. No invented authority or spend during a partition. `aauth-go` stays a general project. |
| Execution | Prepared environments, commands, adapters, outputs, cancellation and unknown-effect reconciliation | Orchestration asks for execution; the executor reports what actually happened. No duplicate consequential effect after a lost reply. |
| Orchestration | Typed routines/subroutines, durable workflow state and replaceable harness execution | Procedure semantics survive agent/daemon replacement. It does not own Work's meaning or infer success from fluent text. |
| Content and records | Note/content revisions, names, blob references, source links and retrieval | Exact historical content and access are explicit. Does not become the universal business-object or workflow database. |
| Work and planning | Work definitions, Plan occurrences, contextual backlog/board/facet use and multi-project continuity | Work is reusable; occurrence completion stays contextual. Multiple projects do not become competing copies of one work description. |
| Organization | Organizational structure, purpose, principles, portfolios and working context | A statement, adopted policy and effective grant are distinguishable. Domain facts do not themselves grant authority. |
| Agent definitions and bindings | Reusable responsibilities, named assignees and activation requirements, composed with existing identity/assignment/execution owners | A named agent persists across runs; its selected model is not its business identity. Do not duplicate task queues, credentials or run storage. |
| Messaging | Collective rooms/direct messages, threads, structured references, catch-up and attention | Durable conversation remains useful through turnover, backlog and scope changes. No Work creation merely to send a message. |
| Lisp and composition | Language profile, resident sessions, retained methods and partial execution | One documented language meaning. Interpreters/helpers do not multiply silently or bypass operation authority. |
| Packages and semantics | Package distribution/admission/activation and common vocabulary/shape discovery | Package installation extends ordinary interfaces. Semantics assist authors without importing every domain into core. Split this stewardship when each area has sustained work. |
| Clients and connectors | CLI/MCP/local UI projections and external-service adapters | Shared meanings, clear help, structured references and usable errors. Connector-specific behavior remains behind its declared interface. |

A component agent is responsible for maintainability, local tests and documentation
as well as features. It may flag an important concern outside its scope; it routes
that concern to the responsible owner or product manager instead of quietly
ignoring it or taking over unrelated work.

### Product-wide agents

| Agent definition | Accountability | Required contribution |
| --- | --- | --- |
| Product manager | Product purpose, scope, acceptance and coverage across component boundaries | Trace each sprint outcome to requirements and real use; identify missing ownership, duplicate features, orphan work and software-only assumptions; maintain a concise whole-product readiness view. Propose scope changes to the operator. |
| Scrum lead / delivery manager | A coherent sprint, dependencies, capacity and visible progress | Gather independent input, select ready assignments with owners, coordinate integration and resolve blockers. Keep new ideas in refinement until deliberately selected. Do not silently change the target or redirect every agent mid-sprint. |
| Systems integration reviewer | Common contracts and the behavior of parts together | Review boundary changes, shared-library growth, database ownership and multi-node composition. Require a focused consumer proof for changed shared contracts. It does not become the author of all components. |
| QA lead | Quality of the installed product and the evidence for it | Design exploratory, adversarial, concurrency, recovery and unfamiliar-user trials; assess every affected help/man/example path, documentation, code readability and unnecessary tests. Distinguish observed results from participant claims. |
| Release engineer | Exact candidate, packaging, distribution and controlled activation | Produce/reproduce the selected artifact, check evidence matches it, verify installer/publication/rollback, and publish its actual capabilities and limits. Does not decide product scope or waive QA findings alone. |

These are accountabilities, not five mandatory permanent model processes. A person
or agent may hold several when capacity is limited, but an implementer cannot be
the only reviewer of its consequential change or the only observer qualifying its
installed result. Independent review uses a separate context and records who did
what. A different vendor is useful where it improves judgment, not a substitute
for evidence.

## Recommended development cycle

The development cycle is a selected Sidecat workflow. It is not compulsory policy
for every customer workflow or ordinary call. At first it can be run explicitly
with existing Sidecat records; its missing enforcement must be visible. Encoding
and qualifying this same procedure in `sidecat-orch` is early catfooding work.

```text
accepted product contract + current shared state
                       |
             independent scrum input
                       |
           selected outcome and ownership
                       |
       brainstorm -> component spec -> plan
                       |
              contract/readiness check
                       |
      parallel implementation + focused tests
                       |
        independent review -> integrated build
                       |
          installed QA + user/doc/load trials
                       |
           release decision and activation
                       |
        sprint review -> next selected outcome
```

### How the scrum runs

The scrum lead distributes one brief: contract revision, current evidence,
candidate outcome, available capacity and the decisions needed. Affected component
agents, product manager, QA and integration reviewer independently return their
own assessment before seeing a lead's preferred answer. Each identifies useful
next work, dependencies, risks, acceptance evidence and any disagreement with
the proposed outcome. The release engineer participates when packaging, deployment
or a candidate release is involved.

The lead then exposes disagreements and asks only the relevant agents to resolve
them. It records one coherent sprint outcome, selected Work/Plan occurrences,
owners, review coverage, budget and stop conditions. Dissent is retained with its
disposition. Every component agent does not attend every discussion. Unaffected
owners can receive the decision afterwards; a quorum of expensive models is not
a goal.

Short progress coordination is triggered by an actual dependency, result, failure
or material change. It is not a perpetual loop that spends tokens saying nothing
changed. At sprint review, each owner reports observed outcomes and unfinished
work; QA gives its assessment; product management checks coverage and value; the
lead dispositions remaining work before selecting again.

### Firm checkpoints

| Checkpoint | Required evidence and decision | Accountable agent |
| --- | --- | --- |
| Ready to commit sprint effort | Named outcome and requirement IDs; current-state evidence; component/review owners; bounded scope; a usable acceptance scenario; dependencies and resource budget. New architectural work includes alternatives and a reuse/rebuild reason. | Scrum lead with product manager; affected owners confirm feasibility. |
| Ready to implement a shared change | Reviewed component spec/plan with concrete calls, object ownership, failure behavior and affected consumers. Shared-contract changes have consumer review and a versioned disposition before independent implementation relies on them. Bounded local repairs need a proportionate design, not another architecture dossier. | Component owner and systems reviewer when a boundary changes. |
| Ready to integrate | Exact source candidate; appropriate failing/passing behavior tests; independent code/contract review; findings disposition; updated user/developer docs; named removed or retired duplication. Scope drift is either rejected or explicitly approved. | Component reviewer; integration owner checks the combined result. |
| Ready to release a candidate | Exact installed artifact and configuration; relevant functional, failure/recovery and concurrency evidence; independent unfamiliar-agent trials; documentation/usability assessment; disclosed limits and findings. A participant report alone is not proof of node state. | QA lead; release engineer verifies artifact identity and packaging. |
| Ready to publish or cut over | Product acceptance against the selected release scope; valid QA decision for the candidate; known authority and destination; installation/recovery instructions and controlled rollback/fresh-store plan. A later source change requires an impact decision and relevant revalidation. | Product manager and release engineer, within operator-granted publication authority. |
| Sprint disposed | Delivered and undelivered outcomes, remaining findings, costs and evidence; coverage gaps and a deliberate next disposition. Record one useful process improvement where evidence supports it. | Scrum lead; product manager and QA contribute. |

The existing sprint-process principle remains: a missed administrative step does
not destroy work that is independently shown to be done. Record that process
defect. Missing evidence, an unresolved blocking defect or a changed unreviewed
artifact is a substantive readiness failure. It holds the affected integration or
release, while unrelated admitted work may continue. The review must name the
requirement, evidence and smallest affected scope; it cannot invent a new product
requirement as a condition of passing.

### What the checks must enforce

Use deterministic checks for facts and agents for judgments. A component manifest
should name its owner, public interfaces, dependencies and test/build entry points.
The shared operation descriptor supplies interface information; do not hand-copy
it into three client schemas and another review ledger. The product manager keeps
requirement-to-owner-to-acceptance coverage in shared Sidecat records and reviews
unowned changes or requirements at planning and release boundaries.

The selected development workflow must check that required assessments exist,
refer to the right artifact/contract revision, have an allowed disposition, and
identify their supporting evidence. It must detect missing owners, changed
interfaces without consumer assessment and source changes after candidate approval.
It cannot mechanically prove that the design is good, tests are sufficient or a
report is honest; independent reviewers inspect the underlying behavior and records.

A reviewer holds a candidate with a specific failing requirement and remedy.
An exception records its narrow scope, authorizer, reason and expiration/revisit
condition; it does not silently rewrite the product contract. Resolving a process
defect or choosing an appropriate affected-test set is not an exception to a
required outcome. These controls apply to our selected development procedure,
not to every ordinary Sidecat operation.

### Testing and review discipline

Developers use test-driven work for behavior changes and bug fixes. Tests must
exercise behavior or a meaningful invariant, not merely repeat implementation
structure. Component suites stay independently runnable. Shared contract fixtures
and a small set of integrated journeys test interaction with real neighbors.

Code review includes correctness, authority, concurrency, clarity and avoidable
complexity. For consequential designs, retain the earlier successful two-pass
pattern: an independent open review of the ideas, then specific questions written
by the author before receiving that review. Keep review instructions outside the
artifact being reviewed. Use additional review when a named risk needs it, rather
than requiring every specialist to re-read every change.

QA independently designs its test charter. Unit/regression tests support that
judgment; they do not replace exploration, documentation assessment, installed
use, recovery and workload testing. Each release candidate includes a CLI newcomer
and an MCP newcomer using shipped guidance, plus adversarial QA, as in the current
user-testing practice. Label these as agent trials; add human trials when available.
No coaching is hidden. All affected help/man/example paths are inspected and tried;
the whole published documentation set is audited before public release.

Load tests include realistic application clusters, hot records/rooms, slow
consumers, retries, restart, partitions and multi-day absence. Record throughput,
latency distribution, queues, write waits, memory/storage growth and context/call
cost. Choose pass thresholds and resource limits before the run. Use an authorized
isolated load environment; the shared build droplet is not a load-test target.

Each sprint assesses whether its changes reduce or add operational and maintenance
burden: overlapping calls, cross-owner dependencies, obsolete code/tests, manual
setup and user call count. It fixes relevant waste or assigns a justified follow-up.
Line count alone is not a score; hiding the same complexity in a shared library is
not improvement.

## Risks that can defeat this effort

| Risk | Warning sign | Required response |
| --- | --- | --- |
| Product drifts into only building itself | Acceptance examples cover only our small development team | Product manager requires a relevant non-software or independent-user case and maps missing V1 coverage before release scope is claimed. |
| Monolith returns through shared infrastructure | A normal domain field change edits daemon routing, global SQL and several hand-maintained interfaces | Systems reviewer holds that boundary change until ownership/projection is corrected or a documented exception is justified. |
| Duplicate meanings accumulate | A second Work, backlog, interpreter, authorization path or synonymous command appears | Name the existing owner; choose extension or replacement and disposition the old path. No parallel implementation by default. |
| The product becomes expensive to use | Ordinary work requires a cascade of custody records, raw IDs, help calls or global context | QA measures the actual task and calls; product manager holds acceptance of the claimed usability improvement. Stronger controls stay selected. |
| Green components hide a broken system | Mocks pass but real neighbors, independent install or remote continuation fails | Integration/QA require the affected installed journey before claiming delivery. |
| Agent reports become self-certification | Receipts say tests passed but logs, candidate identity or observations are absent | Mark evidence insufficient and obtain the missing proof. Never manufacture or reinterpret a pass. |
| Workflow is quietly skipped or changed | Harness prompts carry the procedure; late edits bypass completed review | Pin the run definition and candidate; inspect actual steps/effects and re-evaluate affected approvals. Distinguish intended controls from enforced ones. |
| Growth makes messaging/storage unusable | Unbounded catch-up, one global write queue, event storms, context floods or unrestricted retained history | Qualify bounded behavior and retention under realistic growth before declaring scale support. Preserve explicit historical access and gaps. |
| One lead becomes the whole organization | Ownership and next actions exist only in its private conversation | A fresh instance must resume from shared state. Handoffs, unresolved findings and decisions stay addressable outside the lead's context. |
| Review creates its own bureaucracy | Every small edit summons all roles, duplicates evidence or restarts whole suites | QA/system reviewer choose affected checks with reasons. Scrum lead tracks review cost and removes redundant ceremony without dropping proof. |
| Public product falls behind internal use | Help, installer, examples and public status describe different builds | Release engineer holds publication claims until artifacts and documentation match; QA treats documentation as product behavior. |
| Unowned work expands the system | A useful-looking feature has no requirement, owner, consumer or acceptance condition | Product manager routes it to refinement, rejects it or proposes a contract change. No silent commitment of sprint resources. |

## Adoption and controlled change

Agreement establishes the requirements, recommended decisions and development
accountabilities above. It delegates the named engineering choices; it does not
require operator approval for each routine implementation decision. Scope changes,
weakened required checks and incompatible shared-contract changes need an explicit
decision with affected owners and operator involvement where product authority is
required. Changes are recorded in a dated successor; no silent editing of the
accepted baseline to justify past work.

The first resumed planning cycle must review the current held orchestration sprint,
isolated repairs and earlier commitments against this agreement. Finish compatible
bounded work or disposition it with reasons; do not redirect all agents halfway
through work. Before starting new domain expansion, qualify the shared author
contract with a separately authored app/client and a small installed
Note/Message/Work/Plan composition. Preserve the earlier review's reuse/rebuild
comparison and its distinct internal-catfood and public-release gates.

After acceptance, define only the agents needed for the selected cycle in
version-controlled, harness-neutral files, map them to supported harness
configurations, and qualify the common launch path with a small representative
set. The full roster is a coverage map, not a prerequisite requiring every listed role to have a
permanent process or a separate qualification campaign. A role trial must show that the instance finds its contract, stays on
assignment, identifies a planted or known relevant defect, reports a cross-component
gap and hands off usable shared state. A role label or successful process launch
does not qualify an agent definition.

The existing node keeps its documented Work behavior until an installed successor
provides the replacement Work/Plan semantics. Retire the old completion path in
the same cutover that supplies occurrence completion; do not remove the only usable
path beforehand or relabel old Work records as new Plan objects by assertion.
This is an internal transition using export/repopulation, not a compatibility
commitment to retain two public models.

The current source publication and build tools do not yet enforce every checkpoint
described here. Until the development workflow is implemented and tested, the lead
records and applies the decisions explicitly through Sidecat and reports the
enforcement gap. The workflow owner must then demonstrate a held candidate,
correction, changed artifact, renewed review, restart and harness replacement
without false completion. This is how the development agreement becomes a working
part of Sidecat rather than another document agents can silently ignore.