iron-edge 1.2.0 → 2.0.1

package/squads/squad-courses/squad.yaml

@@ -4,7 +4,6 @@
 # Course creation squad — designs, writes, and produces educational content
 # across all formats: video courses, written courses, mentoring presentations,
 # workshops, workbooks, assessments, and learning paths.
-# 8 agents | 62 tasks | 6 workflows | 10 KBs | 3 checklists | 6 templates
 # ══════════════════════════════════════════════════════════════════════════════
 
 name: squad-courses
@@ -19,8 +18,7 @@ description: >
 author: Iron Edge
 license: MIT
 slashPrefix: IRON
-
-sinapse:
+iron_edge:
   minVersion: "1.0.0"
   type: squad
 
@@ -29,13 +27,6 @@ metadata:
   updated_at: "2026-03-20"
   created_by: "Claude Code (Sprint 1.5)"
   quality_target: "Cursos com estrutura pedagogica solida e alta taxa de conclusao"
-  agents_count: 8
-  tasks_count: 59
-  knowledge_bases_count: 13
-  workflows_count: 6
-  checklists_count: 3
-  templates_count: 6
-  total_files: 95
 
 # ══════════════════════════════════════════════════════════════════════════════
 # AGENTS — 8 SPECIALISTS
@@ -324,3 +315,23 @@ cross_squad_connections:
       delivers: "Course launch campaign briefs, ad creatives brief"
     - to: squad-copy
       delivers: "Course content for repurposing into copy/headlines"
+
+# === GERADO por scripts/build-manifest.js — NAO EDITAR ===
+generated:
+  agents_total: 8
+  agents_iron: 8
+  agents_xq: 0
+  tasks: 59
+  knowledge_bases: 13
+  workflows: 6
+  templates: 6
+  checklists: 3
+  agents:
+    - { id: assessment-creator, layer: iron, role: specialist, orchestrated_by: courses-orqx }
+    - { id: content-writer, layer: iron, role: specialist, orchestrated_by: courses-orqx }
+    - { id: courses-orqx, layer: iron, role: orchestrator, orchestrated_by: courses-orqx }
+    - { id: curriculum-designer, layer: iron, role: specialist, orchestrated_by: courses-orqx }
+    - { id: launch-strategist, layer: iron, role: specialist, orchestrated_by: courses-orqx }
+    - { id: lesson-architect, layer: iron, role: specialist, orchestrated_by: courses-orqx }
+    - { id: production-director, layer: iron, role: specialist, orchestrated_by: courses-orqx }
+    - { id: slide-designer, layer: iron, role: specialist, orchestrated_by: courses-orqx }

package/squads/squad-courses/tasks/adapt-content-for-level.md

@@ -17,30 +17,38 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Nível de entrada e nível de saída declarados (ex.: Praticante → Novato)"
+  - "[ ] Andaime ajustado por nível, não só o vocabulário"
+  - "[ ] Verbo de Bloom do objetivo corresponde ao nível-alvo do módulo"
+  - "[ ] Exemplo trabalhado incluído quando o nível de destino é Novato/Developing"
+  - "[ ] O objetivo original do conteúdo continua o mesmo depois da adaptação"
 ---
 
 # Task: adapt-content-for-level
 
