PRECISA DE VOCE

AgentPack — Prompts de agente + Roadmap

Duas features novas do AgentPack: gestao de prompts de agente (espelho das skills, dentro do projeto) e roadmap com Gantt e agenda ligado as tasks. Branches publicadas, sem merge na main, sem deploy. Producao so leitura.

data 2026-10-13 · sandbox agent-package-audit · Producao do AgentPack (workspace_nommand) foi so leitura. Nenhum deploy, nenhum env_var, nenhum push na main.
feat/prompts-agente · 8 commits, empurrada · corrigida na rodada 3
feat/roadmap-gantt · 3 commits (4d2bb2f, 86f3880, 752c320) · backend pronto, MCP travado, frontend nao iniciado

Os numeros

12
tools MCP novas
6 de prompt + 3 de versao + 3 de vinculo com task. ZERO entram no catalogo padrao: viram toolsets opt-in (prompts, prompts-admin, prompts-history).
4+1
telas novas
Prompts: lista do projeto, editor, aba Historico e aba na task. Roadmap: ZERO entregues — Gantt, Agenda e Configuracoes estao desenhadas, frontend nao iniciado.
65+
testes novos
Roadmap 27 casos (11 + 16, contados nos arquivos novos) e prompts 38 casos nas 5 suites novas de backend, mais 5 da rodada 3. Frontend completo: 2.155 vitest verdes (antes 2.153).
1
gate travado
MCP do roadmap: a tool nova leva o catalogo a 15.318,75 de 15.000 tokens e o gate do proprio repo reprova. Nao e bug — e a sua decisao (§13.7).
234
tools no registro
De 222. O nucleo passa de 83 para 95. O snapshot do registro e o /llms.txt foram regenerados.
5+3
tabelas e migrations
5 tabelas novas de prompt (prompts, versoes, vinculo com task, modelos do sistema) e 3 migrations aditivas que rodam no boot. Rollback e voltar a imagem.
75,25
tokens de folga no catalogo padrao
Catalogo padrao medido em 14.924,75 de 15.000 tokens. A menor tool do nucleo custa 112 tokens: qualquer tool nova no padrao ja estoura.
19
decisoes suas
11 da feature de prompts e 8 do roadmap. Todas com opcoes e recomendacao prontas, mais embaixo nesta pagina.
0
mudancas em producao
Sem deploy, sem env_var, sem restart, sem push na main. A producao foi so leitura, como combinado.

As duas features

Gestao de prompts de agente

PRONTA PARA APROVAR
branch feat/prompts-agente

Gestão de prompts de agente: espelho da feature de skills dentro do PROJETO. O molde de escopo é a Memória (projectId obrigatório, versões com ator, If-Match/expectedVersion -> 409, lixeira) e o molde de produto é a Skill (editor com abas, histórico, duplicar, vínculo com task, contexto do agente, busca). Entrega: 3 tabelas novas + 1 de vínculo + 1 de modelos do sistema, 2 migrations aditivas que rodam no boot, 14 operações REST todas com contrato OpenAPI completo, 12 tools MCP, 3 toolsets opt-in, 1 resource, 3 telas, 0 dependências novas. ACHADO DECISIVO, MEDIDO NO CÓDIGO REAL (não estimado): o catálogo MCP padrão está em 14.907,25 de 15.000 tokens — folga de 92,75. A menor tool do núcleo mede 448 B = 112 tokens, então 1 tool nova no padrão JÁ ESTOURA (15.019); as 3 de vínculo com task somam 2.502 B = 625,5 tokens e iriam a 15.532,75. Por isso TODAS as 12 tools ficam em toolsets opt-in (prompts, prompts-admin, prompts-history): 0 tools e 0 tokens no padrão e nenhum agente existente vê mudança no tools/list. A revisão adversarial achou 2 bloqueantes e mais 9 pontos, todos tratados: o número das MCP instructions era 1074 e é 1196 de 1200 (a frase nova sairia do texto); as 3 tools de vínculo entravam no padrão; faltava o espelho no frontend da lista de toolsets; faltava o trabalho real no teste fechado de toolsets; 2 das 3 tools de versão caem no toolset de ADMIN pelo critério (resolvido com o mesmo carimbo manual que o skills-history usa); e a posição da seção no project_context foi mantida porque o corte é de frente para trás (a crítica leu ao contrário).

