iron-edge 1.2.0 → 2.0.1

package/squads/squad-courses/tasks/define-competency-framework.md

@@ -17,30 +17,49 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Decidido se o curso justifica Competency-Based Design"
+  - "[ ] Cada competencia usa a formula verbo + objeto + condicao + padrao"
+  - "[ ] Sub-habilidades sequenciadas de pre-requisito ate terminal"
+  - "[ ] Padrao de desempenho e mensuravel (nao 'bem' ou 'corretamente')"
+  - "[ ] Cada sub-habilidade aponta para um modulo/licao futuro"
 ---
 
-# Task: define-competency-framework
-
-## Metadata
-- **Agent:** curriculum-designer (Compass)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Definir framework de competências
 
 ## Objetivo
-Definir framework de competencias
-
-## 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 se o curso precisa de desenho por competências (Competency-Based Design) e, quando precisar, decompor a competência terminal em sub-habilidades sequenciadas — do pré-requisito até o domínio.
+
+## A regra que governa
+**"O aluno passa quando consegue demonstrar a habilidade, não quando assistiu ao vídeo."** É a definição de CBD em `instructional-design-frameworks.md`, e ela só vale a pena quando alguém de fora vai julgar o resultado do aluno — certificação profissional, treinamento corporativo, curso vocacional. Fora disso, os outcomes de `define-learning-outcomes` já bastam e este passo fica leve.
+
+## Passos
+
+1. **Decida se este curso pede CBD.** `instructional-design-frameworks.md` lista quando usar: certificações profissionais (OAB, CRC, CPA), treinamento corporativo com outcome verificável, cursos vocacionais (contabilidade, direito, saúde), ou qualquer curso em que empregador/cliente vai julgar o output do aluno.
+   ⚠️ **Mini-curso e lead magnet não pedem CBD.** Construir escada de sub-habilidades e critério de domínio para um curso de 30-90 minutos é esforço que ninguém vai usar — mantenha nos outcomes simples.
+
+2. **Escreva a competência usando a fórmula.** `[Verbo de ação] [objeto] [condição] para [padrão de desempenho]`. Exemplo da própria referência: "Classificar transações contábeis por categoria IFRS usando o plano de contas CPC com 90% de precisão." O padrão tem que ser um número, um critério de aceite ou uma condição de aprovação — nunca um advérbio.
+   ⚠️ **"Fazer bem" e "corretamente" não são padrão.** Se não dá pra saber quando alguém passou do "quase lá" pro "domina", reescreva o padrão.
+
+3. **Decomponha em sub-habilidades.** Use a hierarquia de aprendizagem de Gagné (citada em `instructional-design-frameworks.md`): quebre a competência terminal nas habilidades habilitadoras que a compõem, da mais básica à mais avançada.
+
+4. **Sequencie de pré-requisito a terminal.** Monte a escada: cada sub-habilidade só aparece depois das que ela depende. Esta escada alimenta diretamente `map-prerequisite-chain`, não a substitui.
+
+5. **Defina o critério de domínio antes do conteúdo.** CBD manda desenhar a avaliação de domínio primeiro ("mastery assessments first") — aqui você só declara QUAL é o critério que prova a competência; a avaliação em si é escopo de `assessment-creator`, não desta task.
+
+## Formato da saída
+Tabela: competência terminal, lista de sub-habilidades em ordem, e critério de domínio de cada uma.
+
+| Competência | Sub-habilidade | Ordem | Critério de domínio |
+|---|---|---|---|
+| Recomendar o regime tributário ideal com 90% de acerto | Calcular carga tributária no Simples Nacional | 1 (pré-requisito) | Calcula sem erro em 3 cenários seguidos |
+| (mesma) | Comparar Simples x Lucro Presumido x Lucro Real | 2 | Justifica a escolha por escrito |
+| (mesma) | Recomendar regime para caso real | 3 (terminal) | Recomendação bate com o gabarito do especialista |
+
+## O que não vale
+- Aplicar CBD inteiro (escada + critério de domínio) num curso que só precisa de outcomes simples — desperdício que atrasa o pipeline.
+- Competência sem condição ou sem padrão numérico — vira frase de marketing, não framework.
+- Sub-habilidades fora de ordem de dependência, ou copiadas do índice de módulos sem checar se realmente é pré-requisito.
+- Desenhar a avaliação completa aqui — este passo declara o critério, não escreve a prova.
+
+## Fontes no squad
+`knowledge-base/instructional-design-frameworks.md` (seção Competency-Based Design — CBD, fórmula da declaração de competência, tabela CBD vs. Traditional).

