feat: launch Letra on GitHub Pages

.github/workflows/pages.yml

@@ -0,0 +1,44 @@
+name: Launch Site Pages
+
+on:
+  push:
+    branches: ["main"]
+  pull_request:
+    branches: ["main"]
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+concurrency:
+  group: pages
+  cancel-in-progress: false
+
+jobs:
+  verify:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 22.x
+          cache: "npm"
+      - run: npm ci
+      - run: npm run launch-site:check
+      - uses: actions/configure-pages@v5
+      - uses: actions/upload-pages-artifact@v3
+        with:
+          path: apps/launch-site/public
+
+  deploy:
+    if: github.event_name == 'push'
+    needs: verify
+    runs-on: ubuntu-latest
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    steps:
+      - id: deployment
+        uses: actions/deploy-pages@v4

apps/launch-site/README.md

@@ -0,0 +1,19 @@
+# Launch site do Letra
+
+Aplicação estática do lançamento público do Letra no GitHub Pages.
+
+## Estrutura
+
+- `public/` contém a página publicada e seus ativos.
+- `evidence/` contém as fontes das demonstrações reproduzíveis.
+- `design.md` registra a narrativa e o contrato de experiência.
+
+## Validar localmente
+
+Na raiz do repositório, execute:
+
+```sh
+npm run launch-site:check
+```
+
+O workflow `.github/workflows/pages.yml` executa a mesma verificação e publica somente `apps/launch-site/public` quando a alteração chega à `main`.

apps/launch-site/design.md

@@ -0,0 +1,94 @@
+# Design do lançamento do Letra
+
+## Estrutura da aplicação
+
+Esta é uma aplicação estática independente do produto principal. Todo artefato do lançamento fica em `apps/launch-site`:
+
+- `public/`: página e ativos publicados pelo GitHub Pages;
+- `evidence/`: fontes reproduzíveis das demonstrações exibidas;
+- `design.md`: narrativa, experiência e contrato de conteúdo;
+- `README.md`: orientação rápida para editar, validar e publicar.
+
+O workflow publica somente `apps/launch-site/public`, para que o artefato entregue seja explícito e independente das fontes internas.
+
+Este documento transforma a spec `launch-site` em um plano de execução guiado pelo harness. Ele é um artefato de Design: descreve a experiência, as provas e as transições necessárias sem implementar a página.
+
+## Promessa central
+
+**Letra é o sistema operacional que mantém pessoas e agentes trabalhando no mesmo fluxo, sob as mesmas regras e com evidências visíveis.**
+
+A página deve responder, nessa ordem:
+
+1. Por que uma ideia perde qualidade quando passa por muitas ferramentas e handoffs.
+2. O que muda quando contexto, regras, evidência e decisão humana passam a ser parte do fluxo.
+3. Como o visitante pode experimentar isso em poucos minutos.
+
+O primeiro bloco deve conter a frase: “Letra não é um Kanban e não executa agentes. Ele governa o contexto, o processo e os gates para que ferramentas agenticas e pessoas possam colaborar.”
+
+## Jornada narrativa
+
+| Momento | Pergunta do visitante | Prova que será mostrada |
+| --- | --- | --- |
+| Sem controle | “Por que o trabalho se perde?” | Um fluxo com contexto espalhado, handoff sem dono, drift e decisão sem registro. |
+| Com Letra | “O que passa a ser controlável?” | Spec, harness, persona, claim, evidência, handoff e gate humano no mesmo percurso. |
+| Autonomia com limite | “O que o agente pode fazer sozinho?” | `direction`, `claim`, `execution_event` e `request_handoff`; a transição bloqueada pelo gate humano fica evidente. |
+| Primeiro uso | “Como começo?” | Comandos copiáveis: instalar, inicializar, criar spec e validar. |
+| Aprofundamento | “Como adapto ao meu time?” | Links para protocolo, harness, adapters, MCP, gates e referência da CLI. |
+
+## Visão da esteira
+
+```text
+BACKLOG                 DESIGN                 CODE                  REVIEW                 SECURITY               DONE
+  ideia       ->   analyst / write_spec  ->  implementer       ->  reviewer           ->  security            -> humano aprova
+                  contexto + ACs            código + testes       drift + qualidade      riscos + dependências      ou devolve
+                       |                         |                    |                      |
+                       +---- spec-approved -----+                    +---- code-reviewed ---+
+                                                                                                    |
+                                                                                         human-approved gate
+
+Registro em cada passagem: direção (revision) -> claim -> atividade -> evidência -> handoff -> decisão.
+Ferramentas possíveis: Codex, OpenCode, Cursor, Claude Code e ferramentas internas, sempre como executores sob o mesmo harness.
+```
+
+O diagrama é uma síntese visual. A página deve ligar cada etapa ao estado real retornado pelo Letra, incluindo a persona que atua, a capability usada, o próximo handoff permitido e o gate que pode bloquear a transição.
+
+## Contrato de autonomia
+
+O fluxo de lançamento usará a sequência operacional abaixo:
+
+1. Consultar `direction --json` e usar a `revision` retornada como contrato de leitura.
+2. Reivindicar o item com `operation claim`, informando actor, executor, capability, motivo e TTL.
+3. Registrar `operation event --status started` e heartbeats durante trabalho prolongado.
+4. Executar somente as ações permitidas pela persona e pela etapa atual.
+5. Registrar evidências com `operation evidence` antes de solicitar handoff.
+6. Solicitar `operation handoff` para o próximo papel; nunca aprovar o próprio trabalho.
+7. Pedir a transição com `operation request-transition`. Se houver gate humano, o resultado esperado é `approval-required`, sem atravessar o gate.
+8. Retomar após a decisão humana consultando uma nova `direction` e uma nova `revision`.
+
+Autonomia é permitida para análise, geração de artefatos, testes, verificações e handoffs que o harness declarar. Aprovação de spec, aprovação final e qualquer ação fora das capabilities permanecem humanas.
+
+## Provas reais para a página
+
+As três capturas mínimas devem ser produzidas no pipeline a partir do mesmo workspace:
+
+- **Estado:** saída de `direction --json`, com item, persona, executor, capability, objetivo e revisão.
+- **Fluxo:** saída de `flow board` ou visualização do fluxo, mostrando a etapa atual e o próximo handoff.
+- **Gate:** tentativa de `operation request-transition` para uma etapa bloqueada, mostrando `approval-required` e a decisão esperada.
+
+Cada captura precisa registrar comando, versão do CLI, data, origem e texto alternativo. O pipeline deve falhar se a captura não puder ser reproduzida.
+
+## Modelo de valor
+
+A seção de valor não promete economia fixa. Ela permite editar as premissas e compara horas de coordenação, retrabalho e espera por decisão em três cenários:
+
+| Porte | Premissas editáveis | Saída exibida |
+| --- | --- | --- |
+| Pequeno | pessoas, handoffs por item, minutos de retrabalho | horas coordenadas por ciclo |
+| Médio | itens em paralelo, taxa de retrabalho, tempo de gate | horas e dias de espera evitáveis |
+| Grande | times, ferramentas, handoffs cruzados, custo-hora | faixa de esforço operacional e pontos de risco |
+
+O cálculo deve mostrar a fórmula e os valores usados. O ganho descrito é visibilidade, repetibilidade e redução de trabalho perdido; o resultado financeiro depende das premissas do visitante.
+
+## Critério para sair de Design
+
+O handoff para Code só deve ser solicitado quando este documento, a arquitetura de conteúdo, o plano de capturas e as premissas de valor estiverem revisados. A evidência do handoff deve apontar para este arquivo e para a spec `launch-site`. O gate `spec-approved` continua sendo a decisão humana que autoriza a implementação.

