iron-edge 1.2.0 → 2.0.1

package/squads/squad-courses/tasks/design-slide-structure.md

@@ -17,30 +17,47 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Todo slide tem um layout que casa com o seu tipo (sem layout inventado)"
+  - "[ ] Nenhum slide passa de 3 níveis visuais"
+  - "[ ] Slide que tentava ser 2 tipos ao mesmo tempo foi dividido em 2"
+  - "[ ] Slide de exercício tem os campos obrigatórios do template"
 ---
 
-# Task: design-slide-structure
-
-## Metadata
-- **Agent:** slide-designer (Deck)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Projetar a estrutura de cada slide
 
 ## Objetivo
-Projetar estrutura de slides
-
-## 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, para cada slide já listado no outline, o layout e o esqueleto de conteúdo (headline, visual, bullets) — sem ainda escrever o texto final.
+
+## A regra que governa
+**O layout serve ao tipo do slide, não ao gosto de quem desenha.** `presentation-design-principles.md` define oito tipos de slide, cada um com um layout correspondente. A estrutura não se inventa slide a slide — ela se aplica a partir da tabela.
+
+## Passos
+
+1. **Confirmar o tipo herdado do outline.** Título, conceito, diagrama, quote, exemplo, exercício, resumo ou transição — cada um vem de `create-presentation-outline`. Se o tipo ainda não foi definido, essa é a lacuna a fechar antes de seguir.
+
+2. **Aplicar o layout da tabela, sem variação livre.** Concept slide: headline + visual ou até 3 bullets. Diagram slide: só o diagrama, sem parede de texto ao lado. Summary slide: até 3 bullets. A tabela completa está em "Slide Types and When to Use Each" (`presentation-design-principles.md`).
+
+3. **Testar se o slide é, na verdade, dois.** Se ao descrever o esqueleto do slide você precisa de "e" para juntar dois conceitos que o aluno tem que lembrar separadamente, é sinal de que virou dois tipos disputando um layout. ⚠️ **Isso é a versão estrutural da regra "1 ideia por slide" — o defeito aparece aqui, antes do texto, não depois.** Divida agora.
+
+4. **Aplicar a regra dos 3 níveis visuais.** Nenhum slide passa de 3 camadas de hierarquia (tamanho, peso, cor — "Rule of three" em "Visual Hierarchy"). Se a estrutura pede um 4º nível — por exemplo, título + subtítulo + diagrama + legenda de rodapé — o slide se divide, não se aperta.
+
+5. **Trocar "high load" por "low load" na estrutura.** A tabela "Cognitive Load Management" mapeia direto: parede de texto vira diagrama + 1 frase; 3 conceitos por slide vira 1; layout inconsistente vira template repetido. Aplique a coluna da direita antes de passar a task adiante.
+
+6. **Slide de exercício ganha os 4 campos do template.** Quando o tipo é "exercício", a estrutura precisa dos campos de `templates/presentation-template.md` ("Slide — Exercise"): título do exercício, prompt, tempo, e o que o aluno entrega. Estrutura de exercício sem esses 4 campos vai incompleta para `design-interactive-elements`.
+
+## Formato da saída
+Um bloco por slide:
+```
+Slide 6 — Tipo: Conceito
+Layout: headline + diagrama
+Elementos: [ponto central em uma frase] + [diagrama a construir] — sem bullets
+```
+
+## O que não vale
+- Slide "genérico" sem tipo, empurrando a decisão pra frente.
+- Layout inventado que não está na tabela, sem justificativa registrada.
+- Um slide carregando 2 conceitos "porque estão relacionados".
+- Slide de exercício sem tempo ou sem entrega definida.
+
+## Fontes no squad
+`knowledge-base/presentation-design-principles.md`, `templates/presentation-template.md`.

package/squads/squad-courses/tasks/design-student-onboarding.md

