@baruk/core 0.4.2 → 0.5.0

package/src/db/migrations/0049_national_fiscal_engine.sql

@@ -0,0 +1,279 @@
+-- 0049 — a fundação nacional do motor fiscal.
+--
+-- ═══ A decisão de modelagem que organiza tudo ═══════════════════════════════
+--
+-- Hoje `recurring_item_type` responde duas perguntas diferentes na mesma linha:
+--
+--   "o que é esta obrigação?"        → DAS, ISS, eSocial. Nacional e estável.
+--   "para quem, quando e como vence?" → varia por UF, por município e no tempo.
+--
+-- Enquanto as duas moram juntas, o índice único em `(key)` permite UMA linha
+-- por chave, e daí saem as três limitações que a auditoria mediu: o ISS de
+-- Goiânia e o de São Paulo não coexistem, duas versões da mesma regra não
+-- coexistem, e a aplicabilidade só sabe olhar regime.
+--
+-- Esta migration separa as duas perguntas:
+--
+--   `recurring_item_type`  → a IDENTIDADE. Continua como está. Nada quebra.
+--   `fiscal_rule`          → a REGRA: jurisdição + vigência + versão +
+--                            condições + vencimento.
+--
+-- Um tipo de item passa a ter N regras: uma federal, uma por UF, uma por
+-- município, e mais de uma no tempo. É o que abrangência nacional exige, e é
+-- aditivo — nenhuma linha existente é reescrita.
+--
+-- ═══ O que esta migration NÃO faz ══════════════════════════════════════════
+--
+-- Não cataloga regra nenhuma do Brasil. Ela cria a capacidade; o conteúdo
+-- entra depois, com governança. Os 17 seeds atuais são migrados na 0050 SEM
+-- ganhar precisão que não têm.
+
+-- ── 1 · Vocabulário do perfil fiscal ───────────────────────────────────────
+--
+-- Registro de atributos, e não colunas em `client`.
+--
+-- A alternativa seria `has_employees`, `icms_taxpayer`, `iss_taxpayer`,
+-- `ipi_taxpayer`… uma coluna por pergunta fiscal. Isso não escala: cada UF e
+-- cada segmento acrescenta perguntas, e a tabela de cliente viraria uma
+-- estrutura rígida impossível de evoluir — exatamente o que a premissa pede
+-- para evitar.
+--
+-- Com um REGISTRO, acrescentar um atributo é INSERT, não migration. E a FK
+-- impede erro de digitação virar atributo novo em silêncio.
+
+CREATE TABLE IF NOT EXISTS fiscal_attribute_definition (
+  key           text PRIMARY KEY,
+  label         text NOT NULL,
+  description   text,
+  value_type    text NOT NULL CHECK (value_type IN ('boolean', 'text', 'enum')),
+  -- Para `enum`: os valores aceitos. Para os demais, `null`.
+  allowed_values jsonb,
+  created_at    timestamptz NOT NULL DEFAULT now(),
+  CHECK ((value_type = 'enum') = (allowed_values IS NOT NULL))
+);
+
+COMMENT ON TABLE fiscal_attribute_definition IS
+  'Vocabulário GLOBAL do perfil fiscal. Acrescentar atributo é INSERT, não migration — é o que permite o modelo evoluir sem alterar a tabela de cliente.';
+
+INSERT INTO fiscal_attribute_definition (key, label, description, value_type, allowed_values) VALUES
+  ('has_employees', 'Possui empregados',
+   'Decide a aplicabilidade das obrigações trabalhistas. A AUSÊNCIA deste dado não é "não": é desconhecido, e o motor devolve INSUFFICIENT_DATA.',
+   'boolean', NULL),
+  ('icms_taxpayer', 'Contribuinte de ICMS', NULL, 'boolean', NULL),
+  ('ipi_taxpayer', 'Contribuinte de IPI', NULL, 'boolean', NULL),
+  ('iss_taxpayer', 'Contribuinte de ISS', NULL, 'boolean', NULL),
+  ('activity_segment', 'Segmento de atividade', NULL,
+   'enum', '["comercio","industria","servicos","misto"]'::jsonb),
+  ('cnae_primary', 'CNAE principal', 'Código, sem interpretação pelo motor nesta fase.', 'text', NULL),
+  ('state_registration', 'Inscrição estadual', NULL, 'text', NULL),
+  ('municipal_registration', 'Inscrição municipal', NULL, 'text', NULL)
+ON CONFLICT (key) DO NOTHING;
+
+-- ── 2 · Perfil fiscal do cliente ───────────────────────────────────────────
+--
+-- Ausência de linha = atributo DESCONHECIDO, e é distinto de `false`. É a
+-- distinção que sustenta o `INSUFFICIENT_DATA` do motor: um cliente sobre o
+-- qual ninguém disse se tem empregados não pode receber eSocial nem ser
+-- declarado isento dele.
+
+CREATE TABLE IF NOT EXISTS client_fiscal_attribute (
+  id            uuid PRIMARY KEY,
+  tenant_id     uuid NOT NULL REFERENCES tenant(id),
+  client_id     uuid NOT NULL,
+  attribute_key text NOT NULL REFERENCES fiscal_attribute_definition(key),
+  value_bool    boolean,
+  value_text    text,
+  source        text,
+  updated_by    uuid REFERENCES "user"(id),
+  created_at    timestamptz NOT NULL DEFAULT now(),
+  updated_at    timestamptz NOT NULL DEFAULT now(),
+  CONSTRAINT client_fiscal_attribute_tenant_id_uq UNIQUE (tenant_id, id),
+  FOREIGN KEY (tenant_id, client_id) REFERENCES client (tenant_id, id),
+  -- Exatamente um valor. Nenhum seria linha sem informação; dois seriam duas
+  -- respostas para a mesma pergunta.
+  CHECK ((value_bool IS NOT NULL)::int + (value_text IS NOT NULL)::int = 1)
+);
+
+CREATE UNIQUE INDEX IF NOT EXISTS client_fiscal_attribute_uq
+  ON client_fiscal_attribute (tenant_id, client_id, attribute_key);
+
+ALTER TABLE client_fiscal_attribute ENABLE ROW LEVEL SECURITY;
+ALTER TABLE client_fiscal_attribute FORCE ROW LEVEL SECURITY;
+CREATE POLICY client_fiscal_attribute_tenant_isolation ON client_fiscal_attribute
+  USING (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid)
+  WITH CHECK (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid);
+
+-- Código IBGE do município: o identificador canônico.
+--
+-- `client.municipality` é texto livre e serve para a tela. Casar regra
+-- municipal por texto livre falharia no primeiro "Goiania" sem acento. O
+-- código é opcional: sem ele, regra municipal devolve INSUFFICIENT_DATA em vez
+-- de casar por aproximação.
+ALTER TABLE client ADD COLUMN IF NOT EXISTS municipality_ibge_code text;
+
+DO $$
+BEGIN
+  IF NOT EXISTS (SELECT FROM pg_constraint WHERE conname = 'client_ibge_format') THEN
+    ALTER TABLE client ADD CONSTRAINT client_ibge_format
+      CHECK (municipality_ibge_code IS NULL OR municipality_ibge_code ~ '^[0-9]{7}$');
+  END IF;
+END $$;
+
+-- ── 3 · A regra fiscal versionada ──────────────────────────────────────────
+
+CREATE TABLE IF NOT EXISTS fiscal_rule (
+  id            uuid PRIMARY KEY,
+  -- NULL = regra GLOBAL do produto. NOT NULL = regra do próprio escritório.
+  -- Mesmo padrão de `recurring_item_type` e `role`: ler o global é direito de
+  -- todos; escrevê-lo, de ninguém que opere como tenant.
+  tenant_id     uuid REFERENCES tenant(id),
+  item_type_id  uuid NOT NULL REFERENCES recurring_item_type(id),
+
+  -- ── jurisdição ──────────────────────────────────────────────────────────
+  jurisdiction_scope text NOT NULL CHECK (jurisdiction_scope IN ('federal', 'state', 'municipal')),
+  jurisdiction_uf    text CHECK (jurisdiction_uf IS NULL OR jurisdiction_uf ~ '^[A-Z]{2}$'),
+  jurisdiction_city_ibge text CHECK (jurisdiction_city_ibge IS NULL OR jurisdiction_city_ibge ~ '^[0-9]{7}$'),
+  -- A jurisdição precisa ser COMPLETA para o seu nível. Uma regra "estadual"
+  -- sem UF não é uma regra: é um marcador que casaria com o país inteiro.
+  CHECK (
+    (jurisdiction_scope = 'federal'   AND jurisdiction_uf IS NULL AND jurisdiction_city_ibge IS NULL) OR
+    (jurisdiction_scope = 'state'     AND jurisdiction_uf IS NOT NULL AND jurisdiction_city_ibge IS NULL) OR
+    (jurisdiction_scope = 'municipal' AND jurisdiction_uf IS NOT NULL AND jurisdiction_city_ibge IS NOT NULL)
+  ),
+
+  -- ── vigência e versão ───────────────────────────────────────────────────
+  version       int NOT NULL DEFAULT 1 CHECK (version > 0),
+  valid_from    date NOT NULL,
+  valid_until   date,
+  CHECK (valid_until IS NULL OR valid_until >= valid_from),
+
+  status        text NOT NULL DEFAULT 'pending_validation'
+                  CHECK (status IN ('not_configured', 'pending_validation', 'validated', 'expired', 'disabled')),
+
+  -- ── conteúdo ────────────────────────────────────────────────────────────
+  -- AST declarativa. Interpretada por código tipado, NUNCA avaliada como
+  -- expressão: nada aqui vira `eval`, SQL ou função.
+  conditions    jsonb NOT NULL DEFAULT '{"op":"always"}'::jsonb,
+  due_rule      jsonb,
+
+  -- ── procedência ─────────────────────────────────────────────────────────
+  source_reference text,
+  validated_by  uuid REFERENCES "user"(id),
+  validated_at  timestamptz,
+  note          text,
+
+  created_at    timestamptz NOT NULL DEFAULT now(),
+  updated_at    timestamptz NOT NULL DEFAULT now(),
+  deleted_at    timestamptz,
+
+  CONSTRAINT fiscal_rule_tenant_id_uq UNIQUE (tenant_id, id),
+  -- Uma regra `validated` sem quem validou é uma afirmação sem autor.
+  CHECK ((status <> 'validated') OR (validated_at IS NOT NULL AND validated_by IS NOT NULL)),
+  -- `not_configured` é o estado honesto de quem não tem vencimento definido.
+  -- Uma regra validada SEM vencimento produziria obrigação sem data.
+  CHECK ((status <> 'validated') OR due_rule IS NOT NULL)
+);
+
+-- Versões da mesma regra não se sobrepõem: uma só vigente por jurisdição.
+-- Mesmo padrão que `accounting_regime` já provou para o regime do cliente.
+CREATE UNIQUE INDEX IF NOT EXISTS fiscal_rule_current_uq
+  ON fiscal_rule (
+    coalesce(tenant_id::text, '-'), item_type_id, jurisdiction_scope,
+    coalesce(jurisdiction_uf, '-'), coalesce(jurisdiction_city_ibge, '-')
+  )
+  WHERE valid_until IS NULL AND deleted_at IS NULL;
+
+CREATE UNIQUE INDEX IF NOT EXISTS fiscal_rule_version_uq
+  ON fiscal_rule (
+    coalesce(tenant_id::text, '-'), item_type_id, jurisdiction_scope,
+    coalesce(jurisdiction_uf, '-'), coalesce(jurisdiction_city_ibge, '-'), version
+  )
+  WHERE deleted_at IS NULL;
+
+-- Pré-filtragem: a engine busca por jurisdição + vigência antes de avaliar
+-- condição nenhuma. Sem este índice, avaliar a carteira exigiria varrer o
+-- catálogo inteiro por cliente.
+CREATE INDEX IF NOT EXISTS fiscal_rule_lookup_idx
+  ON fiscal_rule (jurisdiction_scope, jurisdiction_uf, jurisdiction_city_ibge, valid_from)
+  WHERE deleted_at IS NULL;
+CREATE INDEX IF NOT EXISTS fiscal_rule_item_idx
+  ON fiscal_rule (item_type_id, valid_from) WHERE deleted_at IS NULL;
+
+ALTER TABLE fiscal_rule ENABLE ROW LEVEL SECURITY;
+ALTER TABLE fiscal_rule FORCE ROW LEVEL SECURITY;
+
+-- Leitura: a regra global e as do próprio escritório.
+-- Escrita: SOMENTE as do próprio escritório.
+--
+-- O `WITH CHECK` sem o ramo `IS NULL` é a lição da 0045: com ele, qualquer
+-- tenant forjaria regra fiscal GLOBAL — que vale para todos os escritórios do
+-- país. É a escalada mais cara que este schema comporta.
+CREATE POLICY fiscal_rule_visibility ON fiscal_rule
+  USING (tenant_id IS NULL OR tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid)
+  WITH CHECK (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid);
+
+DO $$
+DECLARE owner_role text;
+BEGIN
+  SELECT tableowner INTO owner_role FROM pg_tables
+   WHERE schemaname = 'public' AND tablename = 'fiscal_rule';
+  IF owner_role IS NULL THEN
+    RAISE EXCEPTION 'fiscal_rule sem dono identificável — abortando';
+  END IF;
+  -- FORCE RLS vale para o dono; o provisionamento do catálogo global roda sem
+  -- tenant no contexto e precisa de política nominal. Padrão da 0042/0045.
+  EXECUTE format(
+    'CREATE POLICY fiscal_rule_system_provisioning ON fiscal_rule FOR ALL TO %I USING (true) WITH CHECK (true)',
+    owner_role);
+END $$;
+
+COMMENT ON POLICY fiscal_rule_visibility ON fiscal_rule IS
+  'Leitura: regra global + as do tenant. Escrita: SOMENTE do tenant. O ramo IS NULL fora do WITH CHECK impede forjar regra fiscal nacional (lição do P0-A, Fase 4).';
+
+-- ── 4 · Política operacional do escritório ─────────────────────────────────
+--
+-- Separa REGRA LEGAL de PROCEDIMENTO DO ESCRITÓRIO.
+--
+-- O prazo legal do DAS é do país. O prazo em que o escritório quer os
+-- documentos do cliente na mão é dele. Enquanto os dois moram no mesmo campo,
+-- ajustar o procedimento interno reescreve a regra legal — em silêncio, e para
+-- todo mundo que enxerga aquela linha.
+
+CREATE TABLE IF NOT EXISTS tenant_rule_policy (
+  id            uuid PRIMARY KEY,
+  tenant_id     uuid NOT NULL REFERENCES tenant(id),
+  item_type_id  uuid NOT NULL REFERENCES recurring_item_type(id),
+  -- Dias ANTES do vencimento legal em que o escritório quer a coisa pronta.
+  -- Não altera o vencimento legal: acrescenta um prazo interno ao lado dele.
+  internal_lead_days int CHECK (internal_lead_days IS NULL OR internal_lead_days BETWEEN 0 AND 90),
+  enabled       boolean NOT NULL DEFAULT true,
+  note          text,
+  updated_by    uuid REFERENCES "user"(id),
+  created_at    timestamptz NOT NULL DEFAULT now(),
+  updated_at    timestamptz NOT NULL DEFAULT now(),
+  CONSTRAINT tenant_rule_policy_tenant_id_uq UNIQUE (tenant_id, id)
+);
+
+CREATE UNIQUE INDEX IF NOT EXISTS tenant_rule_policy_uq
+  ON tenant_rule_policy (tenant_id, item_type_id);
+
+ALTER TABLE tenant_rule_policy ENABLE ROW LEVEL SECURITY;
+ALTER TABLE tenant_rule_policy FORCE ROW LEVEL SECURITY;
+CREATE POLICY tenant_rule_policy_tenant_isolation ON tenant_rule_policy
+  USING (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid)
+  WITH CHECK (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid);
+
+COMMENT ON TABLE tenant_rule_policy IS
+  'Procedimento do escritório, ao LADO da regra legal e nunca por cima dela. Prazo interno não é prazo legal.';
+
+-- ── 5 · Preservação histórica ──────────────────────────────────────────────
+--
+-- A instância já congela `label` e `due_date`. Falta saber QUAL versão da
+-- regra produziu aquela data — sem isso, uma V2 publicada amanhã faz a
+-- obrigação de ontem parecer ter nascido de uma regra que não existia.
+
+ALTER TABLE recurring_instance ADD COLUMN IF NOT EXISTS fiscal_rule_id uuid REFERENCES fiscal_rule(id);
+ALTER TABLE recurring_instance ADD COLUMN IF NOT EXISTS fiscal_rule_version int;
+
+COMMENT ON COLUMN recurring_instance.fiscal_rule_id IS
+  'Versão EXATA da regra que gerou esta obrigação. Publicar uma V2 não altera o que já foi gerado sob a V1.';

