Features

Beta

A Feature is a durable execution slice. It carries the evidence needed to understand what changed, why it changed, how it was built, and what verification ran.

Open Spec-Driven Development -> Features to see the full-width Feature table.

Lifecycle evidence

Each Feature uses the standard lifecycle work products:

Feature table

Labels are available as a Feature filter, List display property, grouping field, and saved/default view field. Persisted table-control state stores label ids rather than copied names or colors.

The Feature table is an operational index. It focuses on the current set of Features rather than a raw history log.

Right-click any Feature row and open More properties -> Rename to change its title without leaving the table. The same row menu is reused wherever the Feature table appears, including Initiative, workspace-view, and Team-view contexts. When the rename command opens, the current title is selected and the Rename action is already active: type the replacement and press Enter to save, use the arrow keys to move between Rename and Cancel, or press Escape to close. Rename is available only when Integrity confirms Feature metadata edit capability; the new title appears optimistically and the stable Feature URL slug does not change.

The table intentionally stays dense. Feature work is something teams scan repeatedly, compare, and review; it should not behave like a marketing overview or generic document library.

By default, the table shows:

The default table scope is All Features. The V1 Planning table does not show Version, Initiative, Members, or Updated by default. The main Feature table keeps Health as the default summary column label.

Feature filters narrow the current table in the browser. Supported filters include Status, Priority, Lead, Members, Creator, Teams, Labels, Health, Dates, and Phases. Phase filters can select current or completed stages while preserving display-safe Feature ownership. Status filtering uses the same Feature vocabulary as the table picker, including Completed and Canceled. Display grouping can shape the rendered sections by Initiative, Team, Lead, Member, Labels, Status, Priority, Start date, or Target date. A Feature with several labels appears in every matching label group, while unlabeled Features appear under No labels. Feature grouping also supports one sub-grouping level; the sub-grouping menu stays available when a primary grouping is active and can use the same property when a self-grouped scan is useful. Secondary group rows render under each primary group with their own count and divider line. Display ordering can sort by Manual, Name, Status, Priority, Updated, Created, Health updated, Start date, or Target date; sortable column headers update the same ordering state shown in the Display options menu. Rows with equal ordering values keep their stable table position instead of jumping after unrelated edits. Future parity rows such as Relations, Template, Health grouping, and Specific project remain disabled until those product concepts exist in Integrity.

Active filters appear as compact predicate chips above the table. Removing the last chip removes the filter bar. If filters produce no matches, the table shows a search empty state with the filter bar still available so filters can be changed or cleared. When filters or display options hide rows while the table still has visible content, a bottom footer summarizes hidden counts; Show options opens Display options, and Clear Filters clears the active filter chips.

In List mode, row selection is a session-only table interaction. Select visible rows with the row checkboxes, Ctrl-click (Cmd-click on macOS) a row to toggle only that row while preserving the rest of the selection, use Shift-click to select a visible range, and open Actions from the floating selection bar for supported existing property updates such as Status, Priority, and Lead. Selection is cleared or pruned when the visible table scope changes, and it is never saved to Feature views, copied URLs, or browser-local table-control drafts.

