Primeiros 30 Dias — Issues GitHub

Documento canônico: 04-operations/first-30-days-github-issues.md

Status: criado Issue de origem: #27

---

Objetivo

Registrar a estrutura minima de execucao para que o primeiro mes nao dependa de memoria, conversa solta ou documento estatico.

O GitHub passa a cumprir tres funcoes:

1. manter o plano operacional vivo;
2. registrar evidencia semanal;
3. gerar proximos commits e issues a partir da retrospectiva.

---

Issues criadas

Issue	Semana / tema	Objetivo
#71	Semana 1	Preparar lista top 5 Trust Score, candidatos Porta C e evidencia inicial
#72	Semana 2	Enviar abordagens, registrar pipeline e identificar candidato Blueprint
#74	Semana 3	Avancar propostas, parceiro de indicacao e conteudo
#73	Semana 4	Execucao, NeedyU.ai, artigo, analista senior e retrospectiva
#75	Pipeline	Concentrar status por Porta A/B/C e parceiros

Observacao: a numeracao do GitHub nao segue a ordem semanal porque algumas issues foram criadas em paralelo. A ordem canonica e W1, W2, W3, W4 e Pipeline.

Artefatos da #75

Artefato	Funcao
first-30-days-commercial-pipeline.md	Registro operacional publico-seguro do pipeline A/B/C e parceiros
first-30-days-pipeline-template.md	Modelo reutilizavel para copiar, preencher e adaptar em CRM, planilha ou GitHub Project
#75	Issue viva para status semanal, evidencias, bloqueios e decisoes

---

Labels recomendadas

Label	Uso
fase-01	Tudo que pertence aos primeiros 30 dias
estrategia	Itens que afetam plano, posicionamento ou priorizacao
operacao	Itens que exigem rotina, responsavel ou evidencia
pendente	Ainda nao concluido
prioritario	Bloqueia leitura executiva ou proximo passo comercial

---

Como comentar status

Cada issue semanal deve receber pelo menos um comentario de status. A #75 deve receber comentarios de pipeline sempre que houver movimento comercial relevante.

Template:

## Status - AAAA-MM-DD

**Coluna:** Backlog | Esta semana | Em andamento | Bloqueado | Evidencia | Feito
**Responsavel:**

### O que mudou
-

### Evidencia
-

### Bloqueio
-

### Decisao pedida
-

### Proximo passo
-

---

Quando fechar cada issue

Issue	Pode fechar quando
#71	A lista A1-A5 e C1-C2 estiver preenchida ou houver bloqueio explicito aprovado
#72	As abordagens forem enviadas ou a tese de abordagem for revisada com decisao clara
#74	Propostas/parceiros tiverem evidencia, mesmo que a venda ainda nao tenha fechado
#73	Retrospectiva do mes 1 gerar decisoes e issues/commits do mes 2
#75	O mes 1 for encerrado e o pipeline migrar para CRM, GitHub Project ou rotina permanente

---

Relacao com o plano de 2 anos

O plano de 2 anos continua sendo a visao executiva. As issues sao a camada de execucao.

Atualize 01-strategy/2year-plan.md apenas quando houver evidencia concreta, por exemplo:

• proposta enviada;
• contrato fechado;
• URL publicada;
• artigo publicado;
• pipeline preenchido;
• retrospectiva concluida;
• decisao formal de mudar prioridade.

---

Saida esperada da retrospectiva

A Semana 4 precisa gerar uma decisao para o mes 2.

No minimo, criar ou atualizar:

• uma issue de continuidade comercial;
• uma issue de ajuste de materiais;
• uma issue de operacao interna;
• um commit ou PR refletindo aprendizado real no plano.

Se nada disso acontecer, a retrospectiva nao foi concluida: ela foi apenas uma reuniao.