package/src/db/migrations/0050_fiscal_vocabulary_readonly.sql

@@ -0,0 +1,29 @@
+-- 0050 — o vocabulário do perfil fiscal é lido pelo runtime, nunca escrito.
+--
+-- Esta migration existe separada da 0049 por uma razão de processo, e vale
+-- registrar: eu havia acrescentado este bloco ao fim da 0049 depois de ela já
+-- ter sido aplicada. O runner recusou — migrations são imutáveis, e a checagem
+-- de hash existe exatamente para impedir que o que rodou num ambiente seja
+-- diferente do que roda no próximo.
+--
+-- ── A barreira ─────────────────────────────────────────────────────────────
+--
+-- `fiscal_attribute_definition` é catálogo GLOBAL, sem `tenant_id`. Não há RLS
+-- que o proteja, porque não há linha de ninguém: a barreira só pode ser o
+-- privilégio.
+--
+-- O runtime lê o vocabulário a cada avaliação de aplicabilidade e nunca o
+-- escreve. Um tenant capaz de inserir atributo aqui poderia criar um atributo
+-- que nenhuma regra usa (inócuo) ou — pior — apagar um que as regras de todos
+-- os escritórios usam, derrubando a avaliação do país inteiro por FK.
+--
+-- Repetido em `migrate.ts` no mesmo bloco de `role` e `audit_log`: o GRANT da
+-- allowlist é amplo por construção e devolveria a escrita no deploy seguinte.
+-- Foi o defeito que a Fase 3 encontrou ao separar GRANT de hardening.
+
+DO $$
+BEGIN
+  IF EXISTS (SELECT FROM pg_roles WHERE rolname = 'baruk_app') THEN
+    EXECUTE 'REVOKE INSERT, UPDATE, DELETE ON fiscal_attribute_definition FROM baruk_app';
+  END IF;
+END $$;