@@ -17,10 +17,11 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Sequência das primeiras 48h montada, não só um e-mail de boas-vindas"
+  - "[ ] Itens do pre-launch-checklist testados como aluno novo, não como admin"
+  - "[ ] Lição de vitória rápida da primeira sessão definida"
+  - "[ ] Canal e prazo de resposta de suporte comunicados ao aluno"
+  - "[ ] Nenhuma promessa de conclusão do curso como resultado do onboarding"
 ---
 
 # Task: design-student-onboarding
@@ -31,16 +32,32 @@ Checklist:
 - **Complexity:** STANDARD
 
 ## Objetivo
-Projetar onboarding do aluno
-
-## 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 a jornada das primeiras 48 horas do aluno matriculado, do e-mail de boas-vindas até a primeira ação dentro do curso.
+
+## A regra que governa
+**As primeiras 48 horas decidem se o aluno conclui o curso — onboarding é uma sequência de ações do aluno, não um único e-mail de boas-vindas.**
+
+## Passos
+
+1. **Montar a sequência na ordem**: e-mail de boas-vindas → como acessar a plataforma → primeira lição sugerida → acesso à comunidade/grupo → expectativa de ritmo (quanto estudar por semana, prazo pra concluir).
+   ⚠️ "Primeira lição sugerida" não é "comece pelo Módulo 1" genérico — é a lição que entrega uma vitória rápida, escolhida a dedo.
+
+2. **Cruzar com a seção "Student Onboarding" de `pre-launch-checklist.md`.** Cada item do checklist vira uma entrega verificável desta task: vídeo de boas-vindas configurado, instruções de comunidade no e-mail, lição "comece aqui" acessível, rastreamento de progresso funcionando.
+   ⚠️ **"Configurado" só conta depois de testado como aluno novo.** Entrar com a própria conta de admin não simula a primeira experiência de quem acabou de pagar.
+
+3. **Definir a vitória rápida da primeira lição**: qual conteúdo entrega sensação de progresso em menos de 20 minutos — usando o par "Post-purchase → Onboarding, community, quick wins" da tabela "Content Pillars for Course Creators" de `course-launch-strategy.md` como referência de estágio.
+
+4. **Definir canal e prazo de resposta do suporte** que o aluno vê na primeira mensagem — expectativa de disponibilidade do instrutor, comunicada, não implícita.
+
+5. **Não prometer conclusão do curso como resultado do onboarding.** O objetivo declarado é reduzir abandono nas primeiras 48h, não garantir que o aluno termine o curso.
+
+## Formato da saída
+Linha do tempo (hora/dia · ação · canal · gatilho) das primeiras 48h + checklist dos itens testados como aluno novo, não como admin.
+
+## O que não vale
+- Onboarding com um único e-mail de boas-vindas e nada mais.
+- Marcar item do checklist como pronto sem testar como aluno novo.
+- Prometer que o onboarding garante conclusão do curso.
+
+## Fontes no squad
+`checklists/pre-launch-checklist.md`, `knowledge-base/course-launch-strategy.md`.

package/squads/squad-courses/tasks/design-visual-hierarchy.md

@@ -17,30 +17,49 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Ordem tamanho→peso→cor→posição→contraste foi aplicada, não hierarquia por instinto"
+  - "[ ] Corpo de texto ≥24pt e legenda ≥18pt em material de curso"
+  - "[ ] No máximo 3 cores no deck inteiro"
+  - "[ ] Fundo escuro para vídeo, claro para impresso/PDF, decidido e registrado"
 ---
 
-# Task: design-visual-hierarchy
-
-## Metadata
-- **Agent:** slide-designer (Deck)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Projetar a hierarquia visual
 
 ## Objetivo
