Tasks¶

Versão: 1.0 Escopo: Documento único contendo todas as tasks técnicas do projeto.

TASK-001¶

< Backward: US-001
> Forward: TC-001
Descrição: Criar endpoint de API backend POST /api/notebooks para salvar um novo caderno na raiz.
Critério de aceitação técnico: O endpoint deve receber o nome do caderno e persistir a nova entidade raiz no banco de dados.

TASK-002¶

< Backward: US-001
> Forward: TC-002
Descrição: Desenvolver o componente de interface para acionar a criação de um novo caderno.
Critério de aceitação técnico: A tela deve exibir um modal ou formulário de cadastro de caderno integrado com o endpoint de criação.

TASK-003¶

< Backward: US-002
> Forward: TC-003
Descrição: Implementar a listagem de cadernos no frontend e o endpoint GET /api/notebooks correspondente.
Critério de aceitação técnico: O sistema deve buscar e exibir todos os cadernos criados pelo usuário na interface organizacional.

TASK-004¶

< Backward: US-003
> Forward: TC-004
Descrição: Criar endpoint POST /api/inbox para a captura rápida de itens na Inbox sem exigir classificação.
Critério de aceitação técnico: O item deve ser armazenado com o estado inicial de Inbox e sem vínculo obrigatório a um caderno.

TASK-005¶

< Backward: US-003
> Forward: TC-005
Descrição: Desenvolver a interface de captura rápida (input dedicado) direcionada à Inbox.
Critério de aceitação técnico: O campo de texto deve permitir o registro instantâneo de pensamentos/tarefas sem fricção.

TASK-006¶

< Backward: US-004
> Forward: TC-006
Descrição: Implementar a visualização e listagem dos registros da Inbox via GET /api/inbox.
Critério de aceitação técnico: A interface deve exibir todos os itens que estão atualmente na área temporária de captura.

TASK-007¶

< Backward: US-005
> Forward: TC-007
Descrição: Criar endpoint PATCH /api/items/{id}/classify para associar um item da Inbox a um caderno.
Critério de aceitação técnico: A API deve alterar o estado do item de Inbox para Ativo e registrar o ID do caderno correspondente.

TASK-008¶

< Backward: US-005
> Forward: TC-008
Descrição: Desenvolver o fluxo de movimentação visual (drag & drop ou menu de seleção) da Inbox para o Caderno na interface.
Critério de aceitação técnico: O item deve sumir da listagem da Inbox instantaneamente após a classificação.

TASK-009¶

< Backward: US-006
> Forward: TC-009
Descrição: Implementar validação de integridade no banco de dados garantindo unicidade de relacionamento (1 Item pertence a exatamente 1 Caderno).
Critério de aceitação técnico: O modelo relacional deve impedir chaves estrangeiras duplicadas ou nulas em cadernos pós-classificação.

TASK-010¶

< Backward: US-007
> Forward: TC-010
Descrição: Criar endpoint POST /api/items para criação de itens do tipo TODO com campos opcionais.
Critério de aceitação técnico: O banco deve persistir a flag is_completed inicializada como falsa por padrão e aceitar due date/horário opcionais.

TASK-011¶

< Backward: US-007
> Forward: TC-011
Descrição: Desenvolver o formulário de criação de TODO na interface do usuário.
Critério de aceitação técnico: O formulário deve expor campos flexíveis para horário e data limite.

TASK-012¶

< Backward: US-008
> Forward: TC-012
Descrição: Adaptar o endpoint POST /api/items para validar e persistir itens do tipo SCHEDULE.
Critério de aceitação técnico: O backend deve rejeitar a criação de SCHEDULE se os campos de data/hora de início e término não forem fornecidos.

TASK-013¶

< Backward: US-008
> Forward: TC-013
Descrição: Desenvolver os campos de validação de horário de início e término para o tipo SCHEDULE no frontend.
Critério de aceitação técnico: A interface deve obrigar o preenchimento temporal para submissão do compromisso.

TASK-014¶