package/src/db/migrations/0051_seed_rules_from_catalog.sql

@@ -0,0 +1,72 @@
+-- 0051 — os 17 seeds viram regras, SEM ganhar precisão que não têm.
+--
+-- ═══ O risco que esta migration precisa não correr ═════════════════════════
+--
+-- É tentador aproveitar a estrutura nova para "melhorar" o seed: dar UF ao ISS,
+-- marcar as federais como validadas, escrever condição de folha nos itens
+-- trabalhistas. Cada uma dessas seria legislação inventada por quem não tem
+-- competência para inventá-la — e escrita num lugar em que passaria a parecer
+-- fonte.
+--
+-- Então esta migration converte o que existe, e **nada mais**:
+--
+--   • toda regra nasce `pending_validation`. Nenhuma vira `validated`: ninguém
+--     conferiu nada ainda, e o CHECK do banco exige autor para validar;
+--   • toda condição nasce `{"op":"always"}` — a aplicabilidade que o seed de
+--     fato tem hoje é por regime, e o regime já é filtrado por
+--     `applies_to_regime` no tipo de item. Não invento condição de folha;
+--   • os dois itens de esfera local viram `not_configured`, porque **não se
+--     sabe de qual UF nem de qual município eles são**. Dar-lhes uma
+--     jurisdição seria escolher um estado por conta própria.
+--
+-- `valid_from` é a data desta migration: é honesto dizer "esta regra existe no
+-- sistema desde hoje", e desonesto dizer que ela vale desde sempre.
+
+DO $$
+DECLARE
+  r record;
+  hoje date := CURRENT_DATE;
+BEGIN
+  FOR r IN
+    SELECT id, key, sphere, due_rule, note
+      FROM recurring_item_type
+     WHERE tenant_id IS NULL AND deleted_at IS NULL
+  LOOP
+    -- Idempotente: reexecutar não duplica.
+    IF EXISTS (SELECT 1 FROM fiscal_rule WHERE item_type_id = r.id AND tenant_id IS NULL) THEN
+      CONTINUE;
+    END IF;
+
+    IF r.sphere IN ('estadual', 'municipal') THEN
+      -- Marcador honesto: o item existe, a regra não. Sem UF, sem município e
+      -- sem vencimento — o motor devolve RULE_NOT_CONFIGURED e ninguém gera
+      -- obrigação local por engano.
+      --
+      -- Fica como `federal` no campo de escopo apenas porque o CHECK exige
+      -- jurisdição completa para state/municipal, e completá-la seria inventar.
+      -- O `status` é quem carrega a verdade: não configurada.
+      INSERT INTO fiscal_rule (
+        id, tenant_id, item_type_id, jurisdiction_scope, version, valid_from,
+        status, conditions, due_rule, note
+      ) VALUES (
+        gen_random_uuid(), NULL, r.id, 'federal', 1, hoje,
+        'not_configured', '{"op":"always"}'::jsonb, NULL,
+        coalesce(r.note || ' ', '') ||
+        '[N1] Item de esfera ' || r.sphere || ' sem jurisdição definida. ' ||
+        'Cadastre uma regra por UF (ou por município) antes de gerar.'
+      );
+    ELSE
+      INSERT INTO fiscal_rule (
+        id, tenant_id, item_type_id, jurisdiction_scope, version, valid_from,
+        status, conditions, due_rule, note
+      ) VALUES (
+        gen_random_uuid(), NULL, r.id, 'federal', 1, hoje,
+        'pending_validation', '{"op":"always"}'::jsonb, r.due_rule,
+        coalesce(r.note, '')
+      );
+    END IF;
+  END LOOP;
+END $$;
+
+COMMENT ON TABLE fiscal_rule IS
+  'Regra fiscal versionada por jurisdição. As 17 primeiras vieram do seed inicial e nascem PENDING_VALIDATION ou NOT_CONFIGURED — nenhuma foi conferida por pessoa, e nenhuma ganhou jurisdição ou prazo que o seed não tinha.';