-Projetar hierarquia visual
-
-## 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
+Fixar a especificação de estilo do deck — o que o olho vê primeiro, tamanhos mínimos de fonte e paleta — para aplicar igual em todo slide.
+
+## A regra que governa
+**Contraste e tamanho decidem o que o aluno vê primeiro, e no curso ninguém está do lado apontando.** Numa sala com apresentador, o olhar segue quem fala. No material de curso, o próprio slide precisa carregar a hierarquia sozinho.
+
+## Passos
+
+1. **Aplicar a ordem certa, não a intuitiva.** `presentation-design-principles.md` ("Visual Hierarchy") define a sequência: Tamanho → Peso → Cor → Posição → Contraste. Cada slide tem **um** elemento dominante — decidido nessa ordem, não por "o que parece mais bonito".
+
+2. **Regra dos 3 níveis.** Nunca mais de 3 camadas de hierarquia por slide. Acima disso, o slide não precisa de mais hierarquia — precisa dividir em dois (ver `design-slide-structure`).
+
+3. **Piso de tipografia adaptado para tela, não para sala.** `presentation-design-principles.md` manda nunca abaixo de 16pt pensando em projeção ao vivo ("rooms are rarely ideal"). Material de curso é visto sozinho, em notebook e frequentemente em celular — o piso desta casa é mais alto que o de palestra: título 36-48pt, corpo **24-28pt**, legenda **nunca abaixo de 18pt**. ⚠️ **Copiar o piso de sala (16pt) para o curso é o erro mais comum deste passo.** O que dá para ler ao vivo com alguém apontando não dá para ler sozinho numa tela pequena, sem ninguém guiando o olho.
+
+4. **Paleta com teto de 3 cores.** 1 cor de marca + 1 de destaque + neutros — nunca mais que 3 cores no deck inteiro (`presentation-design-principles.md`, "Color and Typography"). Cor de destaque é reservada só para o que precisa ser visto primeiro; usar a cor de destaque em tudo anula a hierarquia.
+
+5. **Contraste por meio de entrega.** Fundo escuro para vídeo, fundo claro para material impresso ou PDF baixável (regra 9 de "The 10 Fundamental Rules"). A decisão é do formato de entrega, não de preferência estética — e precisa estar registrada, porque quem monta o vídeo ou gera o PDF depende dela.
+
+6. **Fonte única por função.** Um sans-serif para corpo, um display para headline. Fonte de sistema quando houver dúvida (Inter, DM Sans, Lato) — evita renderização quebrada em plataforma de curso que não embute fontes customizadas.
+
+## Formato da saída
+Especificação curta, reutilizável em todo slide do deck:
+```
+Título: 40pt, peso bold, cor de marca
+Corpo: 26pt, peso regular, neutro escuro
+Legenda: 18pt, peso regular, neutro médio
+Paleta: #marca / #destaque / neutros
+Fundo: escuro (vídeo) — claro (PDF do handout)
+```
+
+## O que não vale
+- "Deixa bonito" sem número de tamanho ou cor associado.
+- Hierarquia decidida por instinto, fora da ordem tamanho→peso→cor→posição→contraste.
+- Mais de 3 cores no deck.
+- Corpo de texto abaixo de 24pt em material de curso, mesmo que "coubesse" na régua de sala.
+
+## Fontes no squad
+`knowledge-base/presentation-design-principles.md`.

package/squads/squad-courses/tasks/estimate-lesson-duration.md

@@ -17,30 +17,43 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Estimativa feita por contagem de palavras/seções, não por sensação"
+  - "[ ] Tempo do exercício contado à parte do tempo da lição"
+  - "[ ] Lição comparada contra a tabela de atenção (< 6min / 9-12min / > 12min)"
+  - "[ ] Lição que estourou 12 minutos foi dividida em duas, não cortada"
+  - "[ ] Duração final registrada no campo 'Estimated Duration' do template"
 ---
 
 # Task: estimate-lesson-duration
 