-## Metadata
-- **Agent:** content-writer (Scribe)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Adaptar conteudo para nivel
-
-## 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
+Pegar um conteúdo já escrito (lição, capítulo, estudo de caso) e reescrevê-lo para o nível de domínio real do público, sem trocar o objetivo de aprendizagem que ele serve.
+
+## A regra que governa
+**Nível é andaime, não vocabulário.** Adaptar para baixo não é trocar palavra difícil por fácil — é aumentar o apoio (passo a passo, exemplo resolvido, mais repetição). Adaptar para cima é remover apoio e pedir julgamento independente. A régua vem da tabela de scaffolding do `adult-learning-principles.md`: Novato precisa de passo a passo e exemplo resolvido; Praticante, de prática guiada com feedback; Competente, de cenário desafiador; Expert, de autonomia.
+
+## Passos
+1. **Identifique o nível de entrada e o de saída.** O que o aluno já sabe fazer, e o que este conteúdo pede que ele saiba fazer depois? Se essa informação não vier clara no `context` de entrada, não adivinhe — declare a lacuna e devolva ao pipeline em vez de decidir sozinho.
+   ⚠️ Nível de audiência ("curso pra iniciantes") não é a mesma coisa que nível de conteúdo (Bloom). Um módulo 1 pra iniciantes ainda pode pedir "Aplicar" — só precisa de mais apoio pra chegar lá.
+2. **Ajuste o andaime, não o assunto.** Para baixo: acrescente exemplo resolvido antes do exercício, quebre a instrução em passos numerados, reduza o número de conceitos por seção. Para cima: remova o exemplo resolvido, troque o exercício guiado por um cenário aberto, junte conceitos que antes vinham separados.
+3. **Recalibre o verbo do objetivo.** Módulos 1–2 miram Remember/Understand; módulos 3–5, Apply/Analyze; projeto final, Evaluate/Create (tabela de Bloom em `instructional-design-frameworks.md`). Se o nível do conteúdo não bate com o módulo em que ele vive, o problema é de sequência do curso, não do texto — sinalize em vez de forçar o encaixe.
+4. **Preserve o objetivo original.** O conteúdo adaptado tem que levar o aluno ao mesmo lugar que o original levava — só muda quanto apoio ele recebe no caminho até lá.
+5. **Registre o que mudou.** Uma linha de rastreio junto com a entrega, com o nível de entrada, o nível de saída e o que foi somado ou removido de apoio.
+
+## Formato da saída
+O conteúdo reescrito, com uma linha de rastreio no topo: `Adaptado de Praticante para Novato: exemplo resolvido acrescentado na seção 2, exercício quebrado em 3 passos.`
+
+## O que não vale
+- Trocar "utilizar" por "usar" e chamar isso de adaptação de nível — é edição de estilo, não de andaime.
+- Remover conteúdo pra "simplificar" sem registrar o que foi cortado.
+- Adaptar pra baixo um módulo que a sequência do curso já marcou como avançado — a inconsistência é da estrutura, não do texto, e volta pro pipeline.
+- Manter o mesmo exemplo hipotético do original quando o nível de destino pedia um exemplo trabalhado passo a passo.
+
+## Fontes no squad
+- `knowledge-base/adult-learning-principles.md` — tabela de Scaffolding, seção Knowles' Andragogy
+- `knowledge-base/instructional-design-frameworks.md` — Bloom's Taxonomy revisada, regra de verbo por módulo

package/squads/squad-courses/tasks/adapt-slides-for-format.md

@@ -17,30 +17,48 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Formato assumido (live / gravado / workshop) está declarado no topo do deck"
+  - "[ ] Contagem de slides do módulo gravado bate com a duração real da aula"
+  - "[ ] Corpo de texto continua ≥24pt mesmo na versão com mais texto"
+  - "[ ] Ajustes aplicados estão listados, não implícitos"
 ---
 
-# Task: adapt-slides-for-format
-
-## Metadata
-- **Agent:** slide-designer (Deck)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Adaptar os slides para o formato de entrega
 
 ## Objetivo
