iron-edge 1.2.0 → 2.0.0

package/squads/squad-courses/tasks/design-knowledge-checkpoints.md

@@ -17,30 +17,44 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Abertura recupera a lição anterior; fechamento testa a lição atual — nunca só um dos dois"
+  - "[ ] Pergunta é de recall aberto, não de reconhecimento fácil"
+  - "[ ] Técnica escolhida bate com o tipo de conteúdo (predict-then-check, one-sentence summary etc.)"
+  - "[ ] Nível da pergunta alinhado ao Bloom-alvo da lição"
+  - "[ ] Marcado como formativo — se pedir nota, foi encaminhado para @assessment-creator"
 ---
 
 # Task: design-knowledge-checkpoints
 
-## Metadata
-- **Agent:** lesson-architect (Blueprint)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Projetar checkpoints de aprendizado
-
-## 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 onde, com que técnica e em que nível cognitivo entra o checkpoint de conhecimento da lição — o ponto formativo que confirma se o aluno reteve o que acabou de aprender.
+
+## A regra que governa
+**O checkpoint testa retrieval, não reconhecimento.** Ele pede pro aluno puxar da memória sem olhar a lição de novo — nunca escolher entre opções óbvias. Reconhecimento mede se o aluno sabe reconhecer a resposta certa; retrieval mede se ele consegue produzi-la sozinho, e é isso que fica na memória (Testing Effect, Roediger & Karpicke).
+
+**Fronteira com `@assessment-creator`:** esta task decide **posição, técnica e nível** do checkpoint formativo dentro da lição. Escrever quiz com nota, self-eval de módulo ou rubrica é escopo de `create-quiz-questions` e `create-self-evaluation`, do `@assessment-creator` — não desta task.
+
+## Passos
+1. **Abra a lição com 1-3 perguntas de recall da lição ANTERIOR**, não da atual. É o "stimulate recall" de Gagné e também Spaced Repetition (`adult-learning-principles.md`) — a primeira lição do módulo não tem o que recuperar, então começa direto no hook.
+
+2. **Feche a lição com 1-3 perguntas sobre o conteúdo ATUAL**, sem que o aluno possa consultar as notas — cued recall, não reconhecimento.
+   ⚠️ "Qual das opções abaixo..." é reconhecimento fácil, não retrieval. "Quais são os 3 passos de X?" sem opções na tela é a pergunta que de fato retém.
+
+3. **Escolha a técnica pelo Formative Assessment Toolkit** (`assessment-design-guide.md`), casada com o tipo de conteúdo: *predict-then-check* pra cenários e decisões, *one-sentence summary* pra definições e frameworks, *muddiest point* ou *exit ticket* depois de conceitos densos, *3-2-1* em revisão de módulo.
+
+4. **Alinhe o nível da pergunta ao Bloom-alvo da lição** (saída de `sequence-difficulty-progression`). Se o objetivo é Apply, o checkpoint não pode ser só "liste" — precisa pedir que o aluno resolva algo, não que recite.
+
+5. **Marque explicitamente que é formativo, não somativo.** Isso não gera nota nem certificado. Se o pedido original exigir avaliação com nota (quiz de módulo, self-eval, prova prática), delegue para as tasks correspondentes do `@assessment-creator` em vez de tentar resolver aqui.
+
+## Formato da saída
+> **Abertura (3.2):** recall de 3.1 — "Quais os dois componentes do preço de venda que vimos na lição anterior?"
+> **Fechamento (3.2):** técnica *predict-then-check*, nível Apply — "Dado este cenário de margem negativa, o que você ajustaria primeiro?"
+
+## O que não vale
+- Checkpoint de múltipla escolha decorativo, sem função de retrieval.
+- Ausência de checkpoint em lição com objetivo Apply ou acima.
+- Pergunta de fechamento que testa um objetivo diferente do desta lição.
+- Escrever o quiz graded ou o self-eval de módulo aqui — isso pertence ao `@assessment-creator`.
+
+## Fontes no squad
+`knowledge-base/adult-learning-principles.md` (Retrieval Practice, Spaced Repetition), `knowledge-base/assessment-design-guide.md` (Formative Assessment Toolkit), `templates/lesson-plan-template.md` (seção Checkpoint), `checklists/lesson-quality-checklist.md` (Checkpoint and Assessment).