-## Metadata
-- **Agent:** lesson-architect (Blueprint)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Estimar duracao das licoes
-
-## 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
+Estimar quanto tempo (vídeo) ou quantas palavras (texto) a lição realmente ocupa, e decidir se ela cabe no teto de atenção ou precisa virar duas lições.
+
+## A regra que governa
+**Se o conceito precisa de mais de 12 minutos pra explicar, são duas lições, não uma.** O teto governa o escopo — o escopo nunca estica o teto.
+
+## Passos
+1. **Estime o tempo de narração real, por seção.** Regra prática: ~130-150 palavras por minuto de fala. Some hook + cada seção de conteúdo do outline (`create-lesson-outline`) + a instrução do exercício — não o tempo que o aluno leva pra FAZER o exercício, que é tempo à parte.
+
+2. **Compare contra a pesquisa de atenção.** Vídeos abaixo de 6 minutos são assistidos quase 100% até o fim; entre 9 e 12 minutos, a conclusão cai pra ~50%; acima de 12 minutos, a queda é forte mesmo em vídeo não-interativo (`engagement-retention-patterns.md`, Attention Span Research). Alvo da casa: **5-12 min em vídeo, 800-2.500 palavras em texto** (`lesson-quality-checklist.md`, Duration and Pace).
+   ⚠️ Estimar pela contagem de seções, não pelo conteúdo real de cada uma, engana: duas seções curtas cabem tranquilas no teto, uma seção densa sozinha pode estourar.
+
+3. **Se estourar 12 minutos, divida a lição — não corte conteúdo pra caber.** Perder profundidade pra respeitar um número é pior do que ter uma lição a mais. A divisão volta pra `create-lesson-outline` como duas lições (ex.: 3.2a e 3.2b), cada uma com seu próprio hook e checkpoint.
+
+4. **Não conte o tempo do exercício na duração comunicada da "aula".** Duração da aula é o que o aluno assiste ou lê; o exercício é ação separada, com seu próprio tempo estimado na task `plan-practical-exercises`.
+
+5. **Registre a estimativa no campo correspondente do template.** `Estimated Duration` de `lesson-plan-template.md` — é o dado que o `production-director` e o `slide-designer` consomem depois pra planejar a produção.
+
+## Formato da saída
+Uma linha por lição, com a base do cálculo:
+> Lição 3.2: ~9 min (≈1.260 palavras de narração em 3 seções) — dentro do teto.
+> Lição 4.1: ~15 min (≈2.100 palavras em 4 seções) — estourou; dividir em 4.1a (hook + seção 1-2) e 4.1b (seção 3-4 + exercício + checkpoint).
+
+## O que não vale
+- Arredondar pra baixo pra não precisar dividir a lição.
+- Estimar por sensação em vez de contar palavras ou seções reais.
+- Comunicar ao aluno uma duração que soma lição + exercício como se fosse só a lição.
+- Ignorar o teto porque "o conteúdo é importante" — importância não é motivo pra estourar atenção.
+
+## Fontes no squad
+`knowledge-base/engagement-retention-patterns.md` (Attention Span Research, Pattern 1), `checklists/lesson-quality-checklist.md` (Duration and Pace), `templates/lesson-plan-template.md` (campo Estimated Duration).

package/squads/squad-courses/tasks/finalize-course-delivery.md

@@ -17,30 +17,41 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Veredito APPROVED de review-course-quality confirmado antes de prosseguir"
+  - "[ ] Matrícula de teste real verificada (não presumida a partir da configuração)"
+  - "[ ] Links e handoffs cross-squad empacotados no relatório final de entrega"
+  - "[ ] Pendências restantes do pre-launch-checklist.md, se houver, com dono nomeado"
 ---
 
-# Task: finalize-course-delivery
-
-## Metadata
-- **Agent:** courses-orqx (Syllabus)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Finalizar entrega do curso
 
 ## Objetivo