-Adaptar slides para 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
+Ajustar um deck já escrito para o formato real em que vai rodar — live com apresentador, gravado self-paced, ou workshop — sem reescrever do zero.
+
+## A regra que governa
+**Sem apresentador ao vivo, o slide é o professor — e o professor sozinho não pode contar com alguém apontando o que importa.** É a heurística do próprio agente: em formato gravado, o slide precisa comunicar mais sozinho, porque não existe quem complemente com voz e gesto no momento em que o aluno olha.
+
+## Passos
+
+1. **Identificar o formato antes de mexer em qualquer slide.** Live (mentoria/workshop com apresentador), gravado (módulo de curso, self-paced) ou impresso/PDF baixável — cada um muda a densidade aceitável de texto e o fundo de cor (`presentation-design-principles.md`, regra 9: "Dark background for video, light for print").
+
+2. **Gravado ganha mais linhas, não linhas maiores.** O teto de 6 palavras por linha de `write-slide-content` continua valendo — o que muda entre live e gravado é o número de bullets aceitável por slide, não o tamanho de cada bullet. ⚠️ **"Sem apresentador" não é licença para parede de texto** — é licença para um bullet a mais, nunca para um parágrafo.
+
+3. **Manter o piso de tela pequena mesmo quando o formato "permite" mais texto.** A maioria assiste em notebook ou celular, não em projeção — o corpo de texto nunca cai abaixo de 24pt (`design-visual-hierarchy`), mesmo na versão mais densa do slide gravado.
+
+4. **Ritmo pelo tempo real de fala, não pelo assunto.** `checklists/lesson-quality-checklist.md` fixa aula em vídeo entre 5-12 min. `engagement-retention-patterns.md` (Attention Span Research, dataset edX de 6,9M sessões) mostra vídeo abaixo de 6 min assistido quase 100% e acima de 12 min com queda relevante. Traduzido em slides: trocar de slide a cada 45-90s de fala — uma aula de 8 min cabe entre 5 e 10 slides, não 20.
+
+5. **Workshop mantém a régua de bloco de 30 min sem interação** (`knowledge-base/course-format-patterns.md`). Adaptar para workshop não é reduzir a interatividade que já existia no deck — é redistribuir texto ao redor dela.
+
+6. **Registrar o formato assumido no material.** Sem essa marca no topo do deck, quem herda o arquivo depois — produção de vídeo, ou quem vai facilitar ao vivo — não sabe se está com a versão certa, e o erro só aparece na entrega.
+
+## Formato da saída
+Nota de formato no topo do deck + lista de ajustes aplicados:
+```
+Formato: gravado (self-paced)
+Ajustes: +1 bullet por slide de conceito vs. versão live;
+corpo mantido em 26pt; 7 slides para os 6 min de aula;
+fundo escuro (entrega em vídeo).
+```
+
+## O que não vale
+- Mandar o mesmo deck de mentoria para o módulo gravado sem revisão.
+- "Mais texto" virando bloco de parágrafo em vez de um bullet a mais.
+- Não marcar o formato assumido, deixando quem usa depois adivinhar.
+- Contagem de slides que ignora a duração real da aula gravada.
+
+## Fontes no squad
+`knowledge-base/presentation-design-principles.md`, `knowledge-base/engagement-retention-patterns.md`, `checklists/lesson-quality-checklist.md`, `knowledge-base/course-format-patterns.md`.

package/squads/squad-courses/tasks/create-bonus-strategy.md

@@ -17,10 +17,11 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Objeção nº1 de não comprar identificada"
+  - "[ ] Cada bônus resolve uma objeção nomeada"
+  - "[ ] Valor de referência calculado com lastro, não inventado"
+  - "[ ] Prazo do bônus alinhado ao calendário do lançamento"
+  - "[ ] Conjunto de bônus reforça a transformação central, sem distração"
 ---
 
 # Task: create-bonus-strategy
@@ -31,16 +32,32 @@ Checklist:
 - **Complexity:** STANDARD
 
 ## Objetivo
-Criar estrategia de bonus
-
-## 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 bônus do lançamento — cada um resolvendo uma objeção específica de não comprar, com valor de referência justificável.
+
+## A regra que governa
+**Todo bônus existe para resolver a objeção nº1 de não comprar. Bônus que não resolve objeção é enchimento, não estratégia.**
+
+## Passos
+
+1. **Levantar a objeção nº1 de não comprar.** Vem do FAQ do brief de sales page (`create-sales-page-brief`) ou de DMs/suporte de lançamentos anteriores, quando existir histórico. Sem essa objeção nomeada, não há como desenhar o bônus certo.
+
+2. **Desenhar um bônus específico que resolve essa objeção.** Use "Bonus Ideas by Course Type" de `course-launch-strategy.md` como ponto de partida por categoria (contabilidade, direito, negócios, marketing, tech) — adaptando ao tema real do curso, nunca copiando a lista genérica sem checar se cabe.
+   ⚠️ **"Acesso a materiais bônus" não é bônus.** Nomeie o que é e o que ele faz — "planilha de comparação de regime tributário" é bônus, "materiais extras" é vazio.
+
+3. **Atribuir valor de referência e declarar como ele foi calculado** — preço de mercado de algo equivalente, ou custo de produção real. Nunca escrever "valor de R$X" sem lastro visível.
+   ⚠️ **Valor de bônus inventado sem lastro é o mesmo defeito de prometer resultado**: número sem fonte não entra na peça. Se não há como calcular, não atribua valor — descreva o bônus sem o R$.
+
+4. **Colocar prazo no bônus** ("disponível só até [data]"), alinhado ao calendário definido em `plan-launch-sequence`.
+
+5. **Checar o conjunto contra a transformação central do curso.** Cortar qualquer bônus que não tenha relação direta com o resultado prometido — bônus solto dilui, não soma.
+
+## Formato da saída
+Tabela: bônus · objeção que resolve · o que é (específico) · valor de referência e como foi calculado · prazo.
+
+## O que não vale
+- Bônus genérico ("bônus surpresa", "materiais extras") sem nome nem função.
+- Valor de bônus inventado sem explicar de onde veio o número.
+- Bônus sem relação com a transformação prometida no curso, só pra parecer que tem mais coisa.
+
+## Fontes no squad
+`knowledge-base/course-launch-strategy.md`.

