Extreme-BDD
Versioned contract

Protocol 1.16 — performance-aware, sovereignty-first.

Each repo declares its supported capabilities in bdd/RADICLE_PRIORITIES.json. Clients negotiate against that file instead of guessing. New capabilities arrive as planned, graduate to optional, and remain explicit and grep‑able forever.

Capability tiers

Every capability key carries a tier value — not a boolean. “Supported” is not the same as “required”, and capabilities the repo plans but has not implemented stay visible so callers can route around them.

TierMeaning
required Backlog cannot be rendered correctly without it. (featureCatalog, boardState.)
optional Implemented and stable. Clients may use it; absence is not an error.
planned Declared as a roadmap commitment. Implementation is in progress or scheduled.

What protocol 1.16 added

Protocol 1.16 formalises the performance work that turned the board from “rebuilds the whole world on every request” into a compact-first, side-view-cached read model. None of these changes affect canonical authority — .feature files remain the backlog source of truth.

CapabilityTierWhat it gates
boardPerformanceHotPathsoptionalCompact backlog + sidecar separation on first paint.
compactCardPayloadoptional/api/backlog returns compact cards by default.
cardDetailHydrationoptional/api/card/detail?key=… hydrates the full card on demand.
backlogResponseSidecarsoptionalGhost cards, epic rollups, suite evidence load as opt-in sidecars.
sharedReadModelCacheoptionalOne parse, many endpoints, with explicit invalidation triggers.
persistentBacklogResponseCacheoptionalWarm restarts serve compact backlog without rebuilding cards.
performanceSmokeReportingoptionalscripts/performance_smoke.py records latency, bytes, cache state per endpoint.
payloadBudgetEnforcementoptionalSmoke run fails when compact backlog, card detail, epics, hygiene, or Gantt exceeds documented byte budgets.
httpResponseCompressionoptionalGzip / brotli negotiation on large JSON when the client sends Accept-Encoding.
compactReadModelAssemblyoptionalBuild compact cards directly from the read model; no full-card materialisation on the hot path.
incrementalCardPatchApioptionalMutations return targeted card patches and a board-state revision token.
sideViewCompactSchemasoptionalCompact mode + detail hydration for /api/epics, /api/blockers, /api/hygiene.
multiRepoProgressiveLoadingoptionalPhased startup: repo shells → active repo cards → background secondary repos.
browserRenderingVirtualizationoptionalLarge columns and collapsed groups stop creating DOM nodes for hidden cards.
parallelTestRunneroptionalscripts/run_tests_parallel.py with serial-allowlist + per-domain step bundles.
bddWorkerStepBundlesoptionalBDD workers import only the step bundles their feature domain needs.

Earlier milestones

1.10 — Suite evidence

Optional Circle Source evidence read models in bdd/SUITE_EVIDENCE.json and the matching suiteEvidence capability family.

1.11 — Lifecycle projection

Current passing/failing test evidence projects card lifecycle; sync worker-only status separates from rich remote-issue status.

1.12 — UX proposal review

Five-planes review evidence on uxReview, with templates exposed via /api/ux/review-template.

1.14 — Shared contract rollups

sharedContractRollups and userDesignProposalReview turn multi-repo contracts into a read-only integration signal.

1.15 — Card provenance

Editable BDD provenance under bdd/CARD_PROVENANCE.json, served via /api/provenance and mirrored into Radicle issues.

1.16 — Performance contract

The compact/cache/budget capabilities listed above, plus the parallelTestRunner + bddWorkerStepBundles developer-experience pair.

Negotiation rule A client that needs capability X should read it from the repo’s bdd/RADICLE_PRIORITIES.json before falling back to feature detection. If X is planned, treat it as absent today and as a written commitment for tomorrow.