Plans

A plan is the unit of work an engineer can actually pick up. The initiative above it carries the why; the plan carries the what we are going to do about it. If an initiative is one sentence (add CSV export to the reporting page), a plan is one piece of that work the team can finish and review (build the server endpoint; wire the download button; verify the export format against five real customer files).

There are seven kinds of plan, all backed by the same record but with the affordances that make sense for each kind. An implementation plan carries pull-request fields, a verification plan holds a snapshot of the test cases it covered, a spec plan is mostly a body of writing. The shape is uniform on purpose. A plan's status moves through the same workflow whatever its type, it shows up in the same grid and on the same kanban, and an agent reads and writes them through the same surface. The thing that changes per type is the metadata that actually matters for that kind of work.

If you are coming from Jira, a plan is roughly a Story. If you are coming from Linear, a plan is closer to an Issue under a project than to a sub-task. A plan is meant to be picked up and finished in a sitting or a sprint, not stretched across a quarter; cross-quarter work is what initiatives are for.

How a plan sits in the work model

The initiative is the required parent. Bugs nest underneath any plan they were found under. An implementation plan can link out to a pull request and pick its sandbox profile from the cascade. A verification plan holds a snapshot of the test cases it covers. A sprint can pick the plan up for a time-box without owning it.

How it looks in practice

Continuing the worked example.

Sarah's initiative is CSV Export on the Reporting Page. Once the spec was approved, the agent broke the work into three plans in a single chat turn. Sarah edited a couple of fields and accepted them.

The implementation plans carry the parts of an engineer's actual work.

The verification plan looks different.

Now look at how the plans connect.

Upward. All three plans live under the CSV Export on the Reporting Page initiative. The plans inherit the initiative's project (Insights), and the project's default sandbox profile (Analytics-Node20) is what runs every flow launched from one of them, unless the plan overrides it.

Downward. The CSV server endpoint plan has one bug nested under it: Export timeout on large date ranges, found while testing. The bug rolls up to the same initiative its parent plan does. The CSV format verification plan has a snapshot of five linked test cases; each snapshot records the test case's last-seen status and timestamp, frozen until the plan records new results.

