Intelliboard

Torna este o sprint ATIVO do board — os demais ativos viram 'done' (no máximo 1 ativo por board). Num board compartilhado isso muda o sprint ativo para TODOS os membros e seus agentes. AÇÃO SENSÍVEL: chame primeiro com `dryRun:true` para ver o diff (willActivate/willDeactivate + quantos cards abertos cada sprint a encerrar tem). SEM `force`, a ativação é RECUSADA (409) se algum sprint que seria encerrado ainda tiver cards não-concluídos — revise o dryRun e, se for intencional, chame com `force:true`.

ACRESCENTA uma correção datada ao executionReport de um card. O texto original NUNCA é alterado — a correção fica ao lado dele, com data, autor e método de verificação. Use quando descobrir um erro num relatório já registrado (seu ou de outra sessão): auditoria com erro fixado é pior que auditoria com a correção registrada. Não serve para editar o relatório 'direito' — o histórico não se reescreve.

Bloqueia explicitamente um card e para heartbeat local.

Verifica no npm se há uma versão mais nova do intelliboard-mcp (ignora o cache de 24h). Retorna a versão atual, a última publicada, se há atualização e o comando para atualizar.

Pega o card indicado, trava por assignee e move para 'doing' — o mesmo claim atômico do get_next_task, mas no card que VOCÊ escolheu, sem reordenar o board. Devolve o mesmo briefing (project_context, recent_decisions, git, validação). RECUSA: card já pego por outro agente (409), card bloqueado, card já concluído, e card com dependências não-concluídas (a ordem declarada no board vale igual aqui). Se o card JÁ é seu, readota o claim sem perder o baseline — é o caminho de recuperação depois de um restart do MCP. Para varrer o backlog na ordem do board, continue usando get_next_task.

Faz APENAS commit local das mudanças do card — NUNCA push, NUNCA PR. Antes de commitar, garante a branch correta: se o repo estiver numa branch protegida (main/master), cria/troca para uma branch do card ({type}/slug, onde {type} vem do prefixo [tipo] do título). Estageia só arquivos rastreados (git add -u). COMMIT É OPCIONAL: commit="off" recusa. Nos demais modos, a tool faz um preflight e exige aprovação local separada para git_branch e git_commit. Confirmação no chat NÃO autoriza execução; o usuário decide no terminal. A message deve seguir Conventional Commits (ver commit_convention), usando o [tipo] do título como prefixo.

Conclui um card movendo-o para 'done'. EXIGE comprovante local vinculado ao fingerprint atual; sem ele devolve ticket + comandos exatos para execução pela autorização nativa do agente. Código alterado ou validação falha BLOQUEIAM a conclusão. IMPORTANTE: o executionReport é OBRIGATÓRIO e deve ser detalhado — ele é salvo no campo dedicado execution_report do card e fica visível na aba RELATÓRIO do frontend para auditoria futura.

Cria um board na organização efetiva (select da sessão > vínculo do workspace > config legada > app). O backend já cria as 3 colunas essenciais (Planejamento/Em andamento/Concluído). Recusa nome DUPLICADO na org — o board é resolvido por ID no vínculo e por nome em selects/config legada. Respeita o teto de boards da org (erro claro no limite). Opção select=true passa a operar neste board NESTA sessão (equivale a select_board).

Cria um card a partir de um relato/task. ANTES, LEIA o código relevante para entender a causa real. Descrição em markdown com Problema, Comportamento atual vs Esperado, Causa raiz (arquivo:linha), Como reproduzir, e Critérios de aceite. columnId vem de list_columns. PREFIXE o título com o tipo Conventional Commits em colchetes, ex.: `[fix] corrige expiração do convite`, `[feat] ...`, `[hotfix] ...`, `[chore] ...`, `[docs] ...`, `[refactor] ...`, `[test] ...`. Esse prefixo alimenta o nome da branch e o commit na conclusão. Para criar VÁRIOS cards (ex.: planejar uma sprint), use create_cards_bulk — ele aceita os mesmos campos e ainda liga as dependências entre os cards do lote.

Cria VÁRIOS cards de uma vez (tudo-ou-nada) — ideal p/ planejar uma sprint inteira numa chamada só, revisando o plano antes de persistir. Aceita os MESMOS campos do create_card (epic, validationCommands, etc.), então NÃO é preciso criar e depois corrigir card a card. Cada título DEVE ter prefixo [tipo] (ex.: '[feat] ...'); se algum faltar/for inválido, o lote INTEIRO é rejeitado apontando o índice — nenhum card é criado. DEPENDÊNCIAS DENTRO DO LOTE: os ids ainda não existem quando você monta a chamada, então dê um `ref` (apelido, ex.: 'auth-api') ao card pré-requisito e cite esse ref no `dependsOn` de quem depende dele. O `ref` é resolvido na criação e descartado (não é salvo). `dependsOn` também aceita IDs de cards que já existem no board. Ciclos e refs inexistentes são rejeitados com o lote inteiro. Declarar a ordem importa: get_next_task só entrega um card quando TODAS as suas dependências estiverem 'done'. columnId vem de list_columns; sprintId (opcional) de list_sprints (mesmo board). A posição segue a ordem do array. Máx. 100.