< Backward: US-009
> Forward: TC-014
Descrição: Implementar lógica de relacionamento opcional permitindo associar um ID de SCHEDULE a um TODO (schedule_id).
Critério de aceitação técnico: O banco deve suportar chave estrangeira unidirecional de TODO para SCHEDULE.

TASK-015¶

< Backward: US-010
> Forward: TC-015
Descrição: Criar endpoint POST /api/items/{todo_id}/subitems para inserção de sub-itens vinculados.
Critério de aceitação técnico: O sub-item deve ser gravado estritamente atrelado ao ID do TODO pai.

TASK-016¶

< Backward: US-010
> Forward: TC-016
Descrição: Desenvolver o componente de checklist de sub-itens na interface do TODO e bloquear adições em SCHEDULEs.
Critério de aceitação técnico: A UI deve ocultar a seção de sub-itens caso o item selecionado seja do tipo SCHEDULE.

TASK-017¶

< Backward: US-011
> Forward: TC-017
Descrição: Implementar lógica de escopo isolado para sub-itens no backend.
Critério de aceitação técnico: A conclusão de um sub-item deve atualizar exclusivamente o estado interno daquele checklist pai sem propagação global.

TASK-018¶

< Backward: US-012
> Forward: TC-018
Descrição: Criar endpoint POST /api/items/{id}/duplication para clonagem seletiva de itens.
Critério de aceitação técnico: O sistema deve gerar um novo registro copiando título (com prefixo “Cópia de”), caderno e prioridade.

TASK-019¶

< Backward: US-012
> Forward: TC-019
Descrição: Configurar as propriedades iniciais padrão na duplicação (estado ATIVO e ausência de datas).
Critério de aceitação técnico: O registro clonado não deve herdar datas do item original.

TASK-020¶

< Backward: US-013
> Forward: TC-020
Descrição: Ajustar a query de duplicação para zerar/ignorar explicitamente status de conclusão, sub-itens e vínculos SCHEDULE.
Critério de aceitação técnico: As relações filhas e vínculos de agenda não devem ser duplicados na cópia.

TASK-021¶

< Backward: US-014
> Forward: TC-021
Descrição: Criar endpoint DELETE /api/items/{id} para exclusão definitiva de itens sem sub-itens.
Critério de aceitação técnico: O sistema deve apagar o registro do banco sem exigir validações adicionais caso não existam sub-itens.

TASK-022¶

< Backward: US-014
> Forward: TC-022
Descrição: Implementar a ação de exclusão direta via interface para itens sem dependências filhas.
Critério de aceitação técnico: O clique no botão de deletar remove o item da tela imediatamente.

TASK-023¶

< Backward: US-015
> Forward: TC-023
Descrição: Implementar verificação pré-deleção no endpoint DELETE /api/items/{id} para detectar existência de sub-itens.
Critério de aceitação técnico: Se houver sub-itens, o backend deve retornar flag indicando necessidade de confirmação ou disparar deleção em cascata controlada.

TASK-024¶

< Backward: US-015
> Forward: TC-024
Descrição: Desenvolver o modal de confirmação de exclusão para TODOs contendo sub-itens no frontend.
Critério de aceitação técnico: O sistema deve alertar o usuário que todos os sub-itens vinculados serão removidos juntos.

TASK-025¶

< Backward: US-016
> Forward: TC-025
Descrição: Criar endpoint PATCH /api/items/{id}/archive para transição manual para o estado Arquivado.
Critério de aceitação técnico: O backend deve aceitar a alteração de estado apenas para itens que já estejam concluídos.

TASK-026¶

< Backward: US-016
> Forward: TC-026
Descrição: Adicionar o botão de arquivamento manual na interface de itens concluídos.
Critério de aceitação técnico: O arquivamento não deve ser acionado por rotinas automáticas de sistema.

TASK-027¶

< Backward: US-017
> Forward: TC-027
Descrição: Implementar lógica de recorrência básica (diária, semanal, mensal) com data de término no modelo de dados.
Critério de aceitação técnico: O sistema deve calcular as repetições corretamente para SCHEDULEs e TODOs.