Sideways. All three plans are picked up by Sprint 24 (the Analytics team's current sprint). The two implementation plans have a pull request linked; the platform finds the PR automatically when Priya and Tom push their feat/csv-export-* branches because the branch field on each plan matches. The plans appear on the sprint's mixed-entity backlog alongside the bug, in the order the team dragged them.

Rollups at a glance. On the initiative, Sarah sees: 3 plans, 1 complete (33% progress). On the sprint, the team sees the three plans and the bug all on one board, mapped onto four columns (todo, in-progress, blocked, done).

Seven types of plan

Every plan is one of seven types. The type is picked when you create the plan and can be changed later; the affordances on the page adjust to the type without losing data on the fields that are not relevant.

The implementation plan is the most common type day to day; the verification plan is the most distinctive in shape. The other five share the same record with a slightly different emphasis. Changing a plan's type is non-destructive: switching an implementation plan to chore hides the PR and branch fields but keeps the data, so you can change your mind without losing anything.

The reason there are seven and not one is that an implementation plan and a verification plan have genuinely different shapes. An engineer working an implementation plan wants the PR in the sidebar; a tester working a verification plan wants the linked test cases. Forcing both into one shape would mean one of them carries fields they do not use. The type picker lets the page surface only what is relevant for the work in front of you.

Statuses

Five statuses, backed by a real workflow with the transitions enforced server-side.

The conventional path is draft → in-progress → complete. Blocked is the side state work returns from to in-progress once the dependency clears. Cancelled is the terminal state for descoped work; it can be reopened to draft if the team changes its mind.

Your admin can customize the plan workflow at Platform → Workflows, including the labels, the colors, the transitions, and which statuses are creatable (some teams hide Complete from the create-status picker so a new plan always starts in Draft). A transition the workflow does not allow rejects on the server; the plan stays in its current status and the UI shows the rejected move as a toast.

Soft-delete and restore

Soft-delete is a separate concern from status. Open the Plans list and click the Trash toggle to switch to deleted-only mode; the rows there have Restore and Delete permanently in their action menu instead of the usual edit actions. Restoring is one click; the plan flips back to its previous status with every linked record intact.

Hard-delete is only allowed from the trash view (you have to soft-delete first) and is meant for unrecoverable cleanup. The audit log keeps a record of the hard-delete with who performed it and when.

When you create one

The flow is short.

1. Open the initiative the plan belongs under. Plans cannot exist without a parent initiative, so the entry point is always an initiative's Plans tab. (The workspace-wide Plans grid is a list, not a create surface.)
2. Click New plan. A modal opens. Pick the plan type (defaults to Implementation), enter a title, and optionally pick the owner, the assignee, the estimate, and a sprint.
3. Save. The plan lands at status Draft. You can edit the body in the Spec tab and add steps and clarifications inline.

How the agent authors plans

The fastest way to fill an initiative with plans is not the modal. It is to ask the agent.

From the initiative detail page, click Continue in Chat and ask the agent to break this into plans. The agent reads the approved spec body, the open clarifications, and the linked repository in a sandbox; a moment later it writes back a proposed set of plans with type, title, draft body, and where appropriate a tentative estimate. You read the proposal as a whole and approve, edit, or reject inline. The accepted plans land as real plan records under the initiative, tagged AI-authored on the version history.

The agent often catches plans a person would miss. A spec for a new export feature naturally needs an implementation plan for the endpoint, an implementation plan for the button, and a verification plan for the format check; the agent proposes all three on the first turn. It is also good at noticing the chore plans an experienced engineer adds quietly: a research plan on the streaming-CSV library to pick the right one, a chore plan to wire a new dependency through the build pipeline.

The same Chat path works mid-flight, not just at the start. An initiative whose scope grows in week two does not need to roll back through the create modal; you ask the agent in the same chat to add a plan for the audit-log column we just decided to ship, and it writes the new plan to the same initiative. The reviewer accepts and the plan is live.

The agent's writes are auditable. Every field it edits is stamped with editSource: "ai" on the version snapshot; a reviewer reading the version history can tell at a glance which fields were written by a person, which were written by the agent, and which were applied by the platform itself (a system source covers things like the GitHub PR sync). The three-way split keeps the audit trail honest as the team and the agent share editing duties on the same record.

The distinctive parts

The body, the steps, and the Tasks tab

A plan carries a markdown body (the spec) and a separate structured array of steps. They are not the same thing. The body is whatever the author wants the plan to read like; the steps are first-class records with their own status, their own checkable state, and their own progress count.

The Tasks tab is what renders the steps. It appears on the plan only when steps exist, with an inline done / total counter on the tab badge. Most teams let the agent populate steps from the body during plan-create-from-chat; an engineer working a plan can also write them inline on the tab. Editing the body does not regenerate the steps; the two stay independent, on purpose, so a body that gets reworded does not invalidate the tracked progress.

When a flow runs on a plan, the agent checks off steps as it completes them. The Tasks tab updates live, so an engineer watching the plan sees real-time progress without having to read the body diff. A step the agent flags done writes a system source on the version snapshot; a step a person flags done writes a user source.

Owner and assignee

Two related-but-distinct fields. Owner is the freeform display label that defaults to the initiative's owner (so a leader's name floats down to the work in the initiative). Assignee is the structured field for the person actually doing the work; the assignee picker writes a real user reference, surfaces an avatar, and feeds the My work filters on the grid. Most teams use both: owner is the accountable person, assignee is the doer.

Either field is optional. An unassigned plan is fine; it just shows up in the Unassigned bucket on the grid.

Pull-request fields (implementation only)

When an implementation plan has a branch set, the platform watches GitHub for a pull request on that branch. The match happens server-side, on the branch name, the moment the GitHub webhook lands. Once matched, the platform populates the plan's PR fields automatically: number, URL, status (draft / open / merged / closed), opened-at, merged-at. The sidebar renders these as a card with a click-through to the PR on GitHub.

The PR fields are populated by the GitHub integration, not by hand. If the integration is not configured for the project, the branch field becomes informational only; the PR card does not appear and the lifecycle fields stay empty. The plan still works either way. The integration unlocks the auto-sync; nothing else depends on it.

A plan can land more than one PR over its lifetime. A long-running plan that ships in two releases, or one that gets reverted and re-opened, can carry several PRs across its history. The sidebar shows the most recent open or merged PR; the audit log records each PR event in order, so the full trail is reachable through the version history tab.

PR fields are excluded from the plan's version history. They change independently of human edits (GitHub events push them around), and folding them into the version snapshot would create noise on every PR event with no corresponding human action. The version history records what a person or the agent did to the plan; the PR fields are a sidecar.

Linked test cases (verification only)

