iron-edge 1.2.0 → 2.0.0

package/squads/squad-courses/tasks/plan-b-roll-sequences.md

@@ -6,41 +6,54 @@ atomic_layer: Task
 elicit: false
 
 Entrada:
-  - campo: context
-    tipo: object
-    origem: "pipeline or manual"
+  - campo: script_roteiro
+    tipo: document
+    origem: "write-video-script"
     obrigatorio: true
 
 Saida:
-  - campo: resultado
+  - campo: b_roll_plan
     tipo: document
-    destino: "next phase"
+    destino: "plan-recording-session, design-screen-recording-flow (quando o b-roll e tela)"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Nenhum trecho de talking-head continuo passa de 90s sem b-roll marcado"
+  - "[ ] Cada insercao ilustra o que esta sendo dito naquele momento, nao assunto novo"
+  - "[ ] Fonte de cada b-roll esta definida (gravar agora / reaproveitar / screen recording a parte)"
+  - "[ ] Nenhuma insercao dura mais que a frase que ilustra"
 ---
 
-# Task: plan-b-roll-sequences
-
-## Metadata
-- **Agent:** production-director (Lens)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Planejar B-roll
 
 ## Objetivo
-Planejar B-roll
-
-## Steps
-1. Receber inputs e contexto do curso
-2. Executar operacao principal
-3. Validar output contra criterios pedagogicos
-4. Entregar artefato para proxima fase
-
-## Criterios de Qualidade
-- Alinhado aos learning outcomes
-- Nivel adequado para audiencia
-- Formato consistente com tipo de curso
-- Pronto para proxima fase
+Marcar, no roteiro, onde entra b-roll e de que tipo, para quebrar o padrão visual sem virar decoração desconectada da fala.
+
+## A regra que governa
+B-roll entra para quebrar o padrão visual a cada 60–90 segundos, não para decorar. Se a cena não substitui nem reforça o que está sendo dito naquele instante, ela não entra.
+
+## Passos
+
+1. **Percorrer o roteiro e marcar todo trecho de talking-head contínuo maior que 90 segundos.** Cada um desses é candidato a receber b-roll no meio.
+
+2. **Para cada ponto marcado, escolher o tipo de b-roll pelo que o áudio está dizendo naquele momento:** tela do que está sendo descrito, exemplo real citado, gráfico ou dado mencionado. B-roll ilustra o que já está sendo falado — não introduz assunto novo.
+   ⚠️ **B-roll decorativo** (imagem genérica de "trabalho" ou "estudo" sem relação com a frase) quebra o padrão visual mas não soma retenção — é esforço de edição sem efeito.
+
+3. **Priorizar b-roll que é screen recording ou exemplo real sobre imagem de banco.** Instrutor + tela junto tem retenção medida acima de só talking-head — e frame real bate imagem de banco em credibilidade também.
+
+4. **Marcar a duração de cada inserção.** A regra geral: a cena de b-roll dura o tempo da frase que ilustra, nunca mais — inserção longa demais compete com a narração em vez de reforçá-la.
+
+5. **Registrar de onde vem cada b-roll:** gravado nesta sessão, reaproveitado de gravação anterior, ou a gravar à parte como screen recording específico. Quando for screen recording, esse ponto alimenta a task `design-screen-recording-flow`.
+
+6. **Conferir a distribuição final.** Depois do plano aplicado, nenhum trecho de talking-head contínuo deve ultrapassar 90 segundos sem quebra.
+
+## Formato da saída
+Tabela com colunas: `Trecho do roteiro` | `O que está sendo dito` | `Tipo de b-roll` | `Fonte` (gravar agora / reaproveitar / screen recording à parte) | `Duração da inserção`.
+
+## O que não vale
+- B-roll genérico sem relação direta com a fala do momento.
+- Inserção que dura mais que a frase que ilustra.
+- Trecho de talking-head contínuo acima de 90s sem b-roll marcado.
+- Imagem de banco onde cabia gravação real do próprio conteúdo — frame real vale mais que estoque tanto em retenção quanto em credibilidade.
+
+## Fontes no squad
+`video-production-guide.md` (Editing Tempo e Engagement Patterns), `engagement-retention-patterns.md` (padrões de retenção e pattern interrupts).

