ealmeida/bi-descomplicar

Fork 0

Files

T

ealmeida 75041136d2 chore: ignora graphify-out gerado

2026-10-28 15:59:30 +00:00

4.6 KiB

Raw Blame History

layer, type, title, description, tags, timestamp, status

layer

type

title

description

Ciclo de Vida de Projecto — Sequência Obrigatória

Regra de ouro: Nunca saltar fases. Cada fase produz um artefacto concreto. Sem artefacto → fase não concluída → não avançar.

A Sequência

1. IDEIA
      ↓
2. BRIEFING
      ↓
3. PESQUISA ← obrigatória (Web + NLM + Mem0 + Wiki)
      ↓
4. BRAINSTORMING
      ↓
5. SPEC (aprovada por Emanuel)
      ↓
6. PLAN (validado antes de tocar em código)
      ↓
7. REPO GIT (se projecto com código)
      ↓
8. IMPLEMENTAÇÃO
      ↓
9. CI/CD (se aplicável — paralelo ao deploy)
      ↓
10. DEPLOY

Detalhe por Fase

1. Ideia

Capturar em 00-Inbox/ do Hub ou comentário Desk
Artefacto: nota de ideia (1 parágrafo mínimo)

2. Briefing

Definir: contexto, problema, objectivo, stakeholders, restrições
Registar no Desk CRM como tarefa ou ticket
Artefacto: docs/SPECS/BRIEF.md ou comentário Desk

3. Pesquisa — OBRIGATÓRIA ⚠️

Antes de qualquer decisão de arquitectura ou implementação:

Fonte	O que pesquisar
Web	Estado da arte, soluções existentes, benchmarks
NotebookLM	Notebooks temáticos relevantes
Mem0	`search_memories("contexto do projecto")` — o que já sabemos
Wiki IJFW	Conhecimento curado existente
Hub	PROCs, QRs, decisões anteriores relacionadas

Regra: Se a pesquisa revelar que a solução já existe → usar o que existe, não reinventar.

Artefacto: notas de pesquisa em docs/ ou resumo no BRIEF

4. Brainstorming

Explorar abordagens alternativas
Avaliar trade-offs com evidência da pesquisa
Envolver Mem0 para contexto de decisões passadas
Artefacto: docs/PLANS/BRAINSTORM.md com opções e decisão

5. SPEC

Especificação completa: arquitectura, componentes, interfaces, critérios de aceitação
Aprovação explícita por Emanuel antes de avançar
Artefacto: docs/SPECS/SPEC.md com status approved

6. Plan

Plano de implementação detalhado: fases, tarefas, dependências, estimativas
Validação humana antes de tocar em código
Registar tarefas no Desk CRM
Artefacto: docs/PLANS/PLAN.md + tarefas Desk

7. Repo Git

Criar repositório em git.descomplicar.pt (Gitea)
Seguir PROC INF-EZP-001 para deploy no EasyPanel
Configurar .desk-project na raiz
Artefacto: repo criado, README.md inicial, estrutura XDP-PRJ-001

8. Implementação

Seguir o PLAN por fases
Registar progresso em MEMORY.md por sessão
Cada decisão arquitectural → comentário Desk
Artefacto: código funcional + testes

9. CI/CD (se aplicável)

Configurar via Gitea Actions → EasyPanel webhook
Ver PROC-Gitea-Runners-CICD.md
Artefacto: pipeline funcional com deploy automático

10. Deploy

Seguir PROC INF-EZP-001 (EasyPanel) ou PROC adequado
Validar com E2E após deploy
Actualizar STATUS.md → estado deployed
Artefacto: serviço em produção + STATUS.md actualizado

Artefactos por Fase (resumo)

Fase	Artefacto obrigatório
Ideia	Nota capturada
Briefing	BRIEF.md ou comentário Desk
Pesquisa	Notas de pesquisa (Web + NLM + Mem0 + Wiki)
Brainstorming	BRAINSTORM.md com decisão
SPEC	SPEC.md aprovada
Plan	PLAN.md + tarefas Desk
Repo Git	Repositório Gitea + estrutura
Implementação	Código + testes + MEMORY.md
CI/CD	Pipeline funcional
Deploy	Serviço em produção + STATUS.md

Anti-Padrões (proibido)

❌ Começar a implementar sem SPEC aprovada
❌ Saltar a pesquisa — "já sei o que fazer"
❌ Deploy sem testes passados
❌ Criar repositório antes do PLAN estar validado
❌ Reinventar o que já existe (Mem0 evita isto)

Referências

PROC-Estrutura-Pasta-Projecto.md (XDP-PRJ-001) — ficheiros obrigatórios por pasta
06-Operacoes/Procedimentos/D7-Tecnologia/Infraestrutura/PROC-EasyPanel-Deployment.md — deploy
06-Operacoes/Procedimentos/D7-Tecnologia/Infraestrutura/PROC-Gitea-Runners-CICD.md — CI/CD

Criado: 29-06-2026 | Descomplicar® | Sequência obrigatória para todos os projectos

4.6 KiB Raw Blame History