package/squads/squad-courses/tasks/design-learning-path.md

@@ -17,30 +17,47 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Nivel de audiencia mapeado (homogenea ou mista)"
+  - "[ ] Trilha obrigatoria separada de trilhas opcionais, se audiencia for mista"
+  - "[ ] Grau de scaffolding decidido por trecho do curso (guiado -> autonomo)"
+  - "[ ] Decisao de ritmo (self-paced, live, hibrido) registrada com motivo"
+  - "[ ] Nenhuma secao independente forcada em ordem linear sem necessidade"
 ---
 
-# Task: design-learning-path
-
-## Metadata
-- **Agent:** curriculum-designer (Compass)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Projetar a jornada de aprendizado
 
 ## Objetivo
-Projetar jornada de aprendizado
-
-## 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 rota que o aluno percorre pelo curso — trilha única ou trilhas paralelas, nível de apoio em cada trecho, e onde ele tem escolha — antes de virar lista de módulos.
+
+## A regra que governa
+**Autonomia é o padrão; sequência forçada é a exceção que precisa de justificativa.** `adult-learning-principles.md` é direto sobre o que mata a autodireção do adulto: "sequências rígidas para conteúdo simples, sem opção de pular, sem contexto do porquê desta ordem." Esta task decide ONDE o curso realmente precisa de ordem obrigatória (porque há dependência de conteúdo) e onde pode abrir escolha.
+
+## Passos
+
+1. **Mapeie o nível da audiência.** Homogênea (todos no mesmo ponto de partida) ou mista (mix de iniciante e avançado na mesma turma)? A persona de `curriculum-designer` já assume que audiência mista pede trilha própria: módulos fundamentais obrigatórios + módulos avançados opcionais, com cadeia de pré-requisito clara.
+
+2. **Se a audiência for mista, desenhe duas trilhas.** Uma trilha core (obrigatória, cobre os outcomes Core definidos em `define-learning-outcomes`) e uma trilha estendida (opcional, cobre os outcomes Extension). Aluno avançado pula o básico; iniciante não pula o que precisa.
+
+3. **Aplique scaffolding progressivo por trecho do curso**, usando a tabela de `adult-learning-principles.md`: início do curso guiado (passo a passo, exemplo resolvido), meio com prática guiada e feedback, final com estudo de caso e projeto aberto, trilha opcional sem apoio (autonomia).
+   ⚠️ **Regra de scaffolding: remova o apoio de forma progressiva.** Se o módulo 5 ainda dá passo a passo igual ao módulo 1, o curso não formou autonomia — só empilhou conteúdo.
+
+4. **Decida o ritmo com motivo registrado.** Self-paced (aluno controla velocidade), com sessões ao vivo (accountability, mas menos flexível), ou híbrido — a escolha depende do formato definido na fase de escopo (`course-outline-template.md` já tem o campo Format) e do driver de motivação da audiência (instrumental, social, intrínseco, transformacional — tabela em `adult-learning-principles.md`).
+
+5. **Teste cada trecho linear contra a pergunta "isto depende do que veio antes?"** Se a resposta é não, não force ordem — ofereça como opcional ou paralelo. Documente a lista de trechos que PRECISAM ser lineares (vai virar insumo direto de `map-prerequisite-chain`).
+
+## Formato da saída
+Mapa da jornada, em texto ou tabela: trilha, módulos que ela contém, se é obrigatória ou opcional, e o grau de apoio esperado.
+
+| Trilha | Módulos | Obrigatória? | Apoio esperado |
+|---|---|---|---|
+| Core | 1, 2, 3 | Sim | Guiado → prática com feedback |
+| Estendida | 4, 5 | Não (avançado) | Autônomo, estudo de caso |
+
+## O que não vale
+- Jornada única forçada quando a audiência declarada é mista — ignora o próprio dado de entrada.
+- Trilha opcional sem critério de quem deveria escolhê-la ("avançado" sem definir o que qualifica como avançado).
+- Confundir esta task com `structure-module-sequence`: aqui se decide a ROTA (trilhas, ritmo, grau de apoio); a lista concreta de módulos e aulas numeradas é a task seguinte.
+- Scaffolding igual do início ao fim do curso — sinal de que ninguém pensou em progressão.
+
+## Fontes no squad
+`knowledge-base/adult-learning-principles.md` (Self-Directed Learning, Scaffolding, Motivation Drivers), `templates/course-outline-template.md` (campo Format e Target Audience, usados como insumo desta task).