TASK-028¶

< Backward: US-017
> Forward: TC-028
Descrição: Criar componentes visuais de configuração de recorrência nos formulários de itens.
Critério de aceitação técnico: O usuário deve conseguir selecionar a frequência de repetição desejada.

TASK-029¶

< Backward: US-018
> Forward: TC-029
Descrição: Garantir restrição de código impedindo endpoints de edição ou exclusão de instâncias isoladas de séries recorrentes.
Critério de aceitação técnico: O sistema não deve expor opções de override para instâncias individuais (atendendo à limitação da V1).

TASK-030¶

< Backward: US-019
> Forward: TC-030
Descrição: Criar endpoint PATCH /api/items/{id}/snooze aceitando atalhos de adiamento rápido.
Critério de aceitação técnico: O backend deve atualizar a data de reaparecimento para o dia seguinte (08:00), 3 dias à frente ou próxima segunda-feira.

TASK-031¶

< Backward: US-019
> Forward: TC-031
Descrição: Desenvolver o menu de opções rápidas de Snooze na interface de tarefas ativas.
Critério de aceitação técnico: O item adiado deve ser ocultado temporariamente da listagem padrão até a data estipulada.

TASK-032¶

< Backward: US-020
> Forward: TC-032
Descrição: Implementar suporte a data manual customizada no endpoint e na UI de Snooze.
Critério de aceitação técnico: O usuário deve conseguir selecionar livremente uma data específica no calendário para reaparecimento do item.

TASK-033¶

< Backward: US-021
> Forward: TC-033
Descrição: Desenvolver a Visão Diária do Calendário (timeline vertical de 24 horas) no frontend.
Critério de aceitação técnico: A interface deve renderizar os blocos temporais do dia selecionado.

TASK-034¶

< Backward: US-021
> Forward: TC-034
Descrição: Criar endpoint GET /api/calendar/daily para prover dados agregados de SCHEDULEs e TODOs qualificados por data.
Critério de aceitação técnico: A API deve retornar apenas itens válidos para exibição temporal.

TASK-035¶

< Backward: US-022
> Forward: TC-035
Descrição: Desenvolver as visões Semanal, Mensal e Agenda no módulo de Calendário.
Critério de aceitação técnico: O frontend deve suportar a alternância fluida entre os quatro modos de visualização temporal.

TASK-036¶

< Backward: US-022
> Forward: TC-036
Descrição: Criar endpoints de agregação GET /api/calendar/weekly, monthly e agenda.
Critério de aceitação técnico: Os dados devem ser retornados estruturados de acordo com o escopo de cada visão.

TASK-037¶

< Backward: US-023
> Forward: TC-037
Descrição: Implementar regras de exibição cruzada de itens no calendário no backend/frontend.
Critério de aceitação técnico: SCHEDULEs devem aparecer sempre; TODOs devem aparecer apenas se possuírem horário ou due date; TODOs sem data devem ser rigorosamente omitidos.

TASK-038¶

< Backward: US-024
> Forward: TC-038
Descrição: Criar endpoint GET /api/planner/daily para o Planner Diário.
Critério de aceitação técnico: A API deve retornar todos os TODOs do dia selecionado juntamente com os TODOs que não possuem nenhuma data associada.

TASK-039¶

< Backward: US-024
> Forward: TC-039
Descrição: Desenvolver a tela do Planner Diário no frontend.
Critério de aceitação técnico: A interface deve agrupar tarefas diárias e pendências sem data em um painel unificado.

TASK-040¶

< Backward: US-025
> Forward: TC-040
Descrição: Aplicar restrição de filtro rígido para excluir qualquer item do tipo SCHEDULE do Planner Diário.
Critério de aceitação técnico: Nenhuma consulta ou renderização do Planner Diário pode incluir instâncias de SCHEDULE.

TASK-041¶

< Backward: US-026
> Forward: TC-041
Descrição: Criar endpoint GET /api/search?q= para busca textual simples.
Critério de aceitação técnico: A consulta SQL/ORM deve buscar correspondências estritamente nos títulos de itens do tipo TODO, ignorando Cadernos e SCHEDULEs.