Feature filter, presentation mode, grouping, sub-grouping, group/sub-group order, hidden group/sub-group values, show-empty-groups preference, ordering, display-column, Board card-property, Timeline row-property, and closed-feature visibility drafts are remembered in the current browser per workspace, user, and Feature view badge. Switching view badges restores that badge's draft lens. The current browser also remembers the last selected Feature view badge; a copied URL with ?view= takes precedence, and selecting another badge updates that query in place, while a plain refresh without that query reopens the remembered saved or temporary view instead of returning to All Features. In List, Feature display properties can show Summary under Name and toggle the supported columns Priority, Status, Health, Lead, Team, Start date, Target date, Issues, Created, Updated, and Completed in canonical order. Team filters, group lenses, saved views, and browser-local drafts store stable accessible Team IDs rather than rendered Team labels. If a Team becomes inaccessible, archived, deleted, or hidden by privacy rules, Integrity drops stale Team filters/groups or renders a generic private/unavailable value instead of showing the Team name. The Grouping and Sub-grouping rows expose a settings icon when a grouping is active; it opens an in-menu ordering view with a back button, vertical-only drag ordering, value-specific icons or static avatars, a draggable row body, and eye toggles for whether each group value is visible in the table. Show empty groups appears only when a grouping is selected; when it is off, groups with no visible Features in the current table are omitted. In Board, the same filtered Feature set renders as columns and cards; Board card properties have their own defaults and can include Summary, Priority, Status, Health, Lead, Team, Target date, and Issues without changing List table columns. Board columns can be grouped by the supported Feature grouping fields, optionally split into row swimlanes, ordered, hidden from the canvas, and restored from Board display settings or the far-right Hidden columns lane. That lane stays on the Board content background, expands or collapses hidden-column cards, and each hidden card has an Unhide menu action. Show empty columns is on by default for Board, including new custom views, and Status/Priority/Team groupings seed their stable bucket vocabulary even when a bucket currently has no matching cards; users can turn it off locally or save a different Board default for everyone on built-in views. Board card Status, Priority, Lead, Team, and Target date controls use the same quiet inline controls as the List table, with optimistic updates and no success toast; Health remains display-only. In Timeline, the same filtered Feature set renders on a full-width date grid with a sticky two-row axis, current-day line, viewport-fixed outlined pill-style Today recentering and granularity controls on opaque floating surfaces, and Year, Quarter, Month, and Week granularity. Timeline opens and changes granularity centered on today rather than persisting horizontal scroll. Timeline day labels sit under their owning month/week/day bucket rather than in a detached toolbar row, and the date axis begins at the left edge beneath sticky project-list overlays instead of after a reserved label column. Timeline renders a finite buffered date window for the active granularity and extends it near horizontal scroll edges so more dates appear continuously without rendering an unbounded calendar. Timeline supports primary grouping and ordering but intentionally does not expose Feature sub-grouping. Its floating left project list can show Feature icon/name plus derived Health, Status, Priority, Lead, and Team fields in grounded rounded row labels with direct row-label/control hover feedback only and extra vertical spacing; hovering the Gantt grid area does not highlight the left labels or inline controls. Clicking the row opens the Feature detail page, and the icon color control opens on icon click with a ghost trigger. Timeline group headers are full-width muted overlay buttons across the chart with a sticky left label, visible hover state, and click-to-collapse behavior for the rows below. The Gantt rows do not render per-row horizontal dividers. Status, Priority, Lead, Team, and icon color use icon-only inline controls so status and priority labels do not clip inside the row. Health remains display-only. Timeline bars use a translucent primary fill with a primary border, no shadow, and no text inside the bar; the left project list carries the row name. Board cards and Timeline bars navigate like Feature table rows; inline controls stop row navigation while editing.

Show closed features defaults to None, which hides completed or canceled Features; Past week, Past month, Past 3 months, Past 6 months, and All can bring recently or fully closed Features back into the table or Board. A Feature that is closed from the table is available immediately when the active closed-feature window includes now. When the page opens, Integrity waits for shared custom views, local Feature view metadata, remembered active view selection, and the draft table lens before showing rows, so the default unfiltered table is not shown as a temporary intermediate state. The Clear action removes the current draft filters. On built-in views and temporary new views, Save opens view metadata fields before creating a custom Feature view. On an existing saved custom view, filter/display changes show generic Unsaved view changes / Save changes actions beside the right-aligned secondary-row filter/display controls, active filters, and Display options footer only when the current mode has actionable unsaved changes or the dirty state is shared. A Timeline-only draft remains browser-local and quiet while the user is on Board/List, but if the user then changes Board and clicks Save changes, the save publishes the full current saved-view lens, including the Board and Timeline drafts, while preserving the saved view's opening mode. Switching only between List, Board, and Timeline is a personal viewing preference and does not mark the saved view as unsaved.