Estado depois das rodadas de revisao

  • Rodada 3: os 7 bloqueantes da segunda revisao foram corrigidos. Nenhum foi rejeitado — todos os 7 eram verdadeiros.
  • O mais grave (B2): a rodada 1 tinha corrigido os ARGUMENTOS do ponteiro ({ projectId, promptId } -> { id }) mas nao a ALCANCE. task_context_bundle e project_context, ambos no catalogo padrao, mandavam o agente chamar agentpack_prompt_get, que mora no toolset opt-in e devolve -32602 Unknown tool.
  • Resolvido nas duas metades que o revisor pediu, sem mexer no teto de 15.000 tokens: (1) o corpo do prompt de execucao passa a viajar INLINE em promptLinks[].content, com o mesmo corte por orcamento das memorias; (2) CONTEXT_POINTER_TOOLS virou a fonte da verdade de todo ponteiro de contexto, e o gate de mcp-toolsets.test.ts agora varre o codigo das duas fontes.
  • B1: prompt_get cortava o corpo dividindo por 2 (nao monotônico) e a dica dizia 'truncado a 12 KB' sempre. Agora usa o sliceUtf8 do repo, devolve contentOffset / contentSize / contentNextOffset e a dica diz o tamanho real.
  • B3: AGENTS.md dizia 234 tools / 95 do nucleo; o registro tem 235 / 96. Corrigido e conferido por categoria.
  • B4, B5 e B6 (tela): o botao Ativos/Lixeira apagava o view e a lixeira ficava inacessivel; 'Fechar' perdia ?view=trash; a lista nunca rolava (shrink-0 em pai flex-col) e a leitura ficava ~3.500 px abaixo.
  • B7 catraca: lint:ratchet em 4.794 avisos contra baseline 4.797, 0 erros, nenhuma regra acima do baseline vindo de arquivo desta branch.
  • Prova de que os testes pegam: reintroduzido o codigo antigo da tela, os 3 testes novos falham; o do prompt_get falha com 'Expected: 12288, Received: 6400'.

Roadmap com Gantt e agenda

BLOQUEADA NA SUA DECISAO
branch feat/roadmap-gantt

Roadmap com Gantt e agenda ligado às tasks, desenhado sobre origin/main 26268c0 e CORRIGIDO depois da revisão adversarial. O achado que muda o desenho: o catálogo MCP padrão já está em 14 907,25 de 15 000 tokens (medido, não estimado — folga de 92,75), e a §5 inteira o leva a 15 318,75. O gate do próprio repo reprova: 'Expected: < 15000 / Received: 15318.75'. Nenhuma codificação mais barata salva (pior caso 15 088,25), então a §5 não pode ser escrita sem a decisão do dono sobre onde arrumar ~319 tokens. O resto do desenho fica: 7 colunas em 1 migration aditiva e idempotente com 2 CHECK e 1 índice que roda no boot; 1 rota REST nova com from/to opcionais; 2 telas novas (Roadmap e Configurações, pela regra do dono de que toda configuração tem tela) e 4 telas de task tocadas; ~23 arquivos novos, ~30 tocados; ZERO dependência nova e lockfile intocado; nada de produção. As 16 críticas foram tratadas uma a uma: 12 no corpo do desenho, 1 com o mecanismo reescrito (as datas e o frontend), 1 recusada com motivo (versão na Task) e 1 que virou decisão do dono (§13.7).

Estado depois das rodadas de revisao

  • Correcao da rodada 2 commitada (752c320 sobre 86f3880, base origin/main 26268c0): o revisor correto nos 4 bloqueantes.
  • Tags na lista 'Sem data'; from/to aceitam dia simples e datetime com offset (o dia simples normaliza para o dia inteiro em UTC); dependencias lidas pela pagina em vez do projeto inteiro; unscheduledTotal com count do mesmo where.
  • 27 testes novos + 255 vizinhos verdes. typecheck, eslint dos tocados, cycles, docs:check e check:skills verdes. lint:ratchet 4799/4799 com 0 avisos novos.
  • MCP segue BLOQUEADO pela decisao §13.7: a tool task_timeline_list leva o catalogo a 15.318,75 de 15.000 tokens e o gate reprova. Enquanto voce nao decide, a tool NAO e escrita.
  • Frontend NAO INICIADO: Gantt, Agenda, lista 'Sem data' e a tela de Configuracoes continuam no papel. A regra 'toda configuracao tem tela' esta violada ate o frontend subir — as 4 preferencias do projeto hoje so existem na API e no banco.
  • Producao intocada; sem push na main, sem deploy.

As telas

Nenhuma captura de tela nesta rodada (telas_capturadas: []). Os paineis abaixo sao os esbocos do desenho aprovado da feature de prompts. O roadmap nao tem frontend: as telas dele continuam desenhadas, nao implementadas.

lista do projeto