package/squads/squad-courses/tasks/design-lesson-flow.md

@@ -17,30 +17,48 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Cada bloco do outline está marcado com o evento de Gagné que cumpre"
+  - "[ ] 'Stimulate recall' presente em toda lição a partir da segunda do módulo"
+  - "[ ] Prática (elicit performance) vem antes do checkpoint (assess), nunca depois"
+  - "[ ] Decisão tradicional-vs-PBL registrada, com a justificativa de por que essa lição cabe nela"
+  - "[ ] Fechamento liga a 'enhance retention' — ponte de aplicação real, não só recap"
 ---
 
 # Task: design-lesson-flow
 
-## Metadata
-- **Agent:** lesson-architect (Blueprint)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Projetar fluxo: hook, ensino, pratica, avaliacao
-
-## 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 a ordem e a função pedagógica de cada bloco do outline da lição — por que este pedaço vem antes daquele, não só o que existe.
+
+## A regra que governa
+**O fluxo segue os 9 eventos de Gagné.** A ordem não muda; o que muda é o que se pula. Uma lição curta pode saltar eventos, mas nunca inverte a sequência: atenção → objetivo → recall → conteúdo → orientação → prática → feedback → avaliação → retenção.
+
+## Passos
+1. **Mapeie cada bloco do outline a um evento de Gagné.** Use a tabela de `instructional-design-frameworks.md` (Gagné's 9 Events) — hook = gain attention, seções de conteúdo = present content + provide guidance, e assim por diante. Isso transforma o outline (o que existe) num fluxo (por que existe nessa ordem).
+
+2. **Decida entre lição tradicional e Problem-Based Learning.** Tradicional ensina primeiro e pratica depois; PBL apresenta o problema antes da teoria ("escreva a headline do seu produto antes de eu explicar o framework — vamos revisitar no final"). Use PBL quando o aluno já tem alguma base pra tentar; use tradicional quando o conceito é inteiramente novo.
+   ⚠️ Aplicar PBL na primeira lição de um módulo, sem nenhuma base prévia, não gera descoberta — gera frustração. PBL pressupõe algo pra errar.
+
+3. **Nunca pule "stimulate recall" a partir da segunda lição do módulo.** Abrir ligando com o que já foi visto ("você já sabe X, agora vamos somar Y") é o evento 3 de Gagné e também é Spaced Repetition — as duas fontes concordam que pular isso corta retenção.
+
+4. **Prática sempre antes do checkpoint.** "Elicit performance" (evento 6) é o aluno fazendo; "assess performance" (evento 8) é medir se fez certo. Checkpoint sem prática anterior está avaliando algo que o aluno nunca praticou.
+
+5. **Feche em "enhance retention", não em recap.** O evento 9 de Gagné pede transferência pra vida real, não resumo do que já foi dito — a ponte pro próximo passo do outline já cumpre isso, mas o flow precisa deixar essa função explícita.
+
+## O que não vale
+- Fluxo decorativo: rotular os blocos com nomes de Gagné sem mudar a ordem real do conteúdo.
+- PBL em lição de abertura de módulo sem exemplo guiado antes.
+- Checkpoint antes da prática, ou prática ausente.
+- Confundir esta task com `create-lesson-outline` — o outline decide **o que** existe em cada seção; esta task decide **em que ordem e por quê**.
+
+## Formato da saída
+Lista numerada dos blocos do outline, cada um com o evento de Gagné entre colchetes:
+> 1. [Gain attention] Hook — pergunta sobre erro comum
+> 2. [State objectives] Objetivo da lição, lido em voz alta
+> 3. [Stimulate recall] "Na lição anterior você calculou X..."
+> 4. [Present content + Provide guidance] Seção 1 com exemplo resolvido
+> 5. [Elicit performance] Exercício
+> 6. [Provide feedback + Assess] Checkpoint
+> 7. [Enhance retention] Ponte pra próxima lição
+
+## Fontes no squad
+`knowledge-base/instructional-design-frameworks.md` (Gagné's 9 Events, Problem-Based Learning), `knowledge-base/adult-learning-principles.md` (Kolb's Experiential Learning Cycle, Retrieval Practice).

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

@@ -17,30 +17,45 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Competência do módulo decomposta em lições, cada uma com um sub-skill claro"
+  - "[ ] Scaffolding decrescente dentro do módulo — primeira lição mais guiada que a última"
+  - "[ ] Ao menos uma lição de exemplo guiado antes de qualquer lição de caso aberto"
+  - "[ ] Quick win presente se este for o Módulo 1 do curso"
+  - "[ ] Lição de revisão/consolidação ao final, se o módulo tiver 4+ lições"
 ---
 
 # Task: design-module-structure
 
-## Metadata
-- **Agent:** lesson-architect (Blueprint)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Projetar estrutura interna do modulo
-
-## 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
+Decompor a competência de um módulo em lições — quantas, em que tipo, em que ordem interna — não a ordem dos módulos no curso, que é escopo do `curriculum-designer`.
+
+## A regra que governa
+**O scaffolding decresce dentro do módulo.** A primeira lição é a mais guiada (passo a passo, exemplo resolvido); a última exige julgamento mais independente. Se todas as lições do módulo pedem o mesmo nível de apoio, a estrutura não foi desenhada — foi apenas listada.
+
+## Passos
+1. **Decomponha a competência do módulo em sub-habilidades.** A entrada desta task é o outcome do módulo (saída de `curriculum-designer`); quebre-o nas peças menores que uma lição consegue ensinar — a escada de pré-requisito dentro do próprio módulo.
+
+2. **Ordene as lições pela tabela de scaffolding** (`adult-learning-principles.md`): Novice recebe passo a passo e exemplo resolvido, Developing recebe prática guiada com feedback, Competent recebe cenário desafiador, Expert recebe autonomia. Módulos curtos não passam pelos quatro níveis — mas a ordem relativa nunca inverte.
+   ⚠️ Módulo que abre com um caso aberto ("resolva isto") sem nenhum exemplo guiado antes não é scaffolding — é PBL mal calibrado. Garanta pelo menos uma lição de exemplo resolvido antes de qualquer prática aberta.
+
+3. **Classifique o tipo de cada lição** — Concept / Demo / Practice / Case Study / Review, campo `Type` de `lesson-plan-template.md`. Um módulo só de Concept não treina; um módulo só de Practice não explica.
+
+4. **Se este for o Módulo 1 do curso, abra com uma lição de quick win.** O resultado precisa ser alcançável em menos de 30 minutos e compartilhável (`engagement-retention-patterns.md`, Pattern 3) — regra que vale só pro primeiro módulo, não pra todos.
+
+5. **Feche módulos de 4+ lições com uma lição de revisão/consolidação.** Módulos menores que isso não precisam — a última lição de prática já cumpre esse papel.
+
+## O que não vale
+- Todas as lições do módulo no mesmo nível de scaffolding.
+- Módulo sem nenhuma lição de prática, só conceito.
+- Confundir esta task com `sequence-difficulty-progression` — aqui se decide **quantas lições e em que papel**; lá se decide **o nível de Bloom-alvo de cada uma**.
+- Confundir esta task com a `structure-module-sequence` do curriculum-designer — aquela ordena os MÓDULOS do curso; esta ordena as LIÇÕES dentro de UM módulo.
+
+## Formato da saída
+Tabela lição → tipo → nível de scaffolding → sub-skill:
+> 2.1 — Concept — Novice — "reconhecer os componentes de uma DRE"
+> 2.2 — Demo — Novice/Developing — "seguir o cálculo de margem passo a passo"
+> 2.3 — Practice — Developing — "calcular a margem no próprio negócio"
+> 2.4 — Review — Competent — "revisão + consolidação do módulo"
+
+## Fontes no squad
+`knowledge-base/adult-learning-principles.md` (Scaffolding), `templates/lesson-plan-template.md` (campo Type), `knowledge-base/engagement-retention-patterns.md` (Pattern 3 — quick win).

package/squads/squad-courses/tasks/design-peer-review-rubric.md

@@ -17,30 +17,48 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Confirmou que o curso tem componente de comunidade/cohort antes de montar peer review"
+  - "[ ] A rubrica tem 3–5 critérios amarrados ao outcome do trabalho revisado"
+  - "[ ] Cada critério tem um exemplar (exemplo real) por nível, não só descrição abstrata"
+  - "[ ] O fluxo declara quando o instrutor intervém em nota discrepante"
 ---
 
 # Task: design-peer-review-rubric
 
-## Metadata
-- **Agent:** assessment-creator (Gauge)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Projetar rubrica de peer review
-
-## 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
+Montar a estrutura de peer review — rubrica, atribuição entre pares e moderação — para um curso com componente de comunidade.
+
+## A regra que governa
+**Peer review só entra quando o curso tem cohort ou comunidade ativa.** Sem gente pra revisar, o mecanismo fica montado e vazio. `assessment-design-guide.md`: "When to use: cohort-based courses... When to avoid: solo self-paced courses with no community."
+
+## Passos
+
+1. **Checar a pré-condição antes de desenhar qualquer coisa.** O curso tem cohort ou comunidade com atividade real? Se não, não construa peer review — devolva ao pipeline a recomendação de usar autoavaliação (task `create-self-evaluation`) ou revisão do instrutor no lugar. Montar a estrutura de qualquer forma custa esforço de produção que nunca vai ser usado — é decisão de custo, não de estética.
+
+2. **Definir os critérios da rubrica.** 3–5 critérios mais importantes pro sucesso do trabalho revisado, amarrados ao outcome que o projeto/exercício está provando (`assessment-design-guide.md`, Rubric Creation). Comece descrevendo o nível "Excelente" pra cada critério — é mais fácil definir o teto e descer do que subir a partir do mínimo.
+
+3. **Escrever os 4 níveis e um exemplar por nível.** Depois do "Excelente", defina o "Iniciante" (o mínimo aceitável), depois preencha os níveis do meio. Para cada critério, adicione um exemplo concreto do que essa nota parece na prática.
+   ⚠️ Rubrica sem exemplar é subjetiva demais pra pares não-especialistas aplicarem com consistência — dois revisores dão notas diferentes pro mesmo trabalho, e a rubrica perde a função.
+
+4. **Estruturar o fluxo de atribuição.** Sequência fixa do guia: (1) aluno submete o trabalho, (2) é atribuído a 2 pares junto com a rubrica, (3) cada par avalia e escreve 1 força + 1 ponto de melhoria, (4) o instrutor modera notas que destoam muito entre os pares.
+
+5. **Declarar o critério de moderação.** Que diferença de nota entre os dois pares aciona revisão do instrutor (ex.: mais de 1 nível de rubrica de distância)? Sem essa linha, "o instrutor modera outliers" fica vago demais pra alguém executar.
+
+## Formato da saída
+
+Tabela de rubrica + fluxo:
+
+| Critério | 4 — Excelente | 3 — Proficiente | 2 — Em desenvolvimento | 1 — Iniciante |
+|----------|---------------|------------------|--------------------------|----------------|
+| [Critério 1] | [descrição + exemplar] | [descrição + exemplar] | [descrição + exemplar] | [descrição + exemplar] |
+
+**Fluxo:** submissão → 2 pares designados → avaliação + 1 força + 1 melhoria por par → moderação do instrutor se diferença > [X níveis].
+
+## O que não vale
+- Rubrica sem exemplar por nível — critério vira opinião de quem está avaliando.
+- Peer review montado num curso solo, sem comunidade pra sustentar as revisões.
+- Fluxo sem regra clara de quando o instrutor intervém.
+- Critério vago tipo "qualidade geral" sem descrever o que diferencia um nível do outro.
+
+## Fontes no squad
+- `knowledge-base/assessment-design-guide.md` — Peer Review, Rubric Creation, Assessment Anti-Patterns

package/squads/squad-courses/tasks/design-practical-assessment.md

@@ -17,30 +17,53 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] A avaliação passa no teste: 'um profissional usaria esse output no trabalho dele?'"
+  - "[ ] O outcome-alvo está em Apply ou acima na Taxonomia de Bloom"
+  - "[ ] O cenário é real/plausível pro domínio do curso, não um caso fictício genérico"
+  - "[ ] O critério de correção (rubrica ou standard) está declarado junto com a tarefa"
 ---
 
 # Task: design-practical-assessment
 