TASK-042¶

< Backward: US-026
> Forward: TC-042
Descrição: Desenvolver a barra de busca simples no frontend.
Critério de aceitação técnico: A UI deve exibir os resultados filtrados em tempo real conforme o input do usuário.

TASK-043¶

< Backward: US-027
> Forward: TC-043
Descrição: Adicionar parâmetros de filtro em tela (status, caderno, prioridade e período) ao endpoint de busca.
Critério de aceitação técnico: O backend deve refinar o dataset retornado aplicando os filtros opcionais combinados.

TASK-044¶

< Backward: US-027
> Forward: TC-044
Descrição: Desenvolver os componentes de filtro visual na tela de resultados de busca.
Critério de aceitação técnico: O usuário deve conseguir selecionar status, cadernos, prioridades e intervalos de data para refinar a busca.

TASK-045¶

< Backward: US-028
> Forward: TC-045
Descrição: Implementar lógica de ordenação por critérios específicos (Manual/Drag & Drop, Prioridade, Data limite, Criação, Estimativa e Caderno) no Todo List.
Critério de aceitação técnico: A listagem deve reorganizar os elementos dinamicamente ao selecionar um critério de ordenação.

TASK-046¶

< Backward: US-028
> Forward: TC-046
Descrição: Desenvolver os seletores de ordenação na interface do Todo List.
Critério de aceitação técnico: O modo manual deve permitir persistir a posição alterada por arrastar e soltar.

TASK-047¶

< Backward: US-029
> Forward: TC-047
Descrição: Programar a regra de ordenação padrão estrutural no backend (prioridade > data limite > data de criação).
Critério de aceitação técnico: Quando nenhuma ordenação explícita for informada pelo usuário, a consulta SQL deve ordenar os registros respeitando rigorosamente essa hierarquia.

TASK-048¶

< Backward: US-038
> Forward: TC-048
Descrição: Criar endpoint PUT /api/user/account para atualização de informações pessoais de cadastro.
Critério de aceitação técnico: O sistema deve validar e persistir as alterações de perfil na conta do usuário de forma segura.

TASK-049¶

< Backward: US-038
> Forward: TC-049
Descrição: Desenvolver a tela de configurações de conta no frontend.
Critério de aceitação técnico: As atualizações de perfil salvas devem refletir imediatamente a identificação global do usuário em toda a plataforma.

TASK-050¶

< Backward: US-030
> Forward: TC-050
Descrição: Criar endpoint POST /api/auth/login para validação de credenciais de e-mail e senha.
Critério de aceitação técnico: O backend deve verificar o hash de senha gerando e retornando tokens JWT (Access e Refresh) em caso de sucesso.

TASK-051¶

< Backward: US-030
> Forward: TC-051
Descrição: Desenvolver tela de login e lógica de armazenamento seguro de sessão no frontend.
Critério de aceitação técnico: A interface deve renderizar os inputs, efetuar a chamada à API e persistir os tokens para roteamento autenticado.

TASK-052¶

< Backward: US-031
> Forward: TC-052
Descrição: Padronizar retornos genéricos do endpoint POST /api/auth/login em falhas.
Critério de aceitação técnico: O sistema deve devolver a mesma mensagem de erro genérica (Status 401) tanto para falhas de usuário inexistente quanto para senha inválida.

TASK-053¶

< Backward: US-032
> Forward: TC-053
Descrição: Implementar account lockout (limite de tentativas) na autenticação (Força Bruta).
Critério de aceitação técnico: O backend deve travar contas temporariamente se atingirem 5 falhas sucessivas, impedindo novas requisições.

TASK-054¶

< Backward: US-032
> Forward: TC-054
Descrição: Adequar a interface para renderizar bloqueio temporário por falhas repetidas.
Critério de aceitação técnico: A UI deve intervir e apresentar uma notificação clara com o aviso de bloqueio, impedindo novas tentativas visuais.