┌──────────────────────────────────────────────────────────────────────────────────┐
│ AgentPack  ▾ Projeto Aurora › Prompts                [ + Novo prompt ]              │
├──────────────────────────────────────────────────────────────────────────────────┤
│ [ buscar prompt…        ]  [Todas][Ativos][Inativos][Lixeira]      Tags ▾       │
├──────────────────────────────────────────────────────────────────────────────────┤
│ ● ATIVO   Briefing de code review                                tags: review, ia   │
│           "Use antes de revisar PR de API." · v7 · hoje 09:12 · em 3 tarefas      │
│ ──────────────────────────────────────────────────────────────────────────────── │
│ ○ INATIVO Prompt de passagem de bastão                              tags: handover   │
│           "Modelo do handover semanal." · v3 · 04/10 · em 1 tarefa     [⋮]        │
│ ──────────────────────────────────────────────────────────────────────────────── │
│ ★ MODELOS DO SISTEMA (3)  [ Revisão de PR ] [ Handover ] [ On-call ]  [Usar]      │
├──────────────────────────────────────────────────────────────────────────────────┤
│ Lixeira (2) ›                                                            Exibir     │
└──────────────────────────────────────────────────────────────────────────────────┘

editor

┌──────────────────────────────────────────────────────────────────────────────────┐
│ ← Prompts › Briefing de code review      [Duplicar] [⋯ Excluir]        [ Salvar ]  │
│ Briefing de code review · projeto Aurora · v7 · atualizado há 2 h                   │
├───────────────────────────────────┬──────────────────────────────────────────────┤
│ ┌─ Conteúdo ─┬─ Histórico ─┐      │  METADADOS                              [✕]│
│ │  EDITOR    │  v7  atual   │      │  Nome    [ Briefing de code review     ]  │
│ │  markdown  │  v6  restore │      │  Quando  [ Antes de revisar PR de API ]  │
│ │  (split +  │  v5  update  │      │  Ativo   (●) ligado                   │
│ │  prévia)   │  v4  update  │      │  Tags    [ review ] [ ia ] [ + ]        │
│ │            │  v3  create  │      │  Origem  modelo "Revisão de PR" (só lei) │
│ └────────────┴──────────────┘      └──────────────────────────────────────────┘
├───────────────────────────────────┴──────────────────────────────────────────────┤
│ ⚠ Esta versão mudou enquanto você editava. [Ver diferenças] [Carregar a nova]     │
└──────────────────────────────────────────────────────────────────────────────────┘

aba na task (TaskPageAside › Contexto do agente › Prompts)

┌ Contexto do agente ────────────────────┐
│ Memórias (2)  Skills (1)  Prompts (2)  │
├─────────────────────────────────────────┤
│ Prompts da tarefa                  [ + ]│
│ EXECUÇÃO                                │
│  Briefing de code review                │
│  Antes de revisar PR de API · nota…     │
│  [abrir]                           [⊘]  │
│ REFERÊNCIA                              │
│  Checklist de segurança           [⊘]  │
└─────────────────────────────────────────┘

Desenhadas no roadmap (ainda sem frontend)

Os diagramas

Como o prompt de agente se liga ao projeto e a task

O objeto e do PROJETO (nao e catalogo global): a empresa vem do projeto e a regra de dado da empresa vale por construcao. O corpo do prompt de execucao chega INLINE no pacote de contexto da task, entao o agente le antes de agir sem depender de toolset nenhum.

Quem e dono
Empresa (Conta Nomad)
fonte de empresas e membros
Projeto (AgentPack)
projectId obrigatorio em tudo
O objeto
agent_prompts
nome, conteudo, tags, isActive, deleted_at (lixeira)
agent_prompt_versions
estados substituidos, com ator e origem; trigger recusa UPDATE
agent_prompt_builtin_templates
3 modelos do sistema, globais e so leitura; 'Usar no projeto' duplica
A task
agent_prompt_task_links
taskId + promptId + relationType (execution/reference/validation)
Task
o vinculo recusa prompt de outro projeto (task.projectId == prompt.projectId)
Como o agente le
task_context_bundle
promptLinks[].content INLINE + mustRead para execution
project_context
secao activePrompts, entre rules e activeSkills
12 tools MCP
toolsets opt-in prompts / prompts-admin / prompts-history
resource MCP
agentpack://project/{id}/prompt/{id} (nao publica em prompts/list)

Task com inicio e fim alimentando Gantt e agenda

Sete colunas novas em 1 migration aditiva, 1 rota REST nova e as 4 preferencias de visao no projeto. A janela e sempre por projeto, com teto de 366 dias e 1.000 itens. 'Copiar a URL' e a exportacao.

A task
tasks.start_at / end_at
TIMESTAMP(3), anulaveis; CHECK end_at >= start_at
tasks.all_day
gravado como 00:00Z, mostrado em timeZone UTC (modelo do Google Calendar)
A visao
projects.roadmap_zoom
day | week | month | quarter
projects.roadmap_group
none | status | priority | tag
projects.roadmap_working_days / week_start
dias uteis e primeiro dia da semana
A leitura
GET /projects/:id/roadmap
from/to (dia simples ou ISO com offset), dependencias da pagina, Sem data, unscheduledTotal
task_timeline_list (MCP)
BLOQUEADA: 15.318,75 de 15.000 tokens
Na tela
Gantt
barras por inicio e fim, setas de dependencia, linha de hoje, arrasto e resize
Agenda
mes / semana / dia, dia inteiro na faixa do dia
Lista 'Sem data'
arrastar para a grade grava as duas datas
Exportar
link + resumo em Markdown (a URL carrega a visao inteira)