package/squads/squad-courses/tasks/define-course-scope.md

@@ -17,30 +17,43 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Persona da audiência com 3 a 5 traços observáveis, não um adjetivo genérico"
+  - "[ ] Formato escolhido contra a Format Selection Matrix, com a linha que justifica"
+  - "[ ] Nível e pré-requisitos declarados a partir de sinal do pedido, não presumidos"
+  - "[ ] Formato ou tamanho incerto devolvido ao dono em uma linha antes de seguir para Compass"
 ---
 
-# Task: define-course-scope
-
-## Metadata
-- **Agent:** courses-orqx (Syllabus)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Definir escopo do curso
 
 ## Objetivo
-Definir escopo: audiencia, nivel, formato
-
-## 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 documento de escopo — audiência, nível, formato e tamanho estimado — que Compass usa como ponto de partida para o mapeamento curricular. Escopo errado aqui vira retrabalho de curriculum inteiro depois.
+
+## A regra que governa
+**Formato serve o objetivo de negócio do curso, não o inverso.** Nenhum formato entra no escopo sem passar pela Format Selection Matrix de `course-format-patterns.md` — "parece mais bonito em vídeo" não é critério.
+
+## Passos
+
+1. **Escreva a persona da audiência com 3 a 5 traços observáveis**: nível de experiência prévia, contexto de uso do conteúdo, e o que ela já tenta e não consegue fazer sozinha. Traço vago ("iniciantes", "profissionais ocupados") sem um sinal concreto do pedido não conta — volta pro dono.
+
+2. **Declare o nível a partir de sinal do pedido**, não de estimativa: o dono mencionou pré-requisito técnico? Mencionou "do zero"? Mencionou certificação profissional (OAB, CRC, CPA)? Cada um desses aponta um nível diferente. Sem sinal nenhum, pergunta de uma linha ao dono — nível errado desalinha toda a sequência de Bloom que Compass vai construir em cima disso.
+
+3. **Escolha o formato pela Format Selection Matrix** (`knowledge-base/course-format-patterns.md`): cruze duração desejada, faixa de preço pretendida e taxa de conclusão que o objetivo de negócio exige. Um curso para reter aluno de ticket alto pede workshop ou cohort (85–95% de conclusão); um lead magnet pede mini-curso; conteúdo denso em framework pede curso escrito.
+
+   ⚠️ **Formato não é gosto do Syllabus.** Se dois formatos atendem igualmente ao objetivo (ex.: vídeo vs. escrito para o mesmo público), a escolha muda custo de produção e prazo — isso é decisão do dono, registrada em uma linha, não escolhida por preferência.
+
+4. **Confirme pré-requisitos explicitamente** — o que o aluno precisa saber ou ter antes do módulo 1. Se o pedido não diz, declare "nenhum pré-requisito" como decisão, não como omissão.
+
+5. **Estime o tamanho inicial como faixa, não como número final**: quantidade aproximada de módulos e duração total, usando os intervalos de `course-format-patterns.md` (ex.: vídeo-curso: 2–10h, 3–8 módulos). Essa faixa é previsão para Compass planejar — quem mede o tamanho real é o curriculum-map depois.
+
+6. **Registre o documento de escopo** com os cinco campos acima, pronto para Compass abrir o mapeamento curricular.
+
+## Formato da saída
+Documento curto (persona, nível, formato + justificativa de uma linha, pré-requisitos, faixa de tamanho), no formato: `Escopo: audiência [persona] · nível [X] · formato [Y, porque Z] · pré-requisitos [W] · estimativa [N módulos / M horas].`
+
+## O que não vale
+- Escolher formato por padrão (sempre vídeo, porque é o mais comum) sem checar a matriz contra o objetivo de negócio.
+- Persona escrita em uma palavra ("empreendedores") sem os traços que mudam o design da lição.
+- Prometer um número fechado de módulos nesta fase — é faixa, e a faixa que sai daqui não é o que Compass necessariamente vai confirmar.
+
+## Fontes no squad
+`knowledge-base/course-format-patterns.md` (Format Selection Matrix e componentes de cada formato), `knowledge-base/curriculum-mapping-guide.md` (Passo 1 — Define Course Outcomes, referência para o que vem depois do escopo), `agents/courses-orqx.md`.