TASK-055¶

< Backward: US-033
> Forward: TC-055
Descrição: Criar endpoint GET /api/auth/sessions para listagem das sessões do usuário.
Critério de aceitação técnico: A API deve recuperar e listar as sessões ativas do usuário atreladas ao device, IP ou client user-agent.

TASK-056¶

< Backward: US-033
> Forward: TC-056
Descrição: Desenvolver a tela de dispositivos e sessões ativas no painel de configurações.
Critério de aceitação técnico: O frontend deve exibir de forma amigável os navegadores/dispositivos atualmente autenticados.

TASK-057¶

< Backward: US-034
> Forward: TC-057
Descrição: Criar endpoint DELETE /api/auth/sessions/{id} para exclusão e revogação de tokens de outras sessões.
Critério de aceitação técnico: O servidor de autenticação deve invalidar o refresh token e forçar a expiração das credenciais atreladas ao ID passado.

TASK-058¶

< Backward: US-034
> Forward: TC-058
Descrição: Implementar a funcionalidade e botão “Encerrar Sessão” para sessões remotas.
Critério de aceitação técnico: O usuário deve conseguir, pelo seu dispositivo atual, clicar e desconectar ativamente os dispositivos de terceiros.

TASK-059¶

< Backward: US-035
> Forward: TC-059
Descrição: Ajustar o endpoint de Login para capturar e tratar status de Contas Desativadas e criar POST /api/user/reactivate.
Critério de aceitação técnico: Se a conta tentar fazer login mas estiver desativada, a API deve retornar um status flag (ex: 403 / requires_reactivation). O endpoint reativar altera a flag para “Ativa”.

TASK-060¶

< Backward: US-035
> Forward: TC-060
Descrição: Desenvolver o fluxo de interceptação de login (Modal de Reativação) no frontend.
Critério de aceitação técnico: Se recebida a flag de conta desativada, exibir alerta ao usuário para reativar, e caso ele aceite, prosseguir chamando a reativação e logo após, os tokens.

TASK-061¶

< Backward: US-036
> Forward: TC-061
Descrição: Criar endpoint POST /api/auth/register para cadastro público.
Critério de aceitação técnico: O banco deve persistir os dados do usuário, garantindo status inicial de conta “Ativa” (sem step extra de email).

TASK-062¶

< Backward: US-036
> Forward: TC-062
Descrição: Desenvolver a página pública e formulário de inscrição.
Critério de aceitação técnico: A interface deve ter campos para Nome, E-mail e Senha e encaminhar diretamente ao onboarding após submissão bem-sucedida.

TASK-063¶

< Backward: US-037
> Forward: TC-063
Descrição: Implementar regras e validação de segurança no endpoint e interface de registro.
Critério de aceitação técnico: O sistema não pode permitir cadastro com e-mail duplicado e deve forçar checagem Regex de senhas fortes.

TASK-064¶

< Backward: US-039
> Forward: TC-064
Descrição: Criar endpoint PUT /api/user/password para troca de senha logada.
Critério de aceitação técnico: O backend deve exigir a comprovação da senha atual e só então realizar o update gerando o novo hash.

TASK-065¶

< Backward: US-039
> Forward: TC-065
Descrição: Construir a interface para troca de senha dentro das configurações de conta.
Critério de aceitação técnico: Form com 3 inputs (Senha Atual, Nova Senha, Confirmação) devidamente validados.

TASK-066¶

< Backward: US-040
> Forward: TC-066
Descrição: Configurar gatilho de invalidação automática de sessão na API.
Critério de aceitação técnico: A mudança bem-sucedida no endpoint PUT /api/user/password deve invalidar automaticamente as demais sessões ativas do respectivo ID.

TASK-067¶

< Backward: US-041
> Forward: TC-067
Descrição: Criar endpoint POST /api/user/deactivate para suspender uso da conta.
Critério de aceitação técnico: O banco deve alterar a flag de status de usuário para inativo, mantendo referências e integridade de todos os dados do BD.

TASK-068¶