package/src/db/migrations/0052_fiscal_rule_delete_scope.sql

@@ -0,0 +1,57 @@
+-- 0052 — fechar o DELETE da regra fiscal GLOBAL.
+--
+-- ═══ O defeito, encontrado pelo teste antes do deploy ══════════════════════
+--
+-- A 0049 criou uma política única para `fiscal_rule`:
+--
+--   USING      (tenant_id IS NULL OR tenant_id = current_tenant)
+--   WITH CHECK (tenant_id = current_tenant)
+--
+-- Esse par fecha INSERT e UPDATE — e **não fecha DELETE**. `WITH CHECK` só
+-- governa a linha que passa a existir; quem decide o que um DELETE alcança é o
+-- `USING`. Com o ramo `IS NULL` ali, qualquer escritório apagava regra fiscal
+-- nacional: as regras de todos os outros escritórios do país.
+--
+-- É a mesma forma do P0-A da Fase 4 — o ramo `IS NULL` no lugar errado — com
+-- um agravante: lá a barreira de privilégio segurava, porque `role` teve
+-- INSERT/UPDATE/DELETE revogados do runtime. Aqui não dá para revogar: o
+-- escritório precisa escrever as PRÓPRIAS regras. A separação tem de vir da
+-- política.
+--
+-- ═══ A correção ════════════════════════════════════════════════════════════
+--
+-- Uma política por comando, em vez de uma para tudo. Ler o catálogo nacional é
+-- direito de todos; alterá-lo, de ninguém que opere como escritório.
+
+DROP POLICY IF EXISTS fiscal_rule_visibility ON fiscal_rule;
+
+CREATE POLICY fiscal_rule_read ON fiscal_rule
+  FOR SELECT
+  USING (tenant_id IS NULL OR tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid);
+
+CREATE POLICY fiscal_rule_insert ON fiscal_rule
+  FOR INSERT
+  WITH CHECK (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid);
+
+CREATE POLICY fiscal_rule_update ON fiscal_rule
+  FOR UPDATE
+  USING (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid)
+  WITH CHECK (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid);
+
+CREATE POLICY fiscal_rule_delete ON fiscal_rule
+  FOR DELETE
+  USING (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid);
+
+COMMENT ON POLICY fiscal_rule_read ON fiscal_rule IS
+  'Leitura: catálogo nacional + regras do próprio escritório.';
+COMMENT ON POLICY fiscal_rule_delete ON fiscal_rule IS
+  'Apagar SOMENTE as próprias. A política única da 0049 deixava o DELETE alcançar a regra global, porque WITH CHECK não governa DELETE — só o USING governa.';
+
+-- ── A mesma pergunta, feita às policies vizinhas ───────────────────────────
+--
+-- `role` e `role_permission` têm o mesmo formato desde a 0045 e, no papel,
+-- o mesmo buraco no DELETE. Lá a segunda barreira segura: a 0045 revogou
+-- INSERT, UPDATE e DELETE do runtime, e `migrate.ts` repete o REVOKE a cada
+-- deploy. Fica registrado aqui porque a próxima pessoa a ler aquela policy vai
+-- fazer esta pergunta — e a resposta é "o privilégio segura", não "a política
+-- está certa".