-Finalizar e entregar para publicacao
-
-## 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
+Fechar o projeto: confirmar que o curso está de fato no ar e testado, empacotar a entrega para o dono, e encerrar o loop de orquestração — inclusive apontando handoffs para outras squads quando o lançamento pedir.
+
+## A regra que governa
+**Só fecha o projeto o que está no ar e testado, não o que foi apenas configurado.** "Configurei o checkout" não é "o checkout funciona" — a diferença é a compra de teste que passou.
+
+## Passos
+
+1. **Confirme o veredito APPROVED de `review-course-quality`.** Sem ele, esta task não roda — não existe finalização condicional a "está quase pronto".
+
+2. **Verifique a matrícula de teste real**, não a configuração da plataforma. `pre-launch-checklist.md` já pede isso na fase anterior ("Test purchase completed successfully", "Access granted immediately", "Enrollment confirmation email received") — aqui é a última conferência antes de declarar entregue. Se o teste não foi feito ou não foi registrado, o projeto não está pronto para fechar, mesmo com o resto aprovado.
+
+3. **Empacote a entrega** com os elementos que o dono precisa para operar o curso sozinho a partir de agora: link da sales page, link de acesso à plataforma, link da comunidade/suporte, e o status final dos dois checklists (`course-completeness-checklist.md`, `pre-launch-checklist.md`).
+
+4. **Aponte handoffs cross-squad quando o lançamento pedir.** Se o escopo incluiu tráfego pago, SEO de página de vendas, ou campanha de lançamento, nomeie o handoff explícito: squad-copy para revisão contínua da sales page, squad-paidmedia para os anúncios, squad-growth para SEO/funil. Handoff sem contexto (só "avisar a squad X") obriga a squad seguinte a redescobrir o que já foi decidido aqui — inclua o brief mínimo.
+
+5. **Escreva o relatório final de entrega** para o dono: o que está pronto e no ar, o que ficou fora do escopo original (se algo foi cortado por prazo ou decisão do dono ao longo do projeto), e os próximos passos que dependem dele.
+
+6. **Registre em memória** qualquer decisão de escopo que mudou pelo caminho e o motivo, para não repetir a mesma surpresa no próximo projeto.
+
+## Formato da saída
+`delivery-report.md` com: status APPROVED confirmado, evidência da matrícula de teste, lista de links entregues, handoffs cross-squad nomeados (ou "nenhum necessário"), e a lista do que ficou fora do escopo original, se houver.
+
+## O que não vale
+- Declarar "curso pronto para lançar" sem um link ao vivo funcional testado por alguém.
+- Fechar o projeto com item da seção "Outstanding items before launch" do `pre-launch-checklist.md` ainda preenchido e sem dono.
+- Escrever handoff cross-squad genérico ("squad-paidmedia, pode seguir") sem o brief que a squad seguinte precisa para não perguntar tudo de novo.
+
+## Fontes no squad
+`checklists/pre-launch-checklist.md` (seção Final Go/No-Go e Outstanding items), `checklists/course-completeness-checklist.md` (Final Sign-Off), `agents/courses-orqx.md` (heurística de handoff cross-squad), `workflows/course-launch-cycle.yaml`.

package/squads/squad-courses/tasks/initiate-course-project.md

@@ -17,30 +17,45 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Bandeira de trilha leve (apresentação/mentoria) ou de conteúdo preexistente checada antes de qualquer outra coisa"
+  - "[ ] Trilha declarada em uma linha, com o gatilho observado no pedido"
+  - "[ ] Workflow correspondente identificado pelo nome do arquivo .yaml"
+  - "[ ] Zona cinzenta resolvida com pergunta de uma linha ao dono, nunca por estimativa"
 ---
 
-# Task: initiate-course-project
-
-## Metadata
-- **Agent:** courses-orqx (Syllabus)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Iniciar projeto de curso
 
 ## Objetivo
