Plano de Implementacao¶

Versão: 1.0

< Backward:
- Processo de Desenvolvimento e Entrega (Kanban);
- 03-Requisitos.md (prioridades MoSCoW);
- 05-Casos-de-Uso.md (UC-001 a UC-028);
- 07-User-Stories.md (US-001 a US-055);
- 08-Tasks.md (TASK-001 a TASK-090);
- 09-Casos-de-Teste.md (TC-001 a TC-090);
- 01-Visao-Geral-DAS.md (dependência G-014.7 → G-000);
- 02-Contratos-API.md.

1. Premissas do Plano¶

Equipe: 1 desenvolvedor (00-Visao-Geral-DAS.md, seção 1.2) → WIP baixo, fluxo estritamente sequencial na coluna “Em Desenvolvimento” e revisão feita pelo próprio autor do código antes de avançar.
Regra estrutural inegociável: G-014.7 (sessão autenticada válida) é pré-condição de toda a árvore de G-000 (00-Visao-Geral-DAS.md, seção 1.1). Nenhuma US do Sistema de Tarefas (Fase B em diante) entra em A Fazer antes do Guard Global (ADR-008) estar implementado e íntegro — marco fechado ao final do Lote 4.
MoSCoW herdado de 03-Requisitos.md: todos os RFs são Must, exceto RF-009 (Snooze) e RF-015 (Duplicação), marcados Should. RNF-003 é Won’t nesta versão — não gera item de board, permanece apenas como risco aceito em 03-Riscos-Dívida-Tecnica.md (RISCO-001, RISCO-002). As User Stories e Tasks levantadas no adendo de rastreabilidade (US-043 a US-055, TASK-071 a TASK-090) refinam RFs Must já existentes e herdam a mesma prioridade Must de seus RFs de origem — nenhuma delas introduz escopo novo.
Regra de composição do MVP (seção 4.2 do processo): MVP = { itens Must concluídos e integrados }. Os itens Should (Duplicação, Snooze) — embora descritos na Especificação como parte da “MVP - Versão 1” — só fluem pelo board após o fechamento de todos os Must, compondo o primeiro incremento pós-MVP. A nomenclatura “MVP - Versão 1” nos demais documentos deve ser lida como “escopo da Versão 1”, não como sinônimo estrito do MVP definido pelo processo Kanban.
Granularidade do campo Status: conforme seção 5 do processo, tanto US-000 quanto TASK-000 registram Status. Como a equipe é de 1 pessoa e o WIP de “Em Desenvolvimento” é 1, na prática todas as Tasks de uma mesma US avançam juntas pelo board; por isso, este documento consolida o Status por US (linha da tabela), aplicando-o implicitamente às Tasks vinculadas. Divergência pontual (ex.: uma Task de frontend aguardando a de backend concluir) é anotada em nota de rodapé quando relevante, não em coluna separada.
Limites de WIP adotados (por coluna, válidos para o board inteiro — não por Lote):

Coluna	Limite WIP	Origem
A Fazer	3	Processo, seção 3.2
Em Desenvolvimento	1	Processo, seção 3.2
Em Revisão/Teste	2	Processo, seção 3.2
Pronto para Deploy	3	Adotado neste plano para permitir consolidar um pequeno lote de itens aprovados antes de cada janela de deploy, dado o custo fixo de subir ambiente com equipe de 1 pessoa. Não é um limite exigido pelo processo (que só obriga limite nas três colunas intermediárias), mas uma prática adicional deste plano.

2. Estrutura dos Lotes¶

Cada Lote agrupa User Stories (e suas Tasks/TCs associadas) que só podem entrar em A Fazer quando o(s) Lote(s) da qual dependem estiver(em) em Concluído. Dentro de um mesmo Lote, os itens não possuem dependência bloqueante entre si — na prática, com WIP(Em Desenvolvimento)=1, seguem em fila simples de prioridade Must > Should.

Conforme a Definition of Ready (processo, seção 6.1), um item só é elegível para A Fazer se: (i) está decomposto em Tasks; (ii) possui critério de aceitação claro; (iii) não tem dependência bloqueante pendente. Aplicando essa regra e o limite de WIP(A Fazer)=3 ao estado inicial do board, apenas o Lote 1 atende ao DoR hoje e por isso é o único com Status inicial A Fazer. Todos os demais permanecem em Backlog até sua dependência ser satisfeita — mesmo que, textualmente, pareçam simples, eles não entram na fila de trabalho enquanto o Lote antecedente não estiver em Concluído (DoD, processo seção 6.2).