package/src/db/migrations/0053_rule_validity_lower_bound.sql

@@ -0,0 +1,44 @@
+-- 0053 — `valid_from` descreve a REGRA, não o dia em que a linha foi criada.
+--
+-- ═══ O erro da 0051, e por que ele parecia certo ═══════════════════════════
+--
+-- A 0051 gravou `valid_from = CURRENT_DATE` nas regras do seed, com a
+-- justificativa de que é honesto dizer "esta regra existe no sistema desde
+-- hoje". A frase é verdadeira e a modelagem estava errada: `valid_from` não
+-- descreve quando o REGISTRO nasceu — descreve desde quando a REGRA vale.
+--
+-- O efeito apareceu no primeiro teste: um escritório que abre a competência de
+-- agosto em setembro — que é o normal da profissão, não a exceção — não
+-- recebia obrigação nenhuma, porque nenhuma regra era candidata para agosto.
+--
+-- ═══ Por que uma data antiga é mais honesta que hoje ══════════════════════
+--
+-- Não se sabe desde quando cada obrigação do seed está em vigor; várias são
+-- anteriores ao produto. As duas opções eram:
+--
+--   hoje        → afirma que a regra não valia em agosto. É falso.
+--   limite baixo → afirma que ela vale desde antes de o sistema existir, sem
+--                  dizer desde quando. É verdadeiro e incompleto.
+--
+-- A segunda é a correta: `2000-01-01` aqui não é uma data legal, é a ausência
+-- de início declarado. Declarar o início de verdade faz parte de validar a
+-- regra, e as regras do seed continuam `pending_validation` justamente porque
+-- ninguém as validou.
+--
+-- Nada disso relaxa a barreira: uma regra pendente não gera obrigação. O que
+-- muda é que ela passa a ser CANDIDATA e a aparecer na prévia com o motivo
+-- certo — "aguarda conferência" em vez de "não existe regra", que mandaria o
+-- escritório procurar o que já está lá.
+
+UPDATE fiscal_rule
+   SET valid_from = DATE '2000-01-01',
+       note = coalesce(note || ' ', '') ||
+              '[N1] Início de vigência não declarado: a data é um limite inferior, não uma afirmação legal.',
+       updated_at = now()
+ WHERE tenant_id IS NULL
+   AND deleted_at IS NULL
+   AND valid_from > DATE '2000-01-01'
+   AND status IN ('pending_validation', 'not_configured');
+
+COMMENT ON COLUMN fiscal_rule.valid_from IS
+  'Desde quando a REGRA vale — não quando a linha foi criada. Regra sem início declarado usa um limite inferior antigo, e declarar o início real faz parte de validá-la.';

