# Roadmap

**iKAgent → Roadmap** shows published plans as a flow of phases. Phases that wait on each other run left to right; phases with the same dependencies sit in one column and run in parallel.

## Two groups

- **Your workspace**: plans published by the teams you belong to. Members of other teams do not see them.
- **iKanban**: what we are building in the agent workspace. Every signed-in user sees these.

Newest plan first in each group.

## What a phase shows

Its name, its status and the percent of its tasks that are done. No task titles, keys, people or links.

- **Done**: every task in the phase is done.
- **In progress**: a task has started or is done.
- **Waiting**: no task has started. A phase that waits on an unfinished phase says *waiting on* that phase.
- Cancelled tasks do not count.

## Who publishes a plan

A plan is a top-level Feature; its child Features are the phases.

- Any member of the team can publish one of the team's top-level Features, on a workspace with an active subscription. A child Feature cannot be published.
- Only iKanban staff publish the **iKanban** plans.
- Coding agents publish their plan before multi-step work and then start at once, without waiting for a confirmation. The `ikanban-roadmap` skill in your repository's `.iKanban/` folder tells them how. Agent setup writes it for you.

Plan and phase names are visible to every member of the team. Never put a secret, an internal link or customer data in them.

## The Roadmap follows the plan file

An agent keeps its plan as one JSON file in your repository. The file opts in with a top-level `roadmap` block (`team`, `project`, and the `plan_id` the first sync writes). The agent changes only that file; the sync makes the Roadmap match it.

- `npx ikanban roadmap sync <plan.json>` publishes the plan and applies every change. `--check` changes nothing and exits 1 when the Roadmap differs.
- `npx ikanban hooks install` (once per repository) adds a git **pre-push** hook and an agent hook for Claude Code, Gemini CLI and Copilot CLI. The plan reaches the Roadmap on each agent write and each push, from any git host. No CI is needed.
- MCP: `sync_roadmap_plan` does the same in one call, with `dry_run` to see differences.

| Gate | What happens |
|---|---|
| Who may sync | a member of the team, on a workspace with an active subscription. The **iKanban** plans: iKanban staff only |
| Matching | each phase and task has a key in the file (`F2`, `F2-T3`). A key is found again on every sync, so nothing is created twice, even after a phase is renamed on the Roadmap |
| New tasks | one per task in the file, titled `<key>: <text>`, in the `project` of the block, assigned to the person who runs the sync (never to the AI Agent). They count toward the team's issue limit |
| A task leaves the file | it is cancelled; the Roadmap leaves cancelled tasks out |
| A phase leaves the file | deleted when only its plan tasks were under it; otherwise it stays and the sync warns |
| Other tasks under a phase | never changed. When they hold a phase back from the status in the file, the sync warns |
| Refused, nothing changed | a plan or phase name with a link or email address, a key used twice, a dependency outside the plan or in a cycle, more than 1,000 tasks |
| No key or no network | the command says why and changes nothing. From a hook it never blocks the push or the agent |
| When it shows | at once; at most 60 seconds on a busy server |

## The pencil and the comment

- **Pencil**: renames a phase. Members of the team see it on their workspace plans; iKanban plans can be renamed only by iKanban staff.
- **Comment**: feedback for the agent working on the phase. The number next to it counts your threads on that phase.

## Feedback and the agent's questions

1. Open the comment on a phase, write what to consider or correct, and select **Send**.
2. The agent working on the phase gets it. The agent may ask you a question; it shows in the thread and in your inbox.
3. Write your answer in the thread and select **Reply**. It goes back to the same agent session.

Each thread shows a status: **Queued** (waiting for the agent), **Delivered**, **Agent asked** or **Answered**.

| Gate | What happens |
|---|---|
| Who may send | any signed-in user who sees the phase |
| Who sees a thread | only you; iKanban superadmins see every thread on a phase; other customers see none |
| Length | feedback and replies up to 2,000 characters; an agent's question up to 500 |
| Rate limit | 10 messages an hour per person, feedback and replies together; more answers *try again later* |
| Delivery waits | while the agent's run is going, your feedback waits and goes in when the run finishes. With no agent session on the phase yet, it waits for the next run on the phase |
| Advisory only | the agent gets your text marked as customer feedback to consider, never as instructions. It does not run commands, add links or change scope because of it. Any code change still goes through pull request review |
| Laptop runners only | feedback goes only to a laptop runner session, and only once iKanban turns this on, after a desktop app release carries the feedback-turn safety below. Until then it waits. A GitHub session never gets it: a GitHub run has no feedback-turn safety, and a comment would put your text on the repository. On a phase with only GitHub sessions, it waits for the next laptop run |
| Safety on that turn | the agent's turn that carries feedback asks a person before a push or network call, even when the runner is set to *Allow everything*, and never pushes to main or merges |
| What the agent learns | your words only, never your name or email |
| The agent's questions | keys, links and email addresses are removed before you see them, and each question is copied to iKanban superadmins |

## Slack posts

A workspace can post Roadmap changes to Slack. It is off by default.

- **Turn it on**: Settings → Connections → Slack → **Post iKanban build updates**. Only workspace owners and admins can change it.
- **Where it posts**: the **Default updates channel** in the same dialog. With no channel, nothing is posted.
- **When it posts**: once when a phase changes status (waiting, in progress, done), within about 2 minutes. A phase that does not change is never posted again. Turning the setting on does not post the current status of each phase.
- **What it posts**: one line per change, for example *Checkout redesign: F2 Settings page is now done*, and the plan's flow as text.
- **Which plans**: the iKanban plans and your workspace's published plans. The channel sees plan and phase names of every team in the workspace.

## The count in the sidebar

The number next to **Roadmap** is how many plans changed since you last opened the page: a new plan, a renamed phase, or a task that moved. Opening Roadmap clears it. The count follows your account, so it is the same on every device.