mockup · exemplo de como um /plan ficaria neste estilo
/plan · bstech-sistema

Ensaio de flexão no BStech

Expandir o BStech pra aceitar corpos de prova de flexão (prismáticos), além da compressão de hoje. Este plano lidera com as decisões que são SUAS; a mecânica que você pode confiar fica no fim, fechada. E ele te ensina a própria língua que usa.

esforço: ~2 dias arquivos: 9 migrations: 1 risco: médio (mexe no fluxo de registro)
ordenado por probabilidade de você querer mexer · ↑ decisão sua · ↓ confia no Case
a língua deste plano · 4 termos
migrationbanco de dados
Mudança na estrutura do banco (criar coluna, tabela, índice) versionada num arquivo, aplicada em ordem. É o "commit" do banco.
"essa feature precisa de migration ou é só código?"
backfillbanco de dados
Preencher a coluna nova pros dados que JÁ existem. Sem backfill, todo CP antigo ficaria sem tipo de ensaio.
"e o backfill dos CPs antigos, viram compressão?"
JSONBbanco de dados
Coluna que guarda um objeto flexível (chave: valor) dentro do Postgres. Serve pra campos que variam por tipo, sem criar 10 colunas vazias.
"as dimensões do prisma vão em JSONB ou em coluna própria?"
feature flagdeploy
Interruptor por cliente: a feature existe no código, mas só aparece pra quem tiver a flag ligada. Deploy sem risco: liga pra 1, testa, liga pro resto.
"solta atrás de feature flag e liga só pra Consominas"
A · decisões que são suas
decisão 1 banco

Onde vive o tipo de ensaio: coluna nova ou tabela nova?

Hoje todo CP é compressão implícita. Flexão precisa de: dimensões diferentes (prisma, não cilindro), fórmula diferente, e campos próprios (vão entre apoios).

escolha do Case

Coluna ensaio_type na tabela de CPs + campos extras em JSONB. Um CP continua sendo um CP; a etiqueta diz o ensaio.

Melhor se: flexão se comporta como variação do fluxo atual (é o caso hoje).

alternativa

Tabela ensaios_flexao separada. Isola tudo, mas duplica fluxo de registro, listagem, laudo e relatório.

Melhor se: flexão fosse ganhar ciclo de vida próprio (não é o plano).

custo de errarMudar isso depois de ter dados em produção = migration com reclassificação manual. É a decisão mais cara do plano.
aprovo a escolha quero a alternativa conversar antes
decisão 2 ux

Como o cliente escolhe o ensaio no registro?

No /bulk-registration de hoje não existe escolha: tudo é compressão. Flexão precisa entrar sem atrapalhar quem só usa compressão (a maioria). Assim ficaria a tela com a escolha do Case:

bstech · /bulk-registration · mock
Registro em lote
CompressãoFlexão
códigoobraconcretagemidadesqtd
seletor no topo, vale pro lote inteiro · padrão compressão · quem não usa flexão nunca percebe
escolha do Case (a tela acima)

Seletor no topo do lote, padrão "compressão".

Melhor se: um lote inteiro é sempre do mesmo ensaio (confirmar com Consominas).

alternativa

Escolha por linha/CP. Flexível, mas polui a planilha pra 100% dos clientes por causa de 1 caso.

Melhor se: lotes mistos forem reais na operação.

é isso, aprovo o mock quero a alternativa quase, vou comentar perguntar pro cliente antes
B · ordem de construção
01Migration: ensaio_type + JSONB de dimensões, backfill dos CPs existentes como compressão2h
02Fórmula de flexão no motor de cálculo (backend, Postgres; frontend só renderiza)3h
03Seletor de ensaio no registro em lote3h
04Laudo: template recebe os campos de flexão nos DOIS templates de render4h
05Feature flag por cliente; liga só pra Consominas primeiro1h
C · mecânica (confia)
8 tarefas mecânicas, sem decisão envolvida · abrir se quiser conferir
quiz · prova que o plano é seu
Três situações. Não é decoreba: cada resposta certa exige ter entendido uma decisão lá de cima. A aprovação do plano libera com 3/3.
score 0/3
pergunta 1 de 3
Depois do deploy, um cliente que só faz compressão abre o registro em lote. O que muda pra ele?
Quase. Releia o passo 05 da seção B: a flag liga só pra Consominas primeiro. Pros outros clientes o código existe mas a tela não muda.
pergunta 2 de 3
A fórmula da resistência à flexão mora onde?
Releia o passo 02. Regra da casa: toda conta no banco (backend-first), frontend nunca calcula. É o que garante que laudo, tela e exportação nunca divergem.
pergunta 3 de 3
Por que a decisão 1 (coluna vs tabela) é a mais cara de errar?
Releia o "custo de errar" da decisão 1. Estrutura de dados com dado dentro é o que mais dói pra desfazer; UI se refaz barato.
como você pediria isso · antes e depois
seu pedido, sem a língua
"quero que o sistema aceite ensaio de flexão também"
o mesmo pedido, com a língua do plano
"adiciona flexão como ensaio_type na tabela de CPs, dimensões do prisma em JSONB, backfill dos CPs antigos como compressão, fórmula no Postgres (backend-first), seletor por lote no registro, e solta atrás de feature flag ligada só pra Consominas"
mesma pessoa, mesma intenção. a diferença é a língua: o segundo pedido já contém 4 decisões que o primeiro deixava pro Case adivinhar.
sua resposta, montada pelos cliques

Confere e cola de volta no Case