package/squads/squad-courses/tasks/plan-enrollment-funnel.md

@@ -17,10 +17,11 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Confirmado se já existe lançamento ao vivo validado antes de propor evergreen"
+  - "[ ] Estrutura de funil montada etapa por etapa"
+  - "[ ] Mecanismo de escassez escolhido é honesto, sem cronômetro falso"
+  - "[ ] Rastreamento de conversão definido por etapa"
+  - "[ ] Ponto de vazamento mais provável marcado para revisão"
 ---
 
 # Task: plan-enrollment-funnel
@@ -31,16 +32,33 @@ Checklist:
 - **Complexity:** STANDARD
 
 ## Objetivo
-Planejar funil de matricula
-
-## Steps
-1. Receber inputs e contexto do curso
-2. Executar operacao principal
-3. Validar output contra criterios pedagogicos
-4. Entregar artefato para proxima fase
-
-## Criterios de Qualidade
-- Alinhado aos learning outcomes
-- Nivel adequado para audiencia
-- Formato consistente com tipo de curso
-- Pronto para proxima fase
+Desenhar o funil que leva de tráfego a matrícula — ao vivo (lançamento) ou evergreen — com cada etapa nomeada e sem escassez fingida.
+
+## A regra que governa
+**Funil evergreen só existe depois que um lançamento ao vivo já validou a oferta — e nenhuma escassez no funil pode ser fingida.**
+
+## Passos
+
+1. **Confirmar se já existe um lançamento ao vivo validado** (task `plan-launch-sequence` já rodada e com resultado real). Sem isso, o funil desta task é para o lançamento ao vivo, não evergreen.
+
+2. **Se evergreen:** montar a estrutura de "Evergreen Funnel Structure" em `course-launch-strategy.md` — tráfego (ads/SEO/conteúdo) → isca digital → sequência de nutrição (5-7 e-mails, 7-14 dias) → e-mail de oferta com prazo → página de vendas → compra → upsell.
+
+3. **Escolher o mecanismo de escassez** na tabela "Evergreen Scarcity (Without Lying)" — cronômetro personalizado por lead, cohort-gating, preço por tier crescente, ou lista de espera honesta.
+   ⚠️ **Nunca fingir urgência ou escassez.** Cronômetro que reinicia pro mesmo lead, "vagas esgotando" sem controle real — os dois quebram a regra do KB e destroem confiança de forma permanente, não é exagero de copy, é ruptura de confiança.
+
+4. **Se ao vivo:** montar o funil do carrinho aberto (opt-in → e-mail → página de vendas → checkout → aluno matriculado), casando com o calendário já definido em `plan-launch-sequence`.
+
+5. **Definir o rastreamento de conversão de cada etapa** (UTM, pixel, meta de analytics) — sem isso não há como saber onde o funil vaza.
+
+6. **Marcar o ponto de vazamento mais provável**, com base em histórico de lançamentos anteriores quando existir, para revisão no pós-lançamento.
+
+## Formato da saída
+Diagrama em texto do funil (etapa → etapa → etapa) com o mecanismo de escassez escolhido, por que ele é honesto, e a lista de rastreamento por etapa.
+
+## O que não vale
+- Contador regressivo que reinicia para o mesmo lead.
+- "Últimas vagas" sem controle real do número de vagas disponíveis.
+- Construir funil evergreen antes de qualquer lançamento ao vivo ter validado a oferta.
+
+## Fontes no squad
+`knowledge-base/course-launch-strategy.md`.

package/squads/squad-courses/tasks/plan-launch-sequence.md

@@ -17,10 +17,11 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Tamanho da lista e volume de prova social levantados"
+  - "[ ] Tipo de lançamento escolhido pela tabela Launch Types, não por preferência"
+  - "[ ] Calendário de pré-lançamento e de semana de lançamento montados"
+  - "[ ] Datas checadas contra Carnaval e feriados nacionais"
+  - "[ ] Métricas marcadas como benchmark, nunca como meta garantida"
 ---
 
 # Task: plan-launch-sequence