package/squads/squad-courses/tasks/create-final-project-brief.md

@@ -17,30 +17,56 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] O brief lista os outcomes core do curso que o projeto precisa provar"
+  - "[ ] O projeto exige skills de pelo menos 2 módulos diferentes"
+  - "[ ] O contexto é a situação real do aluno, não um caso fictício genérico"
+  - "[ ] O brief aponta pra rubrica de avaliação (existente ou a construir) e tem prazo"
 ---
 
 # Task: create-final-project-brief
 
-## Metadata
-- **Agent:** assessment-creator (Gauge)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Criar brief do projeto final
-
-## 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 do projeto final (capstone) — a entrega que prova, de uma vez, que o aluno alcançou os outcomes core do curso, não só um deles.
+
+## A regra que governa
+**O projeto final tem que provar todos os outcomes core do curso, não decorar um deles.** Se o brief pode ser cumprido usando skill de um único módulo, ele não é final project — é um exercício de módulo com nome pomposo.
+
+## Passos
+
+1. **Listar os outcomes core do curso.** Vêm do curriculum-designer, nível Apply ou acima na Taxonomia de Bloom (`instructional-design-frameworks.md`). Outcomes de extensão/opcionais não entram como exigência do projeto final — citar como bônus, se fizer sentido.
+
+2. **Checar integração antes de escrever o prompt.** O projeto precisa convocar skills de pelo menos 2 módulos (traço "Integration" do `assessment-design-guide.md`). Se o rascunho do prompt só usa um módulo, volte e amplie o escopo antes de seguir.
+
+3. **Escrever o prompt na estrutura validada.** Modelo do guia: *"Usando o que você aprendeu neste curso, [verbo + tarefa] para [seu contexto]. Sua entrega deve incluir [componentes]. Use a rubrica para se autoavaliar antes de enviar."* O contexto tem que ser a situação real do próprio aluno — não um caso fictício genérico ("a Empresa X quer...").
+   ⚠️ Caso fictício descolado do contexto real do aluno mata a transferência de aprendizado (`adult-learning-principles.md`, Transfer of Learning): o aluno pratica em condições que não parecem com a vida dele depois.
+
+4. **Definir os componentes obrigatórios da entrega.** O projeto tem que produzir um artefato usável — plano, protótipo, roteiro, planilha — não só um texto de reflexão (traço "Artifact output").
+
+5. **Declarar visibilidade e retorno.** O projeto é peer-visible (se o curso tem comunidade)? Tem pelo menos revisão leve do instrutor? Declare os dois — mesmo que a resposta seja "não" com justificativa.
+
+6. **Apontar pra rubrica.** Este brief não constrói a rubrica — ele referencia que ela existe ou vai ser construída (task `design-peer-review-rubric` quando há comunidade, ou uma rubrica de instrutor quando não há). Brief sem rubrica associada deixa o aluno sem saber contra o que está sendo medido.
+
+## Formato da saída
+
+```
+## Projeto Final — [nome do curso]
+Outcomes provados: [lista dos outcomes core]
+Módulos convocados: [módulo A, módulo B, ...]
+
+Prompt: Usando o que você aprendeu neste curso, [tarefa] para [seu contexto].
+Sua entrega deve incluir: [componente 1], [componente 2], [componente 3].
+
+Prazo: [X dias após liberação]
+Avaliação: [rubrica referenciada] · Peer-visible: [sim/não] · Revisão do instrutor: [sim/não]
+```
+
+## O que não vale
+- Caso fictício genérico em vez do contexto real do aluno.
+- Projeto que só exige skill de um módulo.
+- Brief sem prazo ou sem critério de avaliação declarado.
+- Entrega que não produz artefato usável (só "reflita sobre...").
+
+## Fontes no squad
+- `knowledge-base/assessment-design-guide.md` — Final Project Design
+- `knowledge-base/curriculum-mapping-guide.md` — The Mapping Hierarchy
+- `checklists/course-completeness-checklist.md` — seção Assessment Completeness (final project brief + rubric)