As suas decisoes

19 perguntas com as opcoes e uma recomendacao cada. Nenhuma delas esta respondida: a implementacao espera voce.

1 Onde as tools de prompt de agente entram no catálogo MCP, e o que fazer com o teto de 15.000 tokens?

Prompts de agente
Recomendacao

Recomendação: (a) agora — é o caminho mínimo que entrega o pedido inteiro sem mexer em teto, sem furar o teste e sem arriscar regressão no anti-travamento HITL. Levar (c) ao dono como pergunta separada, porque é a única que resolve também o roadmap (cujas 3 datas, medidas, já estouram o teto sozinhas). Se o dono quiser prompts no padrão, escolher (b) e (c) juntas, nunca (b) sozinha: (b) sem folgar 2.086 tokens não resolve o roadmap.

Ver as 4 opcoes
  1. a) Toolset opt-in 'prompts' + 'prompts-admin' + 'prompts-history': zero tools e zero tokens no catálogo padrão; o agente acha as tools com agentpack_search_tools ou liga o toolset na chave. Precedente no próprio repo: render, github, skills-history. Custo: 3 linhas em TOOLSETS, 1 em CoreToolDomain, a lista fechada do teste e o espelho no frontend.
  2. b) Subir o teto de 15.000 para 20.000 tokens: uma linha no teste + uma no doc. Libera prompts E roadmap no padrão, mas é política de produto e backend/docs/mcp-server.md:144 diz que 'subir o teto é decisão humana'.
  3. c) Mover as 7 tools de decisão humana (task_decision_respond, task_request_more_information, task_decision_supersede, task_decision_cancel, task_decision_create, task_decision_list, task_return_to_decision) para um toolset opt-in: medido, somam 8.344 B = 2.086 tokens e o padrão cairia para 12.807, sobrando 2.193. É a ÚNICA opção que destrava as DUAS branches ao mesmo tempo. Regressão: o agente deixa de ver de primeira que precisa entregar a decisão a uma pessoa.
  4. d) As 3 tools de vínculo com task (task_prompt_link/list/unlink) virarem campo novo em task_get/task_context_bundle: mais barato em bytes, pior para o agente (campo polimórfico é mais difícil de usar do que tool).

2 O objeto chama-se 'prompt' ou 'agent_prompt' no código, dado que 'prompt' já é nome de capability MCP (prompts/list, executar-task, handover)?

Prompts de agente
Recomendacao

Recomendação: (a). Conferi que prompt_* não existe hoje em routes/, schemas/, services/ nem na lista de pendentes do OpenAPI, então a colisão é de vocabulário e não de código; 'prompt de agente' é o termo que o dono usou. Nos três casos, prompts/list (MCP Prompts) fica intacto e os prompts do projeto não são publicados lá.

Ver as 3 opcoes
  1. a) agent_prompts no banco, prompt_* no wire (agentpack_prompt_list), 'prompt de agente' na interface. O prefixo agentpack_ do wire já separa do resto; a description de cada tool diz o que o objeto é. (A frase nas instructions seria o reforço ideal, mas não cabe: 1196 de 1200 — ver R1.)
  2. b) agent_prompt_* no wire também (agentpack_agent_prompt_list): redundante com o prefixo, pior de ler no tools/list e no log; escolhido por quem quiser eliminar qualquer chance de confusão com prompts/list.
  3. c) prompt_template_* no wire (agentpack_prompt_template_list): evita a colisão da palavra, mas muda o objeto que o dono nomeou e o termo que aparece na tela.

3 O prompt de agente é do projeto ou um catálogo global ligado ao projeto, como a skill?

Prompts de agente
Recomendacao

Recomendação: (a). A skill é global sem organizationId e qualquer usuário logado de qualquer empresa grava no catálogo — copiar esse modelo seria violar 'todo dado novo é da empresa e do projeto'. Com (a) o objeto já é do projeto, a tabela de vínculo some, a lista do projeto é a lista do catálogo e a leitura por id já responde NOT_FOUND para outro projeto.

Ver as 3 opcoes
  1. a) Do projeto, com projectId obrigatório e isActive como COLUNA (não tabela de vínculo). A empresa vem do projeto e a regra de dado da empresa fica garantida pela construção.
  2. b) Catálogo global + tabela de vínculo (molde project_skills). Só faz sentido se o dono quiser prompts compartilhados entre projetos e empresas.
  3. c) Global dentro da organização.

