What's new in Bugspot: July 2026

The headline this month is entry plans: any entry can now carry a versioned implementation plan that a human reviews and approves before the code gets written. Alongside it, Bugspot got real full-text search over entries, milestone status updates with a health signal, and a noticeably sharper entries list.

Review the plan, not just the pull request

You can now attach an implementation plan to any Bugspot entry — the proposed approach, written out — and review it before anyone starts building. The plan lives on the entry, right where the work is tracked.

The loop is deliberately small:

• A plan is created together with its first version, so there’s no empty draft sitting around.
• The reviewer reads the current version and either requests a revision with feedback, or approves it. Feedback produces the next version, which goes back for review. Every version stays on one timeline, and nothing rewrites a version you already read.
• Approving records who approved which version, and when — a durable answer to “was this signed off?”
• Only the entry’s assignee can approve or request a revision. The person accountable for the work governs its plan.
• Approval isn’t a one-way door: the assignee can unapprove with a required reason, which reopens the plan for another round. Once the plan is marked implemented, it locks for good.

Once a plan has been implemented, it also carries the outcome of the run — when it ran, which model ran it, and what it cost — so the record of “what we agreed to build” and “what actually built it” sit on the same entry.

Every step is a first-class API operation, which means an AI agent, a shell script, or a person in the browser can all drive the same loop. In the terminal, that’s the bugspot plans command group in the CLI. In the app, it’s a panel on the entry that updates live as versions and reviews land.

Why this exists: when a team uses AI coding tools, the approach is usually invisible until a pull request appears — only the output ever gets reviewed. Entry plans move that review to the point where changing your mind is still cheap.

Find any entry by typing part of it

The search box in the entries toolbar is now wired up. Type into it and Bugspot searches across every entry in your company — by key, title, and description — not just the rows currently loaded on screen. It’s typo-tolerant, so a near-miss still finds the entry.

Search is a lens on the list you’re already looking at, not a separate destination. Whatever filters you have active still apply: filter to Stories assigned to you, then type, and you’re searching inside that set. Clear the filters and the same query searches everything.

The [[ entry-reference typeahead in the editor uses the same search, so picking an entry to link now reaches your whole tracker instead of a single preloaded page.

Say how a milestone is actually going

You can now post status updates on a milestone — a short written update with a health signal: On track, At risk, or Off track. Write them, edit them, delete them; the milestone shows its update history, and the latest health appears as a coloured dot on milestone rows so a list of milestones tells you where the trouble is at a glance.

Health is deliberately separate from a milestone’s lifecycle state: a milestone that’s still active can be off track, and one that’s nearly done can be at risk. The progress rollup tells you how much is finished; the status update tells you what the person running it actually thinks. Status updates are available from the terminal too, via the bugspot CLI.

If you’re deciding whether the thing you’re tracking is a milestone in the first place, milestone vs release covers where the line sits.

A sharper entries list

Several changes landed that make the list better at answering narrow questions:

• Reporter is a first-class field. Filter by who reported an entry and add a sortable Reporter column to the list — which, with the grouping that was already there, means you can now slice the list by reporter every way you can slice it by assignee.
• Filter for what’s missing. “Unassigned”, “No milestone”, and “None” are now real filter options — so you can pull up every entry with no assignee, no priority, or no milestone instead of eyeballing the gaps. Saved filters keep them, and the CLI accepts a plain none on the matching filter flags.
• Group in the direction you want. Group-by got a direction toggle, so grouped lists can run A→Z or Z→A without re-sorting everything else.
• The whole list scrolls properly on milestone and project pages, and the filter controls are fully keyboard-operable.

The little things

• Copy an entry’s key straight from its detail header with one click.
• See status inside Linked Entries, plus an optional “Hide done entries” toggle so finished children stop crowding out live work.
• Bare entry keys in comments now render as live pills — mention BS-142 in a comment and it links itself, the way descriptions already did.
• Clear a priority. An entry’s priority can be set back to none instead of being stuck once set.
• Keep your edits. A teammate’s update arriving mid-edit no longer overwrites the description you’re typing.
• Trust the timestamps. Events that just happened no longer briefly read as happening in the future.
• Know when a saved filter breaks — it now says so instead of quietly returning the wrong list.
• Reorder entry resolutions — reordering now works for resolutions the same way it does for the other configurable attributes.
• Clearer errors when rich text can’t be converted, naming what was dropped rather than failing with a generic message.

---

That’s July. The through-line, if there is one: Bugspot is getting better at holding the decisions around work — the plan that was approved, the health someone reported, the reason a plan was reopened — not just the work items themselves.

Bugspot is in public beta — open the app and try entry plans on something you’re about to build. If you’re catching up, June’s roundup covers milestones, entry links, and the CLI.