-Iniciar novo projeto de curso
-
-## 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
+Ler o pedido, classificar a trilha certa e apontar o workflow que vai tocar o projeto — esta é a porta de entrada do squad, e todo erro aqui se propaga para as fases seguintes.
+
+## A regra que governa
+**A trilha nasce do formato e do que já existe, não do tamanho aparente do pedido.** Entre duas trilhas possíveis, vale a mais leve que os gatilhos permitem.
+
+## Passos
+
+1. **Bandeira de conteúdo preexistente primeiro.** O pedido já tem roteiro, vídeo ou lição pronta e falta só publicar? → trilha **course-launch-cycle** (`workflows/course-launch-cycle.yaml`). Já tem curso pronto e o pedido é só auditar? → trilha **course-quality-review** (`workflows/course-quality-review.yaml`). Nenhuma das duas checa o resto dos passos: produzir de novo o que já existe é a armadilha mais cara desta task.
+
+2. **Bandeira de apresentação/mentoria.** Duração declarada de 30 a 90 minutos, uso interno ou pontual (pitch, treinamento de equipe, mentoria), sem sales page nem checkout envolvidos → trilha **presentation-creation** (`workflows/presentation-creation.yaml`). Pipeline curto: Compass define o outcome, Blueprint estrutura o flow, Deck monta os slides, Scribe escreve as notas do apresentador. Produção e lançamento ficam de fora — não é curso à venda.
+
+   ⚠️ **"Rápido" na fala do dono não é gatilho.** O gatilho é a duração e o destino (interno vs. venda), não o adjetivo usado no pedido.
+
+3. **Sem as duas bandeiras acima, é curso novo.** O dono já travou o formato final (só vídeo, ou só texto) E o curso não precisa de sales page própria (ex.: bônus de outro produto, lead magnet simples)? → trilha de formato único: **video-course-production** ou **written-course-creation**, conforme o formato travado.
+
+4. **Padrão: curso completo para plataforma ou venda.** Formato ainda em aberto, ou o curso vai ter preço e checkout próprios → trilha **full-course-creation** (`workflows/full-course-creation.yaml`), a mais pesada: Compass → Blueprint → Scribe + Lens + Deck → Gauge → Launchpad → Syllabus faz o quality gate final.
+
+5. **Zona cinzenta, resolvida por pergunta, não por sensação:**
+   - Entre presentation-creation e uma trilha de formato único (ex.: "workshop" que pode virar vídeo depois) → pergunta de uma linha ao dono: vira produto vendável ou fica interno?
+   - Entre trilha de formato único e full-course-creation (ex.: dono não decidiu se quer sales page) → pergunta de uma linha ao dono. Montar funil de venda é custo e tempo dele, não escolha do Syllabus.
+
+6. **Declare a trilha em uma linha**, com o gatilho: `Trilha full-course-creation: curso novo, formato em aberto, dono confirmou venda em plataforma — pipeline completo.`
+
+## Formato da saída
+Uma linha de declaração de trilha (como no passo 6) seguida do nome do arquivo de workflow correspondente, entregue para o próximo agente da cadeia acionar.
+
+## O que não vale
+- Rodar full-course-creation "pra garantir", quando o pedido já sinalizava trilha leve — isso gasta tempo e agentes que ninguém pediu.
+- Classificar pelo tamanho do texto do pedido em vez dos gatilhos (duração, existência prévia de conteúdo, decisão de venda).
+- Decidir sozinho a zona cinzenta quando a escolha muda o orçamento ou o prazo do dono.
+
+## Fontes no squad
+`agents/courses-orqx.md` (heurísticas de trigger → pipeline), `knowledge-base/course-format-patterns.md` (matriz de formatos e durações), `workflows/full-course-creation.yaml`, `workflows/presentation-creation.yaml`, `workflows/course-launch-cycle.yaml`, `workflows/course-quality-review.yaml`, `workflows/video-course-production.yaml`, `workflows/written-course-creation.yaml`.

package/squads/squad-courses/tasks/map-prerequisite-chain.md

