--- url: https://docs-standcast.usefachada.dev/pt-BR/changelog.md --- # Changelog O que mudou no Standcast. As versões são as mesmas dos [releases no GitHub](https://github.com/ImFelipeOliveira/standcast/releases). A seção da API segue a [política de versionamento](/pt-BR/api/overview#versionamento). ## Produto ### Não lançado ### 0.7.0 — 06/11/2026 ### 0.6.0 — 06/11/2026 ### 0.5.0 — 06/11/2026 * Google Chat: um time com `chat.provider: google-chat` recebe o consolidado num espaço do Google Chat, as dailies atrasadas na thread dele, e os lembretes, os impedimentos encaminhados e os impedimentos sugeridos por mensagem direta, pelo app do Standcast para o Google Chat. Adicione o app a um espaço, e um admin cola o código de vínculo que ele publica no app web (Configuração → Google Chat) ou na página de setup. Cada pessoa se vincula mandando uma mensagem direta para o app uma vez, ou com `members..google_chat: users/` no `standcast.yml`. Uma organização pode usar o Slack num time e o Google Chat em outro. O app funciona nos domínios do Google Workspace em que está disponível; uma listagem no Google Workspace Marketplace vem em breve. Veja [Google Chat](/pt-BR/admin/google-chat). * O modelo de `standcast.yml` da página de setup tem um time no Slack e um no Google Chat. Apague o que você não usa. * No app web, as entregas com falha que qualquer chat pode causar não citam mais o Slack. * Um time com `chat.provider: google-chat` precisa de um nome de espaço (`spaces/...`) em `chat.channel`. Antes, qualquer texto passava na verificação do `standcast.yml` e o consolidado falhava depois com `space_not_linked`. Quando o valor é o link do espaço, o erro diz o nome a usar. * Quando o app do Google Chat não acha a sua conta pelo e-mail, ou acha mais de uma, ele responde também com o seu id no Google Chat (`users/`), pronto para um admin pôr em `members..google_chat` no `standcast.yml`. ### 0.4.1 — 02/11/2026 * Só documentação: as entradas do changelog da 0.4.0. Nenhuma mudança no produto. ### 0.4.0 — 02/11/2026 * O rascunho da daily pode usar as suas sessões locais de IA: o `standcast draft --sessions`, a tool `standcast_get_draft` do MCP (`includeSessions`, ligado por padrão) e a skill `/daily` leem as suas sessões do Claude Code na sua máquina e as agrupam com os seus pull requests, cards e commits no `work`, então o ontem vira uma linha por trabalho. O Standcast nunca envia os dados das sessões para a API dele; o seu cliente de IA recebe esses dados e pode enviá-los ao provedor do modelo dele. Para desligar, use `STANDCAST_SESSIONS=off`. Veja [Privacidade](/pt-BR/privacy#suas-sessoes-de-ia-na-sua-maquina). * A página de setup avisa quando o canal do Slack de um time não existe ou o bot não está nele; os links do consolidado não abrem mais prévias e mostram um rótulo curto (repo#123, FEL-12); um pull request aberto e mergeado na mesma janela aparece uma vez só no rascunho. * O app web está no ar em [app-standcast.usefachada.dev](https://app-standcast.usefachada.dev), começando pela tela de Configuração. A página de setup renderizada pelo servidor continua funcionando. * Hoje no app web: um time no dia atual, com os impedimentos abertos e há quanto tempo estão abertos, pedidos de apoio, as dailies de hoje, o que foi entregue ontem e quem já enviou hoje. Gestores, admins e o autor podem resolver e reabrir um impedimento, e gestores e admins podem lembrar quem ainda não enviou. A tela não mostra métrica por pessoa nem histórico de quem não enviou. Veja [App web](/pt-BR/admin/web-app). * Pedidos de apoio: uma seção opcional da daily para o que você precisa de outra pessoa sem estar travado, como um review, uma decisão ou um pareamento. A skill `/daily`, o servidor MCP e a CLI perguntam por ela depois dos impedimentos, e o consolidado a mostra logo depois dos impedimentos, com quem pediu. Ela não é encaminhada por mensagem direta. * O consolidado e a daily atrasada marcam as seções com emoji para ficarem mais fáceis de ler no Slack: 📅 no título, 🗓️ Ontem, 🎯 Hoje, 🚧 Impedimentos, 🤝 Pedidos de apoio e ⏳ para quem não enviou. A confirmação mostrada antes de enviar a daily usa os mesmos rótulos. ### 0.3.1 — 01/11/2026 * O site de documentação publica `robots.txt` e um `sitemap.xml`, e a landing page serve as próprias fontes. ### 0.3.0 — 01/11/2026 * O Standwise agora é **Standcast**: novo nome, binário da CLI `standcast`, arquivo de configuração `standcast.yml`, variáveis de ambiente `STANDCAST_*`, headers de webhook `Standcast-*`, prefixos de token `sc_`/`sck_` e novas URLs (`api-standcast.usefachada.dev`, `docs-standcast.usefachada.dev`). As sessões e API keys existentes deixam de funcionar: entre de novo e crie keys novas. * Landing page em [standcast.usefachada.dev](https://standcast.usefachada.dev/pt-BR/), em inglês e português, com um formulário para entrar no beta público. Depois de enviar, você vai para o guia de instalação. * Documentação para agentes de IA: `llms.txt`, `llms-full.txt` e uma cópia em Markdown de cada página, em inglês e português. A API serve o próprio `llms.txt`, com links para o documento OpenAPI e os guias da API. * A página de privacidade explica o que o formulário do beta guarda e por quanto tempo. * Os arquivos CODEOWNERS são lidos em tempo linear. ### 0.2.1 — 31/10/2026 * Só ferramentas de release: as versões batem com os releases do GitHub em todo lugar. Nenhuma mudança no produto. ### 0.2.0 — 31/10/2026 Primeiro beta público. * Reforço de robustez: * A página de setup mostra um aviso quando um time do GitHub no `standwise.yml` não é encontrado ou é grande demais (só os primeiros 5.000 membros são usados). * **Sair** na página de setup encerra a sessão web. * Links de pull request são comparados sem diferenciar maiúsculas de minúsculas, então um impedimento não é encaminhado duas vezes para a mesma pull request. * Revisões, eventos da timeline e check runs são lidos página por página no GitHub, então pull requests grandes não são mais cortadas. * O health check tem limite de tempo e não acumula consultas quando o banco está lento. * O instalador funciona em shells BusyBox. * Uma identidade antiga do Slack é removida automaticamente quando o Slack responde `user_not_found` ou `user_disabled`. A pessoa entra de novo para vincular outra vez. * Site de documentação em inglês e português, com a visão geral do produto, guias para admins e membros, a referência do `standwise.yml` e os guias da API. * Plugin do Claude Code com a skill `/daily` e o servidor MCP incluído. * `standwise mcp`: servidor MCP local com as tools de rascunho e de envio confirmado, mais tools de leitura para gestores e admins. * CLI `standwise`: `login`, `logout`, `whoami`, `draft`, `submit` e `suggestion`. * Consolidado do time no Slack no `digest_at`, com as dailies atrasadas na thread. * Página de setup: estado da configuração, conexão com o Slack, entregas com falha, API keys e webhooks. * Lembretes por mensagem direta no `remind_at`, uma vez por pessoa por dia. O `remind_at` precisa ser anterior ao `digest_at`. * Encaminhamento de impedimentos por mensagem direta: revisores, depois CODEOWNERS, depois gestores. * Impedimentos sugeridos para pull requests sem revisão e CI falhando, visíveis só para a pessoa, com `signals.direct_message` para receber também por mensagem direta. * Check run `Standwise config` nas mudanças do `standwise.yml`. * Retenção: logs de entrega de webhook depois de 30 dias, sugestões resolvidas depois de 90 dias, sessões expiradas removidas. * O inglês é o idioma padrão quando nenhum é definido. * Integração com o Linear: um admin conecta um workspace do Linear por instalação na página de setup (app OAuth que age como ele mesmo, escopo só de leitura `read`, tokens criptografados e renovados automaticamente). **Requisito de deploy:** a api e o worker agora precisam de `LINEAR_CLIENT_ID` e `LINEAR_CLIENT_SECRET` e não iniciam sem elas. * `tracker: { provider: linear, team: }` por time e `members..linear` (e-mail); as pessoas também são ligadas pelo e-mail do GitHub. `tracker.provider: jira` é aceito, com um aviso no setup. * Os seus cards do Linear (`card_started`, `card_done`) no rascunho, e impedimentos de card encaminhados aos responsáveis pelos cards que travam, depois ao responsável pelo card, a quem o criou ou aos gestores. * Impedimento sugerido `card_stale` para cards em andamento há `signals.card_stale_days` (padrão 5), visível só para a pessoa. ## API O changelog da API é mantido em inglês. Versions match the GitHub releases. During the public beta (0.x), incompatible changes are listed here before they ship; from 1.0 they are announced at least 90 days in advance. See the versioning guide. ## Unreleased ## 0.7.0 — 2026-11-06 ## 0.6.0 — 2026-11-06 ## 0.5.0 — 2026-11-06 * No public API changes. The errors guide lists three codes returned only by the web app routes that link Google Chat spaces: `invalid_code` (422), `space_already_linked` (409) and `too_many_spaces` (409). `payload_too_large` also applies to the Google Chat webhook receiver. ## 0.4.1 — 2026-11-02 * No API changes. ## 0.4.0 — 2026-11-02 * Additive: dailies have a `support` field, a list of items like `blockers` (what the person needs from someone else without being blocked). `POST /v1/dailies` accepts it as optional, up to 10 items, defaulting to an empty list. It is always present, possibly empty, in `GET /v1/org/dailies`, `GET /v1/org/dailies/{id}`, the manager dailies and the `daily.submitted` webhook payload. Dailies stored before this change return an empty list. `blocker.opened` and `digest.sent` are unchanged, and there is no new scope or event. The MCP tool `standcast_submit_daily` accepts an optional `support`. * Additive: draft activity items for pull requests (`pr_opened`, `pr_merged`) may include `branch`, the pull request head branch. ## 0.3.1 — 2026-11-01 * No API changes. ## 0.3.0 — 2026-11-01 ### Breaking: the rename to Standcast * Base URL: `https://api-standcast.usefachada.dev`. * API keys start with `sck_` and session tokens with `sc_`. Keys and sessions created before 0.3.0 stop working; create new keys on the setup page. * Webhook headers are `Standcast-Signature`, `Standcast-Event` and `Standcast-Delivery`, with `User-Agent: Standcast-Webhooks/1`. Update your signature verification to read `Standcast-Signature`. * The internal confirmation header is `X-Standcast-Confirmation`, and the MCP tools are named `standcast_*`. * The configuration file is `standcast.yml`, and the check run is named "Standcast config". ### New * `GET /llms.txt`: a plain-text index for AI agents, linking the OpenAPI document, the interactive reference and the documentation's `llms.txt`. * `POST /beta` receives the landing page's beta form. It is not part of the public API and is not in the OpenAPI document. * **Deploy requirement:** the api accepts `LANDING_URL` (https, no trailing slash, default `https://standcast.usefachada.dev`). The worker accepts `RESEND_API_KEY`, and needs `BETA_EMAIL_FROM` and `SUPPORT_EMAIL` when the key is set. ## 0.2.1 — 2026-10-31 * No API changes. ## 0.2.0 — 2026-10-31 First public beta. ### Agents, CLI and configuration * The interactive API reference moved from `/docs/api` to `/reference`. `/docs/api` answers with a permanent redirect. The documentation site moved to its own domain (`DOCS_URL`); `/docs` and `/docs/*` on the api redirect there. Deploy requirement: the api accepts `DOCS_URL` (https, no trailing slash, default `https://docs.standwise.dev`). * Linear integration. The draft `activity` can include `card_started` and `card_done` items for your own Linear cards (`repo` is the Linear team key, `url` the card link), and `suggestions` can have `kind: "card_stale"`. Both are additive: clients must ignore kinds they do not know. Blocker `ref` accepts a Linear card URL. * `standwise.yml`: `tracker: { provider: linear, team: }`, `members..linear` (an email) and `signals.card_stale_days` (default 5) now take effect. * Deploy requirement: the api and the worker need `LINEAR_CLIENT_ID` and `LINEAR_CLIENT_SECRET` and fail to start without them. * Setup page: **Connect Linear** and **Reconnect Linear** for admins. A failed connection returns `linear_oauth_failed` (HTTP 502). * Default language is now English when none is specified. * `standwise mcp`: local MCP server over stdio with the tools `standwise_whoami`, `standwise_get_draft` and `standwise_submit_daily` (confirmed by the person through elicitation, or `confirmed: true` as a fallback), plus the manager tools `standwise_list_teams`, `standwise_get_digest`, `standwise_list_dailies` and `standwise_list_blockers`. See the MCP guide. * Suggested blockers: `standwise.yml` accepts `signals.direct_message` (default `false`). Suggestions are visible only to the person, in their draft, and never in the organization API, the manager tools, the webhooks or the setup page. * `standwise suggestion confirm|ignore ` and the MCP tool `standwise_decide_suggestion`. The `suggestions` field of the draft is now a list of `{ id, kind, ref, since }`. A repeated decision is accepted; the opposite decision returns `suggestion_already_decided` (HTTP 409). * `managers` entries must be GitHub logins; `@org/team` is rejected as a validation error. * Internal session routes `GET /v1/manage/teams`, `/v1/manage/digests`, `/v1/manage/dailies` and `/v1/manage/blockers` back the manager tools. They are readable by team managers and organization admins, limited to the last 90 days, and listed only in `/openapi.internal.json`. * Daily item text and link titles may no longer contain control characters (newlines and tabs included), bidirectional controls or line separators, and link titles are limited to 200 characters. Link URLs follow the same character rules and must use `http` or `https`. Invalid dailies get `invalid_daily`. * `GET /health` also checks the database and returns `503` with `{ "ok": false }` when it does not answer. * Internal: `org` is required on `GET /v1/draft` and `GET /v1/today`; the documentation said it was optional. * Internal: the GitHub webhook receiver answers a signed body that is not JSON with `422 invalid_request` instead of `400`, and rejects bodies over 1 MB with `413 payload_too_large`. * Internal: `GET /v1/today` returns the standup date for an organization, and `POST /v1/dailies` accepts an optional `X-Standwise-Confirmation: human|agent` header that is stored with the daily. Neither changes the public API. ### Webhooks * Outbound webhooks: an organization admin registers HTTPS endpoints on the setup page and picks the events `daily.submitted`, `blocker.opened` and `digest.sent`. A `ping` test event can be sent from the setup page. * Every delivery is a signed `POST` with the headers `Standwise-Signature` (`t=,v1=`), `Standwise-Event`, `Standwise-Delivery` and `User-Agent: Standwise-Webhooks/1`. Failed deliveries are retried up to 8 attempts; an endpoint with 20 failed deliveries in a row is disabled. * The OpenAPI document has a `webhooks` section with the payload of each event. See the webhooks guide. ### Organization API * API keys (`swk_`) created by an organization admin on the setup page, with the scopes `teams:read`, `dailies:read`, `digests:read` and `blockers:read`. * Read-only organization operations: `GET /v1/org/teams`, `GET /v1/org/dailies`, `GET /v1/org/dailies/{id}`, `GET /v1/org/digests` and `GET /v1/org/blockers`, paginated by cursor. * New error codes `insufficient_scope` (HTTP 403, with `required_scope`) and `not_found` (HTTP 404). ### Foundation * OpenAPI 3.1 document at `/openapi.json` and interactive reference at `/reference`. * `GET /health`. * Rate limits with `RateLimit-*` and `Retry-After` headers; new error code `rate_limited` (HTTP 429).