4 Como entra o 'builtin somente leitura com cópia editável', já que não existe seed por projeto no repo?

Prompts de agente
Recomendacao

Recomendação: (a). A diretriz cita 'origem builtin somente leitura com cópia editável' e a entrega inteira sem isso não fecha. (b) existe para skills que o repositório atualiza entre deploys; os 3 modelos do sistema são estáticos, então a migration basta. (c) deixaria o pedido pela metade. O caminho (a) também é o que mantém a multiempresa correta: o modelo é global e somente leitura, e só a cópia é do projeto.

Ver as 3 opcoes
  1. a) Tabela global agent_prompt_builtin_templates gravada por migration, SEM nenhuma rota de escrita (a API só lê). 'Usar no projeto' = POST .../duplicate com fromTemplate, que cria um prompt editável e guarda template_slug como procedência. Zero infraestrutura de seed.
  2. b) Seed por projeto no boot, com ledger como as skills: precisa de ledger, job no boot, check:prompts, .dockerignore e validação no Dockerfile — 6 arquivos de infraestrutura para 3 templates estáticos.
  3. c) Sem builtin nesta entrega.

5 O histórico segue o molde da memória (estados substituídos, com ator e If-Match) ou o da skill (estados novos, com hash, sem ator)?

Prompts de agente
Recomendacao

Recomendação: (a). É o que AGENTS.md:167-168 exige para recurso versionado, e prompt de agente é conteúdo que dois agentes editam: com (b) o último que salvar sobrescreve o outro sem ninguém saber. O custo é ter as duas colunas de ator na versão e o 409 na escrita, que reaproveita código pronto (lib/if-match.ts, schemas/memory.ts:44-63, memory.service.ts).

Ver as 2 opcoes
  1. a) Molde da memória: agent_prompt_versions guarda os estados SUBSTITUÍDOS com actorType/actorId/source, version + If-Match ou expectedVersion -> 409 VERSION_CONFLICT, e trigger que recusa UPDATE. Concorrência segura entre dois agentes editando o mesmo prompt.
  2. b) Molde da skill: versões com origin e contentHash, sem ator, PUT last-write-wins. Mais simples e menos colunas.

6 Apagar prompt: lixeira (soft delete) ou hard delete como a skill?

Prompts de agente
Recomendacao

Recomendação: (a). O histórico de versões é metade do valor do objeto, e (b) apagaria justamente o que o dono pediu ao pedir 'versões e histórico'. Custa 1 coluna, 1 rota a mais e o filtro deletedAt IS NULL em toda leitura — que o service já faz com um helper.

Ver as 2 opcoes
  1. a) Lixeira como a memória: deleted_at anulável, GET ?view=trash e POST .../restore. Preserva o histórico de versões.
  2. b) Hard delete como a skill: menos colunas; agent_prompt_versions e a tabela de vínculo vão junto em cascade.

7 O corpo do prompt aceita variáveis {{...}} nesta entrega?

Prompts de agente
Recomendacao

Recomendação: (a) agora. Variável é o diferencial real de um prompt sobre um texto, mas é produto novo: parser, validação na escrita, tela de variáveis e a regra do que acontece quando a variável não é preenchida — e nada disso foi pedido. Se o dono quiser, (b) entra como v2 sem mudar o resto do desenho (uma coluna e uma etapa no prompt_get).

Ver as 2 opcoes
  1. a) Não: o corpo é markdown livre e o agente preenche o que precisa. Variável fica para depois.
  2. b) Sim: coluna variables Json, validação na escrita e substituição na leitura do prompt_get.

8 Quais relações com a task e qual delas entra no mustRead do agente?

Prompts de agente
Recomendacao

Recomendação: (a). 'execution' já cobre 'ler antes de agir', que é o que mustRead significa; (b) só aumenta o enum e o orçamento do bundle sem ganhar comportamento novo. Vale registrar que o vínculo tem de conferir o MESMO projeto da task (molde linkMemory), coisa que o linkSkill de skills NÃO faz — o bug que este clone não pode copiar.

Ver as 2 opcoes
  1. a) execution -> mustRead; reference e validation só resumidas no bundle. Igual à skill.
  2. b) execution e uma categoria nova (constraint) no mustRead; mais um valor no enum AgentPromptTaskRelation.

9 O agente só descobre os prompts do projeto se ligar o toolset, ou eles entram no catálogo padrão junto com o resto?

Prompts de agente
Recomendacao

Recomendação: (a). É coerente com o que o próprio repo já faz com render, github e skills-history, e medido: não há espaço para nenhuma tool nova no padrão (folga de 92,75 tokens). A frase nas instructions NÃO cabe (1196 de 1200, folga 4) e citaria tool fora do padrão, o que o teste proíbe; o agente que liga o toolset descobre tudo por agentpack_search_tools.

