@polymorphism-tech/morph-spec 4.9.0 → 4.10.1

package/framework/skills/level-1-workflows/phase-tasks/SKILL.md

@@ -1,271 +0,0 @@
----
-name: morph:phase-tasks
-description: MORPH-SPEC Phase 4 (Tasks). Breaks approved spec into bottom-up ordered implementation tasks (T001...TXXX) with dependencies, checkpoints every 3 tasks, and effort estimates, producing tasks.md. Use after design and clarification phases to create a structured implementation plan before coding starts.
-argument-hint: "[feature-name]"
-disable-model-invocation: true
-user-invocable: false
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-cliVersion: "4.9.0"
----
-
-# MORPH Tasks - FASE 4
-
-> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
-
-Quebre a especificação em tasks executáveis, defina ordem de execução e estabeleça checkpoints.
-
-## Pré-requisitos
-
-- [ ] FASE 3 (Clarify) concluída
-- [ ] `spec.md` atualizado com clarificações
-- [ ] Todos os edge cases documentados
-
-## Ferramentas Recomendadas
-
-> **Ref:** `framework/skills/level-0-meta/tool-usage-guide/SKILL.md` para guia completo.
-> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` para referência MCP.
-> **Example:** `references/tasks-example.md` — filled-in tasks.md showing expected granularity and format.
-> **Script:** `scripts/validate-tasks.mjs` — validates tasks.md structure, T### IDs, and required fields.
-
-| Ação | Ferramenta | Alternativa |
-|------|------------|-------------|
-| Ler spec + contracts + decisions | **Read** todos os outputs | — |
-| Analisar complexidade de implementação | **Grep** padrões no código existente | — |
-| Contar padrões similares existentes | **Glob** `**/Services/**/*.cs` | — |
-| Consultar padrões de implementação | **Context7 MCP** `query_docs()` | **WebSearch** |
-| Criar issues no GitHub a partir das tasks | **GitHub MCP** `create_issue()` | **Bash** `gh issue create ...` |
-| Renderizar template de tasks | **Bash** `npx morph-spec template render docs/tasks ...` | — |
-| Atualizar state com total de tasks | **Bash** `npx morph-spec state set ... tasks.total N` | — |
-
-**MCPs desta fase:** Context7 (estimar complexidade), GitHub (criar issues).
-
-**Anti-padrões:**
-- ❌ Task agent para quebrar spec simples de 1 domínio (faça diretamente)
-- ✅ Task agent para specs multi-domínio (backend + frontend + infra = 3 planners em paralelo)
-- ✅ Task agent quando spec tem 20+ requisitos em múltiplos bounded contexts
-- ❌ Criar tasks.json sem ler todos os outputs primeiro
-- ❌ **(VSA)** Criar tasks separadas para Handler, Validator e Endpoint — um slice = uma task
-- ❌ **(VSA)** Usar categorias DDD (`domain`, `application`, `infrastructure`) em projetos VSA
-- ❌ **(VSA)** Criar task de "Implementar Service layer" — não existe em VSA
-
----
-
-## ✅ PRÉ-VOO OBRIGATÓRIO (antes de iniciar breakdown de tasks)
-
-### 1. Ler todos os prerequisitos em PARALELO
-
-```
-# Uma única chamada, não sequencial:
-Read: .morph/features/{feature}/1-design/spec.md
-    + Read: .morph/features/{feature}/1-design/contracts.cs
-    + Read: .morph/features/{feature}/1-design/decisions.md
-    + Read: .morph/features/{feature}/1-design/schema-analysis.md  (se existir)
-    + Read: .morph/config/config.json                               (→ architecture.style)
-```
-
-### 2. Criar tasks de sessão para visibilidade
-
-```
-TaskCreate: "Analisar spec e definir tasks"   → activeForm: "Analisando spec"
-TaskCreate: "Gerar tasks.md"                  → activeForm: "Gerando tasks.md"
-TaskCreate: "Avanço de fase"                  → activeForm: "Avançando fase"
-```
-
-> **Nota:** As tasks individuais T001-T00N serão criadas como native tasks durante a fase de implementação (`phase-implement`). Aqui mantemos apenas as 3 tasks de alto nível desta sessão de planejamento.
-
----
-
-## Workflow
-
-### CHECKPOINT DE ENTRADA: Verificar Pré-requisitos
-
-**⏸️ PAUSE - Antes de iniciar o breakdown de tasks:**
-
-- [ ] `spec.md` existe e foi aprovado pelo usuário?
-- [ ] `contracts.cs` existe e corresponde ao schema real?
-- [ ] `schema-analysis.md` foi validado (se aplicável)?
-- [ ] `decisions.md` contém ADRs para todas as escolhas críticas?
-- [ ] Design gate (`morph-spec approve $ARGUMENTS design`) foi aprovado?
-- [ ] Clarificações (FASE 3) foram resolvidas e spec atualizado?
-
-**❌ Se alguma checkbox NÃO estiver marcada:**
-→ Voltar para a fase correspondente e resolver
-
-**✅ Se TODAS as checkboxes estiverem marcadas:**
-→ Prosseguir para análise e breakdown
-
-```bash
-# Verificar estado atual:
-npx morph-spec state get $ARGUMENTS
-# Verificar se design foi aprovado:
-npx morph-spec approval-status $ARGUMENTS
-```
-
----
-
-### Passo 0: Detectar Estilo de Arquitetura
-
-Antes de tudo, determine se o projeto é VSA ou DDD:
-
-```bash
-cat .morph/config/config.json | grep -A3 '"architecture"'
-```
-
-**Se `config.architecture.style === "vertical-slice"`** → siga o **Passo 0.5 (VSA)** e pule o Passo 0 DDD.
-**Caso contrário** → siga o **Passo 0.6 (DDD)** abaixo.
-
----
-
-### Passo 0.5: Plano de Tasks — VSA
-
-> Para padrões de tarefas VSA e mapeamento DDD por nível, veja `references/task-planning-patterns.md`
-
-Leia a seção `## Architecture Style: Vertical Slice` do spec.md para o **VSA Blueprint**:
-
-```bash
-grep -A30 "## Architecture Style" ".morph/features/$ARGUMENTS/1-design/spec.md"
-```
-
-Crie uma task por slice (entity → errors → tags → migration → slices CRUD → slices custom → tests). Cada slice = Handler + Validator + Endpoint numa única task. `GetAll` não tem Validator.
-
-**Após definir tasks VSA, pule direto para o Passo 3 (Dependências).**
-
----
-
-### Passo 0.6: Ler Nível de Domínio — DDD
-
-Leia a seção `## Domain Complexity` do spec.md:
-
-```bash
-grep -A15 "## Domain Complexity" ".morph/features/$ARGUMENTS/1-design/spec.md"
-```
-
-> Se a seção não existir, assuma **Nível 1 (CRUD)**.
-
-Use o nível para restringir categorias (Nível 1: domain→infra→application→presentation→tests; Nível 2: adiciona AggregateRoot, ValueObjects, DomainEvents, CQRS handlers; Nível 3: adiciona BC setup, Integration Events). Ver `references/task-planning-patterns.md` para tabela completa.
-
----
-
-### Passo 1: Analisar Spec
-
-> **VSA:** Se veio do Passo 0.5, o breakdown de tasks já foi definido — use os exemplos gerados como base e pule para o Passo 3 (Dependências).
-
-Leia `.morph/features/$ARGUMENTS/1-design/spec.md` e identifique:
-
-1. **Requisitos funcionais** (FR001, FR002, ...)
-2. **Componentes técnicos** (Entities, Services/Slices, Controllers/Endpoints, Pages)
-3. **Infraestrutura** (Bicep, migrations, configs)
-4. **Testes** (Unit tests, integration tests)
-
-### Passo 2: Quebrar em Tasks
-
-> Para estrutura JSON, categorias e ordem de implementação, veja `references/task-planning-patterns.md`
-
-Crie tasks no formato **T{NNN}** seguindo bottom-up: domain → infrastructure → application → presentation → tests → infra → docs.
-
-### Passo 3: Definir Dependências
-
-Para cada task, especifique dependências:
-
-```json
-{
-  "id": "T005",
-  "title": "Criar {Nome}Service",
-  "dependencies": ["T001", "T002"],
-  "status": "pending"
-}
-```
-
-**Regra:** Task só pode ser executada quando todas as dependências estão `completed`.
-
-### Passo 4: Estabelecer Checkpoints
-
-Defina checkpoints a cada **3 tasks** ou **marcos significativos**:
-
-```json
-{
-  "id": "CHECKPOINT_001",
-  "title": "Domain Layer Completo",
-  "afterTasks": ["T001", "T002", "T003"],
-  "validations": [
-    "Todas as entities criadas",
-    "Migrations aplicadas",
-    "Testes de domain passando"
-  ]
-}
-```
-
-### Passo 5: Estimar Esforço
-
-Para cada task, estime tempo em minutos:
-
-| Complexidade | Tempo Estimado |
-|--------------|----------------|
-| Trivial (CRUD básico) | 15-30 min |
-| Simples (Service, Controller) | 30-60 min |
-| Média (Business logic, validações) | 60-120 min |
-| Complexa (Integrações, AI) | 120-240 min |
-
-### Passo 6: Gerar `tasks.md`
-
-Crie `.morph/features/$ARGUMENTS/3-tasks/tasks.md` com a estrutura completa de tasks, checkpoints e estimativas.
-
-### Passo 7: Incluir Tasks de IaC (se necessário)
-
-Se houver recursos Azure, adicionar tasks de Bicep e migrations.
-
-### Passo 8: Atualizar State
-
-```bash
-npx morph-spec state set $ARGUMENTS tasks.total {N}
-npx morph-spec state mark-output $ARGUMENTS tasks
-```
-
-## Outputs Gerados
-
-- `.morph/features/$ARGUMENTS/3-tasks/tasks.md` - Breakdown completo de tasks
-
-## PAUSA OBRIGATÓRIA
-
-Apresente ao usuário 3 ações sugeridas:
-
-1. **Aprovar breakdown e iniciar implementação**
-2. **Repriorizar tasks** - Mudar ordem de execução
-3. **Adicionar/remover tasks** - Ajustar escopo
-
-## Critérios de Avanço
-
-- [x] `tasks.json` criado com todas as tasks
-- [x] Tasks categorizadas corretamente
-- [x] Dependências mapeadas
-- [x] Checkpoints definidos (a cada 3 tasks)
-- [x] Esforço estimado por task
-- [x] Ordem de execução clara
-- [x] Tasks de IaC incluídas (se aplicável)
-- [x] State atualizado com total de tasks
-- [x] Usuário aprovou breakdown
-
----
-
-## Integração com Superpowers
-
-> Disponível quando o plugin `superpowers` está instalado.
-
-| Skill | Quando Usar | Invocação |
-|-------|-------------|-----------|
-| `writing-plans` | Após breakdown de tasks, para planejar sequência de implementação | `Skill(superpowers:writing-plans)` |
-| `executing-plans` | Para executar o plano de tasks em sessão separada | `Skill(superpowers:executing-plans)` |
-
----
-
-## Outputs desta Fase
-
-<!-- morph:outputs:tasks -->
-| Output | Caminho |
-|--------|---------|
-| `tasks` | `.morph/features/{feature}/3-tasks/tasks.md` |
-<!-- /morph:outputs -->
-
----
-
-Após aprovação: "Planejamento completo! Execute `/morph-apply $ARGUMENTS` para iniciar implementação."