The built-in All Features view has shared display defaults. In its Display options menu, the footer names the active presentation mode: Reset List / Set List Default for Everyone, Reset Board / Set Board Default for Everyone, or Reset Timeline / Set Timeline Default for Everyone. Those actions restore or save only the active List, Board, or Timeline display lens as the workspace default, including group/sub-group order, hidden group/sub-group values, and the show-empty-groups preference where that mode supports them. A Board default update changes Board columns, card properties, and Board-only visibility settings without rewriting List-only table column defaults. A Timeline default update changes Timeline grouping, ordering, granularity, left-list fields, and Timeline-only visibility settings without rewriting List or Board defaults. Shared default changes apply to other open All Features sessions after realtime/refetch, while active filter chips stay private. These actions do not appear in custom Feature views; saved custom views use Save changes and Discard for lens changes instead.

Adding a Feature view creates a temporary local badge. The view metadata panel lets you set the name, description, and badge color with the shared Integrity color picker. Title and color changes preview on the selected badge before Save. Cancelling removes that temporary badge and its local draft, then returns to the exact Feature view that was active before creation with that source view's unsaved lens intact. Save creates a shared workspace view with the current filters, opening presentation mode, grouping, ordering, display fields, Board/Timeline settings, and closed-feature visibility. After a custom view is saved, changing filters or display options marks only the view lens as unsaved; Save changes updates the existing shared view with the current full lens without reopening metadata and preserves the view's existing opening mode, while Discard restores the shared saved lens without changing the mode you are currently using. Other permitted users receive created, edited, recolored, duplicated-and-saved, lens-updated, or deleted custom views after realtime/refetch, but users already viewing the same saved custom view stay in their current List, Board, or Timeline mode.

Right-clicking All Features exposes only Copy link. Right-clicking a custom Feature view exposes Copy link, disabled Favorite, Edit, Duplicate, and Delete. Editing opens the same view metadata panel as New View for name, description, and color; it is not required for routine filter/display saves. Duplicating copies the filter/display lens into a fresh unnamed draft without copying the name, description, or color, and that duplicate becomes shared only after it is saved. Deleting asks for confirmation; in the shared saved-view model, deletion removes the workspace view for other permitted users after realtime/refetch.

Feature detail page

Selecting a Feature from the dedicated table opens a detail page at /workspace/[workspaceId]/features/[featureSlug]. This page uses the shared Spec-Driven Development page shell: a compact breadcrumb/action bar, a centered content column, a collapsible properties panel, and Feature detail badges for Overview, Activity, and Issues. It intentionally does not show the full lifecycle evidence tabs in the dedicated detail page.

The page header shows the Feature icon, title, and short description. Editable users can update the title, short description, icon color, and supported execution properties from compact controls, while read-only users see display-safe values. The Dates row exposes both Start date and Target date from the planning roadmap date window; each editable date control opens the same resolution picker used by the Feature table.

Feature properties include status, priority, lead, members, owning Teams, dates, Initiative membership, Labels, and Blocked by / Blocking dependencies. Non-empty dependency groups also appear in the main detail content before Resources. Accessible dependencies link to their stable Feature route; private and unavailable references use safe non-routing labels and remain removable when policy permits. Labels use the workspace's Feature-specific vocabulary and can be changed by people who may edit Feature metadata. Workspace admins manage Feature label groups, names, colors, archive state, and deletion from Workspace Settings -> Features -> Labels. The settings History action opens Workspace Settings -> Audit log filtered to Feature-label configuration; assigning or removing labels on a Feature remains Feature Activity. Linked Initiatives, Team values, and dependency Features show display-safe current object colors when the viewer can access them. Slack may appear disabled.

The Phases section lets permitted editors create, date, reorder, describe, link to, and delete Feature-owned stages. Current/completed/upcoming state and progress are derived from accessible assigned Issues. Each expanded Phase description is a collaborative primary document inherited from the Feature, not an independently routed or shared Resource. See Manage Feature Phases.

Creating a Feature produces one Activity row. Initial status, priority, lead, Teams, members, labels, dates, Initiative membership, and any future create-time dependency relationships are retained together in its versioned creation snapshot; they do not appear as changes that happened before or immediately after creation. An already-existing dependency counterpart may still record that it gained the relationship. Later edits remain individual Activity rows.