package/squads/squad-courses/tasks/define-learning-outcomes.md

@@ -17,30 +17,48 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Cada outcome comeca com verbo de Bloom, nao com topico"
+  - "[ ] Pelo menos metade dos outcomes esta em Apply ou acima"
+  - "[ ] Cada outcome tem uma forma observavel de provar que foi atingido"
+  - "[ ] Numero de outcomes bate com a duracao do curso (curto = 1-3, longo = ate 7)"
+  - "[ ] Outcomes marcados como Core vs Extension"
 ---
 
-# Task: define-learning-outcomes
-
-## Metadata
-- **Agent:** curriculum-designer (Compass)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Definir learning outcomes
 
 ## Objetivo
-Definir learning outcomes mensuaveis
-
-## 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 de 3 a 7 outcomes mensuráveis que descrevem o que o aluno consegue FAZER ao final do curso — a base de tudo que vem depois no backward design.
+
+## A regra que governa
+**Se não dá pra escrever um outcome mensurável, o tópico não está pronto para virar aula.** Outcome é comportamento observável, não "entender" ou "conhecer" — é o que a `curriculum-mapping-guide.md` chama de regra do Passo 1, e é o motivo de este ser o primeiro passo do backward design: tudo que vem depois (módulo, lição, avaliação) existe para provar que o outcome foi atingido.
+
+## Passos
+
+1. **Nomeie a transformação.** De onde o aluno parte (o que ele já sabe, o que ele já sofre) para onde ele chega — antes de escrever qualquer outcome. `adult-learning-principles.md` é explícito: adultos precisam saber POR QUE antes de aprender ("need to know"); um outcome sem transformação clara não responde essa pergunta.
+
+2. **Escreva cada outcome com verbo de Bloom.** Use a tabela de `instructional-design-frameworks.md` (Bloom's Taxonomy Revisada): comece pelo verbo de ação (classificar, construir, recomendar, projetar), não por substantivo de tópico. Outcomes de curso mira **Apply (nível 3) ou acima** — a mesma tabela lista o nível mínimo por tipo de curso (ex.: fundamentos de contabilidade → Apply; análise jurídica → Analyze; consultoria estratégica → Evaluate).
+   ⚠️ **"Entender X" e "conhecer Y" não são outcomes** — são tópicos disfarçados. Se o verbo é "entender", reescreva até virar algo que dá pra observar de fora.
+
+3. **Calibre a quantidade pela duração.** Curso curto (menos de 2h) trava em 1-3 outcomes — cortar tudo que não serve direto a eles. Curso maior aguenta até 7. Outcome demais em curso curto dilui o que deveria ser foco.
+
+4. **Marque prioridade.** Classifique cada outcome como **Core** (o curso falha sem ele) ou **Extension** (enriquece, mas não é o motivo de compra) — usando a coluna Priority da tabela de outcomes em `curriculum-mapping-guide.md`.
+
+5. **Teste a mensurabilidade.** Para cada outcome, pergunte: "que evidência prova que o aluno chegou aqui?" Se a resposta é vaga ("ele vai saber mais"), o outcome ainda não está pronto — volte ao passo 2.
+
+## Formato da saída
+Tabela com uma linha por outcome, seguindo `curriculum-mapping-guide.md`:
+
+| # | Outcome Statement | Bloom's Level | Priority |
+|---|---|---|---|
+| 1 | Calcular o EBITDA de uma empresa a partir de um DRE real | Apply | Core |
+| 2 | Recomendar o regime tributário ideal para um cenário de faturamento dado | Evaluate | Core |
+| 3 | Montar um dashboard de indicadores financeiros no Excel | Create | Extension |
+
+## O que não vale
+- Outcome que é lista de conteúdo ("módulo sobre fluxo de caixa") em vez de comportamento do aluno.
+- Outcome no nível Remember/Understand quando o curso vende resultado prático — maioria tem que empurrar para Apply+.
+- Mais de 7 outcomes, ou outcomes redundantes que descrevem a mesma habilidade com palavras diferentes.
+- Outcome sem prioridade marcada — sem isso, `structure-module-sequence` não sabe o que é obrigatório e o que é bônus.
+
+## Fontes no squad
+`knowledge-base/curriculum-mapping-guide.md` (Passo 1 e tabela de outcomes), `knowledge-base/instructional-design-frameworks.md` (Bloom's Taxonomy Revisada, tabela de nível mínimo por tipo de curso), `knowledge-base/adult-learning-principles.md` (need to know, motivação).

package/squads/squad-courses/tasks/define-lesson-objectives.md

@@ -17,30 +17,43 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Objetivo usa verbo de Bloom observável, não 'entender' ou 'aprender'"
+  - "[ ] Um único objetivo por lição — nenhum 'e' escondendo um segundo verbo"
+  - "[ ] Nível de Bloom coerente com a posição da lição no módulo/curso"
+  - "[ ] Nível mínimo do domínio respeitado, se o curso for profissional/certificação"
+  - "[ ] Objetivo escrito no formato do template, pronto pra virar hook e checkpoint"
 ---
 
 # Task: define-lesson-objectives
 
-## Metadata
-- **Agent:** lesson-architect (Blueprint)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Definir objetivos de cada licao
-
-## 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, para cada lição, um objetivo de aprendizagem verificável — a frase que decide o que essa lição ensina e o que ela não ensina.
+
+## A regra que governa
+**Todo objetivo nasce de um verbo de Bloom observável.** Se ninguém consegue ver o aluno fazendo o verbo, o objetivo não serve — "entender" e "aprender" não são medíveis, não entram na frase final.
+
+## Passos
+1. **Puxe o outcome do módulo e a posição da lição.** O objetivo da lição não nasce do nada — ele é o outcome do módulo (saída do curriculum-designer) quebrado no tamanho de uma aula. Módulos 1-2 do curso miram Remember/Understand; módulos 3-5 empurram para Apply/Analyze; o projeto final exige Evaluate ou Create (tabela em `instructional-design-frameworks.md`).
+
+2. **Escolha o verbo de Bloom certo pro nível da lição.** Use a tabela de verbos revisada (Anderson & Krathwohl) em `instructional-design-frameworks.md` — não o verbo que soa bem, o verbo do nível que essa lição precisa alcançar.
+   ⚠️ Cursos profissionais têm piso: contabilidade não desce de Apply, direito não desce de Analyze, consultoria estratégica exige Evaluate — a tabela por domínio está no mesmo arquivo.
+
+3. **Escreva no formato do template.** "Ao final desta lição, o aluno será capaz de [VERBO DE BLOOM] [OBJETO ESPECÍFICO]" — é a seção Learning Objective de `lesson-plan-template.md`. Nada de objetivo solto fora desse formato; é ele que a task `create-lesson-outline` consome em seguida.
+
+4. **Garanta um objetivo por lição.** Se a frase tem dois verbos de ação ligados por "e" ("explicar e aplicar X"), são dois objetivos — ou a lição vira duas, ou você escolhe qual dos dois é o desta.
+   ⚠️ A armadilha mais comum: um objetivo "generoso" que promete Understand e Apply na mesma lição de 8 minutos. Ninguém sai da aula tendo alcançado os dois.
+
+5. **Valide contra o checklist da casa.** Rode a seção "Objective and Focus" de `lesson-quality-checklist.md` antes de entregar: verbo de Bloom presente, foco único, título batendo com o conteúdo.
+
+## Formato da saída
+Um objetivo por lição, na frase do template, com o nível de Bloom anotado ao lado:
+> **Lição 3.2** — "Ao final desta lição, o aluno será capaz de **calcular** o ponto de equilíbrio a partir de uma DRE real." *(Bloom: Apply)*
+
+## O que não vale
+- Objetivo com "entender", "aprender", "conhecer" ou "se familiarizar" — nenhum é observável.
+- Dois verbos de ação num objetivo só.
+- Nível de Bloom estagnado — todas as lições do módulo 4 ainda pedindo "listar" ou "identificar".
+- Objetivo copiado do outcome do módulo sem recorte pro tamanho de uma lição.
+
+## Fontes no squad
+`knowledge-base/instructional-design-frameworks.md` (Bloom's Taxonomy Revised, tabela por domínio), `templates/lesson-plan-template.md` (seção Learning Objective), `checklists/lesson-quality-checklist.md` (Objective and Focus).

package/squads/squad-courses/tasks/design-certification-criteria.md

@@ -17,30 +17,51 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] O nível de competência exigido (Declarative/Procedural/Conditional/Adaptive) está declarado"
+  - "[ ] Se o certificado tem peso profissional, o dono confirmou o nível mínimo aceitável"
+  - "[ ] O standard de mastery é mensurável (nota mínima, projeto aprovado por rubrica, etc.)"
+  - "[ ] Nenhum critério é baseado só em presença ou % de conteúdo assistido"
 ---
 
 # Task: design-certification-criteria
 
-## Metadata
-- **Agent:** assessment-creator (Gauge)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Projetar criterios de certificacao
-
-## 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 os critérios que um aluno precisa cumprir para receber o certificado — prova de competência real no nível que o domínio exige, não prova de presença.
+
+## A regra que governa
+**O certificado promete o nível de competência que o curso de fato verifica.** Certificar por conclusão de aulas quando o certificado vai ser usado como credencial profissional é vender uma competência que nunca foi medida.
+
+## Passos
+
+1. **Determinar o nível de competência exigido pelo tipo de curso.** Use os 4 níveis de `assessment-design-guide.md` (Competency Verification: Declarative → sabe dizer a regra; Procedural → segue o processo; Conditional → sabe quando aplicar; Adaptive → lida com situação nova) e a tabela de níveis mínimos por domínio de `instructional-design-frameworks.md` (ex.: fundamentos de contabilidade → Apply; análise jurídica → Analyze; compliance → Apply; consultoria estratégica → Evaluate). Regra geral do guia: cursos com aplicação profissional chegam no mínimo ao nível 3 (Conditional); cursos de assessoria/estratégia chegam ao nível 4 (Adaptive).
+
+2. **Proteger o dono quando o certificado tem peso profissional.** Se o certificado vai ser usado como credencial (LinkedIn, portfólio, exigência de cliente ou empregador), pergunta de uma linha ao dono: *"Este certificado precisa comprovar competência de nível [X]? Se sim, os critérios abaixo precisam incluir [evidência Y]."* Emitir certificado que promete competência que o curso nunca verificou é dano à reputação de quem assina o certificado — não é decisão que se toma sozinho.
+
+3. **Traduzir o nível em standard mensurável.** Nota mínima com retry permitido (ex.: 80% no exame final), projeto final aprovado pela rubrica em nível "Proficiente" ou acima, ou combinação dos dois (`assessment-design-guide.md`, Performance-Based Grading — criterion-referenced, contra um padrão, não contra os colegas).
+
+4. **Publicar o standard antes do curso começar.** Regra do guia: "always publish the performance standard upfront." O aluno precisa saber, desde a matrícula, o que precisa demonstrar pra ganhar o certificado — não descobrir no fim.
+
+5. **Excluir presença como critério isolado.** Presença ou % assistido pode ser pré-requisito pra acessar a avaliação final, mas nunca substitui a prova de competência.
+   ⚠️ "Completou 100% das aulas" é o critério mais fácil de medir e o menos relacionado a competência real — é o disfarce mais comum de certificado de participação vendido como certificado de competência.
+
+## Formato da saída
+
+```
+## Critérios de Certificação — [curso]
+Nível de competência exigido: [Declarative/Procedural/Conditional/Adaptive]
+
+Para receber o certificado, o aluno precisa:
+1. [critério mensurável 1 — ex.: nota mínima de 80% no exame final]
+2. [critério mensurável 2 — ex.: projeto final aprovado em nível Proficiente+ pela rubrica]
+3. [pré-requisito de acesso, se houver — ex.: acesso liberado após 100% dos módulos]
+```
+
+## O que não vale
+- Certificar só por presença ou % de conteúdo assistido.
+- Certificado sem standard publicado antes do curso começar.
+- Nível de competência abaixo do mínimo exigido pelo domínio (ex.: compliance certificado em nível Declarative).
+- Decidir sozinho o nível de um certificado com peso profissional, sem checar com o dono.
+
+## Fontes no squad
+- `knowledge-base/assessment-design-guide.md` — Competency Verification, Performance-Based Grading
+- `knowledge-base/instructional-design-frameworks.md` — Bloom's para cursos de domínio específico (tabela de nível mínimo por tipo de curso)

package/squads/squad-courses/tasks/design-email-sequence.md

@@ -17,10 +17,11 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Sequência identificada (pré-lançamento / semana de lançamento / onboarding)"
+  - "[ ] Cada e-mail tem tom e CTA próprios, conforme o tipo"
+  - "[ ] Assunto, primeira linha, bullets do corpo e CTA escritos por e-mail"
+  - "[ ] Métrica de abertura/clique marcada como benchmark, não promessa"
+  - "[ ] Nenhum e-mail pede desculpa por vender"
 ---
 
 # Task: design-email-sequence
@@ -31,16 +32,31 @@ Checklist:
 - **Complexity:** STANDARD
 
 ## Objetivo
-Projetar sequencia de emails
-
-## 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 brief da sequência de e-mails do lançamento (ou onboarding), com objetivo e tom de cada e-mail definidos — não só o assunto.
+
+## A regra que governa
+**Cada e-mail da sequência tem um objetivo e um tom próprios — e a casa nunca pede desculpa por vender: vender é avisar de um prazo que ajuda o aluno a decidir.**
+
+## Passos
+
+1. **Definir qual sequência está sendo desenhada**: pré-lançamento, semana de lançamento (usa o calendário day-by-day de `plan-launch-sequence`), ou onboarding pós-matrícula (ver `design-student-onboarding`).
+
+2. **Para cada e-mail, aplicar a tabela "Launch Email Sequence — Tone Guide"** de `course-launch-strategy.md`: tipo → tom → CTA. Abertura, objeção, prova social, escassez e fechamento não têm o mesmo tom.
+   ⚠️ **Tom errado no e-mail errado quebra a sequência inteira** — urgência com tom empático e sem prazo não gera decisão; fechamento pedindo desculpa por vender também não.
+
+3. **Escrever assunto + primeira linha + bullets do que o corpo cobre + CTA** de cada e-mail — não escreva a copy completa, isto é brief para quem finaliza a copy.
+
+4. **Marcar a métrica-alvo de abertura e clique como benchmark de mercado** (tabela "Launch Metrics": 25-45% abertura, 3-8% clique), nunca como promessa de resultado desta sequência específica.
+
+5. **Se for onboarding**, siga a ordem: boas-vindas → como acessar → primeira lição sugerida → comunidade → expectativa de ritmo — conforme a seção "Student Onboarding" de `pre-launch-checklist.md`.
+
+## Formato da saída
+Tabela: dia/gatilho · tipo de e-mail · tom · assunto · CTA · o que o corpo precisa cobrir (bullets).
+
+## O que não vale
+- Pedir desculpa por vender ou suavizar o CTA de fechamento.
+- Prometer taxa de abertura/clique como resultado garantido desta sequência.
+- Escrever a sequência inteira no mesmo tom, do início ao fim — cada e-mail tem um papel diferente na semana.
+
+## Fontes no squad
+`knowledge-base/course-launch-strategy.md`, `checklists/pre-launch-checklist.md`.

package/squads/squad-courses/tasks/design-interactive-elements.md

@@ -17,30 +17,52 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Todo slide de exercício tem prompt específico, tempo e entrega definidos"
+  - "[ ] Slide de retrieval practice existe na abertura e no fechamento da aula"
+  - "[ ] Slide de debrief é separado do slide de exercício"
+  - "[ ] Retrieval não virou avaliação disfarçada"
 ---
 
-# Task: design-interactive-elements
-
-## Metadata
-- **Agent:** slide-designer (Deck)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Projetar os elementos interativos
 
 ## Objetivo
-Projetar elementos interativos
-
-## 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 os slides que pedem ação do aluno — exercício, retrieval practice, debrief — com prompt, tempo e formato de entrega definidos.
+
+## A regra que governa
+**Interação sem prompt específico é enfeite.** `checklists/lesson-quality-checklist.md` reprova exercício que só manda "refletir sobre isso" sem uma pergunta clara. Um slide interativo sem prompt acionável não gera prática — gera silêncio.
+
+## Passos
+
+1. **Os 4 campos obrigatórios do slide de exercício.** Título do exercício, prompt específico e acionável, tempo, e o que o aluno entrega — conforme `templates/presentation-template.md` ("Exercise Slide"). Um exercício sem os 4 campos não está pronto para virar slide.
+
+2. **Timer visível quando o tempo é fechado.** A tabela "Slide Types and When to Use Each" (`presentation-design-principles.md`) define o layout do slide de exercício como "prompt claro + timer". Sem o timer visual, o exercício não tem limite perceptível — e vira o bloco que estoura o tempo do módulo.
+
+3. **Retrieval practice como slide dedicado, não fala solta.** `adult-learning-principles.md` mostra que recuperar informação fixa memória mais que reler ou reassistir (Roediger & Karpicke, 2006: 50% a mais de retenção após uma semana). Abrir a aula com 1-3 perguntas sobre a aula anterior e fechar com 1-3 perguntas sobre o conteúdo atual — cada bloco vira um slide próprio, não uma linha na nota do apresentador.
+
+4. **Problema antes da teoria, quando fizer sentido.** Ciclo de Kolb e Problem-Based Learning (`adult-learning-principles.md`): apresentar o problema real antes de ensinar o framework aumenta a prontidão para aprender. Nesses casos, o slide de exercício pode vir **antes** do slide de conceito na sequência, não só depois.
+
+5. **Debrief é slide próprio, com perguntas fixas.** 2-3 perguntas de `templates/presentation-template.md` ("Exercise Debrief"): "O que você percebeu?", "O que te surpreendeu?" — nunca embutidas no mesmo slide do exercício, porque são dois momentos diferentes da sessão.
+
+6. **Interatividade em curso gravado não é a mesma de workshop ao vivo.** Sem grupo para debriefar em tempo real, o elemento interativo vira prompt de reflexão com destino definido — postar a resposta na comunidade (`engagement-retention-patterns.md`, Pattern 4). ⚠️ **Retrieval não pode virar prova disfarçada.** A régua do KB é explícita: "Retrieval ≠ testing for grades" — a pergunta é ferramenta de aprendizagem, não de nota.
+
+## Formato da saída
+```
+Slide 12 — Exercício
+Prompt: "Escreva o preço atual do seu produto principal e o que
+você acha que ele deveria valer. Guarde os dois números."
+Tempo: 5 min
+Entrega: anotado no handout, revisitado no Slide 14
+
+Slide 13 — Debrief
+"O que te surpreendeu na diferença entre os dois números?"
+"Alguém quer compartilhar o que escreveu?"
+```
+
+## O que não vale
+- "Discuta com seu colega" sem pergunta nenhuma.
+- Exercício sem tempo definido.
+- Slide de exercício e slide de debrief fundidos em um só.
+- Retrieval practice virando prova com nota, quebrando a confiança do aluno em errar.
+
+## Fontes no squad
+`templates/presentation-template.md`, `knowledge-base/adult-learning-principles.md`, `knowledge-base/engagement-retention-patterns.md`, `checklists/lesson-quality-checklist.md`.

package/squads/squad-courses/tasks/design-intro-outro.md

@@ -6,41 +6,52 @@ atomic_layer: Task
 elicit: false
 
 Entrada:
-  - campo: context
+  - campo: course_branding
     tipo: object
-    origem: "pipeline or manual"
+    origem: "courses-orqx ou briefing do curso"
     obrigatorio: true
 
 Saida:
-  - campo: resultado
+  - campo: intro_outro_spec
     tipo: document
-    destino: "next phase"
+    destino: "toda aula do curso (padrao fixo aplicado no roteiro de cada uma)"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Intro abaixo de 10 segundos"
+  - "[ ] Outro abaixo de 15 segundos, com CTA unico"
+  - "[ ] Nenhum CTA de plataforma social (curtir/inscrever) dentro do curso"
+  - "[ ] Elementos fixos e variaveis por aula estao claramente separados"
 ---
 
-# Task: design-intro-outro
-
-## Metadata
-- **Agent:** production-director (Lens)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Projetar intro e outro
 
 ## Objetivo
-Projetar intro e outro
-
-## 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 o padrão fixo de abertura e fechamento que se repete em toda aula do curso, curto o bastante para não ser pulado.
+
+## A regra que governa
+Intro e outro existem para dar identidade sem custar atenção — acima de 10s de intro ou 15s de outro, o aluno pula.
+
+## Passos
+
+1. **Definir os elementos fixos da intro:** nome do curso, logo, música de fundo curta. Sem jingle longo — o aluno que já está na segunda aula pula qualquer coisa que se repete e demora. Duração-alvo: menos de 10 segundos.
+
+2. **Definir os elementos fixos do outro:** ponte pra próxima aula ("na próxima aula, vamos ver...") + um CTA único (exercício, download, ou seguir pra próxima aula) + logo. Duração-alvo: menos de 15 segundos.
+   ⚠️ **Não copiar convenção de YouTube público** — "curte e se inscreve", contador de notificação, pedido de comentário. O aluno já pagou pelo curso; o CTA do outro é sobre continuar aprendendo, não sobre engajamento de plataforma aberta.
+
+3. **Separar o que é fixo do que muda por aula.** Logo, música e timing não mudam nunca — é isso que dá consistência visual e profissionalismo. O que muda: o título da aula na intro, e o tema da próxima aula no outro.
+
+4. **Escrever o texto exato** que aparece ou é falado no outro — a linha "na próxima aula, vamos ver [X]" precisa estar pronta pra encaixar no roteiro de cada aula sem reescrita.
+
+5. **Entregar a especificação de forma independente de ferramenta.** Esta task define o quê (texto, elementos, ordem, timing) — a montagem em motion graphics, template de slide, ou animação simples é escolha de quem executa a edição.
+
+## Formato da saída
+Documento com duas seções — Intro e Outro — cada uma com: elementos fixos, duração-alvo, texto/copy exato, e o que varia por aula. Exemplo de linha do outro: `Texto: "Na próxima aula, você vai aprender [TEMA_DA_PROXIMA]. Te vejo lá." | Duração: 12s | CTA: seguir para a próxima aula`.
+
+## O que não vale
+- Intro acima de 10s ou outro acima de 15s.
+- Jingle longo ou animação de abertura demorada.
+- CTA genérico de rede social dentro de um curso pago.
+- Intro ou outro que muda de estrutura entre aulas — a consistência é o motivo de a peça existir.
+
+## Fontes no squad
+`video-production-guide.md` (seção Intro and Outro).