A verification plan holds a snapshot of the test cases it covers. Each entry records the test case ID, the test case's current status (one of passing, failing, draft, active, or obsolete), and the timestamp of the last recording. The snapshot is frozen between plan-level recordings: if the underlying test case changes status from a different surface, the plan's snapshot does not move until the verifier records a fresh result against the plan.

The snapshot is per-link, not per-test-case. Two verification plans that link the same test case keep independent snapshots; each plan records what that plan's verifier saw on that day. This is how the verification plan stays trustworthy as a record of what was checked.

How a verification plan records results

The verifier works the plan from its Test Cases tab. Each linked test case is a row with a status picker. Picking a status writes a fresh snapshot with the verifier's user, the timestamp, and the new status; the row updates inline. Failures spawn bugs through the found-by relation: the platform offers to file a bug pre-populated with the test case ID, the failure context, and a link back to the verification plan as the source.

The plan's own status moves in response to the recordings. The first non-stale result lifts the plan from Draft to In progress automatically. The move from In progress to Complete is guarded by a check that every linked test case is at status passing (or obsolete, the explicit "skip" status). The platform asks for a confirmation if any are still failing or draft, so a verification plan does not silently roll up as complete on a half-finished test pass.

The verification plan is a real record of what was tested, by whom, when, against what. The version history is the audit trail; the snapshot array is the live state.

Sprint membership

A plan can sit in at most one sprint at a time. The sprint picker on the plan's sidebar writes the sprint ID and the plan's position within that sprint's backlog. Clearing the sprint picker unassigns the plan, which sends it back to the unscheduled list on the workspace-wide grid.

A sprint is team-scoped, so picking a sprint also means picking which team is going to do the work. The platform blocks the assignment if you do not belong to the destination team's sprint; the picker returns a 404-shaped response rather than naming the sprint, so a sprint you cannot see does not leak its existence.

The sandbox profile cascade

A plan can override its sandbox profile, but most do not. The platform resolves the profile for any run launched from a plan in this order: the plan's own override, then the parent initiative's profile, then the parent project's default. The first profile that is set wins. The cascade keeps the common case simple (one profile set on the project flows down to every plan in every initiative) and the override path available when a single plan needs to run on a different image (a verification plan that needs an integration-tests image, an implementation plan that needs an extra runtime).

Estimation

Plans can carry an estimate in hours, in points, or in both. The team's primary estimate unit is set on the team's settings page; that choice decides which unit renders by default on the grid, the kanban card, and the sprint backlog. The other unit is still readable; if a plan has both, the sidebar shows the secondary as a smaller chip below the primary, and the grid shows the secondary in a chip column you can opt into.

The hours and points fields are independent records on the plan. A team migrating from hours to points keeps the old hours value while the new points value gets populated; nothing is overwritten. A team using neither leaves both fields empty, and the sprint capacity rollup tracks them as uncommitted (it does not assume a default). A team using only one unit leaves the other empty and the platform never asks for it.

The sprint capacity rollup uses whichever unit the team has set as primary. A team running on hours rolls up hours; a team running on points rolls up points. Both units are written and read in the same pass server-side, so flipping the team's primary unit changes which roll-up surfaces without re-running any math.

The environment-health blocker banner

A plan that depends on a sandbox can pick up a real-time blocker. If the platform detects that the plan's sandbox profile or one of its environment dependencies has broken (a credential rotated, a service the sandbox needs went down, a migration left the database in a state the plan's flow cannot run against), the plan grows a banner at the top of the detail page above the tab bar. The banner lists each open blocker with a one-line description and a Resolve action.

The banner is denormalized onto the plan record, so it survives a refresh; it is not a transient toast. When a blocker is resolved (or the platform detects the environment has recovered), the row drops out of the banner in real time through the platform's live update stream. A plan with no open blockers has no banner.

The detection itself is automatic. The flag is on for every plan by default; a readiness plan that is deliberately editing infra files and does not want each edit to register as a fresh blocker can suppress the detection on the plan record, set on a per-plan basis.

The action launcher

The page header on every plan carries an action launcher button. Which actions appear depends on the plan's current status and type; the platform ships four core plan actions with sensible status gates.

• Edit plan lets you revise the spec without leaving the page. Available on Draft.
• Revise plan spec is the AI action that folds in any pending Clarifications. Surfaces from the Clarifications tab on draft plans.
• Implement plan kicks off the implementation flow on a sandbox. Available on Draft and In progress.
• Verify plan kicks off the verification flow against the linked test cases. Available on In progress (verification plans).

