Extension Contracts
AGILAB is easier to maintain when every extension follows a small contract instead of adding page-specific or app-specific glue. This page is the public contract kit for new apps, page bundles, notebook bridges, proof evidence, connectors, and shared-core changes.
The machine-readable source is
data/extension_contracts.toml.
Maintainers can inspect it through the maintenance dashboard:
uv --preview-features extra-build-dependencies run python tools/maintenance_dashboard.py --json
./dev maintenance
Contract shape
Every extension type declares:
metadata: files, manifests, labels, or registration points that make the extension discoverable;
evidence: reports, run manifests, hashes, UI robot output, or verifier results that prove the extension boundary;
guardrails: tests or tools that fail before drift reaches release time;
maturity labels: the capability-map labels that separate shipped local paths, contract proofs, live checks, and roadmap boundaries.
Use Capability Map as the single reference for maturity-label meanings.
Extension types
Type |
Maintenance rule |
Primary guardrail |
Typical evidence |
|---|---|---|---|
|
Public apps must be installable, runnable, documented, and evidence-producing. |
|
|
|
Pages stay app-agnostic, dependency-isolated, and discoverable through provider/catalog metadata. |
|
UI robot, static render, apps-pages docs row. |
|
Notebook import/export must preserve stage order, runtime hints, role metadata, and artifact references. |
Notebook preflight and round-trip reports. |
Import preview, |
|
Evidence surfaces must have schemas, producer commands, verifier behavior, and explicit claim boundaries. |
Evidence claims policy and release proof checks. |
Plain JSON, |
|
Connectors reference data systems by ID and credential reference, not by embedded secrets or hidden local paths. |
Connector facility, resolution, and adapter reports. |
Local proof, contract proof, emulator proof, or live probe result. |
|
Shared runtime or installer changes need explicit blast-radius analysis and focused regression evidence before merge. |
|
Impact report, focused tests, docs when public behavior changes. |
Adoption rule
Before adding a new feature, choose its extension type and maturity label. If a feature does not fit any row, add or revise the contract first. This keeps AGILAB maintainable as the number of apps, page bundles, connectors, and proof surfaces grows.
Release rule
Do not promote an extension as public-ready until its metadata, evidence, docs, and guardrails are all present. For split packages, the package split and release plan remain the source of truth for what is published.