package/src/db/migrations/0054_tenant_profile_and_rule_source.sql

@@ -0,0 +1,89 @@
+-- 0054 — a identidade do escritório vira dado do produto, e a regra fiscal
+-- passa a citar a fonte.
+--
+-- ═══ Por que estas duas coisas na mesma migration ══════════════════════════
+--
+-- As duas nascem do mesmo achado da auditoria C360: o produto tinha caminho de
+-- LEITURA e não tinha caminho de ESCRITA. A marca do escritório vivia em
+-- `tenant.settings` e só era gravável por `UPDATE` manual no banco; a regra
+-- fiscal tinha `source_reference` em texto livre e nenhum lugar canônico para o
+-- endereço da norma. Nos dois casos o efeito é o mesmo: um escritório novo
+-- exigia desenvolvedor.
+--
+-- Nenhuma tabela nova. Nenhum GRANT novo: `tenant` e `fiscal_rule` já estão na
+-- allowlist do runtime, e GRANT em Postgres é por tabela — coluna nova nasce
+-- alcançável pelo mesmo privilégio.
+
+-- ── 1 · Identidade do escritório ───────────────────────────────────────────
+--
+-- `display_name` e `legal_name` já existiam. Faltavam o documento e o fuso, e
+-- os dois têm consumidor concreto e próximo:
+--
+--   documento → o escritório é ele mesmo um contribuinte. A onda de ingestão
+--               fiscal precisa do CNPJ dele para o certificado da própria casa
+--               (`digital_certificate.client_id IS NULL` já prevê esse caso).
+--   fuso      → todo vencimento hoje é calculado em data, sem hora. No dia em
+--               que houver corte por horário (janela de envio, D-0 às 18h), a
+--               ausência do fuso vira erro de um dia para metade do país.
+--
+-- Só dígitos, como em `client.document_number`: máscara é apresentação, e duas
+-- representações do mesmo documento não se encontram em nenhuma busca.
+ALTER TABLE tenant ADD COLUMN IF NOT EXISTS document_number text;
+ALTER TABLE tenant ADD COLUMN IF NOT EXISTS timezone text NOT NULL DEFAULT 'America/Sao_Paulo';
+
+DO $$
+BEGIN
+  IF NOT EXISTS (SELECT FROM pg_constraint WHERE conname = 'tenant_document_format') THEN
+    ALTER TABLE tenant ADD CONSTRAINT tenant_document_format
+      CHECK (document_number IS NULL OR document_number ~ '^[0-9]{11}$' OR document_number ~ '^[0-9]{14}$');
+  END IF;
+
+  -- Fuso: a lista dos fusos BRASILEIROS, não um texto livre.
+  --
+  -- `CHECK` não enxerga `pg_timezone_names`, então a alternativa seria aceitar
+  -- qualquer string e descobrir o erro na primeira conversão. O produto é
+  -- nacional; enumerar os dezesseis fusos do país é a restrição honesta e
+  -- fecha a porta para `'GMT-3'`, `'Brasilia'` e afins, que parecem certos e
+  -- não são identificadores IANA.
+  IF NOT EXISTS (SELECT FROM pg_constraint WHERE conname = 'tenant_timezone_br') THEN
+    ALTER TABLE tenant ADD CONSTRAINT tenant_timezone_br
+      CHECK (timezone IN (
+        'America/Sao_Paulo','America/Bahia','America/Fortaleza','America/Recife',
+        'America/Belem','America/Araguaina','America/Maceio','America/Campo_Grande',
+        'America/Cuiaba','America/Santarem','America/Manaus','America/Porto_Velho',
+        'America/Boa_Vista','America/Rio_Branco','America/Eirunepe','America/Noronha'
+      ));
+  END IF;
+END $$;
+
+COMMENT ON COLUMN tenant.document_number IS
+  'CNPJ (14) ou CPF (11) do próprio escritório, só dígitos. O escritório é contribuinte de si mesmo — a ingestão fiscal precisa deste número para o certificado da casa.';
+COMMENT ON COLUMN tenant.timezone IS
+  'Fuso IANA do escritório. Restrito aos fusos brasileiros: o produto é nacional e um texto livre aceitaria identificadores que não existem.';
+
+-- ── 2 · A regra fiscal cita a fonte ────────────────────────────────────────
+--
+-- `source_reference` continua sendo a referência humana ("IN RFB 2.005/2021,
+-- art. 3º"). `source_url` é o ENDEREÇO oficial, separado de propósito: uma URL
+-- misturada com texto livre não pode ser verificada, aberta na tela nem
+-- comparada entre versões.
+--
+-- Só https. A regra fiscal aparece numa tela de conferência e o endereço vira
+-- link; `javascript:` e `data:` num campo editável seriam XSS armazenado com a
+-- assinatura do escritório.
+--
+-- Isto NÃO valida a regra. Citar a fonte é o insumo da conferência humana, e
+-- `status` continua exigindo `validated_by` e `validated_at` para sair de
+-- `pending_validation`.
+ALTER TABLE fiscal_rule ADD COLUMN IF NOT EXISTS source_url text;
+
+DO $$
+BEGIN
+  IF NOT EXISTS (SELECT FROM pg_constraint WHERE conname = 'fiscal_rule_source_url_https') THEN
+    ALTER TABLE fiscal_rule ADD CONSTRAINT fiscal_rule_source_url_https
+      CHECK (source_url IS NULL OR source_url ~ '^https://[^\s"''<>]+$');
+  END IF;
+END $$;
+
+COMMENT ON COLUMN fiscal_rule.source_url IS
+  'Endereço oficial da norma, https. Insumo da conferência humana — citar a fonte não valida a regra.';