From b6ccd7e8b409b03165ab120e0226db1b0c656ffb Mon Sep 17 00:00:00 2001 From: Francisco Solla Date: Mon, 24 Aug 2026 23:14:37 -0300 Subject: [PATCH] style: prettier no plano e changelog da C115-F1 --- ...-snapshot-race-e-hermeticidade-int-impl.md | 27 ++++++++++--------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/docs/plans/c115-followup-snapshot-race-e-hermeticidade-int-impl.md b/docs/plans/c115-followup-snapshot-race-e-hermeticidade-int-impl.md index 8ecdf279..1c0a4274 100644 --- a/docs/plans/c115-followup-snapshot-race-e-hermeticidade-int-impl.md +++ b/docs/plans/c115-followup-snapshot-race-e-hermeticidade-int-impl.md @@ -15,9 +15,9 @@ Appetite restante: herdado (~0,5–1 dia eng) espelhada (estabilidade ×N sem falhas de contagem). - **O que NÃO negociar:** - Regra D4/C115 intacta: evento previamente visto que sumiu (`lastSeenIds.has(eventId)` - + atividade `confirmado`) → cancelamento da atividade (`cancelActivityFromGoogle`), - nunca recriação (`src/utilities/googleCalendarSync.ts:569-584`). O fix só muda QUANDO - o snapshot é confiável para gravar, jamais a semântica de decisão. + - atividade `confirmado`) → cancelamento da atividade (`cancelActivityFromGoogle`), + nunca recriação (`src/utilities/googleCalendarSync.ts:569-584`). O fix só muda QUANDO + o snapshot é confiável para gravar, jamais a semântica de decisão. - `ensureGoogleCalendarPushChannel` lê o MESMO snapshot para o pin de calendarId (`googleCalendarSync.ts:678-690`) — essa leitura continua funcionando com estado legado e novo, sem mudança de contrato. @@ -82,6 +82,7 @@ benignos; serializá-los seria cerimônia sem volatilidade. O doc carregado em o owner `googleCalendarSync.ts`). **Alternativas rejeitadas:** + - **B) advisory lock por passada** (`acquireTextAdvisoryLocks`, `src/utilities/postgresTransactionLocks.ts:40-61`): `pg_advisory_xact_lock` exige transação aberta durante toda a passada (`withPayloadTransaction` envolvendo @@ -111,8 +112,8 @@ o owner `googleCalendarSync.ts`). **Recomendação: C — documentar a convenção no header de `tests/int/googleCalendarSync.int.spec.ts`.** O mecanismo de isolamento JÁ EXISTE e já é usado: `fixtures.own` limpa por teste (beforeEach/afterEach em -`tests/helpers/campaignFixtures.ts:1115-1146`), então não há vazamento *entre testes* — -o problema real é coexistência *durante* execução paralela (vitest até 8 forks num único +`tests/helpers/campaignFixtures.ts:1115-1146`), então não há vazamento _entre testes_ — +o problema real é coexistência _durante_ execução paralela (vitest até 8 forks num único `teqo_test`, `vitest.config.mts:18-22`), e contra isso a única defesa válida é o consumidor da janela se escopar — o que a spec do motor já faz com `activityWhere {title like 'C114%'}` (`googleCalendarSync.int.spec.ts:120-130`, mecanismo @@ -176,7 +177,7 @@ Não se aplica (nenhuma superfície de dados nova exposta; o snapshot mantém a criam atividades de passagem mantêm cleanup por teste via `installCampaignFixtures`. Sem código de produção. Verificar: lint verde. 4. **Gates e estabilidade**: rodar o arquivo alvo ×5 local (`pnpm test:int -- - tests/int/googleCalendarSync.int.spec.ts`, repetido) e a suíte int completa 1× +tests/int/googleCalendarSync.int.spec.ts`, repetido) e a suíte int completa 1× (`pnpm test:int`) sem falhas de contagem; `pnpm gate:fast`; PR com cascade normal (CI roda o conjunto curado conforme ci-scope); push via `pnpm push`. @@ -237,10 +238,10 @@ Não se aplica (nenhuma superfície de dados nova exposta; o snapshot mantém a ## Self-score (decision-quality, gate ≥4) -| Dimensão | Nota | Justificativa | -| --- | --- | --- | -| Decisões caras têm rejeitadas? | 5 | CAS vs advisory-lock vs aceitar vs merge-por-listedAt vs retry — cada uma com motivo técnico citando precedentes do repo. | -| Abordagem cabe no appetite? | 5 | Guard ~20 linhas no owner + 1 teste de corrida + 1 bloco de comentário; bem dentro de 0,5–1 dia. | -| Rabbit holes nomeados? | 5 | Seis itens explícitos (fila, retry, generalização do CAS, helper F2, specs irmãs, dupla-insersão). | -| Depth check: reusa o que existe? | 4 | Edita o owner `googleCalendarSync.ts`, reusa `activityWhere`/fixtures/stub existentes; perde 1 pois o stub ganha mecanismo novo de gate (justificado: único jeito determinístico de coreografar a corrida). | -| Intenção permanece satisfeita? | 5 | Outcome e regra D4 intactos; engenharia escolheu forma (guard por `updatedAt` vs `lastSuccessAt`) sem reescrever o aceite. | +| Dimensão | Nota | Justificativa | +| -------------------------------- | ---- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Decisões caras têm rejeitadas? | 5 | CAS vs advisory-lock vs aceitar vs merge-por-listedAt vs retry — cada uma com motivo técnico citando precedentes do repo. | +| Abordagem cabe no appetite? | 5 | Guard ~20 linhas no owner + 1 teste de corrida + 1 bloco de comentário; bem dentro de 0,5–1 dia. | +| Rabbit holes nomeados? | 5 | Seis itens explícitos (fila, retry, generalização do CAS, helper F2, specs irmãs, dupla-insersão). | +| Depth check: reusa o que existe? | 4 | Edita o owner `googleCalendarSync.ts`, reusa `activityWhere`/fixtures/stub existentes; perde 1 pois o stub ganha mecanismo novo de gate (justificado: único jeito determinístico de coreografar a corrida). | +| Intenção permanece satisfeita? | 5 | Outcome e regra D4 intactos; engenharia escolheu forma (guard por `updatedAt` vs `lastSuccessAt`) sem reescrever o aceite. |