LoopX Product Capabilities

A LoopX capability is a stable, provider-neutral contract for producing one bounded, verifiable caller outcome from LoopX state. It owns the domain policy, normalizes provider observations, validates the result, and proposes a typed transition to the Kernel.

Each built-in capability owns its canonical README, registration metadata, and implementation in one package below this directory. The documentation site is a build-time projection of those package-owned Markdown files, not a second authored copy. A directory still does not become a shipped capability merely by existing: registration metadata, a real entrypoint, and durable validation are required.

That makes it different from the surrounding boundaries:

• the Kernel owns durable goal, todo, gate, quota, recovery, and scheduling truth;
• a provider performs a bounded external or local operation and returns readback;
• an extension packages and operates an optional provider without acquiring Kernel authority;
• host declarations such as shell and network describe runtime capacity, not a product capability or a permission grant.

Inspect What This Release Can Do

The runtime registry is authoritative. Directories and documentation do not become shipped capabilities merely by existing:

loopx capability list --format json
loopx capability show issue-fix --format json

list reports registered capability and provider readiness. show adds the user value, maturity, entry commands, explicit write boundary, implemented protocols, and durable validation for one capability. Use that readback before enabling an advanced path or optional provider.

Choose By Outcome

The selected documents below explain human usage paths behind registered capabilities. The CLI remains the source for the complete catalog and for exact availability and maturity in the installed release.

Engineering Delivery

You need to...	Capability path
Prepare and qualify local no-upload benchmark experiments through a fail-closed evidence lifecycle	Benchmark Toolkit
Turn public issue and PR signals into a focused, reviewable fix with validation evidence	issue-fix capability (中文)
Qualify the exact final diff through bounded review, safe repair, and strict receipts	Change Quality
Review a changing public PR queue against exact-head evidence and typed completion rules	Pull Request Review
Detect source-head drift and safely rebuild a local stack of already reviewed branches	Integration Branch
Gate local repository changes by a typed schedule and retain blocked unmerged work across restarts	Repository Change Window

Research And Decision Continuity

You need to...	Capability path
Preserve questions, hypotheses, experiments, findings, and composition frontiers across a long exploration	Explore (中文版)
Run one bounded multi-agent research question with role-scoped evidence and terminal decisions	Auto Research
Separate current evidence, advisory proposals, and verified outcomes before making a decision	Decision Context (中文)
Recall a settled autonomous turn without manufacturing a new user prompt	Agent Turn Recall
Add optional, provider-neutral preference recall without making memory the state authority	Semantic Preference
Preserve typed feedback memory and evaluate bounded recall/application pilots	Reward Memory (中文)

Operations And Projection

You need to...	Capability path
Deliver release-owned skills into selected project-local host surfaces	Project Skill Delivery
Compose scheduled or progress-triggered reports with source, archive, delivery, and settlement receipts	Periodic Report
Turn public/private content signals into reviewable source, angle, draft, feedback, and publish-gate packets	Content Operations
Inventory, archive, migrate, and rerank a material store without losing raw source authority	Material Lifecycle (中文)
Inspect compatibility routes for public-safe external-value intake while callers migrate to outcome-owned capabilities	Value Connectors

Contributor Navigation And Ownership

Every registered built-in capability package contains a catalog_entry.py. That record declares its stable id, commands, provider boundary, canonical documentation source, published route, implemented protocols, and durable validation. The root catalog.py only composes package-owned entries; it does not maintain a second capability-to-document map.

Use the runtime readback for the installed release:

loopx capability list --format json
loopx capability show <capability-id> --format json

show reports canonical_doc, documentation_route, commands, write boundaries, protocols, smokes, and provider readiness from the same registered record used to build the documentation site.

Supporting packages such as shared context-provider helpers may live under this namespace without a catalog_entry.py; they are internal modules, not product capabilities. Optional providers and extension-delivered capabilities keep their documentation beside the owning extension package and use the same build projection without gaining Kernel authority.

From Capability To Provider

The execution and control paths deliberately run in opposite directions:

Agent -> Capability -> Provider -> external system
Provider readback -> Capability transition proposal -> Kernel

Start from the caller outcome, not from an extension name. A built-in provider may already implement the capability. When an optional implementation is needed, inspect its declared permissions and readiness, then use the explicit install, doctor, enable, disable, upgrade, and rollback lifecycle documented in Extensions and Capabilities. Installing an extension does not grant new authority.

Architecture Rule: Domain Lanes, Not Kernel Columns

An operator surface may render LoopX as an agent-native Kanban. The Kernel supplies generic lifecycle operators such as claim, gate, monitor, complete, supersede, quota, and writeback. A capability may add a domain lane that interprets provider observations, but it must not create parallel todo or scheduling authority.

For example, Issue Fix can project feasibility -> patch -> checks -> review -> merge, while an experiment path can project hypothesis -> execute -> evaluate -> promote/retire. These labels come from capability-owned domain state and accepted Kernel transitions; they are not new core lifecycle statuses. If a domain stage changes permission, claim eligibility, quota, a user gate, or terminal closure, the capability must propose a typed transition through the existing Kernel contract.

Keep Kernel control-plane code generic. Put scenario-specific contracts, implementation modules, CLI entrypoints, package documentation, and smokes under the capability they serve. Cross-capability architecture, Kernel and extension contracts, and general guides remain under docs/. Do not add a registered capability until there is a package-owned catalog entry, canonical README, real entrypoint, and durable smoke. Future ideas belong in product planning docs until they have executable evidence.