A feature is a user-visible capability that evolves over time. A version is one concrete milestone of that capability — v1.0 shipped X, v1.1 added Y, v2.0 rewrote Z. Linked to the epics that delivered it and the releases that announced it.
A DB trigger watches work_items. When an epic with metadata.feature_slug transitions to done, a draft version appears on the matching feature. Owners finalize; they do not create from scratch.
v1 · 1.2.3-rc1 · 2026.04 · MVP · Beta. Optional SemVer validation if you want strict checking; off by default.
Product Map shows current version badges on matching epics. Apps page links to feature history. Changelog attaches releases to versions. Org Brain cites features as sources and can propose create_feature_version in Acting mode.
On /features, click New feature. A feature is a user-visible capability — Auth, Billing, Org Brain. You pick a name, slug, owner, and status (planned / building / live / deprecated).
On any epic, add metadata.feature_slug = your feature slug. When that epic closes, a draft feature version is auto-proposed with the epic pre-linked.
Open the feature detail page. Draft versions show a yellow 'Draft' pill with a Finalize button. Name the version (v1.0, 2026.04, MVP — whatever works for your team), edit the summary, flag breaking changes.
Toggle share_public on the feature to put it on your team public page at /p/<team-slug>/features. External readers see a clean timeline — no auth, no clutter.
Toggle share_public on any feature. Visit /p/<your-team-slug>/features to see the public page — no auth, no dashboard clutter, just every published version with summary and shipped date.
Visibility is double-gated: the team must have public_enabled=true AND the feature must have share_public=true. RLS enforces both.
An app is a codebase (a repo you own). A feature is a user-visible capability. One app can host many features; one feature can span multiple apps.
An epic is a unit of work — it starts, progresses, finishes. A feature is a named capability that persists across many epics over time. Think: many epics deliver one feature, each delivery is a version.
An AFTER UPDATE trigger on work_items. It fires when (a) the row is an epic, (b) status transitions to done, (c) metadata.feature_slug is set, (d) a feature with that slug exists. If the feature does not exist yet, nothing happens silently — so rolling out gradually is safe.
Use the Backfill button on /features. It sweeps every done epic in your team with metadata.feature_slug, finds any not yet linked to a version, and creates drafts you can finalize.
Yes. Flip the Brain's Acting toggle and say 'ship v1.1 of Org Brain with these fixes'. It proposes an action_card you approve; approval calls create_feature_version_for_user RPC as you. Every action is logged to brain_actions for audit.
Anyone, but only when BOTH the team has public_enabled=true AND the feature has share_public=true. RLS enforces both gates at the DB layer — there is no leak path.
Open /features in your TeamX dashboard. Creating the first feature takes 30 seconds.