FASE A — Sistema de Autenticação¶

Lote 1 — Cadastro `[Must]`¶

Dependência: nenhuma — ponto de entrada do sistema. Status do Lote: A Fazer (2 itens, dentro do limite WIP=3 da coluna)

US	Título	Status	Tasks	TCs
US-036	Cadastrar nova conta	A Fazer	TASK-061, TASK-062	TC-061, TC-062
US-037	Validar regras de cadastro	A Fazer	TASK-063	TC-063

Lote 2 — Login e Emissão de Sessão `[Must]`¶

Dependência: Lote 1 (exige contas já cadastradas — pré-condição de TC-050: “possuir conta cadastrada e ativa”). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-030	Autenticar via e-mail e senha	Backlog	TASK-050, TASK-051	TC-050, TC-051
US-031	Omitir existência de conta em falhas	Backlog	TASK-052	TC-052

Lote 3 — Proteção contra Força Bruta `[Must]`¶

Dependência: Lote 2 (UC-016 “Estende UC-015” — precisa do fluxo básico de login já funcional para contar tentativas sobre ele). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-032	Bloquear conta temporariamente por força bruta	Backlog	TASK-053, TASK-054	TC-053, TC-054

Lote 4 — Gerenciamento de Sessão + Guard Global `[Must]`¶

Dependência: Lote 2 (precisa de emissão de sessão já funcionando para existir o que listar/revogar/renovar). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-033	Visualizar sessões ativas	Backlog	TASK-055, TASK-056	TC-055, TC-056
US-034	Revogar sessão individual remotamente	Backlog	TASK-057, TASK-058	TC-057, TC-058
US-051	Renovar sessão automaticamente sem novo login (Refresh Token)	Backlog	TASK-071, TASK-080	TC-071, TC-080
US-052	Revogar todas as sessões remotas de uma vez	Backlog	TASK-081, TASK-089	TC-081, TC-089

Marco arquitetural deste Lote: implementação do AuthGuard global (ADR-008), aplicando RNF-002/G-014.7, e do fluxo completo do modelo híbrido de tokens (US-051 fecha o ciclo Access/Refresh Token descrito em RF-021). A partir da conclusão deste Lote, toda rota do Sistema de Tarefas (Fase B em diante) pode ser protegida por padrão — nenhuma US da Fase B entra em A Fazer antes deste marco fechar. Nota de sequenciamento interno: dentro do Lote, US-051 (renovação) e US-052 (revogação em massa) reaproveitam, respectivamente, o par de tokens e a função revokeAllSessions (ADR-007) — ambos só ficam testáveis de ponta a ponta depois que US-033/US-034 (listagem e revogação individual) estiverem concluídas, por isso seguem essa ordem dentro do Lote mesmo sem bloqueio formal entre elas.

Lote 5 — Desativação de Conta `[Must]`¶

Dependência: Lote 4 (reutiliza revokeAllSessions, ADR-007, já implementada). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-041	Desativar conta temporariamente	Backlog	TASK-067, TASK-068	TC-067, TC-068

Lote 6 — Reativação de Conta `[Must]`¶

Dependência: Lote 5 (o fluxo real de produção só produz uma conta Desativada via desativação; embora testável isoladamente via seed direto no banco, a ordem de produção segue a jornada real do usuário). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-035	Reativar conta pelo login	Backlog	TASK-059, TASK-060	TC-059, TC-060

Lote 7 — Configurações: Perfil `[Must]`¶

Dependência: Lote 4 (Guard Global precisa estar ativo para proteger a rota). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-038	Atualizar informações pessoais de cadastro	Backlog	TASK-048, TASK-049	TC-048, TC-049
US-053	Consultar meus dados de perfil atuais	Backlog	TASK-082, TASK-083	TC-082, TC-083

Nota de sequenciamento interno: US-053 (GET /user/me, pré-preenchimento do formulário) precede US-038 na prática de implementação — o formulário de edição depende dos dados carregados por ela — mas ambas fecham o mesmo Lote por não terem dependência formal de Lotes diferentes.

Lote 8 — Alteração de Senha `[Must]`¶

Dependência: Lote 4 (revokeAllSessions, ADR-007). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-039	Alterar senha da conta	Backlog	TASK-064, TASK-065	TC-064, TC-065
US-040	Invalidar sessões na troca de senha	Backlog	TASK-066	TC-066