Ver as 2 opcoes
  1. a) Só com o toolset ligado (opt-in); a descoberta é por agentpack_search_tools, que é do toolset core (padrão) e devolve tools de toolsets desligados com o campo activate. O padrão não muda e nenhum agente existente é afetado.
  2. b) No padrão, o que exige subir o teto de 15.000 tokens (ver D1).

10 Onde ficam as 3 tools de versão (prompt_version_list/get/restore) e o task_prompt_unlink? O critério isAdminToolName manda 2 das 3 de versão e o unlink para o toolset de ADMIN, e prompt_version_get é de LEITURA — quem só quiser ler uma versão teria de ligar prompt_delete junto.

Prompts de agente
Recomendacao

Recomendação: (a). É o precedente do próprio repo e mantém a armadilha que a correção sugeria de criar. Com (a), prompts-admin tem só prompt_delete e ler uma versão não habilita apagar nada; task_prompt_unlink fica em tasks-admin pelo critério, e prompts-history NÃO entra em ADMIN_CONNECTION_TOOLSETS porque é leitura — igual a skills-history, que também não entra. Se o dono preferir (b), a consequência a registrar é que ligar prompts-admin por uma leitura habilita prompt_delete junto, sem tela que faça isso hoje.

Ver as 3 opcoes
  1. a) As 3 de versão em prompts-history, carimbadas à mão, como skills-history já faz: prompts-admin fica SÓ com prompt_delete. Precedente medido no repo (isAdminToolName também dá true para skill_version_get e skill_version_restore, e as 3 skill_version_* moram em skills-history pelo carimbo de tools/core/index.ts:47-48). Custo: um spread carimbado a mais em core/index.ts e um ramo no teste.
  2. b) Aceitar o critério: prompt_version_get e prompt_version_restore em prompts-admin. Menos código, fiel ao critério, mas leitura mora em toolset de administração e não existe tela que ligue um -admin fora da conexão de administração (ADMIN_CONNECTION_TOOLSETS, lib/agentKeys.ts:73-79).
  3. c) Renomear as tools (prompt_versions_list etc.) ou mexer no ADMIN_TOOL_PATTERN: muda critério de produto já usado por skills, memórias e knowledge.

11 As 3 tools de vínculo com task (task_prompt_link/list/unlink) também não cabem no catálogo padrão. Entram em toolset opt-in junto com as de prompt, ou viram campo novo em task_get/task_context_bundle?

Prompts de agente
Recomendacao

Recomendação: (a). Medido: o trio equivalente (task_skill_link 1.051 B + task_skill_list 636 B + task_skill_unlink 815 B) leva o padrão a 15.532,75 tokens, acima do teto. Nenhuma tool de prompt volta ao padrão, então nenhum agente existente vê mudança no tools/list — e isso vira asserção por prefixo em mcp-toolsets.test.ts, não só uma frase no doc.

Ver as 3 opcoes
  1. a) Toolset opt-in: link/list carimbadas em prompts, unlink em tasks-admin pelo critério. Padrão continua em 57 tools e 14.907,25 tokens. Precedente: render, github, skills-history.
  2. b) Campo novo em task_get / task_context_bundle: mais barato em bytes, pior para o agente (campo polimórfico é mais difícil de usar do que tool).
  3. c) Subir o teto de 15.000 tokens: é política de produto e o doc diz que 'subir o teto é decisão humana'.

12 Onde arrumar os ~319 tokens que faltam no catálogo MCP? (MEDIDO: 14 907,25 de 15 000 hoje; a §5 inteira vai a 15 318,75 e o gate reprova)

Roadmap
Recomendacao

B. É a única que preserva a §5 inteira, e não é exceção: 'corrigir decisão errada' é manutenção, não fluxo do dia a dia do agente, que é literalmente o critério documentado em mcp/toolsets.ts:108-125. C é mexer na regra do repo sem o dono pedir. Enquanto o dono não decidir, a implementação NÃO escreve a tool nova: o primeiro comando do passo 6 é o gate, e ele reprova.

Ver as 3 opcoes
  1. B) Mover task_decision_supersede para tasks-admin (recomendada): medido 14 308,25, folga 691,75, a §5 inteira preservada, uma linha em ADMIN_TOOL_NAMES
  2. A) Toolset opt-in roadmap: medido 15 046,75, NÃO cabe sozinho; só funciona junto com o movimento de B, ou entrando por task_update apenas
  3. C) Subir o teto de 15 000 tokens: regra do repo (MCP-08) e não é pedido do dono

13 Arrasto concorrente no Gantt: guard no cliente ou versão na task?

Roadmap
Recomendacao