The Issues badge renders the shared Issue table scoped to the current Feature's active primary Issue links. The Issue create action opens the existing Issue create flow with the current Feature preselected. The right drawer includes an issue-derived Progress card with Scope, Completed, Assignees, and Labels based on the same visible linked Issues as the table. Initiative rollups, multi-Feature Issue links, sub-issues, and roadmap progress charts remain separate future capabilities.

The Feature add-property affordance is limited to dependency relationships. It can add Blocked by or Blocking links to other Features; it does not create arbitrary custom fields. The same actions are available from the Feature row's More properties -> Dependencies submenu. Completed Features remain eligible targets, while archived, deleted, duplicate, inverse, and cycle-forming choices are excluded or disabled. Existing dependency rows can change direction or be removed from their ellipsis menu. Changes keep the current value visible and dim only the affected control until the server confirms success.

Dependency add, reverse, and remove actions create endpoint-relative Activity for both Features. They do not change Feature status, dates, health, progress, notifications, inbox, unread state, or email delivery.

The content body includes the Feature's primary collaborative narrative and a Resources row for supporting links, private attachments, and collaborative Documents. Resources inherit Feature access; supporting Documents have their own stable nested routes and can appear in search and Favorites when accessible. Lifecycle evidence such as Spec, Plan, Tasks, Build Notes, Proposals, Activity, and Lineage remains available through the existing Spec-Driven Development lifecycle views.

Archive Features

Archived is a workflow status for completed historical evidence, not deletion. Open Archived features from the workspace Features utility menu and select the Archived tab to see every accessible Feature with that status. Archived rows do not open the unavailable Feature detail page. If you can edit Feature metadata, change the row's Status to any active workflow status to move it out of the archive; the Feature's content, relationships, and history remain intact.

The adjacent Deleted tab is different: deletion starts a 30-day recoverable removal lifecycle and does not change the Feature's workflow status.

Delete and restore Features

People who can edit Feature metadata can delete one Feature from its row or detail menu, or delete several selected Features from the table. Deletion removes the Feature from operational tables, selectors, rollups, exports, reminders, and other active work without changing its workflow status or relationships. The confirmation dialog names the destructive action before it runs.

Deleted Features remain recoverable for 30 days. Open Recently deleted from the workspace Features utility menu for the workspace-wide list, or open Deleted Features in a Team archive for a Team-scoped list. A multi-Team Feature appears once in each associated Team archive that you can access. Team recovery also requires Feature edit access; workspace viewers cannot use it.

Opening an accessible deleted Feature keeps its canonical URL and shows authorized content read-only. Restore returns the same Feature, workflow status, document, links, memberships, labels, and planning relationships to active work. Workspace owners and admins can instead choose Permanently delete after a second destructive confirmation.

Permanent deletion cannot be undone. Integrity keeps only a generic identity tombstone for route and audit safety, removes authored/generated content and active relationships, and shows unavailable references without the former Feature title. Permanent tombstones do not retain a workspace workflow status, so later status changes cannot affect the retention process. Lifecycle transitions appear in Feature Activity, but they do not send Inbox or email notifications.

Planning ownership

Integrity owns Feature execution state that affects Spec-Driven Development behavior: status, priority, lead, members, owning Teams, Planning dates, relationships, summary text, and object icon color. Features can have one or more owning Teams; the first selected Team is the primary compatibility Team. Team ownership is organizational context, not access control, and assigning a Team does not grant Spec-Driven Development, Source Library, artefact, baseline, review, trace, or workspace permissions. Private Team associations stay hidden from viewers who cannot access that Team. Planning dates can be day-, month-, quarter-, half-year-, or year-level values and are stored as planning roadmap date windows. Notion remains the planning and backlog hub for tracker priority, personal ownership, external due dates, and the question of what to work on next. Integrity does not mirror Notion priority, owner, or due-date fields into hidden app truth.

Relationship to requirements

Features can explain and link to requirements work, but they do not become requirements. Controlled requirements, artefacts, traceability links, reviews, approvals, and baselines remain in Source Library and Requirements Management surfaces.

Related