A workspace admin can bind additional skills to plan statuses through Platform → Workflows; the launcher's set updates as soon as the binding lands. The status-skill registry is what makes this clean: a skill is bound to a (plan, status) pair without editing the plan's record, and rotating skills in or out is a single edit that propagates to every plan in the workspace at that status.

Bulk operations on plans

The workspace-wide Plans grid is where bulk operations happen. Three patterns come up day to day.

Bulk reassignment moves a slice of work from one engineer to another. An engineer leaves, takes a leave, or hands off; the team filters the grid to their open plans, selects all matching, and reassigns to the new owner in one operation. The audit log captures the bulk move with the actor and the timestamp.

Bulk sprint move pulls a set of plans into a sprint after planning. The team filters to Sprint: Unscheduled, Initiative: Q4 launches, selects the plans they are pulling in, and assigns the sprint in the bulk-edit toolbar. Each plan's sprint membership writes through a single edit; the destination sprint's team membership is validated for the actor before any write lands.

Bulk status change marks a finished batch as Complete after a release wrap. Useful at quarter-end when the team is closing out the work that shipped. The platform enforces the workflow on the bulk move, so an invalid transition for a plan in the selection is rejected with a structured failure reason; valid moves go through.

The grid's select-all-matching is the secret weapon here. With a filter applied, the Select all matching checkbox in the toolbar selects every record across every page that matches the filter. The bulk operation acts on the full filtered set, not just the visible page.

The detail page

The plan detail page carries the spec, the related work, and a Chat panel one button away. The tabs across the top:

• Spec holds the title, the body, and the sidebar with the type picker, owner, assignee, estimate, sprint chip, branch, PR card (implementation), and integration links.
• Tasks (conditional) appears when the plan's structured steps array is populated. Each step tracks its own done state with an inline counter on the tab badge.
• Test Cases lists the test cases linked to the plan. On a verification plan this is the primary working surface, with a status picker per row that records a fresh snapshot; on other plan types the tab is still available and shows whichever test cases have been linked for context.
• Bugs lists the bugs found under this plan, organized by status.
• Clarifications (conditional) appears when the plan has at least one open question; the same three-group view (Needs Input, Pending Revision, Incorporated) used on initiatives.
• Documents lists files and documents attached to the plan.
• Sessions lists every chat and flow run that has worked this plan.
• Version History holds the snapshots and the restore controls.
• Workspace (optional) renders the sandbox's workspace browser for the plan, when the feature is enabled.

The page header carries the Continue in Chat button, the status dropdown (with allowed transitions only), the action launcher for running a flow or a skill on the plan, and the kebab for edit, delete, and the rest.

The list

The Plans page is the workspace-wide view. It runs on the shared data grid, so every standard grid affordance works here: column filters, the filter panel, inline editing, bulk edit with select-all-matching, and shareable URL views.

There is also a kanban board view, with one column per status: Draft, In progress, Complete, Blocked, Cancelled. A card dragged between columns triggers the status transition; an invalid transition rejects with a toast and the card snaps back. A card dragged within a column writes a new sort order, so the team can order the column by priority without changing the status. Within a column the ordering is by sort order then most recently updated, so a brand-new plan with no explicit position lands at the top.

Versioning

Plans are versioned. Every meaningful save creates a snapshot of the full record, tagged with who edited it and whether the edit came from a user or the agent. The version history is a tab on the plan detail page.

What a snapshot covers

A snapshot covers the title, body, status, owner, branch, dependencies, steps, clarifications, integration links, sandbox profile, and the rest of the editable spec content. PR fields (number, URL, status, branch, opened-at, merged-at) are excluded, because they are populated by the GitHub integration and change independently of human edits. Plan type, sort order, sprint ID, assignee, and linked test cases are excluded for a different reason: those are positioning and routing fields rather than spec content, and they have their own audit trails through the workflow events.

Every snapshot is stamped with one of three edit sources. User means a person edited the field. AI means the agent wrote it during a chat or a flow. System means the platform itself applied it (a workflow event, a backfill, an integration sync that does write through the snapshot). A reviewer reading the history can tell each of the three apart at a glance, which is what makes the audit trail honest as the team and the agent share editing duties on the same record.

Restoring is non-destructive

Restoring a previous version writes a new version with the old content and a change note like Restored from v8. The old versions stay intact, so you can restore again later if you change your mind, and the audit log records when a restore happened and who triggered it.

Concurrent edits

If you and a teammate save changes at the same time, the system's last-write-wins on the record and both versions are preserved in history. You can read both attempts on the Version History tab and pick which one to restore.

Cross-links