Standcast

Português (Brasil)

English

Português (Brasil)

English

Aparência

Changelog ​

O que mudou no Standcast. As versões são as mesmas dos releases no GitHub. A seção da API segue a política de versionamento.

Produto ​

Não lançado ​

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, 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: <CHAVE> } por time e members.<login>.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.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: <KEY> }, members.<login>.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 <id> 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=<unix seconds>,v1=<hex HMAC-SHA256>), 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).