A agora, B como backlog. A crítica original acusou last-write-wins silencioso e está certa no diagnóstico, mas a correção que propôs (version + If-Match em Task) é mudança de contrato de escrita de TODA task: toca TaskUpdatePatch, task_events, o cliente gerado e todo agente que já chama PATCH /tasks/:id sem header. Num desenho de mudança mínima, isso introduz uma quebra maior do que a que evita. O residual (última-escrita-vence entre browser e agente) continua existindo e está escrito como risco, não escondido.

Ver as 2 opcoes
  1. A) Guard no cliente (recomendada): snapshot de query.dataUpdatedAt; se o cache mudou, não grava e mostra 'a task mudou na tela, atualize'
  2. B) version Int @default(1) com If-Match e 409 VERSION_CONFLICT

14 Como exportar a visão do roadmap?

Roadmap
Recomendacao

A. Zero dependência, zero serviço, zero risco, e o link abre exatamente a visão que o dono viu. B degrada: o render-screenshot.ts já devolve a URL e o motivo em vez de falar quando o serviço não está. C é um renderizador novo com fontes e cores do tema dentro do container da API.

Ver as 3 opcoes
  1. A) Link + resumo em Markdown copiado (a URL já carrega período, zoom, agrupamento e filtros)
  2. B) PNG pelo serviço de captura (SHOT_SERVICE_URL)
  3. C) PDF gerado no servidor

15 Fuso: como gravar e mostrar o dia inteiro?

Roadmap
Recomendacao

A. É o modelo all-day do Google Calendar: o dia inteiro é o mesmo dia em qualquer fuso. B faria a mesma task ter dias diferentes conforme quem olha — o bug clássico de agenda. O dono está em America/Sao_Paulo, então o horário aparece na hora dele e o dia inteiro não anda para trás em UTC-3.

Ver as 2 opcoes
  1. A) allDay gravado como 00:00:00.000Z e formatado com timeZone UTC; horário no fuso de quem vê
  2. B) Gravar o fuso de quem criou e converter na leitura

16 A task atrasada entra no filtro 'Precisa de atenção'?

Roadmap
Recomendacao

A. As contagens do board e os KPIs do Dashboard continuam significando o que significam hoje, e a regra da catraca de contagens não mexe. B é decisão de produto à parte, com o número antigo à parte.

Ver as 2 opcoes
  1. A) Não: só o chip de prazo no card e a linha no detalhe
  2. B) Sim: passa a contar no board e no Dashboard

17 Onde fica a tela de configurações da visão?

Roadmap
Recomendacao

A. As 4 preferências são por projeto (4 colunas em projects) e a tela fica ao lado da coisa que elas mudam. Settings.tsx está em 281/300 e configuração de projeto não é configuração do usuário.

Ver as 2 opcoes
  1. A) No projeto, em /projects/:projectId/roadmap/config
  2. B) Em /settings, com seletor de projeto

18 Sugestão automática de datas por dependência e prioridade entra nesta entrega?

Roadmap
Recomendacao

A. O pedido diz que é opcional e que só propõe; isso é um serviço de sugestão, uma tela de revisão e uma ação em lote. Gravar direto sairia do combinado com o dono. O gancho já fica pronto: dependsOnIds[] vem na resposta da tool e da rota.

Ver as 2 opcoes
  1. A) Não (entra depois, só propondo, quem confirma é a pessoa)
  2. B) Entra agora com sugestão automática e gravação

19 Uma branch só ou duas (backend e frontend)?

Roadmap
Recomendacao

A. Migration e backend primeiro (para o frontend ser escrito contra o schema novo), depois frontend de tasks, depois a feature nova, gates no fim. B dobra o trabalho de resolver conflito em schema.prisma, no CHANGELOG, no snapshot do registro e nos 4 arquivos gerados, que as duas frentes do workflow já vão disputar. Em todo caso: branch publicada, sem main e sem deploy.

Ver as 2 opcoes
  1. A) Uma branch feat/roadmap-agenda em 6 passos
  2. B) Duas branches para revisão separada

Mudancas de producao e ordem de deploy