Observação: ao final do Lote 8, G-014 está satisfeita com exceção de G-014.4.2 (Exclusão de Conta), deliberadamente adiada para o Lote 15 — ver nota de dependência cruzada na Fase D.

FASE B — Sistema de Tarefas: Estrutura Base¶

Lote 9 — Cadernos `[Must]`¶

Dependência: Lote 4 (Guard Global ativo — primeira rota protegida do Sistema de Tarefas). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-001	Cadastrar novo Caderno na raiz	Backlog	TASK-001, TASK-002	TC-001, TC-002
US-002	Visualizar lista de cadernos criados	Backlog	TASK-003	TC-003

Lote 10 — Inbox e Classificação `[Must]`¶

Dependência: Lote 9 (classificação exige Cadernos já existentes). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-003	Capturar item rápido na Inbox	Backlog	TASK-004, TASK-005	TC-004, TC-005
US-004	Visualizar itens na Inbox	Backlog	TASK-006	TC-006
US-005	Mover item da Inbox para um Caderno	Backlog	TASK-007, TASK-008	TC-007, TC-008
US-006	Validar unicidade de vínculo item-caderno	Backlog	TASK-009	TC-009

FASE C — Motor Central de Itens¶

Lote 11 — Criação, Detalhe e Edição de Itens (TODO/SCHEDULE) `[Must]`¶

Dependência: Lote 10 (item pode nascer já classificado ou vir da Inbox). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-007	Criar item do tipo TODO	Backlog	TASK-010, TASK-011	TC-010, TC-011
US-008	Criar item do tipo SCHEDULE	Backlog	TASK-012, TASK-013	TC-012, TC-013
US-009	Associar TODO a um SCHEDULE	Backlog	TASK-014	TC-014
US-050	Visualizar detalhes completos de um item	Backlog	TASK-074, TASK-084	TC-074, TC-084
US-045	Editar propriedades de um item	Backlog	TASK-075, TASK-085	TC-075, TC-085
US-046	Impedir edição de campos incompatíveis com o tipo do item	Backlog	TASK-075	TC-075

Nota de sequenciamento interno: US-050 (visualização de detalhes) é implementada antes de US-045/046 (edição), pois o formulário de edição reaproveita a mesma tela/endpoint de detalhe como base. A resposta de GET /items/{id} só exibirá sub-itens de fato depois que o Lote 12 estiver concluído — isso não bloqueia o fechamento deste Lote (o contrato já suporta o campo vazio), mas o TC-074 completo (com sub-itens populados) só é validado de ponta a ponta após o Lote 12.

Lote 12 — Sub-itens `[Must]`¶

Dependência: Lote 11 (exige TODO já existente para vincular sub-itens). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-010	Adicionar sub-item a um TODO	Backlog	TASK-015, TASK-016	TC-015, TC-016
US-011	Validar escopo restrito do sub-item	Backlog	TASK-017	TC-017
US-054	Concluir sub-item de uma tarefa	Backlog	TASK-077, TASK-087	TC-077, TC-087
US-049	Remover sub-item individualmente	Backlog	TASK-078, TASK-088	TC-078, TC-088

Lote 13 — Ciclo de Vida: Conclusão, Arquivamento e Deleção `[Must]`¶

Dependência: Lote 12 (deleção de TODO precisa checar sub-itens antes de exigir confirmação de cascata — TASK-023). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-047	Marcar TODO como concluído	Backlog	TASK-076, TASK-086	TC-076, TC-086
US-048	Reverter conclusão de um TODO	Backlog	TASK-076	TC-076
US-016	Arquivar item concluído manualmente	Backlog	TASK-025, TASK-026	TC-025, TC-026
US-014	Deletar item sem sub-itens	Backlog	TASK-021, TASK-022	TC-021, TC-022
US-015	Deletar item com sub-itens mediante confirmação	Backlog	TASK-023, TASK-024	TC-023, TC-024
US-043	Excluir caderno movendo itens para a Inbox	Backlog	TASK-072	TC-072
US-044	Confirmar exclusão de caderno na interface	Backlog	TASK-073	TC-073

Nota de sequenciamento interno: a ordem lógica dentro do Lote é conclusão (US-047/048) → arquivamento (US-016, que exige isCompleted=true como pré-condição de domínio, ADR-012) → deleção (US-014/015). A exclusão de Caderno (US-043/044) foi incluída neste Lote por reaproveitar o mesmo padrão transacional (ADR-010) da deleção de item, embora dependa apenas dos Lotes 9–10 tecnicamente — sua posição aqui é uma escolha de sequenciamento de implementação (reuso de padrão já estabelecido), não uma dependência funcional bloqueante.

