Watching progress

Real-time visibility into what your agent is doing — the kanban board, the Activity feed, and the tab dots. · Recommended

Once your agent is connected and the first AC is claimed, the Track tab on the Development page is where you live. Three surfaces give you visibility at three different zoom levels.

1. The kanban board (mid-zoom)

The board groups acceptance criteria into columns by status:

Cards animate as their status changes, so you see motion as the agent works. If you've planned sprints, the board groups cards into per-sprint sections, with a Foundation section at the top for the scaffolding ACs from your auto-derived Foundation stack.

2. The Activity feed (narrative zoom)

Below the board is a collapsible Activity feed — a chronological, human-readable log of every transition:

Agent vm_a1b2c3 claimed User can sign up with email · 2m ago Agent vm_a1b2c3 submitted for review User can sign up with email · 18m ago You approved User can sign up with email · 19m ago

The feed polls every few seconds (and on demand via its refresh button). When new events arrive while it's collapsed, an N new badge appears. Every row names the actor (You, Agent, CI, System), so it doubles as an audit trail.

Use the feed to:

• Follow one agent's session end to end.
• Spot blocked work — blocked events stand out in the feed.
• Watch for stalls — no new events for 5+ minutes during an active run usually means your agent has crashed or lost connection.

3. The tab status dots (high zoom)

The Development page's three tabs — Plan, Hand off, Track — each carry a small status dot (grey → amber pulsing → green, or red on failure). They're your at-a-glance "is this still set up right?" reminder. If your API key gets revoked or your spec is reset, the relevant dot flips back from green.

Reviewing and approving

When an agent submits an AC it lands in In Review. Approving is your job (or your CI's) — agents can't approve their own work. For each item:

1. Read the diff the agent submitted (a git SHA and diff URL are required on every submission).
2. Approve → the card moves to Passed and the next AC in the chain becomes claimable.
3. Send back → the card lands in Failed; re-open it and the agent picks it up on its next loop.

💡 Tip: Review in batches every 5–10 minutes, not after every single AC. The agent keeps moving as long as it has claimable work, and you avoid constant context-switching.

Tips for unattended runs

VibeMap's MCP loop is built to run for an hour or more without supervision:

• Check in every 5–10 minutes, approve in batches.
• Use the sprint Gantt totals as a rate gauge — the passed/total count updates live.
• Watch the Backlog. If ACs land in Backlog instead of planned sprints, the planner likely mismatched some slugs — re-plan, or drag them manually.

⚡ Power user: There's no Pause/Resume button because the agent runs in your IDE, not in VibeMap. To pause, tell your agent to stop or close the IDE; to resume, re-issue the "get next ready and implement" instruction — claims persist. For a hard stop, revoke the API key: the next MCP call fails auth and the agent halts cleanly.

↔ The traditional way

Traditionally, "how's it going?" is a standup question, a Slack ping, or a Jira board someone has to remember to update. Here the board is the work: your agent moves its own cards and leaves its own notes as it goes, so progress is something you glance at, not something you chase.

What's next

• Something not moving? → 11.4 Troubleshooting
• Day-to-day kanban workflow → Kanban tracker (developer docs)
• Detect spec drift as the code evolves → 12.2 Drift detection