Blueprints and milestones

What this accomplishes

The project intelligence in Miton: the blueprint, the milestone tracker, the drift detection, the orientation panel, the suggestion-strip signals, the project plan and the project status.

Track your project plan, milestones, and when the codebase drifts from what you intended. The blueprint, milestone tracker, and drift alerts live in the Project area and suggestion strip.

See also transparency and approvals.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build and an active project containing source code.
• A connected model. Trust the project before allowing file, terminal or Git actions.

The blueprint

The blueprint is the project’s living architecture brief — its title, status (active or shipped), and tracked components — shown in the Project area’s Blueprint tab. It’s generated from the codebase and from prompts you send (see Backend design loop for how a backend prompt populates it), and it’s written back to .miton/blueprint.md so it’s readable outside the app too.

The blueprint is the right shape for understanding what the project is and what it’s made of. It is not a dependency graph or an IDE-style code map; use the file tree or code search to navigate to a specific file.

The milestone tracker

The milestone tracker, in the Project area, shows the project’s milestones and each milestone’s tasks. A milestone has:

• Status — pending, active, blocked, or completed.
• Mode — auto, prompt, or suggest, controlling how much confirmation Miton asks for before advancing it.
• Dependencies — a milestone can list other milestones that must complete first (blockedBy); Miton uses this to know when a blocked milestone is ready to start.
• Tasks — each task has its own status (idle, running, or completed).
• Target date — an optional due date the tracker can flag as overdue.

Milestones aren’t nested (there’s no parent/sub-milestone hierarchy); dependencies between milestones are expressed through blockedBy instead.

The drift detection

Drift detection compares the blueprint and the codebase and raises alerts in the Project area’s Drift tab when they diverge. Each alert has a severity (low, medium, high) and one of these kinds:

• blueprint-stale — the blueprint hasn’t been refreshed against a codebase that has moved on.
• stale-doc / wiki-stale — documentation or wiki pages that no longer match the code they describe.
• untested — a component with no detected test coverage.
• broken-import — an import or reference that no longer resolves.
• config-drift — a package.json script (or similar config) that references a file that no longer exists.
• milestone-overdue — a milestone past its target date.
• cve-found, insecure-headers, malicious-url, supply-chain-risk — security signals surfaced alongside the plan/code drift, not tucked away in a separate panel.

Each alert can be dismissed individually. There are no separate configurable severity thresholds — alerts surface as the underlying rules find them.

The orientation panel integration

The orientation panel is a panel that aggregates signals from every subsystem into one view. The orientation panel shows:

• Active project — the current project, the current branch, the uncommitted files, the active chronicle, the pending approvals.
• Milestones — the current milestone, the task progress, the blocked items.
• Drift count — the number of drift items, the severity breakdown.
• Safety findings — the number of safety findings, the severity breakdown.
• Cost — today’s spend, the budget, the headroom.
• Sub-agents — running, queued, failed, completed recently.
• Worktrees — all worktrees, the ages, the last commits, the cleanup candidates.
• Things you might do next — actionable chips (the actionable bit; the chips answer “what should I do?”).

Sub-agent and Specialist activity shown here is the same data as the Specialists dashboard.

The suggestion-strip signals

The suggestion strip is the row of chips the user sees at the bottom of the chat input. The suggestion strip is populated by signals from every subsystem; the project intelligence contributes three signals:

• Drift chip — surfaces when the drift detection has crossed a threshold. The chip text is “Update the plan to match the code (N drift items)” or similar.
• Milestone chip — surfaces when the current milestone has a blocked task. The chip text is “Resolve the blocked task on the current milestone” or similar.
• Plan chip — surfaces when the user has been working on a task for a long time. The chip text is “Update the milestone tracker (the current task has been in progress for N days)” or similar.

The user can click a chip to see the underlying signal; the user can dismiss the chip with a dismiss action. The dismiss action is a per-chip dismiss; the dismiss is preserved for the session.

The project plan and the project status

The project plan is the source-of-truth for the project. The plan is a markdown file in .miton/plan.md. The plan is read by the agent on every session open; the plan is updated by the user (or by the agent on the user’s behalf).

The project status is the read-only view of the project’s current state. The status is generated from the git history, the milestone tracker, the drift detection, and the agent’s recent activity. The status is shown in the orientation panel.

The project plan and the project status are distinct. The plan is the user’s intent; the status is the project’s reality. The drift detection is the delta between the plan and the status.

What the project intelligence does not cover

The project intelligence does not cover:

• Time tracking — the project intelligence tracks the milestone completion, not the time spent on each task. The user can use a third-party time-tracking tool; the agent can sync the time-tracking tool’s state into the project status.
• Cross-project intelligence — the blueprint, milestones, and drift are all scoped to the active project; there’s no aggregate view across every project you have open.

The project intelligence focuses on the per-project signals the user can act on.

What success looks like

The project intelligence is a set of features that track the user’s project plan, the project’s milestones, and the drift between the plan and the code.

The blueprint is the right shape for understanding the project at a high level — its title, status, and tracked components, generated from the codebase and from backend-design prompts.

The milestone tracker is the right shape for the project plan, with each milestone’s status, mode, dependencies, and tasks.

The drift detection is the right shape for catching the divergence between the plan and the code. The drift detection runs in the background; the drift detection surfaces a signal in the suggestion strip and in the orientation panel.

The orientation panel is the right shape for seeing the project at a glance. The panel aggregates signals from every subsystem; the panel is the user’s “where am I?” view.

Common failures and recovery

• Confirm the correct project and branch are active.
• Check the model connection and the permission request shown in Chat.
• Keep the exact error before retrying; use Code troubleshooting when the failure persists.

Related next action

Open Code troubleshooting for recovery steps and diagnostic paths.