@@ -17,30 +17,48 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Pre-requisito interno (modulo anterior) separado de externo (fora do curso)"
+  - "[ ] Cada pre-requisito interno verificado contra o conteudo que realmente ensina aquilo"
+  - "[ ] Nenhum modulo travado por pre-requisito 'default' nao verificado"
+  - "[ ] Pre-requisitos externos com criterio observavel, nao vago"
+  - "[ ] Nenhum pre-requisito redundante com conteudo re-ensinado depois"
 ---
 
-# Task: map-prerequisite-chain
-
-## Metadata
-- **Agent:** curriculum-designer (Compass)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Mapear a cadeia de pré-requisitos
 
 ## Objetivo
-Mapear pre-requisitos entre modulos
-
-## 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
+Documentar, módulo a módulo, o que o aluno precisa saber antes de entrar — separando o que o próprio curso ensina antes (pré-requisito interno) do que ele precisa trazer de fora (pré-requisito externo).
+
+## A regra que governa
+**Pré-requisito é dependência, não recomendação.** Só entra na cadeia o que o módulo realmente não funciona sem. `curriculum-mapping-guide.md` trata isso como o Passo 5 da montagem do currículo — e o erro mais caro aqui é confundir "seria bom saber" com "não dá pra seguir sem saber".
+
+## Passos
+
+1. **Para cada módulo, liste o que o aluno precisa entrando nele.** Separe em duas colunas: pré-requisito interno (um módulo anterior deste mesmo curso) e pré-requisito externo (ferramenta ou habilidade que o aluno tem que trazer de fora, ex.: "Excel básico").
+
+2. **Verifique a cadeia interna contra o conteúdo real.** Se o módulo 3 exige um conceito, esse conceito precisa aparecer de fato no módulo 1 ou 2 — não pode ser suposição. Cruze com a lista de lições de `structure-module-sequence`; se o conceito não está lá, ou o módulo anterior ganha uma lição nova, ou o "pré-requisito" não existe de verdade.
+
+3. **Caçe sobre-sequenciamento.** Alguns módulos entram em ordem linear por hábito, não por dependência real. `adult-learning-principles.md` nomeia isso como o que mata a autodireção: "sequências rígidas para conteúdo simples." Se um módulo não depende de nada antes dele, ele é candidato a virar opcional ou paralelo — devolva esse achado para `design-learning-path`.
+   ⚠️ **"Módulo N precisa do módulo N-1" como padrão automático não é medição.** Cada dependência tem que ser verificada, não assumida pela posição na lista.
+
+4. **Dê critério observável ao pré-requisito externo.** "Conhecimento básico de marketing" não é verificável. "Já rodou pelo menos uma campanha de tráfego pago" é. Pré-requisito externo vago vira desculpa depois, quando o aluno trava e ninguém sabe apontar onde.
+
+5. **Elimine redundância.** Se algo está listado como pré-requisito mas o próprio curso reensina aquilo em algum módulo, corte um dos dois: ou não é pré-requisito de verdade, ou a reintrodução é desperdício de tempo de aula.
+
+## Formato da saída
+Tabela por módulo, seguindo `curriculum-mapping-guide.md`:
+
+| Módulo | Pré-requisito interno | Pré-requisito externo |
+|---|---|---|
+| Módulo 1 | Nenhum | Nenhum |
+| Módulo 2 | Módulo 1 completo | Nenhum |
+| Módulo 3 | Módulo 2 completo | Conta ativa na ferramenta X |
+
+## O que não vale
+- Cadeia linear "N depende de N-1" aplicada a todos os módulos sem checar se é real.
+- Pré-requisito externo sem critério observável — vira ponto cego no suporte ao aluno.
+- Pré-requisito que o próprio curso reensina depois (redundância não resolvida).
+- Marcar como obrigatório o que era só recomendação — trava aluno à toa e prejudica a trilha opcional desenhada em `design-learning-path`.
+
+## Fontes no squad
+`knowledge-base/curriculum-mapping-guide.md` (Passo 5 — Prerequisites Chain, Common Curriculum Mistakes), `knowledge-base/adult-learning-principles.md` (o que mata a autodireção: sequência rígida sem necessidade).