package/squads/squad-courses/tasks/create-lesson-outline.md

@@ -17,30 +17,42 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Todas as seções obrigatórias do template estão presentes (identidade, hook, seções, exercício, checkpoint, takeaways, ponte)"
+  - "[ ] Hook responde 'por que isso importa agora' em até um parágrafo"
+  - "[ ] Cada seção de conteúdo tem uma core idea de uma frase"
+  - "[ ] No máximo 2-3 seções de conteúdo — outline não estourou o escopo de uma lição"
+  - "[ ] Outline é esqueleto (core ideas + exemplos apontados), não o texto final da aula"
 ---
 
 # Task: create-lesson-outline
 
-## Metadata
-- **Agent:** lesson-architect (Blueprint)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Criar outline detalhado da 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
+Montar o esqueleto da lição — todas as seções do template preenchidas com a estrutura e a ideia central de cada parte, prontas para o `content-writer` escrever o texto final.
+
+## A regra que governa
+**O outline segue a ordem do template, nunca a ordem mais fácil de escrever.** Hook, seções de conteúdo, exercício, checkpoint, takeaways, ponte — essa sequência existe porque cada peça depende da anterior; pular a ordem quebra a lição antes mesmo dela ser escrita.
+
+## Passos
+1. **Preencha a Lesson Identity.** ID (módulo.lição), título, módulo, tipo (Concept / Demo / Practice / Case Study / Review) e formato — campos do topo de `lesson-plan-template.md`. O objetivo já vem pronto da task `define-lesson-objectives`; cole-o aqui, não reescreva.
+
+2. **Escreva o Hook em um parágrafo curto.** Uma pergunta, uma estatística, um problema reconhecível — o que importa é responder "por que isso importa pra mim agora" nos primeiros segundos (`adult-learning-principles.md`, Need to know). O hook não é o título reformulado; é o gancho que faz o aluno continuar.
+
+3. **Quebre o conteúdo em 2-3 seções**, cada uma com uma **core idea de uma frase** e um exemplo concreto apontado (não escrito por extenso).
+   ⚠️ Seção sem core idea de uma frase é seção que ainda não decidiu o que ensina — volte e resuma antes de seguir.
+
+4. **Aponte, não preencha, o Exercício e o Checkpoint.** Marque onde eles entram no fluxo ("[EXERCÍCIO — ver task plan-practical-exercises]", "[CHECKPOINT — ver task design-knowledge-checkpoints]"); o conteúdo deles é de outra task.
+
+5. **Feche com Key Takeaways (3-5) e a Bridge to Next Lesson** — a frase de transição que liga esta lição à próxima, campo final do template.
+
+## O que não vale
+- Outline que já é o texto final da aula, com parágrafos prontos — isso é trabalho do `content-writer`, não desta task.
+- Hook igual ao título ("Nesta aula você vai aprender sobre X") — não é hook, é sumário.
+- Mais de 3-4 seções de conteúdo numa lição só — sinal de que precisa virar duas lições (ver task `estimate-lesson-duration`).
+- Exercício e checkpoint escritos por extenso aqui, duplicando o trabalho das tasks específicas.
+
+## Formato da saída
+Um documento seguindo exatamente as seções de `lesson-plan-template.md`, com todos os campos de estrutura preenchidos e o corpo de cada seção reduzido à core idea + exemplo apontado:
+> **Seção 2 — Como calcular a margem de contribuição.** *Core idea:* a margem de contribuição mostra quanto cada venda sobra depois do custo variável. *Exemplo:* recalcular o preço de um produto do próprio negócio do aluno.
+
+## Fontes no squad
+`templates/lesson-plan-template.md` (estrutura completa da lição), `knowledge-base/adult-learning-principles.md` (Need to know, hook).

