Initiatives

Beta

An Initiative groups related Features so a workspace can inspect sequencing, scope, and roadmap state together. Initiatives are planning containers; they do not replace the Feature lifecycle packet.

Open Spec-Driven Development -> Initiatives to see the full-width Initiative table.

What an Initiative is for

Labels are available as an Initiative filter, display property, and grouping field. Persisted table-control state stores label ids rather than copied names or colors.

Use an Initiative for work such as:

• a product area or delivery theme
• a release slice
• a dogfooding effort
• a dependency cluster that needs one shared explanation

The Initiative table shows current roadmap containers and summary context such as owner, target timing, completed-over-total Feature counts, health, and active Feature counts. Non-empty Blocked by and Blocking badges sit immediately after each Initiative name; hover them for a bounded display-safe preview. The table has Active, Planned, and Completed status badges; terminal shipped and archived Initiatives appear as Completed in Planning.

Right-click any Initiative row and open More properties -> Rename to change its name in place. The reusable Initiative row menu follows the table into its main, workspace-view, and Team-view contexts. The command selects the current name and focuses Rename first, so typing and pressing Enter is enough to save; arrow keys move between Rename and Cancel, and Escape closes the command. Rename appears only after Integrity confirms metadata edit capability, updates visible Initiative readers optimistically, and preserves the Initiative's stable URL slug.

Initiative filters narrow the current table in the browser. Supported filters include Owner, Creator, Team, Labels, Health, and Dates. Display grouping can shape the rendered sections by Owner, Team, or Labels, while Health grouping remains disabled until that product model exists. An Initiative with several labels appears in every matching label group, while unlabeled Initiatives appear under No labels. When grouping is active, the Grouping row exposes a settings icon that opens an in-menu ordering view with a back button, vertical-only drag ordering, static owner avatars or Team icons, row-body drag handles, and eye toggles for whether each group is visible in the table. Show empty groups appears only when grouping is selected; when it is off, groups with no visible Initiatives in the current scope are omitted. Display ordering can sort by Name, Manual, Health updated, Updated, 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. The status badges are fixed table scopes, not user-created saved views, so the Initiative table does not show an add-view button beside them.

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 while keeping the filter bar available for changes. 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.

Row selection is session-only. Select visible Initiative rows with the row checkboxes, use Shift-click to select a visible range, and open Actions from the floating selection bar for supported existing edits such as Status and Owner. Selection follows the visible table scope and is not stored in browser-local table drafts, shared defaults, saved views, or URLs.

Initiative filter, grouping, group order, hidden group values, show-empty-groups preference, ordering, and display-column drafts are remembered in the current browser per workspace, user, and fixed status badge. Active, Planned, and Completed can each restore their own draft table lens, including visible columns. Team filters and group lenses store stable accessible Team IDs only; private or no-longer-accessible Team values hydrate as generic private/unavailable states or are dropped instead of exposing labels. The badges remain fixed table scopes, not user-created saved views. When the page opens, Integrity waits for that local draft lens before showing rows, so users do not briefly see the default unfiltered table before their browser-local scope restores.

Each fixed Initiative scope can also have a shared display default. In the Display options menu, Reset to default restores that scope's shared default display lens, while Set Default for Everyone lets authorized users save the current grouping, group order, hidden group values, show-empty-groups preference, ordering, and display properties as the workspace default for that specific scope. Shared default changes apply to other open tables for that same scope after realtime/refetch, while active filter chips stay private. Setting the default for Active does not change Planned or Completed.

Initiative detail page

Selecting an Initiative from the dedicated table opens a detail page at /workspace/[workspaceId]/initiatives/[initiativeSlug]. The page uses the same Spec-Driven Development shell as Feature detail pages: a compact breadcrumb/action bar, a stable route, a main planning surface, and a collapsible properties panel with Initiative metadata.

Users with workspace edit access can update the Initiative name, short description, icon color, Status, Owner, Team, and Target date from the detail page. These are quiet inline edits: the changed value appears immediately, and Integrity only shows an error toast if the update fails. Viewers see the same values as plain read-only text and icons without edit menus. If an Initiative is associated with a private Team the viewer cannot access, the planning object remains visible when Spec-Driven Development permits it, but the Team value appears only as a generic private Team reference.

The Initiative name and short description are intentionally constrained. Names must be 2-120 characters. Descriptions are single-line, optional, and limited to 250 characters. Over-limit paste or typing attempts are rejected with inline feedback instead of being truncated and saved.

Initiative V1 properties are deliberately small:

Status and Team use the same compact selector grammar in the Initiative table and properties panel. Planned uses the Target glyph, Active uses CircleChevronUp, and Completed uses CircleCheck. Accessible Team values link to the stable Team route; hidden private Team values do not link. Derived Feature counts and health remain table/model context rather than properties-card rows.

Editable roadmap fields are only presented to users who can save them. Initiative Labels use a separate workspace vocabulary and appear in the properties panel and table controls. People who may edit Initiative metadata can assign existing labels through the shared selector; labels can also filter, group, or appear as a display property in the Initiative table. Workspace admins manage the vocabulary from the Labels card at the bottom of Initiative settings. The settings History action opens Workspace Settings -> Audit log filtered to Initiative-label configuration; assigning or removing labels on an Initiative remains Initiative Activity. The Initiative Properties + and row More properties -> Dependencies submenu can add Blocked by or Blocking links to other Initiatives. Existing dependency rows can be reversed or removed after server confirmation. The add menu remains dependency-specific; Initiative V1 does not support arbitrary custom properties, Slack behavior, phases, or saved views.

The main Initiative canvas has three parts:

• Non-empty Blocked by and Blocking groups appear before Resources, with canonical routes for accessible Initiatives and safe non-routing restricted references.
• Resources lists supporting links, private attachments, and collaborative Documents that inherit Initiative access.
• Summary is the Initiative's primary collaborative narrative document.
• Features embeds the Initiative-scoped Features table with the same display options, grouping, ordering, and display-property grammar as the main Features table. The embedded header keeps the plus action disabled until create-vs-attach behavior is defined.

The embedded Features table uses the same session-only selection behavior as the main Feature table, scoped to the current Initiative. Hidden or filtered-out rows are pruned from selection rather than kept for later actions.

Roadmap graph, Gantt, outline, log, notes, decisions, Health, authored updates, subscriptions, and activity behavior still live in existing or future Planning surfaces until their dedicated work lands.

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

Initiative membership

Features can belong to Initiatives through roadmap membership state. One membership is the Feature's home placement. Additional memberships are references so the same Feature can appear in more than one planning context without becoming duplicate work.

Membership state belongs to Integrity's planning roadmap substrate. Notion remains the backlog and priority planning hub; it does not become the hidden source of truth for app roadmap relationships.

Notion also remains the source for tracker priority, personal planning ownership, and external planning dates. Integrity Initiative Owner and Target date are planning execution fields for in-product roadmap behavior; the Planning target-date picker supports day, month, quarter, half-year, and year values.

Roadmap views

Opening an Initiative from roadmap context shows the current planning roadmap views:

The later timeline/Gantt redesign is separate work. The current views are useful for traceable context, but they are not a full scheduling engine.

Related