< Backward: US-041
> Forward: TC-068
Descrição: Desenvolver botão com alerta para desativar a conta temporariamente.
Critério de aceitação técnico: A interface deve avisar que a desativação desloga o usuário, mas retém os dados.

TASK-069¶

< Backward: US-042
> Forward: TC-069
Descrição: Criar endpoint DELETE /api/user/account com deleção forçada e em cascata.
Critério de aceitação técnico: A lógica do banco deve garantir a deleção transacional onde TODOs, SCHEDULEs, Cadernos e informações de conta sejam totalmente apagados do banco de dados.

TASK-070¶

< Backward: US-042
> Forward: TC-070
Descrição: Desenvolver o fluxo perigoso de exclusão de conta permanente na UI.
Critério de aceitação técnico: O usuário deve obrigatoriamente preencher uma caixa de confirmação (ex: “Excluir minha conta”) antes do acionamento final ser habilitado.

TASK-071¶

< Backward: US-051
> Forward: TC-071
Descrição: Criar endpoint POST /api/auth/refresh que valida o refresh token via cookie httpOnly e emite um novo access token.
Critério de aceitação técnico: O endpoint deve rejeitar (401) refresh tokens expirados ou revogados e emitir um novo Access Token válido em caso de sucesso.

TASK-072¶

< Backward: US-043
> Forward: TC-072
Descrição: Criar endpoint DELETE /api/notebooks/{id} que retorna os itens do caderno para notebookId = null (Inbox) em transação, antes de remover o caderno.
Critério de aceitação técnico: Nenhum item deve ser perdido; a operação deve ser atômica (transação única, ADR-010).

TASK-073¶

< Backward: US-044
> Forward: TC-073
Descrição: Desenvolver o botão de exclusão de caderno na interface, com alerta de confirmação informando que os itens serão movidos para a Inbox.
Critério de aceitação técnico: O caderno deve sumir da listagem e seus itens devem aparecer na Inbox imediatamente após a confirmação.

TASK-074¶

< Backward: US-050
> Forward: TC-074
Descrição: Criar endpoint GET /api/items/{id} retornando as propriedades completas do item, incluindo sub-itens quando aplicável.
Critério de aceitação técnico: A resposta deve incluir todos os campos do item e a lista de sub-itens (se TODO).

TASK-075¶

< Backward: US-045, US-046
> Forward: TC-075
Descrição: Criar endpoint PATCH /api/items/{id} para edição parcial de propriedades (título, prioridade, dueDate, recorrência), validando campos compatíveis com o tipo do item.
Critério de aceitação técnico: O backend deve rejeitar edição de campos não pertencentes ao tipo do item (ex.: dueDate em SCHEDULE) e deve impedir a alteração do campo type.

TASK-076¶

< Backward: US-047, US-048
> Forward: TC-076
Descrição: Criar endpoint PATCH /api/items/{id}/complete para alternar o estado isCompleted de itens TODO.
Critério de aceitação técnico: O endpoint deve rejeitar a chamada para itens do tipo SCHEDULE e não deve alterar o campo status.

TASK-077¶

< Backward: US-054
> Forward: TC-077
Descrição: Criar endpoint PATCH /api/items/{todoId}/subitems/{subItemId} para alternar o estado isCompleted de um sub-item.
Critério de aceitação técnico: A alteração deve afetar exclusivamente o sub-item indicado, sem propagar ao TODO pai ou a outros sub-itens.

TASK-078¶

< Backward: US-049
> Forward: TC-078
Descrição: Criar endpoint DELETE /api/items/{todoId}/subitems/{subItemId} para remoção individual de um sub-item.
Critério de aceitação técnico: Apenas o sub-item indicado deve ser removido; o TODO pai e os demais sub-itens devem permanecer intactos.

TASK-079¶

< Backward: US-055
> Forward: TC-079
Descrição: Criar endpoint PATCH /api/items/reorder que recebe a lista ordenada completa de IDs de um escopo (ex.: caderno) e persiste a nova posição manual de cada item.
Critério de aceitação técnico: O backend deve validar que todos os IDs enviados pertencem ao escopo informado antes de persistir, rejeitando listas incompletas ou com IDs estranhos ao escopo (ver ADR-026).