package/squads/squad-courses/tasks/create-presentation-outline.md

@@ -17,30 +17,47 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Cada seção segue o arco Problema→Stakes→Solução→Prova→Ação"
+  - "[ ] Todo slide da lista tem um tipo (não é genérico)"
+  - "[ ] Contagem de slides bate com o tempo disponível, não com o conteúdo"
+  - "[ ] Formato do material (live, gravado, workshop) está declarado"
 ---
 
-# Task: create-presentation-outline
-
-## Metadata
-- **Agent:** slide-designer (Deck)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Criar o outline da apresentação
 
 ## Objetivo
-Criar outline de apresentacao
-
-## 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
+Entregar a espinha dorsal da apresentação — a sequência de slides por seção, com tipo e tempo — antes de qualquer slide ser desenhado ou escrito.
+
+## A regra que governa
+**O outline segue o arco da aula, não o índice do conteúdo.** Uma lista de tópicos copiada do syllabus não é um outline de apresentação — é um sumário. O outline organiza a experiência de quem assiste, não o assunto.
+
+## Passos
+
+1. **Herdar o fluxo, não recriar.** A entrada desta task é o outline e o fluxo que vêm do lesson-architect (Blueprint) — a sequência pedagógica já foi decidida ali. Aqui você traduz esse fluxo em slides, não reabre a decisão de ordem do conteúdo.
+
+2. **Aplicar o arco de 5 atos por seção.** Problema → Stakes → Solução → Prova → Ação, descrito em `presentation-design-principles.md` ("Storytelling in Slides"). Cada seção do módulo abre com o problema que o aluno reconhece e fecha com a capacidade dele de resolver — não com "fim do tópico X".
+
+3. **Orçar a quantidade de slides pelo tempo, não pelo assunto.** Uma mentoria de 30-60min cabe em 15-20 slides. Um módulo gravado cabe em menos slides ainda, porque o ritmo é ditado pela duração da aula: `checklists/lesson-quality-checklist.md` define aula em vídeo entre 5-12 min, e nesse intervalo cabem entre 5 e 12 slides — não 20. ⚠️ **Encher o tempo com slides é o erro mais comum aqui.** Se o outline tem mais slides do que o tempo permite, o problema é o outline, não a régua.
+
+4. **Marcar o tipo de cada slide da lista.** Use a tabela "Slide Types and When to Use Each" de `presentation-design-principles.md` (título, conceito, diagrama, quote, exemplo, exercício, resumo, transição). Um slide sem tipo definido ainda não está pronto para a próxima task.
+
+5. **Declarar o formato assumido.** Live (mentoria/workshop com apresentador), gravado (módulo self-paced) ou workshop presencial/remoto — a densidade de slides muda entre eles (tabela "Workshop Slides vs Lecture Slides"). Quem herdar este outline em `adapt-slides-for-format` precisa saber qual foi a base.
+
+## Formato da saída
+Lista numerada por seção, com tempo estimado e tipo de cada slide:
+```
+Seção 2 — Framework de precificação (8 min)
+Slide 5 — [Transição] Abertura da seção
+Slide 6 — [Conceito] O ponto central do framework
+Slide 7 — [Exemplo] Antes/depois de um caso real
+Slide 8 — [Resumo] 3 takeaways da seção
+```
+
+## O que não vale
+- Outline que é o índice do conteúdo com números na frente.
+- Contagem de slides que ignora o tempo disponível.
+- Slide "a definir depois" sem tipo — isso empurra o problema para a próxima task.
+- Mesmo outline reaproveitado para live e gravado sem marcar qual é qual.
+
+## Fontes no squad
+`knowledge-base/presentation-design-principles.md`, `checklists/lesson-quality-checklist.md`, `knowledge-base/engagement-retention-patterns.md`.