-## Metadata
-- **Agent:** assessment-creator (Gauge)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Projetar avaliacao pratica
-
-## 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
+Projetar a avaliação prática — a tarefa que mede o que o aluno consegue FAZER no contexto real do domínio, não o que ele consegue recitar.
+
+## A regra que governa
+**"Um profissional usaria esse output no trabalho dele?"** É o teste de `assessment-design-guide.md` (Authentic Assessment) pra qualquer avaliação prática. Se a resposta é não, a tarefa não é prática — é um exercício de sala de aula com roupa de "aplicação".
+
+## Passos
+
+1. **Identificar o outcome-alvo.** Tem que estar em Apply ou acima na Taxonomia de Bloom (`instructional-design-frameworks.md`). Avaliação prática não serve pra medir outcome de Remember — pra isso já existe o quiz (task `create-quiz-questions`).
+
+2. **Rodar o teste de autenticidade antes de fechar a tarefa.** "Um profissional da área usaria esse output no trabalho dele?" Se a resposta é não, redesenhe a tarefa até passar — normalmente trocando dado fictício por dado plausível do domínio, ou trocando "explique" por "produza".
+   ⚠️ Cenário do tipo "a Empresa X, fictícia, tem um problema Y" passa no teste visual de "parece prática" mas falha no teste real se o dado for genérico demais pra alguém usar o raciocínio no trabalho de verdade.
+
+3. **Escolher o formato pela referência de domínio.** `assessment-design-guide.md` traz exemplos de avaliação autêntica por área (contabilidade → analisar um DRE real com critérios IFRS/CPC; direito empresarial → redigir cláusula de contrato de sociedade limitada; LGPD/compliance → mapeamento de dados de uma empresa fictícia mas realista). Adapte pro domínio do curso em questão — não invente um formato genérico quando o guia já tem um mapeado pro tema.
+
+4. **Estruturar como problema antes de solução, quando fizer sentido.** Apresente o problema real primeiro, deixe o aluno tentar com o que já sabe, só depois valide contra o gabarito ou rubrica (`instructional-design-frameworks.md`, Problem-Based Learning) — reforça a aplicação em vez de só testar memorização do procedimento ensinado.
+
+5. **Declarar o critério de correção junto com a tarefa.** Rubrica ligada ao nível de competência mínimo do domínio (`assessment-design-guide.md`, Competency Verification — nível 3 "Conditional" pra a maioria dos cursos profissionais). Avaliação prática sem critério de correção declarado deixa o aluno sem saber o que precisa acertar pra passar.
+
+6. **Garantir pelo menos um retorno.** Mesmo que light-touch (comentário do instrutor, gabarito comentado, ou rubrica de autocorreção) — sem isso a tarefa prática não fecha o ciclo de aprendizado, só gera trabalho sem retorno.
+
+## Formato da saída
+
+```
+## Avaliação Prática — [módulo/curso]
+Outcome: [outcome, nível Apply+]
+
+Cenário: [situação real e plausível do domínio]
+Tarefa: [verbo + ação concreta — "analise", "redija", "calcule", nunca "explique"]
+Critério de sucesso: [standard mensurável / rubrica associada]
+Retorno: [gabarito comentado / revisão do instrutor / autocorreção por rubrica]
+```
+
+## O que não vale
+- Caso fictício genérico ("Empresa X quer...") sem lastro real no domínio do curso.
+- Tarefa em nível Remember/Understand disfarçada de "prática" (ex.: "explique o que é X" em vez de "aplique X a este caso").
+- Avaliação sem critério de correção declarado.
+- Tarefa que nenhum profissional da área usaria no trabalho — falha no teste de autenticidade.
+
+## Fontes no squad
+- `knowledge-base/assessment-design-guide.md` — Authentic Assessment, Competency Verification
+- `knowledge-base/instructional-design-frameworks.md` — Problem-Based Learning, Bloom's para cursos de domínio específico