Nenhuma escrita em producao. NENHUMA escrita em producao nesta entrega. Sem deploy, sem deployments_trigger, sem env_vars, sem services, sem domains, sem restart, sem docker_exec e sem push na main. A producao do AgentPack (workspace_nommand, agentpack-backend-ws e agentpack-frontend-ws, https://agentpack-v0.mp.serendiped.com) foi so leitura.

Ordem de deploy, quando voce mandar

  1. 1. Backend das DUAS features + as 3 migrations ANTES de qualquer frontend. As migrations rodam no boot (docker-entrypoint.sh faz prisma migrate deploy antes do node; se falhar, a API nao sobe) e todas sao aditivas: rollback e voltar a imagem, sem backup.
  2. 2. Conferir a migration aplicada e o /llms.txt gerado.
  3. 3. Depois o frontend de prompts. Frontend novo com backend antigo perde o campo em silencio no z.object e a tela mostra 'Salvo' sem ter salvo nada.
  4. 4. Roadmap: so depois da sua decisao §13.7 — a tool MCP nao existe enquanto o teto nao resolver.

Contrato que muda

Detalhes de operacao das duas features
  • NENHUMA. Este workflow entrega branch; sem push na main, sem deploy, sem escrita em produção. A produção do AgentPack (workspace_nommand, agentpack-backend-ws, agentpack-frontend-ws, https://agentpack-v0.mp.serendiped.com) foi só leitura.
  • Para o deploy futuro: as DUAS migrations rodam no boot (docker-entrypoint.sh:25-39 executa prisma migrate deploy antes do node; se falhar, a API não sobe) e o healthcheck tem 5 min de start-period para o migrate (Dockerfile:74-75).
  • Rollback: as duas migrations são aditivas (tabela nova, coluna nova, ADD VALUE em enum) — voltam com a imagem anterior. Nada reescreve tabela existente nem apaga dado, então NÃO precisa de backup.
  • Ordem obrigatória: backend + migration ANTES do frontend. Frontend novo com backend antigo perde o campo em silêncio no z.object e a tela mostra 'Salvo' sem ter salvo nada.
  • Cache: nada a invalidar. As tools do MCP entram no catálogo em mcp_tools no boot por registerBuiltinCatalog (server.ts:44-55; falhou, aborta o boot).
  • Observação de operação: como as tools de prompt ficam em toolset opt-in e NÃO entram no catálogo padrão, NENHUM agente existente vê mudança no tools/list e nenhuma conexão atual quebra.
  • Deploy de pé: trigger do backend, conferir a migração aplicada e o /llms.txt gerado, depois o frontend. (Não executado neste workflow.)
  • NENHUMA. Este workflow não toca em produção: sem deployments_trigger, sem env_vars, sem services, sem domains, sem restart, sem docker_exec e sem push na main.
  • O deploy do AgentPack roda prisma migrate deploy no boot (docker-entrypoint.sh:25-39) e a API não sobe se a migration falhar — por isso a migration precisa ser aditiva e o código e ela precisam subir juntos.
  • Rollback de CÓDIGO é seguro (colunas nullable/com default, código antigo não as conhece). Rollback de DADOS (restaurar backup de antes da migration) deixa o projects_roadmap_prefs órfão: o passo do runbook é DROP CONSTRAINT antes de restaurar (§10).
  • O fluxo de produção é: branch → revisão → merge na main → o deploy aplica a migration sozinha. Nada disso acontece antes da decisão do dono sobre a §13.7.
  • frontend/src/api/generated/* é regenerado NA BRANCH (npm run api:gen) e só entra em produção no merge. O openapi.json do origin/main NÃO é JSON válido (vírgula sobrando na linha 16800, commit bbc205c): api:gen vem ANTES de api:check, e é precondição da feature (§16.5).
  • db push é proibido fora de banco local descartável (AGENTS.md): a schema só muda por migration versionada, e a pasta nova vai commitada.

O que ficou de fora

Prompts de agente

Roadmap

Apendice: tools, testes e gates

Gestao de prompts de agente

ToolToolsetDicaObservacao
agentpack_prompt_listpromptsreadlista do projeto, SEM o corpo
agentpack_prompt_getpromptsreadcorpo com janela offset (contentOffset/Size/NextOffset)
agentpack_prompt_createpromptscreatecria e grava a versao 1
agentpack_prompt_updatepromptsupdateexpectedVersion -> 409 VERSION_CONFLICT
agentpack_prompt_duplicatepromptscreatecopia editavel no projeto (e o caminho dos modelos)
agentpack_prompt_deleteprompts-adminremoveunica tool de prompts-admin
agentpack_prompt_version_listprompts-historyreadhistorico sem o corpo
agentpack_prompt_version_getprompts-historyreadum estado substituido, com ator e origem
agentpack_prompt_version_restoreprompts-historyupdaterestaura como versao nova
agentpack_task_prompt_linkpromptslinkrecusa prompt de outro projeto
agentpack_task_prompt_listpromptsreados prompts da task
agentpack_task_prompt_unlinktasks-adminremovepelo criterio de admin

Testes e verificacoes

Roadmap com Gantt e agenda

ToolToolsetDicaObservacao
agentpack_task_timeline_listtasksreadBLOQUEADA pelo teto de tokens — nao escrita
task_create (mudanca)taskscreateganharia startAt / endAt / allDay (+576 bytes)
task_update (mudanca)tasksupdateganharia os 3 campos, com patch derivado do schema

Testes e verificacoes

Gates

Nenhum gate aberto nas branches entregues. O unico bloqueio e o teto do catalogo MCP, que segura a tool do roadmap — e ele esta ai para a sua decisao, nao para ser contornado.

Verdes

Falhas e ressalvas