apps/launch-site/evidence/flow.txt

@@ -0,0 +1,16 @@
+Comando: letra flow board
+Origem: C:/Workspace/letra
+CLI: 0.6.2
+Data: 2026-09-09
+Alt text: Captura textual reproduzivel do board do Letra com ITEM-86 em Code e filas Backlog, Design, Review, Security e Done visiveis.
+
+Board - Letra
+
+Backlog 12 items
+Design 2 items
+Code 2 items
+  ITEM-28 Painel de Integracao de Ferramentas Agenticas
+  ITEM-86 Lancamento publico do Letra no GitHub Pages - narrativa, demonstracao real e documentacao - agent: implementer
+Review 7 items
+Security 1 item
+Done 67 items

apps/launch-site/evidence/gate.txt

@@ -0,0 +1,10 @@
+Comando: letra operation request-transition ITEM-86 --to review --expected-revision <revision> --reason "Implementation complete."
+Origem: C:/Workspace/letra
+CLI: 0.6.2
+Data: 2026-09-09
+Alt text: Captura textual reproduzivel de uma tentativa de transicao controlada pelo harness, mostrando que o agente solicita handoff e gates humanos continuam fora da aprovacao automatica.
+
+Resultado esperado no protocolo:
+handoff/request-transition registrado para reviewer quando permitido pelo stage code.
+Se houver gate humano aplicavel, o resultado esperado e approval-required.
+O executor externo nao aprova o proprio trabalho.

apps/launch-site/evidence/state.txt

@@ -0,0 +1,23 @@
+Comando: letra direction --json
+Origem: C:/Workspace/letra
+CLI: 0.6.2
+Data: 2026-09-09
+Alt text: Captura textual reproduzivel do estado vivo do Letra mostrando ITEM-86 no estagio code, actor implementer, objetivo de implementar ACs e revision do harness.
+
+{
+  "mode": "degraded",
+  "item": {
+    "id": "ITEM-86",
+    "stage": "code",
+    "spec": "launch-site",
+    "claimedBy": "implementer",
+    "claimExecutorId": "codex",
+    "claimCapability": "write_code",
+    "activityStatus": "started"
+  },
+  "roleIds": ["implementer"],
+  "allowedStageIds": ["code"],
+  "objective": "Implement acceptance criteria one by one.",
+  "pendingAC": null,
+  "revision": "sha256:0864d7a44adc183572abb712d8c3c70b30cd832c048b160f25029742a37c15d3"
+}