Cria uma coluna. Verifique duplicatas com list_columns antes. role opcional: todo|doing|done.

Cria um sprint no board atual (status inicial 'planning'). Datas em YYYY-MM-DD (opcionais). NÃO ativa automaticamente — use activate_sprint. Num board compartilhado o sprint fica visível a todos os membros/agentes.

Remove um card permanentemente.

Remove uma coluna e TODOS os cards dela. Use com cuidado.

Pega o primeiro card disponível da coluna 'todo', trava por assignee e move para 'doing'. Retorna { done: true } quando não há mais. Loop: get_next_task → implementar → complete_card → repetir.

Retorna a nota de CONTEXTO do projeto (kind=context) — o briefing que descreve convenções, decisões e objetivos. LEIA antes de implementar cards para seguir o padrão do projeto. Retorna SEMPRE { hasContext, text }: hasContext=false + text=null significa que o board não tem briefing (não é erro). Não existe resposta ambígua aqui — se hasContext=true, `text` tem conteúdo.

Read-only: compara baseline atual com o working tree.

Diz se o MCP está conectado e autenticado no Intelliboard. Chame logo após instalar para confirmar a conexão. Retorna { authenticated, apiUrl, user? }. Se authenticated=false, chame a tool `login`.

Vincula ESTE repositório a uma organização + board. Aceita nome ou id; omita o campo quando só há uma opção acessível. O board é procurado DENTRO da organização já resolvida, então um par cruzado (org de um lado, board de outro) não chega a existir. Se faltar informação ou houver ambiguidade, devolve `candidates` tipados em vez de escolher sozinho — repita passando o id. O vínculo grava em disco, vale imediatamente para este processo e para os demais, e substitui um vínculo anterior. Recusa enquanto houver card em andamento neste agente.

Lista os agentes com claim ativo no board (sessão, cliente, estado, card e heartbeat). Use ANTES de pegar trabalho num board compartilhado: mostra quem já está em quê, evita dois agentes editando as mesmas áreas e permite escrever handoff endereçado. `stale: true` = claim sem heartbeat recente (o agente provavelmente morreu; o servidor libera o card). Não expõe PID, host, caminho, comando nem diff — só a identidade mínima do processo.

Lista os boards da organização efetiva. Com allOrganizations=true, descobre boards de TODAS as orgs em uma chamada e inclui organizationId/organizationName, sem alterar seleção, vínculo ou board ativo. O escopo normal segue: select da sessão > vínculo do workspace > config legada > app ativo.

Lista as colunas do board ativo (com role) e seus cards. Por padrão os cards vêm ENXUTOS (id, título, coluna, assignee, épico, sprint, dependências, prazo) — SEM description, executionReport nem validationLog, que são os campos longos que estouram o contexto num board grande. - Precisa da descrição/report de um card? Peça por nome: `fields: ['description']` — de preferência junto com `columns` e/ou `limit` para não trazer o corpo de todos. - Só quer o tamanho do board? `summaryOnly: true` (contagem por coluna, mais barato ainda). - Procurando um card específico num board grande? Prefira `search_cards`. Filtros combináveis: `sprintId`, `epic`, `columns`, `limit` (máx por coluna).

Lê o log append-only de decisões do board (mais recentes primeiro). Filtros: source, q, cardId, epic, limit. Cada entrada traz id, summary, detail, source, cardId, epic, at.

Cards atribuídos a você (assignee = seu usuário).

Lista as organizações do usuário (id, nome, papel, e memberCount — 1 = pessoal, >1 = compartilhada/time). Use para escolher em qual org o agente vai atuar com select_organization.

Lista os sprints do board atual (id, nome, status, período, meta). Num board compartilhado todos os membros veem os mesmos sprints. Use para achar o sprintId de um card ou saber qual está ativo (status 'active').

Read-only: lista TODOS os workspaces vinculados nesta máquina para a API atual (caminho local, organização e board). Útil para descobrir a que board um outro repositório está ligado sem precisar entrar nele.

APPENDA uma decisão ao log do board — histórico datado do que mudou e por quê (ex.: troca de biblioteca, mudança de arquitetura, re-implementação de entidade). Append-only: NUNCA sobrescreve nada. O próximo agente lê essas decisões no get_next_task, então registre mudanças que afetam COMO o projeto funciona. Não use isto para editar o BRIEFING (estado atual) — a mudança do briefing é aprovada por um humano.

Autentica o usuário no Intelliboard por device flow (OAuth). PASSO DO HUMANO: NÃO tente abrir a URL, aprovar ou autenticar você mesmo. Retorna { verification_url, user_code } — MOSTRE a URL ao usuário e peça para abrir no navegador e aprovar. O token é salvo automaticamente quando ele aprova; depois chame intelliboard_status para confirmar.