@@ -31,16 +32,34 @@ Checklist:
 - **Complexity:** STANDARD
 
 ## Objetivo
-Planejar sequencia de lancamento
-
-## Steps
-1. Receber inputs e contexto do curso
-2. Executar operacao principal
-3. Validar output contra criterios pedagogicos
-4. Entregar artefato para proxima fase
-
-## Criterios de Qualidade
-- Alinhado aos learning outcomes
-- Nivel adequado para audiencia
-- Formato consistente com tipo de curso
-- Pronto para proxima fase
+Decidir o tipo de lançamento e desenhar o calendário de pré-lançamento e semana de lançamento, com dias, ações e canais.
+
+## A regra que governa
+**O tipo de lançamento é decidido pelo tamanho da lista e pela prova social disponível — nunca pela preferência de formato.**
+
+## Passos
+
+1. **Levantar o tamanho da lista de e-mail e o volume de prova social** (depoimentos, resultados de beta) disponível hoje.
+
+2. **Escolher o tipo de lançamento** na tabela "Launch Types — Selection Guide" de `course-launch-strategy.md`: PLF pede 2.000+ e-mails; Lançamento Semente serve tópico novo sem prova ainda; Lançamento Interno serve lista quente menor; Evergreen só entra depois de um lançamento ao vivo já validado.
+   ⚠️ **Lista pequena sem prova social não vira PLF só porque é o formato mais robusto.** Sem lista/prova suficiente → Lançamento Semente, que valida antes de produzir tudo.
+
+3. **Montar o calendário de pré-lançamento** (4-8 semanas, tabela week-by-week) **e o calendário da semana de lançamento** (7 dias, tabela day-by-day) do KB, adaptando as ações ao curso real — não copiar o genérico sem ajustar.
+
+4. **Se for PLF, encaixar a sequência de 4 vídeos** (Oportunidade → Transformação → Experiência de Dentro → Oferta) nos dias -10/-7/-4/0.
+
+5. **Checar as datas contra "Brazilian Launch Calendar — Peak Windows"** — nunca fechar carrinho durante Carnaval ou feriado nacional.
+
+6. **Declarar as métricas de acompanhamento** (tabela "Launch Metrics") como benchmark de mercado.
+   ⚠️ **Nunca prometer resultado de vendas na sequência** ("essa sequência vende X unidades"). Conversão 1-5%, 30-40% da meta até o dia 3 — são benchmark de mercado pra comparar durante a semana, não garantia desta sequência.
+
+## Formato da saída
+Calendário em tabela (semana/dia · ação · canal · e-mail) do pré-lançamento e da semana de lançamento, com o tipo de lançamento escolhido e o porquê em uma linha no topo.
+
+## O que não vale
+- Fechar o carrinho durante Carnaval ou feriado nacional.
+- Prometer número de vendas ou conversão como resultado garantido da sequência.
+- Pular a fase de pré-lançamento porque "o curso já está pronto" — pré-lançamento aquece a lista, não depende do curso estar pronto.
+
+## Fontes no squad
+`knowledge-base/course-launch-strategy.md`.

package/squads/squad-courses/tasks/plan-practical-exercises.md

@@ -17,30 +17,44 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Prompt tem verbo de ação e entregável — não é 'reflita sobre isso'"
+  - "[ ] Exercício usa o contexto real do aluno quando isso é possível"
+  - "[ ] Posição antes/depois da teoria decidida por regra, não por hábito"
+  - "[ ] Deliverable e destino definidos (plataforma / comunidade / só para o aluno)"
+  - "[ ] Tempo do exercício cabe no teto da lição — senão, é exercício de módulo"
 ---
 
 # Task: plan-practical-exercises
 