package/framework/skills/level-1-workflows/phase-uiux/SKILL.md

@@ -1,286 +0,0 @@
----
-name: morph:phase-uiux
-description: MORPH-SPEC Phase 1.5 (UI/UX). Creates design-system.md, mockups.md, components.md, and flows.md using Figma/Playwright/Context7 MCPs. Use after setup for features with frontend UI components, pages, dashboards, forms, wizards, or visual interactions requiring design documentation.
-argument-hint: "[feature-name]"
-user-invocable: false
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-cliVersion: "4.9.0"
----
-
-# MORPH UI/UX Design - FASE 1.5
-
-> INTERNAL: Workflow skill used by /morph-proposal during automated phase orchestration. Not a user command.
-
-Fase condicional para features com front-end. Coleta requisitos de UI/UX, gera wireframes, specs de componentes e fluxos de usuário.
-
-## Pré-requisitos
-
-- [ ] FASE 1 (Setup) concluída
-- [ ] Feature tem keywords de UI detectadas (blazor, ui, component, page, dashboard, wizard, form, chart)
-- [ ] `uiux-designer` agent ativado
-
-## Ferramentas Recomendadas
-
-> **Ref:** `framework/skills/level-0-meta/tool-usage-guide/SKILL.md` para guia completo.
-> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` para referência MCP.
-
-| Ação | Ferramenta | Alternativa |
-|------|------------|-------------|
-| Verificar design system existente | **Read** `.morph/context/design-system.md` | — |
-| Ler screenshots do usuário | **Read** (arquivo de imagem) | — |
-| Buscar variáveis CSS existentes | **Grep** `--root:` em `*.css,*.scss` | — |
-| Encontrar componentes existentes | **Glob** `**/Components/**/*.razor` ou `**/components/**/*.tsx` | — |
-| Extrair design tokens do Figma | **Figma MCP** `get_file({ fileKey })` | Read CSS/SCSS variables |
-| Documentação de componentes UI | **Context7 MCP** `query_docs({ libraryId, query })` | **WebSearch** + **WebFetch** |
-| Preview de página existente | **Playwright MCP** `browser_navigate()` + `browser_take_screenshot()` | **WebFetch** URL |
-| Inspecionar estrutura da página | **Playwright MCP** `browser_snapshot()` | **WebFetch** + parse manual |
-| Testar layout responsivo | **Playwright MCP** `browser_resize()` + `browser_take_screenshot()` | Manual testing |
-| Referências de design externas | **WebSearch** + **WebFetch** | — |
-| Renderizar templates UI | **Bash** `npx morph-spec template render docs/ui-mockups ...` | — |
-| Gerar design system de CSS existente | **Bash** `npx morph-spec generate design-system --scan` | — |
-| Atualizar state | **Bash** `npx morph-spec state mark-output ...` | — |
-
-**MCPs desta fase:** Figma (design tokens), Playwright (preview, inspeção, responsividade), Context7 (docs de componentes).
-
-**Anti-padrões:**
-- ❌ WebSearch para docs MudBlazor (use Context7 MCP — mais preciso)
-- ❌ Task agent para ler um screenshot (use Read direto na imagem)
-- ❌ Adivinhar props de componentes (use Context7 para API real)
-
----
-
-## Workflow
-
-### Passo 0: Verificar Design System Existe
-
-**CRITICAL:** Antes de iniciar a FASE UI/UX, verifique se um design system existe:
-
-```
-Read: .morph/context/design-system.md
-```
-
-Se o arquivo não existir (design system não encontrado):
-
-1. **Opção A - Scaffold automático:**
-   - O sistema criará automaticamente um design system ao avançar para implementação
-   - Você pode gerar manualmente agora: `npx morph-spec generate design-system`
-
-2. **Opção B - Criar manualmente:**
-   - Crie `.morph/context/design-system.md` (project-level, compartilhado)
-   - Ou `.morph/features/$ARGUMENTS/2-ui/design-system.md` (feature-specific)
-
-3. **Opção C - Scan existing CSS:**
-   - Se o projeto já tem CSS com variáveis: `npx morph-spec generate design-system --scan`
-
-**⚠️ IMPORTANTE:**
-- Design system é **obrigatório** para features UI
-- Gate automático bloqueará implementação (FASE 5) se design system não existir
-- Melhor criar agora para garantir consistência visual
-
-### Passo 1: Detectar Se Fase É Necessária
-
-Verifique se agentes ativos incluem `uiux-designer`:
-
-```bash
-npx morph-spec state get $ARGUMENTS
-```
-
-Se `uiux-designer` NÃO estiver nos `activeAgents`, pule esta fase e continue para FASE 2 (Design).
-
-### Passo 1.5: Design Thinking — Direção Estética
-
-> **Ref:** `framework/standards/frontend/design-system/aesthetic-direction.md`
-
-**ANTES de coletar requisitos técnicos**, definir a direção visual com 4 perguntas:
-
-1. **Purpose**: Que problema resolve? Quem usa? Qual o contexto profissional?
-2. **Tone**: Qual direção? (Minimal Refined / Editorial / Soft Professional / Industrial / Modern Luxury)
-3. **Differentiation**: Qual o 1 elemento memorável desta interface?
-4. **Constraints**: Framework, performance budget, brand guidelines existentes
-
-**CRITICAL:** Commitar à direção ANTES das specs técnicas. Documentar em `ui-design-system.md`
-na seção `## Aesthetic Direction` (template disponível no standard acima).
-
-**Anti-padrões a evitar:**
-- ❌ Gradiente roxo em fundo branco (AI cliché)
-- ❌ Inter/Roboto como fonte de display
-- ❌ Grid 3-colunas de cards sem diferencial visual
-- ❌ Paleta de 5 cores de peso igual (sem dominant + accent)
-
-### Passo 2: Coletar Input do Usuário
-
-**SEMPRE perguntar ao usuário PRIMEIRO:**
-
-1. **Layout e estilo**:
-   - Você tem alguma ideia de layout em mente?
-   - Tem alguma referência visual? (sites, apps, screenshots)
-   - Como imagina o fluxo do usuário?
-
-2. **Componentes e interações**:
-   - Quais os principais componentes desta tela/página?
-   - Quais estados precisam ser considerados? (loading, error, empty, success)
-
-3. **Imagens de referência**:
-   - Tem imagens de exemplo que eu possa analisar?
-   - Se SIM: use Read tool para ler screenshots e extrair padrões
-
-### Passo 3: Decidir Biblioteca UI
-
-Escolha entre **Fluent UI Blazor** (recomendado para AI-first) ou **MudBlazor** (componentes complexos):
-
-**Critérios:**
-- Fluent UI: Para dashboards, forms simples, AI components, Microsoft design language
-- MudBlazor: Para data grids avançadas, charts complexos, material design
-
-**Documente a decisão em `decisions.md`.**
-
-### Passo 4: Gerar Deliverables
-
-Crie os seguintes arquivos em `.morph/features/$ARGUMENTS/`:
-
-> **Use templates:** Utilize `npx morph-spec template render` para gerar os arquivos a partir dos templates em `.morph/framework/templates/docs/`. Templates disponíveis: `ui-design-system`, `ui-mockups`, `ui-components`, `ui-flows`.
-
-#### 4.1. `ui-design-system.md`
-
-**Se design system project-level existe (`.morph/context/design-system.md`):**
-- Referencie-o nos specs: "Uses project design system at .morph/context/design-system.md"
-- Crie `ui-design-system.md` apenas se houver cores/componentes **específicos** da feature
-
-**Se não existe:**
-- Crie design system feature-level completo com:
-  - **Seção `## Aesthetic Direction`** (usar template de `aesthetic-direction.md`):
-    direção, font pair, color philosophy, motion intent, composition approach
-  - Paleta de cores (primary, secondary, accent, semantic)
-  - Tipografia (heading scales, body text, code)
-  - Spacing e layout (grid, margins, paddings)
-  - Componentes base (buttons, inputs, cards)
-
-#### 4.2. `ui-mockups.md`
-
-Wireframes ASCII + descrições:
-- Layout geral de cada tela/página
-- Posicionamento de componentes
-- Responsividade (desktop, tablet, mobile)
-- Estados (loading, error, empty, success)
-
-#### 4.3. `ui-components.md`
-
-Specs técnicas de componentes Fluent UI/MudBlazor:
-- Componente a usar (FluentButton, MudDataGrid, etc.)
-- Props e configurações
-- Eventos e bindings
-- Validações e estados
-
-#### 4.4. `ui-flows.md`
-
-Fluxos de usuário completos:
-- User stories
-- Diagramas de fluxo (texto/ASCII)
-- Edge cases (o que acontece se...?)
-- Validações e feedback
-
-### CHECKPOINT: Validar Deliverables UI
-
-**⏸️ PAUSE - Antes de prosseguir para acessibilidade:**
-
-- [ ] Direção estética definida e documentada em `ui-design-system.md`?
-- [ ] Font pair especificado (não apenas Inter/Roboto para display)?
-- [ ] Color philosophy: dominant + accent + rationale documentados?
-- [ ] Design system definido (project-level ou feature-level)?
-- [ ] Wireframes cobrem todos os estados (loading, error, empty, success)?
-- [ ] Componentes especificados com props reais da biblioteca UI escolhida?
-- [ ] Fluxos de usuário completos com edge cases?
-- [ ] Biblioteca UI escolhida documentada como ADR em `decisions.md`?
-
-**❌ Se alguma checkbox NÃO estiver marcada:**
-→ Voltar e completar o deliverable faltante
-
-**✅ Se TODAS as checkboxes estiverem marcadas:**
-→ Prosseguir para validação de acessibilidade
-
----
-
-### Passo 5: Validar Acessibilidade e Responsividade
-
-Documente nos arquivos UI:
-- **WCAG 2.1 Level AA** compliance
-  - Contraste de cores adequado
-  - Labels acessíveis para screen readers
-  - Navegação por teclado
-- **Responsive breakpoints**
-  - Desktop (>1200px)
-  - Tablet (768px - 1199px)
-  - Mobile (<768px)
-
-### Passo 6: Atualizar State
-
-```bash
-npx morph-spec state mark-output $ARGUMENTS ui-design-system
-npx morph-spec state mark-output $ARGUMENTS ui-mockups
-npx morph-spec state mark-output $ARGUMENTS ui-components
-npx morph-spec state mark-output $ARGUMENTS ui-flows
-```
-
-> **Nota sobre formatos:** Os comandos `mark-output` aceitam TANTO kebab-case (`ui-design-system`)
-> QUANTO camelCase (`uiDesignSystem`). Ambos os formatos funcionam igualmente! Use o que for mais
-> confortável para você. Exemplos:
-> - `npx morph-spec state mark-output my-feature uiDesignSystem` ✅
-> - `npx morph-spec state mark-output my-feature ui-design-system` ✅
-
-## Outputs Gerados
-
-- `.morph/features/$ARGUMENTS/2-ui/design-system.md`
-- `.morph/features/$ARGUMENTS/2-ui/mockups.md`
-- `.morph/features/$ARGUMENTS/2-ui/components.md`
-- `.morph/features/$ARGUMENTS/2-ui/flows.md`
-- `.morph/features/$ARGUMENTS/1-design/decisions.md` (atualizado com ADR UI library)
-
-### Passo 7: Validar Design com Frontend Review
-
-Após gerar todos os 4 outputs de UI e atualizar o state (Passo 6):
-
-```bash
-/frontend-review $ARGUMENTS
-```
-
-O skill valida: contraste WCAG dos tokens, existência de todos os outputs, acessibilidade
-estática no design, e gera screenshots dos mockups se dev server disponível.
-
-**🚫 Se o frontend-review bloquear**, corrija os issues antes de apresentar ao usuário.
-
----
-
-## PAUSA OBRIGATÓRIA
-
-Apresente ao usuário 3 ações sugeridas:
-
-1. **Aprovar UI/UX e prosseguir para design técnico**
-2. **Ajustar wireframes/componentes de telas específicas**
-3. **Revisar biblioteca UI escolhida (Fluent UI / MudBlazor)**
-
-## Critérios de Avanço
-
-- [x] Input do usuário coletado (layout, referências)
-- [x] Biblioteca UI escolhida e justificada (ADR)
-- [x] 4 deliverables criados (design-system, mockups, components, flows)
-- [x] Acessibilidade WCAG 2.1 documentada
-- [x] Responsividade especificada
-- [x] State atualizado
-- [x] Usuário aprovou UI/UX
-
----
-
-## Outputs desta Fase
-
-<!-- morph:outputs:uiux -->
-| Output | Caminho |
-|--------|---------|
-| `uiDesignSystem` | `.morph/features/{feature}/2-ui/design-system.md` |
-| `uiMockups` | `.morph/features/{feature}/2-ui/mockups.md` |
-| `uiComponents` | `.morph/features/{feature}/2-ui/components.md` |
-| `uiFlows` | `.morph/features/{feature}/2-ui/flows.md` |
-<!-- /morph:outputs -->
-
----
-
-Continuar automaticamente para FASE 2 (Design) após aprovação.

