Troubleshooting

Four things go wrong, and each has a first check that finds it faster than reading the board does. Start with the command, not with the dashboard.

A ticket stopped moving

Run these two, in this order, before you look at the dashboard.

npx -y github:macleodlabs-ai/teamflow-plugin status

status prints who is signed in, which organisation is being credited, which project the repository belongs to, which ticket is bound, and what was last sent. Most stopped tickets are visible right there: nothing is bound, or the wrong thing is.

npx -y github:macleodlabs-ai/teamflow-plugin doctor

doctor checks the transport, the account and its credits, the tracker connections and the tracker's own MCP server. It is what finds a credential that expired, an organisation out of credits, and a repository reporting keys to an organisation that has no connection for that tracker.

If both of those look right

The plugin never fails loudly. Every hook exits successfully and prints nothing your editor could read as a refusal, so a fault inside it shows up as tickets that stop advancing rather than as an error. That is deliberate: a reporting bug must never block your work.
Check the key. Tickets are joined by issue key, and the key has to be the one being reported. Jira and Linear keys are upper case, like DAEMON-142 and ENG-42. A GitHub key is the repository's own name and the number, like core#17, with no owner. status prints the key the last report used.
Check the filter. A tracker connection scoped to one team or one project drops everything else silently.

The plugin is out of date

If a session tells you the plugin build on disk is older than the one installed, reload it inside Claude Code:

/reload-plugins

A stale build reports with old rules, which usually looks like a stage that stopped appearing rather than like an error. The session says this once, when it starts, and not on every prompt.

Reporting from a repository in no project

status and doctor both say when the repository you are in belongs to no project, and a session is told once when it starts.

Nothing is lost. The reports land and show under Outside any project, with an option to add the repository to one.

To fix it, add the repository to a project. Its history moves with it, because nothing was ever stamped with a project in the first place. Projects has every case.

Sign-in fails

The command prints the reason, and the two reasons mean opposite things.

"Could not reach" — the service did not answer. Try again. It is a network or an outage, and retrying is the right response.
A message naming the sign-in issuer — the service answered but publishes no sign-in configuration. Retrying will not fix that one; tell us.

Two more things that look like failures and are not:

The browser did not open. The command prints a URL and keeps waiting. Open that URL on the same machine and the command finishes by itself. Do not cancel the command to hand the URL over: it only works while the command is still running.
Your browser is on another machine. Ordinary sign-in redirects to 127.0.0.1, so it cannot work across two machines. Use login --device, which prints a short code in the terminal for you to approve in a browser anywhere.

Nothing appears on the board at all

Reporting from an editor is not what puts a ticket on the board. Your tracker does that.

Is a tracker connected? doctor says.
Has anything ever arrived? The members page shows the last delivery per connection.
On a connection made today, the issues that existed before it come from the import, not from the webhook. Press Backfill now rather than waiting for somebody to touch a ticket.

Connect a tracker has the rest, including what each provider can and cannot import.