-## Metadata
-- **Agent:** lesson-architect (Blueprint)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Planejar exercicios praticos
-
-## Steps
-1. Receber inputs e contexto do curso
-2. Executar operacao principal
-3. Validar output contra criterios pedagogicos
-4. Entregar artefato para proxima fase
-
-## Criterios de Qualidade
-- Alinhado aos learning outcomes
-- Nivel adequado para audiencia
-- Formato consistente com tipo de curso
-- Pronto para proxima fase
+Escrever o prompt do exercício da lição — o passo que o aluno executa, com verbo de ação, entregável e destino definidos, no formato do template.
+
+## A regra que governa
+**O exercício usa o contexto real do aluno, nunca um caso fictício quando o real está disponível.** Adultos aprendem aplicando ao próprio projeto, não a um personagem genérico — e o que sobrevive depois da aula é o que foi praticado na condição mais parecida com a aplicação real.
+
+## Passos
+1. **Decida se o exercício vem antes ou depois da teoria.** Antes (Problem-Based Learning: "escreva sua headline antes de eu explicar o framework") quando o aluno já tem alguma base pra tentar; depois (prática guiada tradicional) quando o conceito é inteiramente novo. Essa decisão já devia vir de `design-lesson-flow` — aqui você só escreve o prompt coerente com ela.
+
+2. **Escreva o prompt com verbo de ação e entregável explícito**, no formato da seção "Exercise / Action Step" de `lesson-plan-template.md`.
+   ⚠️ "Pense em como aplicar isso" não é exercício, é convite à procrastinação — todo prompt tem um verbo ("escreva", "calcule", "liste", "classifique") e um resultado que existe fora da cabeça do aluno.
+
+3. **Use o projeto real do aluno como matéria-prima sempre que possível.** "Usando o seu próprio negócio, calcule..." em vez de "Considere a empresa fictícia XYZ..." (`adult-learning-principles.md`, Self-Directed Learning — Agency in application). Só recorra a caso fictício quando o aluno ainda não tem contexto próprio pra aplicar (ex.: primeira lição do curso).
+
+4. **Defina o deliverable e o destino.** O que exatamente o aluno produz (documento, lista, rascunho, planilha) e onde isso vai — exercício da plataforma, thread da comunidade, ou só para uso próprio. Campos do template, nunca deixados em aberto.
+
+5. **Feche exercícios de fim de módulo com a pergunta de transferência:** "como você vai usar isso nos próximos 7 dias" (`adult-learning-principles.md`, Transfer of Learning). Não repita essa pergunta em toda lição — ela pertence ao fechamento de módulo, não ao de cada aula.
+
+6. **Calibre o esforço pelo teto da lição.** O exercício precisa caber dentro do tempo estimado em `estimate-lesson-duration`; se exige mais de 15-20 minutos, não é exercício de uma lição — é exercício de módulo, e deve ser tratado como tal (fora do escopo desta task isolada).
+
+## O que não vale
+- Caso fictício quando o projeto real do aluno estava disponível.
+- Prompt sem verbo de ação ou sem entregável claro.
+- Exercício que testa um objetivo diferente do declarado em `define-lesson-objectives` para essa lição.
+- Exercício de módulo inteiro disfarçado de exercício de uma lição isolada.
+
+## Formato da saída
+> **Prompt:** "Usando um produto ou serviço do seu próprio negócio, escreva a headline de venda dele em uma frase."
+> **Tempo estimado:** 10 min · **Deliverable:** headline escrita · **Destino:** thread da comunidade, módulo 1.
+
+## Fontes no squad
+`templates/lesson-plan-template.md` (seção Exercise/Action Step), `knowledge-base/adult-learning-principles.md` (Self-Directed Learning, Problem-Based Learning, Transfer of Learning), `knowledge-base/instructional-design-frameworks.md` (Case Method, Think-Pair-Share).

package/squads/squad-courses/tasks/plan-recording-session.md

@@ -6,41 +6,61 @@ atomic_layer: Task
 elicit: false
 
 Entrada:
-  - campo: context
-    tipo: object
-    origem: "pipeline or manual"
+  - campo: shot_list
+    tipo: document
+    origem: "create-shot-list"
+    obrigatorio: true
+  - campo: script_roteiro
+    tipo: document
+    origem: "write-video-script"
     obrigatorio: true
 
 Saida:
-  - campo: resultado
+  - campo: recording_session_plan
     tipo: document