Lote 14 — Recorrência `[Must]`¶

Dependência: Lote 11 (recorrência se aplica a SCHEDULE e TODO já existentes). Sem dependência de Lote 12/13 — pode ser paralelizado com eles caso o WIP permita. Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-017	Configurar recorrência básica em item	Backlog	TASK-027, TASK-028	TC-027, TC-028
US-018	Restringir exceções de recorrência	Backlog	TASK-029	TC-029

FASE D — Exclusão de Conta (dependência cruzada entre as duas raízes)¶

Lote 15 — Exclusão de Conta `[Must]`¶

Dependência: Lote 13 (a cascata de exclusão de conta remove Cadernos/Itens/Sub-itens — RF-023/ADR-010 —, portanto exige que esse schema já esteja implementado e testável). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-042	Excluir conta permanentemente	Backlog	TASK-069, TASK-070	TC-069, TC-070

Nota de dependência cruzada: esta US pertence conceitualmente ao Sistema de Autenticação (G-014.4.2), mas só é tecnicamente concluível após a Fase C, pois depende do modelo de dados do Sistema de Tarefas existir para que a cascata (ADR-010) seja implementada e validada de ponta a ponta. É o único ponto do plano em que a ordem de implementação diverge da ordem de agrupamento temático dos documentos de requisitos.

Ao final do Lote 15, ambas as metas-raiz (G-000 e G-014) têm a totalidade de seus itens Must concluídos.

FASE E — Organização e Descoberta¶

Lote 16 — Ordenação `[Must]`¶

Dependência: Lote 11 (prioridade, due date e data de criação já existem no item). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-028	Ordenar listagem por critérios estruturais	Backlog	TASK-045, TASK-046	TC-045, TC-046
US-029	Aplicar ordenação padrão em listagens	Backlog	TASK-047	TC-047
US-055	Persistir reordenação manual de tarefas	Backlog	TASK-079, TASK-090	TC-079, TC-090

Lote 17 — Calendário `[Must]`¶

Dependência: Lote 14 (recorrência já calculável) + Lote 11 (datas de SCHEDULE/TODO já existentes). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-021	Visualizar Calendário em modo Diário	Backlog	TASK-033, TASK-034	TC-033, TC-034
US-022	Visualizar Semanal/Mensal/Agenda	Backlog	TASK-035, TASK-036	TC-035, TC-036
US-023	Aplicar regras de exibição cruzada	Backlog	TASK-037	TC-037

Lote 18 — Planner Diário `[Must]`¶

Dependência: Lote 17 (reaproveita CalendarVisibilityService, ADR-015, centralizado nessa camada). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-024	Visualizar Planner Diário	Backlog	TASK-038, TASK-039	TC-038, TC-039
US-025	Omitir SCHEDULEs do Planner Diário	Backlog	TASK-040	TC-040

Lote 19 — Busca `[Must]`¶

Dependência: Lote 11 (título e demais propriedades do TODO já existem para indexação/filtro). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-026	Buscar itens TODO por texto no título	Backlog	TASK-041, TASK-042	TC-041, TC-042
US-027	Refinar resultados com filtros	Backlog	TASK-043, TASK-044	TC-043, TC-044

Ao final do Lote 19, todos os itens [Must] do sistema — incluindo os refinamentos levantados no adendo de rastreabilidade (US-043 a US-055) — estão concluídos → condição de MVP satisfeita (seção 4.2 do processo).

FASE F — Incremento Pós-MVP (Should)¶

Lote 20 — Duplicação de Item `[Should]`¶

Dependência: Lote 13 (exige ciclo de vida, prioridade e caderno de origem já definidos no item a ser duplicado). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-012	Duplicar item de forma seletiva	Backlog	TASK-018, TASK-019	TC-018, TC-019
US-013	Omitir propriedades na duplicação	Backlog	TASK-020	TC-020

Lote 21 — Snooze `[Should]`¶

Dependência: Lote 13 (o item precisa estar no estado Ativo, gerenciado pelo ciclo de vida). Status do Lote: Backlog

US	Título	Status	Tasks	TCs
US-019	Adiar item ativo (Snooze rápido)	Backlog	TASK-030, TASK-031	TC-030, TC-031
US-020	Adiar item por data específica	Backlog	TASK-032	TC-032