TASK-080¶

< Backward: US-051
> Forward: TC-080
Descrição: Implementar interceptor HTTP no frontend que captura respostas 401 de Access Token expirado, aciona POST /api/auth/refresh silenciosamente e reenvia a requisição original.
Critério de aceitação técnico: O usuário não deve perceber interrupção de navegação enquanto o Refresh Token for válido; falha na renovação deve redirecionar ao login.

TASK-081¶

< Backward: US-052
> Forward: TC-081
Descrição: Criar endpoint DELETE /api/auth/sessions que revoga todas as sessões do usuário, exceto a sessão corrente, reutilizando revokeAllSessions(userId, exceptSessionId) (ADR-007).
Critério de aceitação técnico: A sessão que originou a requisição nunca deve ser revogada pela própria chamada.

TASK-082¶

< Backward: US-053
> Forward: TC-082
Descrição: Criar endpoint GET /api/user/me retornando os dados de perfil do usuário autenticado.
Critério de aceitação técnico: A resposta deve refletir os dados persistidos mais recentes, sem cache desatualizado.

TASK-083¶

< Backward: US-053
> Forward: TC-083
Descrição: Popular automaticamente o formulário de Configurações com os dados retornados por GET /api/user/me ao carregar a tela.
Critério de aceitação técnico: Os campos do formulário devem chegar preenchidos antes de qualquer edição do usuário.

TASK-084¶

< Backward: US-050
> Forward: TC-084
Descrição: Desenvolver o modal/tela de detalhes de item no frontend, consumindo GET /api/items/{id}, exibindo sub-itens quando aplicável.
Critério de aceitação técnico: O modal deve renderizar corretamente tanto itens TODO (com sub-itens) quanto SCHEDULE (sem seção de sub-itens).

TASK-085¶

< Backward: US-045
> Forward: TC-085
Descrição: Desenvolver o formulário de edição de item no frontend, consumindo PATCH /api/items/{id}, ocultando campos não aplicáveis ao tipo do item selecionado.
Critério de aceitação técnico: O formulário não deve exibir campo de dueDate para itens SCHEDULE, nem campos de horário obrigatório para TODO.

TASK-086¶

< Backward: US-047
> Forward: TC-086
Descrição: Adicionar checkbox de conclusão na listagem de TODOs, consumindo PATCH /api/items/{id}/complete.
Critério de aceitação técnico: O clique no checkbox deve refletir o novo estado imediatamente na interface, sem recarregar a página.

TASK-087¶

< Backward: US-054
> Forward: TC-087
Descrição: Adicionar checkbox de conclusão em cada sub-item do checklist, consumindo PATCH /api/items/{todoId}/subitems/{subItemId}.
Critério de aceitação técnico: A marcação de um sub-item não deve alterar visualmente o estado do TODO pai.

TASK-088¶

< Backward: US-049
> Forward: TC-088
Descrição: Adicionar botão de remoção individual em cada sub-item do checklist, consumindo DELETE /api/items/{todoId}/subitems/{subItemId}.
Critério de aceitação técnico: O sub-item deve desaparecer da lista imediatamente após a confirmação da remoção.

TASK-089¶

< Backward: US-052
> Forward: TC-089
Descrição: Adicionar botão “Encerrar todas as outras sessões” na tela de gerenciamento de sessões, consumindo DELETE /api/auth/sessions.
Critério de aceitação técnico: Após o clique, a listagem deve manter apenas a sessão corrente.

TASK-090¶

< Backward: US-055
> Forward: TC-090
Descrição: Adaptar o modo de ordenação Manual do Todo List (já iniciado em TASK-046) para persistir a nova ordem via PATCH /api/items/reorder ao final do drag & drop.
Critério de aceitação técnico: Ao recarregar a página, a ordem manual definida deve ser mantida, refletindo a última chamada bem-sucedida ao endpoint.