-    destino: "next phase"
+    destino: "create-production-checklist"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Ordem de gravacao agrupada por setup, nao pela ordem do curso"
+  - "[ ] Pausa marcada a cada 45min de gravacao"
+  - "[ ] Estimativa usa a proporcao 2:1 (gravacao : video final)"
+  - "[ ] Criterio de audio e luz descrito por resultado, sem marca de equipamento"
 ---
 
-# Task: plan-recording-session
-
-## Metadata
-- **Agent:** production-director (Lens)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Planejar sessão de gravação
 
 ## Objetivo
-Planejar sessao de gravacao
-
-## Steps
-1. Receber inputs e contexto do curso
-2. Executar operacao principal
-3. Validar output contra criterios pedagogicos
-4. Entregar artefato para proxima fase
-
-## Criterios de Qualidade
-- Alinhado aos learning outcomes
-- Nivel adequado para audiencia
-- Formato consistente com tipo de curso
-- Pronto para proxima fase
+Definir ordem de gravação, setup mínimo por critério de resultado e tempo estimado, para que a sessão renda o máximo de vídeo pronto sem estourar o dia.
+
+## A regra que governa
+Uma hora de gravação vira cerca de trinta minutos de vídeo final — o plano existe para a sessão não estourar, e a pausa a cada 45 minutos não é opcional: é queda de energia medida, não capricho.
+
+## Passos
+
+1. **Listar as aulas a gravar na ordem lógica, não cronológica.** Agrupe pelo mesmo setup — cenário, roupa, luz — em vez de seguir a ordem do curso. Trocar de setup no meio da sessão custa tempo real; trocar de assunto não custa nada.
+
+2. **Definir o setup mínimo por critério de resultado, nunca por marca de equipamento:**
+   - Câmera: altura dos olhos, enquadramento cabeça + ombros, 20% de espaço acima da cabeça.
+   - Luz: sem sombra sob os olhos ou no queixo, sem misturar temperatura de cor (não combinar luz de janela com luz artificial sem corrigir).
+   - Áudio: microfone a 30–50cm da boca, sem ruído de fundo audível — nada de ar-condicionado, ventilador ou rua perceptível na gravação.
+   ⚠️ **Não aceite "dá pra entender" como critério de áudio.** O padrão é ausência de ruído perceptível, não inteligibilidade mínima — a diferença aparece na edição, quando já é tarde pra regravar.
+
+3. **Gravar 10 segundos de silêncio (tom de sala) no início da sessão** — usado depois na edição para limpar ruído de fundo residual.
+
+4. **Estimar o tempo com a proporção 2:1:** uma hora de vídeo final consome cerca de duas horas de sessão contando retakes. Use isso para decidir quantas aulas cabem numa sessão, não a duração do roteiro somada direto.
+
+5. **Programar pausa a cada 45 minutos de gravação.** Energia cai depois disso — sessão sem pausa programada rende mais retakes, não menos tempo total.
+
+6. **Reservar o primeiro take de cada sessão como aquecimento** e descartá-lo por padrão.
+
+## Formato da saída
+Plano com: lista de aulas na ordem de gravação (agrupadas por setup), checklist de setup por critério de resultado, cronograma em blocos de 45 minutos com pausas marcadas, e tempo total estimado (horas de sessão vs. minutos de vídeo final entregue).
+
+## O que não vale
+- Ordem de gravação igual à ordem do curso, ignorando agrupamento por setup.
+- Estimativa de tempo sem aplicar o fator 2:1 — subestimar a sessão é o erro mais comum de planejamento de gravação.
+- Sessão sem pausa marcada a cada 45 minutos.
+- Especificar marca ou modelo de câmera, luz ou microfone como exigência — o plano descreve o resultado (enquadramento, ausência de sombra, ausência de ruído); a ferramenta para chegar lá é do executor.
+
+## Fontes no squad
+`video-production-guide.md` (Camera Setup, Lighting, Audio, Production Checklist e heurística de sessão do agente).

package/squads/squad-courses/tasks/proofread-course-content.md