package/squads/squad-courses/tasks/create-production-checklist.md

@@ -6,41 +6,56 @@ atomic_layer: Task
 elicit: false
 
 Entrada:
-  - campo: context
-    tipo: object
-    origem: "pipeline or manual"
+  - campo: recording_session_plan
+    tipo: document
+    origem: "plan-recording-session"
     obrigatorio: true
+  - campo: shot_list
+    tipo: document
+    origem: "create-shot-list"
+    obrigatorio: false
 
 Saida:
-  - campo: resultado
+  - campo: production_checklist
     tipo: document
-    destino: "next phase"
+    destino: "inicio da sessao de gravacao"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Todo item de audio tem criterio mensuravel, nao vago"
+  - "[ ] Teste de audio marcado como algo que se ouve de volta, nao so grava"
+  - "[ ] Item de screen recording so entra se a aula tiver [SCREEN] no roteiro"
+  - "[ ] Sessao so comeca com todos os itens marcados"
 ---
 
-# Task: create-production-checklist
-
-## Metadata
-- **Agent:** production-director (Lens)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
+# Task: Criar checklist de produção
 
 ## Objetivo
-Criar checklist de producao
-
-## 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
+Reunir, num checklist único, os critérios de pronto-pra-gravar que evitam descobrir um defeito depois — quando já é retake.
+
+## A regra que governa
+O checklist existe para pegar o defeito antes de apertar gravar. Todo item nele custa caro de corrigir depois e é barato de checar antes.
+
+## Passos
+
+1. **Reunir os critérios de pronto-pra-gravar em quatro frentes:** câmera (enquadramento e foco checados), luz (sem sombra no rosto, temperatura de cor única), áudio (teste gravado e ouvido de volta, sem ruído de fundo), ambiente (fundo limpo, celular no silencioso, notificação desligada).
+
+2. **Puxar do plano de sessão e da shot list o que é específico desta gravação.** Roteiro ou outline revisado em mãos, shot list conferida, e — só quando a aula tiver trecho `[SCREEN]` no roteiro — o ambiente de screen recording preparado (resolução, fonte legível, navegador limpo).
+   ⚠️ **Checklist genérico que repete os mesmos itens pra toda sessão erra por dois lados:** sobra item de screen recording numa aula que não tem tela, e falta esse mesmo item numa que tem. O checklist puxa da sessão real, não de um molde fixo.
+
+3. **Formular o item de áudio como verificação, não como hábito.** Critério: pico entre -12dB e -6dB, nunca no vermelho (0dB), e ausência de ruído perceptível ao ouvir a gravação de teste de volta — não só "gravei o teste".
+
+4. **Incluir os itens pequenos que evitam interrupção no meio da gravação real:** garrafa d'água fora de quadro, primeiro take reservado como aquecimento descartável, telefone no silencioso.
+
+5. **Fechar com a regra de decisão.** Todos os itens marcados: começa a sessão. Item pendente: não grava até resolver — parar antes custa sempre menos que descobrir o defeito no material já gravado.
+
+## Formato da saída
+Checklist em Markdown com caixas de marcação, agrupado por frente — Câmera / Luz / Áudio / Ambiente / Conteúdo em mãos —, pronto para ser conferido item a item nos minutos antes de gravar. Exemplo de item: `[ ] Áudio: teste de 10s gravado e OUVIDO de volta, sem ruído de fundo perceptível`.
+
+## O que não vale
+- Item vago como "áudio ok" sem critério mensurável por trás.
+- Marcar o teste de áudio como feito sem ouvir a gravação de volta.
+- Checklist idêntico para sessão com e sem screen recording.
+- Considerar a sessão pronta com item pendente porque "dá pra ajustar depois na edição" — esse raciocínio é exatamente o que o checklist existe para impedir.
+
+## Fontes no squad
+`video-production-guide.md` (Audio checklist e Production Checklist per recording session).

package/squads/squad-courses/tasks/create-progress-milestones.md

@@ -17,30 +17,48 @@ Saida:
     destino: "next phase"
 
 Checklist:
