Duas lanes, duas convenções de evento — consolidar na da wt-insights?
wt-insights e wt-cohort nomearam os mesmos eventos de formas incompatíveis. As duas funcionam — convenção (produto), não defeito.
toque pra ver as duas convenções, o diff e a saída da lane ›
proposta · orchestrate
Cap de 4 lanes simultâneas no orchestrate (anti-OOM)?
Hoje sobe N lanes sem teto — muitas em paralelo estouram a RAM (incidente #160). A lane propõe um cap de 4.
toque pra ver o código, o incidente e as alternativas ›
gate maduro · decisão adiada
Cutover do resto do corpus pro banco
Você queria viver com o piloto antes — já são 4 dias estável. Pronto pra decidir.
toque pra ver o porquê do adiamento e o que falta ›
Em voo3
wt-client-v11-shell-androidrunningΔ7
Shell Android v11 — ponte push + ads
3 / 5 — buildando o APK na box
wt-pgvectorreviewingΔ12
pgvector — busca semântica (peça g)
revisão final — pronta pra integrar
wt-cohortheldΔ4
Eventos de telemetria — coorte de audiência
⏳Segurada pela escalação #214 — a convenção de eventos lá em cima. Decide e ela retoma sozinha.
deploy livre e2e livre merge livre
seguradas › .int-insights— escalou #214 (convenção de eventos)
landou (24h) › e-gates-comportamento
escalação · integrar wt-insights · #214
Duas lanes, duas convenções de evento — consolidar na da wt-insights?
Ao integrar, wt-insights e wt-cohort definiram a mesma família de eventos de telemetria com nomes incompatíveis. As duas passam no check e funcionam — não é defeito. É uma escolha de convenção que vira o padrão de telemetria de todos os projetos, por isso subiu pra você. A perdedora é renomeada e os eventos já gravados são migrados.
Enquanto você não decide, isto segura a integração .int-insights e a lane wt-cohort (as duas em "Em voo"). Decidir libera as duas.
as duas convenções
A
wt-insights — push_openedpush_dismissedpush_delivered snake_case · verbo no passado · alinha com os eventos que já existem
B
wt-cohort — pushOpenpushDismisspushDeliver camelCase · presente · alinha com o JS do client
o que muda no código
templates/nextjs-fullstack/lib/telemetry.ts ~14 linhas
lib/core/events.ts ~6 linhas
+ 2 migrations de rename de evento (já gravados)
⟲ diff completo (main…wt-insights) + saída do terminal da lane — derivados ao vivo pelo helper
proposta · orchestrate · #215
Cap de 4 lanes simultâneas no orchestrate (anti-OOM)?
O Orchestrate (orchestrate.go:1059) sobe todas as tarefas como lanes de uma vez, sem teto de concorrência nem checagem de recurso. Muitos agents em paralelo estouram a RAM do droplet — foi o incidente OOM #160 (13 min de prod fora). Hoje a única rede é o preflight, e ele só roda no e2e, não no orchestrate.
a proposta da lane
›
Semáforo de 4 lanes simultâneas; a 5ª enfileira até liberar slot.
?
Alternativa em aberto: cap fixo (4) vs derivar de MemAvailable em runtime.
⟲ ligado ao followup #10 · decisão vira a política do scheduler
gate maduro · decisão adiada
Cutover do resto do corpus pro banco
Quando você cutou o plano vivo como piloto (decisão #91), adiou o cutover do resto do corpus pra depois de viver com o piloto — julgamento, sem proxy mensurável na época. O gate marca que a condição amadureceu.
o porquê do adiamento
›
Dogfood do regime banco-canônico num doc de baixo risco antes do corpus inteiro.
✓
4 dias estável: drift-gate verde, write-through sem clobber, zero rollback.
Ainda não-acionável aqui (gate-ack escreve state.json = root → v1.1). Por enquanto: core gates done cutover-corpus
lane · running · Δ7
wt-client-v11-shell-android
Tarefa: Shell Android v11 — ponte push (getPushToken) + ads, conforme a spec do client v11. Solo + TDD.
progresso · 3 / 5
✓ ponte getPushToken (WebView ↔ nativo)
✓ ponte de ads (banner + interstitial)
✓ open-tracking do push
▸ build do APK na box (em curso)
· smoke no Test Lab
⟲ diff (main…wt-client-v11) + saída ao vivo do terminal da lane — derivados pelo helper
lane · reviewing · Δ12
wt-pgvector
Tarefa: pgvector (peça g) — busca semântica sobre decisions/specs/followups. Em revisão final, pronta pra integrar.
⟲ diff + saída da lane ao vivo · ação de integrar fica no terminal (v1.1)
lane · held · Δ4
wt-cohort
Segurada pela escalação #214 (a convenção de eventos). A lane terminou o trabalho, mas não integra até você escolher a convenção — senão landaria com os nomes errados. Retoma sozinha assim que você decidir.
⟲ vínculo real: a lane está held por causa de #214 — o mesmo objeto, ligado pelo slug
followup · #2 · aberto
Tower (F): chat web + execução por lanes + conversa compartilhada terminal↔web
Chat da Tower = camada leve que coordena, não executa. O Agent SDK interpreta a direção e despacha; a execução fica nas lanes de terminal (claude real, autonomia total). SDK executando direto perde autonomia.
Mesma conversa terminal↔web via sessão resumível (hand-off, não simultâneo). É Claude-Code-específico → o chat é efêmero; o durável vai pro banco (CLI-agnóstico intacto).
Escopo de F expande de "só decidir (fila)" pra "decidir + chat" — v2.
followup · #7 · aberto
Watchdog ponto-cego em freeze total do host → heartbeat externo
O watchdog roda no droplet — num freeze total do host, congela junto e não alarma. Precisa de um observador fora da caixa. O #7b (boot-inesperado por staleness de heartbeat) já saiu na (e); falta o #7a (heartbeat externo).
A Tower não resolve (roda no mesmo droplet) — é candidata só a superfície de alerta no v2+.
followup · #9 · aberto
Estado compartilhado entre lanes: prevenir colisão de identificador
Worktree isola o file tree, não o estado fora dele: os Postgres são compartilhados por todas as lanes. O Postgres trata a concorrência dos dados; a costura é estreita — artefatos onde duas lanes escolhem o mesmo número/nome.
Caso provado: colisão de número de migration entre lanes (bateu 2×). Hoje há um gate que pega, não previne. Ponta-solta: alocação atômica vs manter o catch-gate.
followup · #10 · aberto
core orchestrate: sem cap de concorrência nem governor de recurso
O loop do Orchestrate dispara todas as tarefas como lanes sem cap nem checagem de recurso. A única proteção de RAM (preflight) está no e2e, não no orchestrate. Ligado à proposta #215 lá em cima.
decision · #162
Fecha (e) — gates de comportamento
Onde os TestConform_ (d) gateiam código, a (e) gateia/detecta comportamento — com o teto honesto do privilégio (coredev é root → advisory/detecção, não bloqueio-duro).
Três mecanismos: core preflight (RAM antes do e2e) · core deploycheck (alarma deploy-velho no SessionStart) · boot-inesperado (watchdog detecta freeze do host por staleness de heartbeat).
decision · #161
(d) gates de conformação de código
Invariantes de código que espelham uma fonte derivável, guardados por conformance tests TestConform_ rodados pelo go test do check.sh — build vermelho se driftar, zero token.
decision · #159
Cutover projeto-side (Opção A)
Governança-de-projeto + skills viram banco-canônico ENFORCING. Opção A: o template-file é projeção gerada do banco (write-through); create/sync/restore seguem lendo o template intocados.
decision · #158
Cutover Core-side
O corpus de prosa Core-side inteiro (decisions, plan, governança, specs) vira banco-canônico — md gerado por write-through, edição só-por-verbo, drift-gate duro no check.sh.
plano · (f) · andando
Tower — control-plane de escrita
A peça atual: superfície web de escrita sobre os verbos (non-root). v1 = cockpit consolidado do coredev + decidir a fila. Chat = v2.
plano · (g) · próxima
pgvector — busca semântica
Índice semântico sobre decisions/specs/followups pra recall e anti-duplicação. Aditiva, depois da Tower.