@@ -17,30 +17,38 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] As 8 seções do lesson-quality-checklist.md rodadas contra o conteúdo, uma a uma"
+  - "[ ] Objetivo verificado: usa verbo de Bloom, não 'entender'/'aprender'"
+  - "[ ] Jargão e sigla conferidos: definidos na primeira aparição"
+  - "[ ] Extensão conferida contra a faixa esperada pro formato da peça"
+  - "[ ] Decisão registrada — PASS / REVISE / REWRITE — com instruções específicas por item"
 ---
 
 # Task: proofread-course-content
 
-## Metadata
-- **Agent:** content-writer (Scribe)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Revisar conteudo escrito
-
-## Steps
-1. Receber inputs e contexto do curso
-2. Executar operacao principal
-3. Validar output contra criterios pedagogicos
-4. Entregar artefato para proxima fase
-
-## Criterios de Qualidade
-- Alinhado aos learning outcomes
-- Nivel adequado para audiencia
-- Formato consistente com tipo de curso
-- Pronto para proxima fase
+Auditar um conteúdo já escrito (lição, capítulo, handout, workbook) contra `lesson-quality-checklist.md` e devolver uma decisão — PASS, REVISE ou REWRITE — com o que precisa mudar, nunca uma reescrita silenciosa.
+
+## A regra que governa
+**Revisar é medir contra o objetivo declarado, não reescrever no gosto de quem revisa.** O `lesson-quality-checklist.md` já define: um conteúdo que falha em 3 ou mais das 8 seções precisa de revisão antes de publicar. A revisão não é "eu escreveria diferente" — é "isso atinge o que o próprio conteúdo se propôs a ensinar?".
+
+## Passos
+1. **Rode as 8 seções do checklist, uma a uma, sem pular.** Objetivo e foco · Gancho e abertura · Estrutura de conteúdo · Prática e aplicação · Checkpoint e avaliação · Duração e ritmo · Acessibilidade e linguagem · Fechamento e takeaways. Marque cada item como passa ou falha — não avalie por impressão geral.
+2. **Verifique o objetivo primeiro.** Ele usa um verbo de Bloom (não "entender", "aprender", "conhecer")? O título bate com o que o conteúdo de fato ensina? Isso decide se o problema é de conteúdo ou só de rótulo.
+   ⚠️ "Está bem escrito" não é critério do checklist. Prosa elegante com objetivo mal definido ainda falha a seção 1.
+3. **Confira jargão e acessibilidade.** Toda sigla ou termo técnico do domínio precisa estar definido na primeira aparição — mesmo que pareça óbvio pra quem escreveu.
+4. **Confira a extensão contra a faixa esperada** pro tipo de peça: lição em vídeo 5–12 min, lição em texto 800–2.500 palavras (`lesson-quality-checklist.md`); pra outras peças (capítulo, handout, workbook), use a faixa definida na task de escrita correspondente.
+5. **Conte as falhas e declare a decisão.** 0–2 seções falhas com correção pontual → REVISE, com a lista exata do que mudar. 3+ seções falhas, ou o objetivo em si está errado → REWRITE. Nenhuma falha → PASS.
+6. **Nunca reescreva por conta própria durante a revisão.** Entregue o diagnóstico e as instruções de correção — quem escreveu (ou a próxima passagem da task de origem) faz a reescrita.
+
+## Formato da saída
+A tabela de resumo do próprio `lesson-quality-checklist.md` preenchida (8 critérios, pass/fail, notas), mais a decisão final (PASS/REVISE/REWRITE) e, quando REVISE ou REWRITE, instruções específicas por item — nunca um comentário genérico como "melhorar a introdução".
+
+## O que não vale
+- Reescrever o conteúdo em vez de listar o que precisa mudar.
+- Aprovar (PASS) com falhas registradas "porque no geral está bom".
+- Feedback vago tipo "falta clareza" sem apontar a seção do checklist e o trecho.
+- Pular seções do checklist por já "ter uma boa impressão" do texto.
+
+## Fontes no squad
+- `checklists/lesson-quality-checklist.md` — instrumento completo de revisão, as 8 seções e a régua de 3+ falhas

