Skip to content

Latest commit

 

History

History
80 lines (67 loc) · 3.81 KB

scope.md

File metadata and controls

80 lines (67 loc) · 3.81 KB

Otto — Scope axis (Layer 3 overlay)

A recipe is the shape of the work; scope is the blast radius it runs under. Any shape × either scope.

Scope Means Artifact model
standard one repo, one branch one specs/NNN/ (the base recipes)
workspace a coordinated effort across N repos / platforms one workspace spec + N per-repo specs/NNN/, linked

Standard is the default. The router selects workspace when the intent crosses repo boundaries — names multiple repos/platforms, or touches a contract shared between them (see ../router/routing-policy.md, "Scope detection").

Workspace coordination model

A workspace effort = one shared goal, fanned across repos that each do different work, with dependencies and a shared contract. It reuses standard-scope recipes per repo and adds five things:

  1. Workspace manifest — the repos/units in play, each one's role, the shared goal. Lives in a chosen coordination location (a lead repo's specs/, or a dedicated workspace-specs/<effort>/).
  2. Workspace spec — cross-repo success criteria + the inter-repo contracts (API schemas, event/message formats, data contracts). Contracts are the source of truth each repo codes against.
  3. Per-repo sub-specs — each repo runs its own standard-scope recipe (feature/migration/ refactor/…) for its slice, linked back to the workspace spec.
  4. Dependency graph + sequencing — derived from the contracts (producer-before-consumer, schema-before-consumer). Independent repos fan out in parallel; dependent ones are gated. Driven by the orchestrate capability — at workspace scope the Claude Code Workflow backend is primary (autonomous/workflow-backend.md); spec-kit engine / conductor skill per the selection table.
  5. Workspace gates — beyond each repo's own gates: (a) all repos agree on the shared contract, (b) integration verified across repos (not just per-repo tests), (c) a coordinated rollout + rollback plan that respects inter-repo deploy order.














How a recipe runs at workspace scope

flowchart TB
    A["workspace spec + contracts"]
    B["derive repo dependency graph<br/>(from the contracts)"]
    C["<b>for each repo</b><br/>(parallel where independent,<br/>sequenced where dependent)<br/>run that repo's standard-scope recipe"]
    D["per-repo gates"]
    E["workspace integration gate<br/>(cross-repo)"]
    F["coordinated rollout / rollback"]
    A --> B --> C --> D --> E --> F
Loading



Example — db-as-queue → real queue, across backend / api / frontend / db:

  • Workspace spec: the queue contract (message schema, topics, delivery semantics).
  • Sequence: provision queue → backend publishes (migration) → api exposes (feature) → frontend consumes (feature); db-as-queue decommissioned last (migration).
  • Workspace gate: end-to-end message flow verified across all four before the old path is removed.

Memory at workspace scope

Workspace efforts imply a workspace-level constitution + CONTEXT (shared conventions/domain across repos) on top of each repo's own. See the memory stack's workspace tier (../memory/memory-stack.md); the workspace spec holds the shared contracts.

Deferred (designed-later — full reference: ../ROADMAP.md; decisions: DESIGN.md §12)

  • Portfolio layer — managing the standing stream of efforts (intake → triage → prioritize → track) above the router; ties to the connected ClickUp/Todoist + PK /triage.
  • Domain profiles — per-surface gate/deploy semantics (hardware OTA, ML/CV evaluation).