Composition documentation index¶

Start here¶

• Choose Website or Web application — Browser-facing product? Classify the artifact from product identity and caller-visible behavior, not static/dynamic rendering, hosting, runtime, or PWA technology.
• Website product walkthrough — Creating your first content/document-oriented Website? Follow Project Docs from a separate repository through website selection, inspect -> plan -> apply -> validate, Website contracts, planning/product evidence, implementation, and browser proof.
• Webapp product walkthrough — Creating your first Web application? Start here. Follow one zero-to-one Task Ledger path from a separate product repository through installation, composition.json, inspect -> plan -> apply -> validate, ownership, implementation, product tests, evidence, optional Policy, and later update/upgrade.
• Composition concepts for first-time readers — Optional mental-model guide for repository-specific uses of recipe, artifact, component, contract, material, and lock. You do not need to read it before following a first-use walkthrough.
• Agent Skill first-use walkthrough — Create a reusable Skill from a separate repository with the smallest Composition path.
• Evaluating Composition — canonical independent clean-room evaluator entry point: follow the formal protocol, use the scorecard guide, validate the machine-readable scorecard against its schema, and preserve transcript chronology.
• Using Composition — task-oriented create, inspect, update, upgrade, recovery, ownership, and conflict workflows for consumer repositories. Human terminal users may add --format human to inspect, plan, apply, or validate for concise next-action guidance; automation should continue to use the default JSON output.
• Choosing a recipe and components — choose skill, website, or webapp, then select only the capabilities or lifecycle behavior the product actually needs.
• Producing a product release — product evidence, fixed executable argv, exact candidate revision, transactional release production, rollback, and recovery.
• Composer reference — exact CLI modes/options, inspect states, plan fields, ownership semantics, recovery rules, and managed lifecycle diagnostics.
• Composition overview — current authority, lifecycle summary, safety model, and documentation entry points.

Composition architecture¶

• Composition model — foundation, artifact, capability, lifecycle, ownership, intent, and lock semantics.
• Composer architecture — resolver precedence, plan/apply safety, trust boundaries, managed reconciliation, and recovery protocol.
• Production catalog architecture — closed component and recipe inventory.
• Generated contract manifest — deterministic generated contract registry architecture.

Publication boundary¶

• Publication boundary — what this provider exposes to the integrated documentation site and why.

Composition provider maintenance¶

• Maintaining the Composition provider — canonical overview for changing Composition itself: components, catalog, Composer, schemas, evaluation, validation, provider publication, and provider release procedures. It is not consumer-product maintenance guidance.
• Composition installer release — immutable provider release identities and verified consumer bootstrap boundary for the installable Composition Skill.

Agent Skill artifact¶

• Skill documentation index — Skill-specific profiles, architecture, and responsibility map.
• Skill contract scaffold — trigger, workflow, resources, routing, output, validation, and safety contract.

Shared Web foundation¶

• Website or Web application decision guide — artifact selection and the boundary between shared Web semantics and artifact-specific semantics.
• Web URL and path design guidance — advisory naming, persistence, hierarchy, query/fragment, and implementation-independence guidance that does not change route conformance.
• Shared browser identity contract — product-neutral browser identity.
• Shared routes contract — generalized canonical paths, aliases, deep-link expectations, and navigation accessibility.
• Shared viewports contract — responsive viewport and input-capability expectations.

Website artifact¶

• Website product walkthrough — canonical first-use path for a concrete content/document-oriented Website.
• Website component descriptor — Website artifact dependencies, contracts, validators, and materials.
• Website structure contract — page inventory, hierarchy, home page, primary navigation, and shared-route bindings.
• Website document metadata contract — titles, descriptions, language, canonical-path policy, indexability, and social-preview intent.
• Website discovery contract — canonical origin, robots, sitemap, and feed discovery semantics.

Web application artifact¶

• Webapp product walkthrough — canonical first-use path for a concrete Web application.
• Web application documentation index — application-specific contracts and validation on top of the shared Web foundation.
• Web application template contract — framework-neutral browser application obligations.

Reusable application capabilities¶

• Implementation runtime decision record — implementation ecosystem, commands, dependencies, environment, distribution, and deployment choices.
• Choosing an implementation runtime — criteria for selecting an implementation ecosystem and dependency workflow.
• Progressive Web App capability — artifact-neutral installability, offline/freshness, application identity, and update behavior for Website or Webapp products.
• Packaged CLI interface — caller-visible CLI behavior.
• MCP interface — MCP protocol, transports, client roles, and semantic equivalence.
• MCP transport guidance — stdio and Streamable HTTP guidance.
• MCP Apps extension — Host/View bridge, resources, sandbox, and fallback contract.
• MCP Apps guidance — implementation guidance for MCP Apps.
• WebMCP browser capability — canonical browser-exposed MCP capability contract, selection boundary, runtime behavior, and security expectations.
• Standalone browser interface — browser-facing routing, security, health, and failure semantics.
• Headless service interface — non-browser service behavior, health, security, and lifecycle.

Reusable lifecycle contracts¶

• Composition state — self-contained resolved-state and material-ownership validation.
• Contract evolution — closed contract registry, schema binding, version histories, and migrations.
• Implementation evidence — implementation boundaries, proofs, commands, and release gates.
• Release evidence — revision-bound execution provenance and release decisions.
• Release bundle — deterministic digest-closed handoff.

Repository topology¶

• Repository topology contract — Hub-and-Orphan topology invariants, read-only discovery projection, orphan component authorities, branch-equals-mount-path, leaf-only namespace, and authority-to-hub synchronization.
• Repository topology architecture — architectural details and operational invariants of the Hub-and-Orphan pattern.

Historical provenance¶

• Composition authority migration — consolidated chronology of the authority cutover, provider migration, branch retirement, and immutable PR provenance. Stage-specific implementation notes are retained only for repository maintenance and are not reader publication pages.

Machine-readable authorities¶

• Production catalog guide — catalog closure rules, path conventions, consumer recipe/component selection guidance.
• Composition schema guide — component, recipe, configuration, lock, transaction, and catalog schema responsibilities.