package/src/commands/project/index.js

@@ -1,8 +0,0 @@
-/**
- * Project-Level Commands
- */
-export { initCommand } from './init.js';
-export { doctorCommand } from './doctor.js';
-export { updateCommand } from './update.js';
-export { tutorialCommand } from './tutorial.js';
-export { monitorCommand } from './monitor.js';

package/src/core/index.js

@@ -1,10 +0,0 @@
-/**
- * Core Framework Logic
- *
- * Central hub for state management, templates, and workflows.
- * Separated from shared libraries (lib/) for clear architectural boundaries.
- */
-
-export * from './state/index.js';
-export * from './templates/index.js';
-export * from './workflows/index.js';

package/src/core/state/index.js

@@ -1,8 +0,0 @@
-/**
- * Core State Management
- *
- * State management and phase state machine for MORPH-SPEC workflow.
- */
-
-export { StateManager } from './state-manager.js';
-export { PhaseStateMachine, PHASES, validatePhase } from './phase-state-machine.js';

package/src/core/templates/index.js

@@ -1,9 +0,0 @@
-/**
- * Core Template System
- *
- * Template registry, rendering, and data sources for code generation.
- */
-
-export { TemplateRegistry } from './template-registry.js';
-export { TemplateRenderer } from './template-renderer.js';
-export { TemplateDataSources } from './template-data-sources.js';