3. Mapa de Dependências (visão consolidada)¶

flowchart TD
    O1[Lote 1: Cadastro] --> O2[Lote 2: Login/Sessão]
    O2 --> O3[Lote 3: Força Bruta]
    O2 --> O4[Lote 4: Sessão Avançada + Guard Global]
    O4 --> O5[Lote 5: Desativação]
    O5 --> O6[Lote 6: Reativação]
    O4 --> O7[Lote 7: Perfil]
    O4 --> O8[Lote 8: Alterar Senha]
    O4 --> O9[Lote 9: Cadernos]
    O9 --> O10[Lote 10: Inbox/Classificação]
    O10 --> O11[Lote 11: Itens - Criação/Detalhe/Edição]
    O11 --> O12[Lote 12: Sub-itens]
    O12 --> O13[Lote 13: Ciclo de Vida/Deleção]
    O11 --> O14[Lote 14: Recorrência]
    O13 --> O15[Lote 15: Exclusão de Conta]
    O11 --> O16[Lote 16: Ordenação]
    O14 --> O17[Lote 17: Calendário]
    O17 --> O18[Lote 18: Planner Diário]
    O11 --> O19[Lote 19: Busca]
    O13 --> O20[Lote 20: Duplicação - Should]
    O13 --> O21[Lote 21: Snooze - Should]

    classDef mvp fill:#3498db,stroke:#2980b9,color:#fff,font-weight:bold;
    classDef should fill:#f39c12,stroke:#c87f0a,color:#fff,font-weight:bold;
    class O1,O2,O3,O4,O5,O6,O7,O8,O9,O10,O11,O12,O13,O14,O15,O16,O17,O18,O19 mvp;
    class O20,O21 should;

4. Composição do MVP¶

MVP = Lotes 1 a 19 (todos os itens [Must] concluídos e integrados,
      incluindo US-043 a US-055 do adendo de rastreabilidade)
Incremento Pós-MVP #1 = Lotes 20 e 21 (itens [Should])

Conforme a Definition of Done (processo, seção 6.2), cada Lote só é considerado Concluído quando:

Código implementado e integrado;
Todos os TCs relacionados (coluna TCs de cada tabela acima) executados e aprovados;
Deploy realizado no ambiente de destino;
Critério de aceitação da(s) US correspondente(s) atendido integralmente.

A conclusão do Lote 19 marca o alcance formal do MVP. A partir daí, o board continua fluindo (Lotes 20–21 e eventuais itens futuros de V2 já mapeados em 03-Riscos-Dívida-Tecnica.md como RISCO-001/RISCO-002 e candidatos a meta futura), sem necessidade de um novo Plano de Implementação — apenas a atualização incremental do campo Status de cada item já cadastrado aqui.

5. Regra de Manutenção do Documento¶

Toda vez que um item mudar de coluna no board físico/digital, o campo Status correspondente neste documento deve ser atualizado no mesmo commit/sessão de trabalho — nunca em lote posterior, para evitar dessincronia entre o plano e o estado real (mesma disciplina já adotada em 01-Modelo-de-Dados.md para o schema).
Novo item de escopo (nova US/Task originada de um gap de especificação, como o adendo US-043 a US-055 já incorporado acima) deve ser inserido no Lote correspondente à sua dependência funcional real — nunca apenas anexado ao final do documento — preservando a leitura de dependências pelo mapa da seção 3.
Ao mover o Lote inteiro para Concluído, o próximo Lote elegível (dependência satisfeita) deve ter seus itens promovidos de Backlog para A Fazer, respeitando o limite de WIP=3 daquela coluna — se o Lote tiver mais de 3 itens, os excedentes permanecem em Backlog até haver espaço.

Plano de Implementacao¶

1. Premissas do Plano¶

2. Estrutura dos Lotes¶

FASE A — Sistema de Autenticação¶

Lote 1 — Cadastro [Must]¶

Lote 2 — Login e Emissão de Sessão [Must]¶

Lote 3 — Proteção contra Força Bruta [Must]¶

Lote 4 — Gerenciamento de Sessão + Guard Global [Must]¶

Lote 5 — Desativação de Conta [Must]¶

Lote 6 — Reativação de Conta [Must]¶

Lote 7 — Configurações: Perfil [Must]¶

Lote 8 — Alteração de Senha [Must]¶

FASE B — Sistema de Tarefas: Estrutura Base¶

Lote 9 — Cadernos [Must]¶

Lote 10 — Inbox e Classificação [Must]¶