Self-Healing PRs, MCP Time Approval, and Preview Improvements

Six areas in this update: pull requests self-heal on CI failures, MCP-tracked time goes through an approval workflow, issues can be copied as an implementation prompt, runners support engine selection and branch picking, and Preview Environments get an address bar, status indicators, reset, and a dashboard.

Self-Healing PRs

When a pull request's CI pipeline fails, Spedy now automatically starts a coding agent to fix the issue — no manual intervention needed.

How it works

1. A runner job completes and opens a pull request
2. The PR's CI pipeline fails (tests, lint, build)
3. Spedy detects the transition to "Failed" and starts a new runner job
4. The agent works on the same branch, reads the failed checks, fixes the issue, and pushes the fix
5. The PR re-runs its checks automatically

Limits

• Up to 2 automatic repair attempts per PR within 24 hours — preventing infinite loops
• Only for PRs with a linked ticket and a runner team that has self-healing enabled
• The agent doesn't create a new PR — it pushes to the existing branch

MCP Time Tracking: Approval Workflow

Time stopped by AI agents via MCP tools (e.g. timers_stop) no longer books directly. Instead, entries are created as drafts with a "Pending" status and must be approved by a human.

What changes

• MCP-tracked entries do not appear in time lists, budgets, or MOCO sync until approved
• New Time → Approvals page with an inbox of all pending drafts
• Dashboard card and sidebar badge show the number of waiting approvals

Approve, adjust, or discard

Under Time → Approvals, you can for each draft:

• Approve — accept the suggested duration and book the entry
• Adjust + Approve — change the duration before approving (e.g. from 45 to 30 minutes)
• Approve all — approve all pending drafts at once
• Discard — delete the draft without booking it

MCP time factor

Under Settings → Time Tracking, there's a new setting: MCP time factor (default: 1.0, range: 1–10). This factor multiplies agent minutes before the draft is created. Example: A factor of 2.0 means 30 minutes of agent work appear as 60 minutes in the draft.

The original unfactored value is preserved on the entry and visible in the approval view.

Copy issues as implementation prompt

In the Issues list view, you can now copy selected issues to the clipboard as structured text.

1. Select one or more issues using the checkboxes
2. Click Copy in the bulk action toolbar
3. The issues are copied as a numbered list with ticket ID, title, and link

The result works directly as input for AI tools or as a task list for manual work.

Runners: per-agent engine selection

Previously, the provider (Claude or Codex) was automatically inferred from the selected model. Now there's an explicit Engine selector per pipeline stage and per agent.

What changes

• New Engine dropdown next to the model selection in pipeline stages and agent configurations
• Choose between Claude and OpenAI (Codex) — the model dropdown then shows only matching models
• The GPT model list has been cleaned up: GPT-5 Codex, GPT-5, and GPT-5 Mini

The engine setting takes priority over model inference. A job still runs on a single provider — a Claude orchestrator can only spawn Claude subagents.

Runners: branch selection on start

When starting a runner job, you can now choose which branch the agent should work on.

• New branch — pick a base branch to create a fresh feature branch from
• Existing branch/PR — continue work on an existing branch or pull request

The picker shows the repo's default branch plus all branches and PRs linked to the ticket. Ticket-referencing branches are shown first.

Preview: address bar and loading indicator

The preview view in a ticket now behaves like a browser: when navigating within a running preview, a thin progress bar and an address bar spinner appear — instead of the full boot overlay. The address bar shows the current URL and supports navigation via Enter or the refresh button.

The boot overlay now only appears for genuine container states (cold boot, stopping, error).

Preview: stop while booting and status indicator

Stop while booting

You can now stop a preview at any time — even while it's still starting up. Previously, you had to wait until the preview was fully running. The stop button is available in the boot overlay and the toolbar.

Status indicator on the ticket

The ticket header now shows a colored dot next to the preview link:

• Green — preview is running
• Amber — preview is starting
• Red — preview is degraded

This lets you see a preview's status without opening it.

Preview: running previews at a glance

Two new surfaces show all running previews across your organization:

• Dashboard card — the work dashboard shows a card with all running previews. From there you can jump to a preview or stop it directly.
• Board header — a chip in the board header shows the number of running previews on that board. Click opens a popover with details.

Both surfaces hide automatically when no previews are running.

Preview: reset

The new Reset button in the preview toolbar clears the cloned code and rebuilds the preview from the repo's current default branch. This is useful when:

• The preview is stuck on a stale branch
• A broken build has made the container unusable
• You need a clean start from the repo's current state

After reset, the preview reboots automatically — you don't need to start it manually.