The FEATURE Header

The FEATURE Header

Every plugin module may expose a module-level FEATURE dict that describes
itself. The the-feature-catalog-and-discovery reads it, and
edition-gating-and-packaging uses its status to decide what loads.

Fields

| Field | Meaning |
|---|---|
| id | stable machine id (defaults to the file stem). Also the catalog id. |
| display_name | friendly name shown in the UI. |
| category | integration / event_source / channel / connector / scheduler / encryption / payment / secrets / storage / tool / ability. |
| status | the production gate — stable / beta / experimental. |
| summary | one line for the catalog. |
| requires | list of human-readable prerequisites. |
| skill / skill_mode / skill_handle | optional bundled skill — see ability-bundled-skills. |

Status is the production gate

• stable → included in the production edition.
• beta / experimental → excluded from production (included in beta/full).
• No header → treated as unknown and excluded from any non-full edition,

so an un-annotated file is never assumed production-ready by accident. **Always
add a header.**

Promoting a feature

Change one word: its status from experimental/beta → stable (or name it in
an edition's include list in app/features/editions.json).

Example

FEATURE = {
    "id": "email",
    "display_name": "Email (Gmail / Outlook / Yahoo)",
    "category": "integration",
    "status": "stable",
    "summary": "Read, search, and send email across Gmail and Outlook.",
    "requires": ["Google and/or Microsoft OAuth credentials"],
}