package/squads/squad-courses/tasks/design-pricing-model.md

@@ -17,10 +17,11 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Modelo de precificação escolhido (one-time/subscription/cohort/freemium/tiered)"
+  - "[ ] Fórmula de valor rodada com probabilidade conservadora (30-60%)"
+  - "[ ] Benchmark de mercado aplicado só se o público for do mesmo mercado da tabela"
+  - "[ ] Moeda e jurisdição declaradas junto do preço"
+  - "[ ] Anchoring e parcelamento definidos (acréscimo máximo 20%)"
 ---
 
 # Task: design-pricing-model
@@ -31,16 +32,32 @@ Checklist:
 - **Complexity:** STANDARD
 
 ## Objetivo
-Projetar modelo de pricing
-
-## 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 modelo de precificação e a faixa de preço do curso, com moeda, jurisdição e fonte do número declaradas junto.
+
+## A regra que governa
+**Preço nasce da transformação entregue e do mercado real, nunca do tempo gasto produzindo — e nenhum número de preço sai sem moeda, jurisdição e fonte.**
+
+## Passos
+
+1. **Escolher o modelo** pelo formato do curso — one-time, subscription, cohort, freemium ou tiered — usando a tabela "Pricing Model Overview" de `course-pricing-models.md` como critério de encaixe, não preferência.
+
+2. **Rodar a fórmula de valor**: Preço = (valor econômico do resultado) × (probabilidade realista de o aluno alcançar) × (multiplicador de credibilidade). Use as faixas conservadoras do KB — probabilidade 30-60%, preço final entre 10-30% do valor calculado.
+   ⚠️ **A fórmula estima um teto de precificação, nunca vira frase de venda.** O número calculado orienta o preço a cobrar; ele não vira promessa ao aluno tipo "você vai economizar R$X" — isso é decisão da task `create-sales-page-brief`, não desta, e mesmo lá entra como exemplo, não garantia.
+
+3. **Cruzar com benchmark de mercado só se o público for do mesmo mercado da tabela.** "Pricing Norms by Segment" em `course-pricing-models.md` é medida em Reais, sobre o mercado brasileiro de 2025-2026 (GMV Hotmart etc.) — cite o arquivo e a janela de tempo do dado ao usar.
+   ⚠️ **Preço, imposto e taxa de plataforma mudam por país.** Se o público não for majoritariamente brasileiro, essa tabela não se aplica. Pesquise o benchmark do mercado de destino ou devolva a pergunta ao dono — nunca aplique o valor em R$ direto a outra moeda.
+
+4. **Decidir anchoring e parcelamento** com "Price Anchoring Strategies" e "Payment Options" — nunca mais de 20% de acréscimo no parcelado.
+
+5. **Declarar o preço final**: valor, moeda, jurisdição, modelo, e se o número é estimativa de mercado ou preço já testado em lançamento anterior.
+
+## Formato da saída
+Bloco curto: `Modelo: [x] · Preço: [valor] [moeda] · Jurisdição/mercado: [x] · Parcelamento: [x] · Base: [benchmark do KB com data / pesquisa externa / preço já testado]`.
+
+## O que não vale
+- Aplicar a tabela de preços em R$ do KB a um público fora do Brasil sem converter moeda nem confirmar jurisdição.
+- Transformar o resultado da fórmula de valor em promessa de resultado ao aluno.
+- Preço "redondo" escolhido por instinto, sem passar pela fórmula nem pelo benchmark.
+
+## Fontes no squad
+`knowledge-base/course-pricing-models.md`.