package/squads/squad-courses/tasks/monitor-course-progress.md

@@ -17,30 +17,41 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Gate de cada fase concluída conferido contra o critério escrito no workflow, não contra impressão"
+  - "[ ] Causa do gate reprovado diagnosticada (pedagógica/conteúdo/produção) antes de qualquer retry"
+  - "[ ] Contagem de retries por fase registrada, com teto de 2"
+  - "[ ] Status reportado com fase atual, bloqueio nomeado e próximo responsável"
 ---
 
-# Task: monitor-course-progress
-
-## Metadata
-- **Agent:** courses-orqx (Syllabus)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Monitorar progresso do curso
 
 ## Objetivo
-Acompanhar progresso de criacao
-
-## 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
+Manter o estado real do projeto de curso visível a qualquer momento — qual fase está em andamento, quais gates passaram, e o que está travado — sem deixar um bloqueio silencioso avançar para a fase seguinte.
+
+## A regra que governa
+**Status é o que o gate da fase diz, não o que o agente reportou ter feito.** Cada fase do workflow ativo (`full-course-creation.yaml`, `presentation-creation.yaml` etc.) tem um `gate:` escrito — é contra ele que se mede, não contra a lista de tarefas marcadas.
+
+## Passos
+
+1. **Identifique a fase corrente e seus outputs esperados** no workflow em execução (ex.: fase-2-curriculum espera `curriculum-map.md`). Output ausente é fase não concluída, mesmo que o agente reporte "pronto".
+
+2. **Verifique o gate da fase**, não a lista de tasks. O gate é a condição escrita (ex.: "Curriculum validado para alinhamento e completude") — confira contra o output real, não contra o relato do agente responsável.
+
+3. **Gate reprovado: diagnostique a causa antes de qualquer retry.** Segue a heurística da casa (`agents/courses-orqx.md`): falha pedagógica volta para Compass, falha de conteúdo volta para Scribe, falha de produção volta para Lens. Retry sem diagnosticar reenvia o mesmo agente para o mesmo erro.
+
+   ⚠️ **Diagnosticar não é reexecutar e ver se resolve.** É nomear o que especificamente falhou no output antes de decidir quem corrige.
+
+4. **Registre a tentativa e conte.** Teto de 2 retries por fase. Na segunda reprovação seguida, não tente uma terceira — é zona cinzenta: pergunta de uma linha ao dono se quer replanejar o escopo, trocar de abordagem, ou seguir com uma ressalva registrada.
+
+5. **Reporte o status em uma síntese curta**: fase atual, gates já passados, bloqueio nomeado (se houver), próximo agente responsável, e contagem de retry se aplicável. Isso é o que o dono ou o próximo agente da cadeia precisa para agir, não um relatório de tudo que já aconteceu.
+
+## Formato da saída
+Uma linha de status por fase relevante, no formato: `Fase 3 (Conteúdo) — em andamento, Scribe. Fase 2 (Curriculum) — gate passado. Fase 1 (Escopo) — aprovado pelo dono.` Quando há bloqueio: `Fase 5 (Assessments) — bloqueada, retry 1/2: quizzes reprovados no gate Bloom's-aligned, devolvido a Gauge.`
+
+## O que não vale
+- Marcar fase como concluída porque o agente disse que terminou, sem o output existir.
+- Rodar um terceiro retry na mesma fase sem levar a decisão ao dono.
+- Relatório de status que lista tudo que aconteceu no projeto em vez do que está travado agora.
+
+## Fontes no squad
+`agents/courses-orqx.md` (heurística "Quality gate falha em alguma fase" e regra de diagnóstico + max 2 retries), `workflows/full-course-creation.yaml`, `workflows/course-quality-review.yaml` (gates de cada fase, usados como critério de medição).