Move um card para outra coluna/posição. Mover para a coluna 'doing' TAMBÉM faz o claim no backend; esta tool alinha o estado local (baseline + heartbeat) ao claim resultante, então não existe card pego pelo servidor e desconhecido pelo agente. Para pegar um card para trabalhar, prefira claim_card — ele valida dependências, bloqueio e conflito de claim antes de mover.

Baixa e prepara a versão publicada AGORA, com a sessão ainda de pé, para que o próximo start do cliente seja cache hit em vez de uma instalação fria. Use isto antes de pedir ao usuário para reabrir a sessão. Só faz sentido quando o servidor é lançado por npx (o caminho recomendado). Não substitui o processo em execução e não altera nada do seu board. Pode levar dezenas de segundos numa primeira instalação; se o cliente cortar a chamada por timeout, o download continua e o reinício ainda sai beneficiado.

Libera o claim do card e para heartbeat local.

Renomeia um board (por nome ou id) da organização efetiva. Vínculos de workspace continuam válidos pelo ID; workspace status informa se o nome local ficou desatualizado. Config legada por nome precisa ser atualizada.

Busca cards do board ativo por texto (título e descrição, case-insensitive) e/ou filtra por épico, sprint e assignee. Resultado ENXUTO por padrão (sem description/report) — a forma barata de achar um card num board grande, em vez de listar tudo com list_columns e varrer. Achou o card e precisa do corpo? Chame list_columns com `fields: ['description']` e `columns` da coluna dele. Escopo: SOMENTE o board ativo desta instância. Sem `q`, funciona como filtro puro (ex.: só `epic`).

Fixa o BOARD (da org atual) que ESTA instância opera, por nome ou id — override em memória do processo. NÃO toca o navegador nem outras instâncias. Board de outra org → erro. Recusa se há card em andamento neste agente.

Fixa a ORG que ESTA instância do MCP opera, por nome ou id — override em memória do processo. NÃO altera o navegador nem outras instâncias (não toca user_context). Reseta o board (re-resolve na nova org). Depois use list_boards + select_board. Recusa se há card em andamento neste agente (o escopo é por-card).

Persiste, na máquina do dev (~/.config/intelliboard/prefs.json), como o MCP trata branch/commit ao concluir cards. Isto controla a preferência de fluxo, NÃO concede permissão para executar Git. Mesmo em auto, branch/commit passam pelo broker local e podem exigir aprovação no terminal. mode="off" impede a operação. action="branch", "commit" ou "both". mode="ask" volta a perguntar. Não afeta outros devs nem o board compartilhado.

Grava o perfil de validação deste workspace — o gate que complete_card exige antes de concluir um card. Sem `commands`, usa o que for detectado do projeto (ou o `validate` da config legada). Com `commands`, grava exatamente o argv informado (sem shell). Nada é executado durante o setup. Sobrescreve um perfil anterior. O perfil fica fora do repositório, em ~/.config/intelliboard/validation.json.

Remove o bloqueio manual sem iniciar claim/heartbeat.

Remove o vínculo local deste repositório. Depois disso o escopo volta à precedência seguinte (config legada, ou org/board ativos no app). Idempotente: sem vínculo, responde ok sem erro. Recusa enquanto houver card em andamento neste agente.

Explica como atualizar o intelliboard-mcp. O processo em execução NÃO se auto-substitui: a versão nova entra ao REABRIR a sessão do agente. A ordem importa — chame `prepare_update` ANTES de pedir o reinício, senão o download acontece dentro da janela de startup do cliente e a sessão pode abrir sem nenhuma tool. Não é preciso relogar: o token do device flow persiste.

Atualiza campos de planejamento e handoff de um card, inclusive comandos de validação, riscos, limitações e notas de segurança. Use `sprintId` para mover o card para outro sprint (grooming de backlog) ou `null` para tirá-lo do sprint. O backend valida que o sprint é do mesmo board do card. Campos omitidos ficam inalterados; null limpa campos textuais nullable.

Atualiza nome, meta, período (YYYY-MM-DD) ou status ('planning'|'active'|'done') de um sprint. Para trocar o sprint ativo, prefira activate_sprint (garante no máximo 1 ativo por board).

Prepara um ticket de validação e devolve os comandos exatos para execução pela ferramenta nativa de terminal. Não executa comandos dentro da tool.

Read-only: diz se este workspace tem perfil de validação e qual. Sem perfil, devolve `recommendation` com os comandos detectados a partir do projeto (package.json, Cargo, go.mod, pyproject) — passe-os a setup_validation ou aceite a detecção.

Read-only: mostra o workspace detectado (identidade Git ou caminho), o vínculo local de organização/board, a validade dele contra o backend, a precedência de escopo em vigor e o que a config legada ainda declara. Use antes de link_workspace para saber se já existe vínculo.