-  - "[ ] Validar inputs"
-  - "[ ] Executar steps"
-  - "[ ] Verificar qualidade"
-  - "[ ] Gerar output"
+  - "[ ] Cada milestone é evidência de desempenho, não de consumo (% assistido)"
+  - "[ ] Cada milestone tem um threshold mensurável (nota mínima, entrega aprovada, etc.)"
+  - "[ ] Os milestones seguem progressão de exigência (scaffolding) do módulo 1 ao final"
+  - "[ ] Os milestones são visíveis ao aluno, não só registro interno do sistema"
 ---
 
 # Task: create-progress-milestones
 
-## Metadata
-- **Agent:** assessment-creator (Gauge)
-- **Squad:** squad-courses
-- **Complexity:** STANDARD
-
 ## Objetivo
-Criar milestones de progresso
-
-## 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 marcos que sinalizam progresso real ao longo do curso — o que o aluno consegue FAZER a cada etapa, não quanto conteúdo ele consumiu.
+
+## A regra que governa
+**Milestone é evidência de desempenho, não de consumo.** "Assistiu 100% do vídeo" não é um milestone — é um log de reprodução. O milestone certo é algo que o aluno FEZ e que pode ser checado.
+
+## Passos
+
+1. **Amarrar cada milestone a um outcome de módulo.** Para cada módulo, identifique o outcome que ele fecha (`curriculum-mapping-guide.md`, Mapping Hierarchy). Sem outcome, não há o que marcar como conquistado — é só posição no índice.
+
+2. **Escolher a evidência certa pro nível de competência do módulo.** Use os 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). Módulo introdutório pode fechar em Procedural; módulo final de curso profissional deveria fechar em Conditional ou acima.
+
+3. **Definir o gatilho e o threshold.** O milestone dispara por algo mensurável: quiz aprovado com nota mínima, exercício entregue, checkpoint validado — nunca "abriu a lição" ou "chegou ao fim do vídeo" (`assessment-design-guide.md`, Performance-Based Grading: criterion-referenced, com padrão de mastery, ex. 80% com retry permitido).
+   ⚠️ Milestone de consumo passa no teste de "parece progresso" mas não mede nada — o aluno pode ter deixado o vídeo rodando em outra aba.
+
+4. **Sequenciar por scaffolding.** Módulo 1 tem exigência mais guiada (ex.: completar um exercício com template); módulos finais exigem mais autonomia (ex.: entregar sem andaime) — `adult-learning-principles.md`, tabela de Scaffolding (Novice → Expert). Se todos os milestones pedem o mesmo nível de exigência, a progressão não existe de fato, só no nome.
+
+5. **Tornar visível ao aluno.** Milestone que só existe no banco de dados não cumpre a função motivacional — `adult-learning-principles.md` (Self-Directed Learning: progress visibility). Declare como o aluno vê cada marco batido (barra de progresso, selo, desbloqueio de módulo seguinte).
+
+## Formato da saída
+
+| Módulo | Outcome | Milestone (evidência) | Threshold | Visível como |
+|--------|---------|------------------------|-----------|---------------|
+| 1 | [outcome] | Quiz do módulo aprovado | ≥80% | Selo + desbloqueia módulo 2 |
+| 3 | [outcome] | Exercício de caso entregue | Entrega completa (sem nota) | Progresso na trilha |
+| Final | [outcome] | Projeto final aprovado pela rubrica | Nível "Proficiente"+ | Certificado liberado |
+
+## O que não vale
+- Milestone de "% do vídeo assistido" ou "lição aberta".
+- Milestone sem threshold — vira pass/fail indefinido, ninguém sabe o que conta como passou.
+- Milestone que não aparece pro aluno, só existe como registro interno.
+- Todos os milestones no mesmo nível de exigência, sem progressão do módulo 1 ao final.
+
+## Fontes no squad
+- `knowledge-base/assessment-design-guide.md` — Performance-Based Grading, Competency Verification
+- `knowledge-base/adult-learning-principles.md` — Scaffolding, Self-Directed Learning
+- `knowledge-base/curriculum-mapping-guide.md` — The Mapping Hierarchy