package/squads/squad-courses/tasks/review-course-quality.md

@@ -17,30 +17,41 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] course-completeness-checklist.md rodado item a item, não por amostragem de memória"
+  - "[ ] pre-launch-checklist.md rodado item a item"
+  - "[ ] Relatórios de curriculum/lesson/assessment/produção reunidos antes do veredito"
+  - "[ ] Veredito declarado (APPROVED | NEEDS REVISION) com os itens pendentes nomeados"
 ---
 
-# Task: review-course-quality
-
-## Metadata
-- **Agent:** courses-orqx (Syllabus)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Revisar qualidade do curso
 
 ## Objetivo
-Review de qualidade dos materiais
-
-## Steps
-1. Receber inputs e contexto do curso
-2. Executar operacao principal
-3. Validar output contra criterios pedagogicos
-4. Entregar artefato para proxima fase
-
-## Criterios de Qualidade
-- Alinhado aos learning outcomes
-- Nivel adequado para audiencia
-- Formato consistente com tipo de curso
-- Pronto para proxima fase
+Emitir o veredito final de qualidade do curso — APPROVED ou NEEDS REVISION — antes de liberar para `finalize-course-delivery`. É o último gate antes de o curso ir ao ar.
+
+## A regra que governa
+**Nenhum curso libera com item de checklist pendente.** Não existe "APPROVED com ressalva" — ressalva vira item de NEEDS REVISION nomeado, e o dono decide se aceita o risco.
+
+## Passos
+
+1. **Reúna os relatórios das fases anteriores** antes de abrir os checklists. São artefatos que o próprio pipeline gerou nas fases de cima — não vêm no pacote, e se algum faltar, diga qual e siga com os que existem: `curriculum-review-report.md` (Compass), `lesson-review-report.md` (Compass), `assessment-review-report.md` (Gauge), `production-review-report.md` (Lens). Se algum relatório não existe, a fase correspondente não terminou — este passo não avança, e isso vira bloqueio reportado em `monitor-course-progress`, não um item ignorado aqui.
+
+2. **Rode `checklists/course-completeness-checklist.md` item a item.** Cobre currículo e estrutura, completude por módulo, completude por lição, completude de avaliação, configuração de plataforma e sales page. Cada item marcado precisa ter sido conferido de fato — abrir a lição, contar as perguntas do quiz — não presumido porque "a fase anterior disse que estava pronta".
+
+3. **Rode `checklists/pre-launch-checklist.md` item a item.** Cobre plataforma, conteúdo carregado, preço e checkout, sales page, sequência de e-mail, funil de matrícula, onboarding, suporte e legal. Este checklist testa o curso como aluno real veria — não como configuração no painel administrativo.
+
+   ⚠️ **Amostra não é evidência de tudo.** Assistir 20% do vídeo ou revisar uma lição por módulo é o padrão de amostragem esperado (ver `course-quality-review.yaml`), mas isso cobre só a checagem qualitativa — os itens do checklist de completude e pré-lançamento não são amostrados, são binários: existe ou não existe, funciona ou não funciona.
+
+4. **Cada item não marcado vira uma linha nomeada**, nunca "vários itens pendentes na sales page". Ex.: `CTA da sales page aponta para checkout antigo — precisa atualizar o link.`
+
+5. **Declare o veredito.** APPROVED só quando os dois checklists estão 100% e todos os relatórios de fase mostram PASS/ALIGNED. Qualquer pendência real → NEEDS REVISION, com a lista de itens e o agente dono de cada correção.
+
+## Formato da saída
+`quality-review-report.md` com a lista de itens verificados (ambos os checklists), os relatórios de fase referenciados, e a linha de veredito: `Veredito: NEEDS REVISION — 2 itens: (1) quiz do módulo 3 sem explicação nas alternativas erradas [Gauge], (2) e-mail de boas-vindas não testado [Launchpad].`
+
+## O que não vale
+- Aprovar porque o projeto já está atrasado ou porque o dono está pressionando — atraso não é critério de qualidade.
+- Marcar item de checklist como feito sem abrir o artefato correspondente.
+- Emitir veredito sem os quatro relatórios de fase reunidos.
+
+## Fontes no squad
+`checklists/course-completeness-checklist.md`, `checklists/pre-launch-checklist.md`, `workflows/course-quality-review.yaml` (fases 1 a 5, amostragem de 30%/20% e critérios de veredito por área), `workflows/full-course-creation.yaml` (fase-8-quality-review).

