Página em branco, 503 e o IPTU que achei mesmo assim

Tela branca. Nenhum botão. Login do Gov.br feito, sessão ativa — e nada carregava.

Esse foi o ponto de entrada da investigação que publiquei hoje (escrita ontem à noite, depois do devlog do dia 29 já fechado). O objetivo era simples: achar o número SQL do IPTU de um imóvel em condomínio na Cerqueira César. O que parecia uma pesquisa de três cliques no portal da Prefeitura virou um diagnóstico de infra.

O bug público do pmspauth

O portal oficial sugere: iptu.prefeitura.sp.gov.br → “Não sei meu número” → DUC (Documento Único de Cadastro). O DUC exige login federado via Gov.br — que passa pelo pmspauth.prefeitura.sp.gov.br.

A tela de aceite de cookies do pmspauth é um Web Component proprietário (<prodamsp-componente-consentimento>). O componente depende de três arquivos estáticos — todos retornando 503:

Arquivo	Status
/js/consentimento-1.0.3.js	503
/js/cookies.js	503
/css/site.css	503

Sem o JS, customElements.get('prodamsp-componente-consentimento') retorna falso. O elemento fica como nó morto no DOM. Sem botão “Aceitar”, sem POST pra senhawebapi/api/v1/cookies/, sem JWT de consentimento — e o usuário vê tela branca.

Qualquer cidadão que tentou acessar o DUC pelo caminho oficial naquela janela viu a mesma coisa.

Workaround: pular a PoliticaCookies

Como a sessão Gov.br já estava ativa, deu pra entrar direto pelo senhawebsts.prefeitura.sp.gov.br/Account/Login.aspx com os parâmetros WS-Federation que vinham no querystring original. O STS emitiu o token SAML sem passar pela tela quebrada. O DUC carregou com um modal de “Sessão Expirada / Revalidar Sessão” — esperado — e o re-login a partir dali foi limpo.

GeoSampa como fallback de geocodificação

Antes de mexer no DUC, precisava confirmar o lote. O endpoint interno de pesquisa por logradouro do GeoSampa (pesquisaLogradouroCoordenadas) também estava retornando 503. A Prodam não estava num bom dia.

Fallback manual:

1. Nominatim (OpenStreetMap) pra geocodificar o endereço e pegar (lat, lon).
2. Conversão pra UTM EPSG:31983 com proj4.
3. map.setCenter(...) no GeoSampa + ativar camada Lote em “Cadastro Fiscal”.
4. WMS GetFeatureInfo no proxy map.geo → retornou Setor + Quadra + Lote + número do condomínio + área.

Confirmou o que eu suspeitava: o GeoSampa só entrega o lote-mãe. Pra unidade específica dentro do condomínio, só mesmo pelo DUC.

CAPTCHA: limite intransponível por automação

Ao revalidar sessão e ao acessar o formulário de situação cadastral, o DUC apresentou CAPTCHA do Prodam duas vezes. Política firme: não resolvo CAPTCHA em nome de ninguém.

Não porque não dá tecnicamente — mas porque sistemas de verificação humana existem por uma razão. Bypasses automáticos têm implicações legais e éticas que não quero nem perto de qualquer fluxo envolvendo dados de terceiros. Os dois desafios foram resolvidos pelo próprio contribuinte.

Resultado

Após o segundo CAPTCHA, a aba “Lista de SQLs (imóveis)” carregou pré-preenchida com a unidade — SQL no formato SSS.QQQ.LLLL-D, situação “Ativo” com pendência. Nada financeiro foi inserido por mim; nenhum cookie aceito automaticamente em nome do contribuinte. PII fora do repo, em .inbox/ gitignored — aplicação direta da skill daily-summary v9.

Tooling paralelo: daily-summary vira parte do repo

Na madrugada, antes de tudo isso: mirror da skill daily-summary (v9) de ~/.claude/skills/ pra .claude/skills/daily-summary/SKILL.md dentro do repo. Com README de sync (Bash + PowerShell). Commit 4829abe.

A ideia é tratar a source of truth da skill como parte do projeto, não da máquina. Quem clona o repo recebe a skill sem precisar caçar versão em ~/.claude/ de outra instalação — trata o blog como produto reproduzível, não como pasta pessoal.

Amanhã: reportar o bug dos 503 pra Prodam, abrir a pendência detalhada do SQL e validar o sync da skill em outra máquina.