package/squads/squad-courses/tasks/design-screen-recording-flow.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 (trechos marcados [SCREEN])"
     obrigatorio: true
 
 Saida:
-  - campo: resultado
+  - campo: screen_recording_flow
     tipo: document
-    destino: "next phase"
+    destino: "sessao de gravacao"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Todo passo tem narracao definida (fala ou silencio)"
+  - "[ ] Dados de exemplo preparados antes, nao digitados na hora"
+  - "[ ] Fonte minima de 16pt em tudo que aparece na tela"
+  - "[ ] Nenhuma ferramenta de gravacao de tela nomeada como exigencia"
 ---
 
-# Task: design-screen-recording-flow
-
-## Metadata
-- **Agent:** production-director (Lens)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Projetar fluxo de screen recording
 
 ## Objetivo
-Projetar fluxo de screen recording
-
-## 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 passo a passo exato de tudo que vai aparecer na tela, com narração e preparo definidos antes de apertar gravar.
+
+## A regra que governa
+Screen recording sem fluxo escrito antes vira pausa, erro e retake — o fluxo decide cada clique antes da gravação começar, não durante.
+
+## Passos
+
+1. **Listar cada tela e ação na ordem exata em que acontece**, a partir dos trechos `[SCREEN]` do roteiro. Um fluxo com screenshot de cada tela evita esquecer um passo no meio da gravação.
+
+2. **Marcar, para cada passo, o que falar enquanto mostra** (narração sincronizada com o clique) **versus o que só mostrar em silêncio.** Essa decisão pertence ao fluxo, não ao improviso durante a gravação.
+
+3. **Preparar o ambiente por critério de resultado, não por marca de ferramenta:** resolução mínima 1920×1080, fonte de pelo menos 16pt em tudo que aparece, navegador limpo sem extensão visível, aba ou menu irrelevante escondido.
+   ⚠️ **Gravar com o desktop pessoal** (ícones espalhados, notificação pop-up, aba de outro assunto) quebra a ilusão de ambiente profissional e distrai do conteúdo — é o erro mais comum de screen recording amador.
+
+4. **Preparar os dados de exemplo com antecedência:** arquivo de teste, conta de demonstração, dado fictício pronto. Nunca digitar dado real ou inventar exemplo durante a gravação — isso gera pausa, erro de digitação e retake.
+
+5. **Marcar onde o cursor precisa de destaque** (clique visível) **e onde o movimento deve ser deliberadamente lento.** Essa decisão registrada no fluxo poupa o editor de adivinhar depois o que era importante.
+
+6. **Prever os pontos de corte.** Cada mudança de tela ou aplicativo é um corte natural — marcar no fluxo facilita a edição posterior.
+
+## Formato da saída
+Lista numerada de passos, cada um com: ação na tela, narração (fala definida ou silêncio marcado), e nota de preparo (o que precisa estar pronto antes de apertar gravar). A ferramenta de gravação (Loom, OBS, Camtasia, Screenflow ou qualquer outra) é escolha de quem executa — o fluxo não assume nenhuma, só o resultado: tela legível, sem ruído visual, sem dado inventado na hora.
+
+## O que não vale
+- Fluxo que descreve só "mostrar o processo" sem passo a passo detalhado.
+- Gravar sem preparar dado de exemplo com antecedência.
+- Nomear uma ferramenta específica de gravação de tela como parte da instrução — o critério é o resultado (fonte legível, ambiente limpo), a ferramenta é do executor.
+- Ignorar fonte pequena ou notificação visível na tela porque "dá pra entender assim mesmo".
+
+## Fontes no squad
+`video-production-guide.md` (seção Screen Recording e heurística de fluxo do agente production-director).