package/squads/squad-courses/tasks/select-platform-strategy.md

@@ -17,10 +17,11 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Mercado do público identificado (BR/LATAM vs. internacional)"
+  - "[ ] Critérios do curso levantados (comunidade, afiliados, drip, lista própria)"
+  - "[ ] Candidatas cruzadas na tabela de decisão do platform-comparison.md"
+  - "[ ] Fee confirmada na fonte oficial da plataforma, com data"
+  - "[ ] Decisão declarada em uma linha, com trade-off"
 ---
 
 # Task: select-platform-strategy
@@ -31,16 +32,33 @@ Checklist:
 - **Complexity:** STANDARD
 
 ## Objetivo
-Selecionar plataforma ideal
-
-## Steps
-1. Receber inputs e contexto do curso
-2. Executar operacao principal
-3. Validar output contra criterios pedagogicos
-4. Entregar artefato para proxima fase
-
-## Criterios de Qualidade
-- Alinhado aos learning outcomes
-- Nivel adequado para audiencia
-- Formato consistente com tipo de curso
-- Pronto para proxima fase
+Decidir a plataforma de venda e hospedagem do curso, com o porquê registrado — não a plataforma "mais famosa", a que serve este mercado e este curso.
+
+## A regra que governa
+**O mercado do público decide a família de plataforma primeiro; orçamento e feature decidem qual, dentro da família.** Público pagando em R$/PIX pede uma família (Hotmart, Kiwify, Eduzz); público pagando em USD/cartão internacional pede outra (Kajabi, Teachable, Thinkific, Udemy).
+
+## Passos
+
+1. **Identificar o mercado do público.** BR/LATAM (PIX, boleto, afiliados locais) ou internacional (Stripe, PayPal)? Use a tabela "Decision Guide" e "Platform Selection by Audience and Goal" de `platform-comparison.md`.
+   ⚠️ Público misto não se decide por "maioria" — decide pelo canal de aquisição principal deste lançamento.
+
+2. **Levantar os critérios do curso.** Precisa de comunidade nativa? Sistema de afiliados? Conteúdo com liberação programada (drip)? Já existe lista de e-mail própria de 1.000+? Cada "sim" muda a candidata favorita.
+
+3. **Cruzar mercado + critérios na tabela de decisão** de `platform-comparison.md`, chegando em 1 ou 2 candidatas plausíveis — nunca uma lista de cinco.
+
+4. **Calcular o custo líquido real.** Use "Platform Fee Benchmark" e "Pricing Impact Calculator" como ponto de partida, aplicando ao preço e volume esperado deste curso.
+   ⚠️ **Fee de plataforma muda por país, moeda e no tempo — o valor do KB tem data-base.** Antes de fechar a decisão, confirme a fee vigente na página oficial da plataforma escolhida e registre a data da confirmação. Sem isso, a decisão fica com um número que pode já estar errado.
+
+5. **Declarar a decisão** em uma linha, nomeando o critério que decidiu e o trade-off aceito.
+
+## Formato da saída
+Tabela comparativa das 1-2 candidatas (plataforma · fee confirmada · moeda · feature decisiva) + uma linha de decisão.
+Exemplo: `Plataforma: Kiwify — mercado BR, fee 7,99% confirmada em kiwify.com.br em 22/08/2026, sem comunidade nativa (resolvido à parte via Circle).`
+
+## O que não vale
+- Escolher pela plataforma mais conhecida sem cruzar com o mercado real do público.
+- Copiar a fee da tabela do squad direto pro brief, sem confirmar na fonte oficial da plataforma.
+- Prometer volume de vendas pela escolha de plataforma — plataforma reduz fricção, não garante conversão.
+
+## Fontes no squad
+`knowledge-base/platform-comparison.md`.