This agreement and the product contract, revision 4 incorporate the UI amendment authorized on 2 October 2026. They retain the agreements approved together on 29 September 2026. This agreement sets Sidecat's own development obligations; it is not compulsory customer policy or a gate on ordinary calls. The guide can refine role arrangements and practices but cannot waive either agreement. Live assignments, decisions and evidence belong in Sidecat; progress distinguishes intended checks, manual checks, enforced behavior and qualified results.
Required roles and accountability
Use the selected roles and independent role input from the next development cycle, even before native role management is implemented. Record exact harness-neutral role revisions in version-controlled files. Record actors, assignment scope and execution choices in available shared state; disclose manual bindings/checks. A manual kit or credential profile does not qualify native managed-agent capability. Do not postpone responsibility until automation.
| Required function | Accountability |
|---|---|
| Product management | Trace outcomes to purpose, applicable requirements and real use; maintain requirement-owner-acceptance coverage and concise readiness. Identify missing ownership, duplication, orphan work and software-only assumptions. Send changes to required scope to the operator. |
| Delivery coordination | Gather independent input; select coherent ready assignments with owners, dependencies, capacity, review coverage, budget and stop conditions. Coordinate integration, resolve blockers and disposition unfinished work. Keep new ideas in refinement until selected. |
| Systems integration | Review boundaries, shared-library growth, database ownership and multi-node composition. Require focused consumer proof for changed shared contracts; do not author every component. |
| Call-surface usability | Review complete tasks across relevant applications: discovery, meaning, prerequisites, dependency/sequence clarity, composition and recovery. Assess observed caller friction, not total catalog size. |
| Independent QA | Design exploratory, adversarial, concurrency, recovery and unfamiliar-user trials; inspect usability, documentation, readability and unnecessary tests. Separate observations from claims. |
| Release and activation | Produce/reproduce exact artifacts; verify matching evidence, configuration, packaging, installer, publication and rollback. Publish capabilities/limits. Cannot decide product scope or waive QA findings alone. |
These are functions, not a fixed role roster or permanent model processes. Roles can be combined, grouped or specialized while retaining coverage. An implementer cannot be the sole reviewer of a consequential change or sole observer qualifying its installed result. Independent review uses a separate context and records who did what; a different vendor is useful judgment input, not substitute evidence. Component owners maintain public contracts, local tests and docs and route concerns to their owners instead of silently ignoring or taking over unrelated work. AAuth Go independently refreshes specifications, assesses conformance and implements justified library updates. Keep the library generally useful outside Sidecat; Sidecat policy/branding/integration remain outside its repository and use its public interface.
Development cycle
shared state + product/development agreements
-> independent role input -> selected outcome and ownership
-> brainstorm -> component spec -> plan -> readiness check
-> implementation + focused tests -> independent review -> integration
-> installed QA + user/documentation/load trials -> release decision/activation
-> sprint review and unfinished-work disposition -> next outcome
How the scrum runs
- Prepare the brief. The lead supplies agreement revisions, current evidence, the candidate outcome, observed capacity and decisions needed. Identify affected call surfaces, documentation and operator views. Assign each participant an exact role revision; a model/harness name is not a responsibility.
- Gather independent input. Affected owners, product management, QA and integration assess useful work, dependencies, risks and acceptance before seeing the lead's preferred answer. Include release responsibility when relevant.
- Select the work. Resolve disagreements with affected holders and retain their disposition. Record one outcome, Work/Plan occurrences, owners, review coverage, budget and stop conditions. Unaffected holders need not attend every discussion.
- Coordinate on changes. Respond to dependencies, results, failures and material changes. Avoid empty status loops and unannounced mid-cycle redirection.
- Review and disposition. Owners report observed and unfinished outcomes; QA assesses evidence; product management checks value and coverage. Disposition remaining work before selecting the next cycle.
Firm checkpoints
| Checkpoint | Required evidence and decision | Accountable role |
|---|---|---|
| Ready to commit sprint effort | Named outcome and requirement IDs; current-state evidence; role assignments and prepared context; component/review owners; affected surfaces/docs/operator views and UI path/owner; 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; updated runnable UI build with matching source/docs for affected operator paths; appropriate failing/passing behavior tests; independent code/contract review; findings disposition; checked affected call/UI surfaces and 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 | Independent QA after the completed working build and before release; exact installed artifact and configuration; functional, failure/recovery and concurrency evidence; all supported call surfaces and actual available UI paths, including operator review; 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. |
Missing administrative steps do not invalidate independently demonstrated work; record the process defect. Missing evidence, blocking defects or changed unreviewed artifacts hold the smallest affected integration/release while unrelated admitted work continues. Name the requirement, evidence and remedy; invent no new product requirement as a passing condition.
Shared contracts and dependency decisions
A component manifest names owner, interfaces, dependencies and test/build entry points. Use shared operation descriptors rather than independent client-schema/review copies. Before dependent work relies on a choice, its owners resolve:
| Choice | Required decision/proof |
|---|---|
| Common wire profile | Integration, affected owners and QA settle version/schema selection, timing, unknown-outcome lookup, immutable schemas, event identity and subscription lifecycle. Qualify separately authored app/client; call-only proof cannot qualify event-driven messaging or Work notifications. Authors need not await unused capabilities. |
| Go contribution hosting | Runtime/packages compare resident handlers and supervised workers for authoring, installation, load and isolation before external Go admission. No plugin ABI is assumed. |
| Messaging provider | Messaging/federation select against durable conversation, access, authority and return-after-absence acceptance; a Matrix connection alone is insufficient. |
| Storage/indexes/blobs | Owners specify access patterns, transaction invariants, growth/retention and contention before persistence implementation. Git/content-addressed artifacts are candidates, not a synchronous universal database. |
| Platform/capacity | QA/runtime/release declare workloads, hardware, limits and failure thresholds before qualification. Product management takes scope shortfalls to the operator. |
Before selecting a component's replacement scope, review its relevant existing code, documentation, decisions, tests and unfinished work. Maintain the capability mapping with intended behavior, observed implementation/qualification, proposed owner, reuse/extract/revise/rebuild/retire decision and reason, and acceptance/gaps. Unassessed is not rejected. Contract omissions are review gaps, not permission to drop capabilities. Perform this analysis by component as work is selected; no whole-history reconstruction is required before every task.
Check existing assignments/commitments each cycle; finish compatible work or disposition it with reasons. Before domain expansion, qualify an independent app/client and installed Note/Message/Work/Plan composition. Reuse/rebuild decisions compare required results and total development/maintenance cost, not novelty or entitlement.
Surfaces, documentation and testing
Every cycle identifies affected public operations, surfaces and documents at planning and verifies disposition before integration. Supported argv/CLI, MCP, Lisp and native client/bus entry points preserve the same inputs, results, errors, authority and recovery; UI consumes those calls and relevant events/subscriptions. Generic entry points can expose contributions without a top-level command, separate tool or screen per operation. Missing projections remain product gaps.
Before adding a domain concept or task entry point, review whether an existing record owner, package-defined shape or routine supplies it. The spec names the semantic definition, storage/effect owner and supported caller path; choose Go or Lisp from responsibility, workload, invariants and development/maintenance cost. Keep required checks in the selected procedure/owner, and align the application author contract with package-defined records and composition. A declared extension without an independently usable authoring path does not qualify extensibility.
Call-surface review directly targets the failures recorded across prior Sidecat generations: confusing/overlapping meanings, hidden state and prerequisites, and sequences agents cannot find or complete. Review the intended task and its application dependencies before approving affected interface choices. Include independent unfamiliar-agent evidence of discovery, completion and recovery in qualification. Record preparation and assistance; verify the actual outcome. A populated catalog can test relevance and dependency discovery where applicable. Total application/call count and protocol conformity alone establish no usability verdict. Calls, context, time and interventions are diagnostic measurements under the task's acceptance, not a universal quota or reason to merge applications.
Inspect and try affected CLI help, MCP descriptions/schemas, Lisp discovery, man pages, examples, user/author guides, README, llms.txt and web instructions. Record changes or why unaffected. Prefer generated projections where appropriate, but inspect authored explanations and installed use. Private unrelated changes need no artificial surface pass.
Every release cycle exercises its installed candidate through all supported public surfaces: argv/CLI, MCP, Lisp and native client interface, plus available UI views/actions. Use shared acceptance scenarios and surface-specific discovery, presentation and recovery checks. Backend tests alone do not establish interface usability; neither every catalog entry nor a screen per operation must be manually exercised. Audit the whole published documentation set before public release.
Use TDD for behavior changes/fixes and meaningful behavior/invariant tests, independently runnable component suites, shared fixtures and a small real-neighbor journey set. Review correctness, authority, concurrency, clarity and avoidable complexity. Consequential designs use independent open review, then the author's specific questions written before receiving that review; keep review instructions outside the artifact. Add specialists for named risks, not every change.
QA independently chooses its charter. Unit tests do not replace exploration, installed use, docs, recovery or workload trials. Each release candidate has unfamiliar CLI and MCP agents using shipped guidance plus adversarial QA; label agent trials and add people when available. Disclose coaching. Load trials cover application clusters, hot records/rooms, slow consumers, retries, restart, partitions and multi-day absence. Measure throughput, latency distributions, queues/write waits, memory/storage growth and context/call cost; choose limits/thresholds beforehand in an authorized isolated environment, never the shared build droplet. Each sprint assesses overlapping calls, cross-owner coupling, obsolete code/tests, manual setup and call counts, fixing waste or assigning justified follow-up. Line count or moving complexity into libraries is no improvement proof.
Internal clients and cutover qualification
- Deliver and use Sidecat UI each sprint. Provide a runnable, tested working operator build early in Version 1 development, before cutover, and update it every sprint. Keep relevant views/actions aligned with delivered capabilities; inspect purpose, recent work, assignments, test activity/results and recorded updates through the actual UI. Use the completed working build for independent QA and operator review in the same sprint, before release. Pure backend changes need no artificial screen. Progress names the exact available candidate, launch instructions/access, environment, freshness and known limits; completed source alone is not an available UI. Keep the prior working build available while its successor has blocking findings, and record unfinished affected UI work explicitly.
- Present observations honestly. A running test is not a passing test. Show missing, stale and error states; never present a mock as implemented behavior. Package source and visibility remain distinct from track. UI observation does not own collection, authority or accounting. Apply the product's summary/detail rules; the guide supplies the writing convention.
- Qualify the role launch path. A representative set finds its contract, stays on assignment, identifies a relevant known/planted defect, reports a cross-component gap and leaves usable shared state. Neither permanent processes nor a separate campaign per role are required; labels/process launches alone prove nothing.
- Qualify native roles before cutover. Exercise roles, actors and assignments through the common application contract: offline message/work assignment, activation with actual run attribution, and worker/lead replacement preserving pending work and unresolved effects. Manual files/profiles do not qualify V1-10.
- Qualify workflow continuation. Demonstrate a held candidate, correction, changed artifact, renewed review, restart and harness replacement without false completion. Documentation does not prove enforcement. Follow the product's coordinated Work/Plan transition and separate full-release scope.
Risks that can defeat this effort
| Risk | Warning sign | Required response |
|---|---|---|
| Product drifts into only building itself | Acceptance covers only our development team | Require a relevant non-software or independent-user case and map missing V1 coverage before claiming release scope. |
| Monolith returns through shared infrastructure | Domain changes edit routing, global SQL and hand-maintained interfaces | Hold the affected boundary until ownership/projection is corrected or a documented exception justified. |
| Duplicate meanings accumulate | Second Work/backlog/interpreter/auth path or synonymous command | Name the owner; choose extension/replacement and disposition the old path. No parallel implementation by default. |
| The product becomes expensive to use | Ordinary work needs custody cascades, raw IDs, help calls or global context | Measure actual task/calls; hold claimed usability acceptance. Stronger controls remain selected. |
| Green components hide a broken system | Mocks pass; real neighbors, installation or remote continuation fail | Require the affected installed journey before delivery claims. |
| Agent reports become self-certification | Claims lack logs, candidate identity or observations | Obtain missing proof; never manufacture or reinterpret a pass. |
| Workflow is quietly skipped or changed | Harness prompts carry procedure; edits bypass completed review | Pin definition/candidate, inspect actual steps/effects and revisit affected approvals; disclose unenforced controls. |
| Growth makes messaging/storage unusable | Unbounded catch-up/queues, storms, context floods or history | Qualify realistic bounded growth/retention before scale claims; preserve explicit historical access and gaps. |
| One lead becomes the whole organization | Ownership/next actions exist only in private chat | A fresh instance resumes shared state, including handoffs, findings and decisions. |
| Review creates its own bureaucracy | Small edits summon every role, duplicate proof or rerun whole suites | Choose affected checks with reasons; track review cost and remove ceremony without dropping proof. |
| Public product falls behind internal use | Help, installer, examples and status describe different builds | Hold claims until artifacts/docs match; treat documentation as product behavior. |
| Unowned work expands the system | No purpose, owner, consumer, acceptance or deliberate selection | Refine/select compatible work explicitly; reject unjustified work or propose changed commitments. No silent sprint-resource commitment. |
Context, amendments and manual checks
Each assignment supplies exact agreement/role revisions, purpose, applicable requirements, design rules, accountability, checkpoint/independence, risks and used component/dependency contracts. Capacity/release/cutover work includes product scale/release constraints. Use bounded linked excerpts with source digests, section/requirement/named-row references; no full-history briefing or orientation essay. Owners check omissions; actors report gaps before relying on incomplete material. Handoffs preserve references and unfinished actions. Pin active revisions unless authorized amendment changes them; pinning never preserves expired/revoked grants. The guide can revise reading paths without amending either agreement.
Use deterministic checks for facts and role judgment for sufficiency. Required assessments identify evidence, allowed disposition and exact contract/artifact; detect missing owners, changed interfaces without consumer review and source changes after approval. Reviewers inspect behavior because mechanical checks cannot prove good design, sufficient tests or honesty. Record checkpoint decisions in Sidecat and disclose manual versus enforced checks. Encoding and qualifying the procedure in orchestration is early catfooding, not a reason to defer the next cycle's obligations or impose historical audits on ordinary user paths.
Exceptions name narrow scope, authorizer, reason and expiry/revisit. They cannot silently amend commitments; proportional test selection and fixing process defects are not exceptions to required outcomes. Compatible additional features follow deliberate ownership/acceptance and resource selection. Weakening outcomes/checks, reducing agreed release scope, displacing selected work or incompatible shared contracts require affected-owner decisions and operator involvement where required. Record dated successors, preserve accepted agreements, and hold only affected work. Remove redundant ceremony while retaining proof.
Document history
2 October 2026 — development revision 3: Joshua Gay authorized early UI delivery, every-sprint updates and independent testing after the working build, with product revision 4. Prior development revision 2.
29 September 2026 — development revision 2 accepted with product revision 3. Approval record · Approved review text.