-- 0036 — pacotes: conteudo do tenant que so quem contratou enxerga -- -- O PROBLEMA, E POR QUE O DEFAULT DE HOJE ESTA INVERTIDO -- -- A heranca de hoje (0019, 0021, 0032) tem uma direcao so: o que esta na camada -- do TENANT e herdado por TODOS os projetos, e a unica ferramenta e a NEGACAO -- -- as tabelas context_server_optouts e embed_prompt_optouts, que tiram um item de -- um projeto especifico. -- -- Isso e o certo para regra do ERP: "contas a pagar vencidas" vale para todo -- cliente, e a excecao e rara. E o ERRADO para um produto pago. -- -- Cenario real: o cliente vende um pacote de suporte. O conteudo -- documentos -- de "como fazer X no sistema", ou um MCP de suporte, mais os itens de menu -- correspondentes -- e O MESMO para todos que compraram, entao pertence a -- camada do tenant. Mas herdado por todos significa que quem NAO comprou -- tambem recebe, ate alguem lembrar de negar um a um. -- -- E ninguem vai lembrar: numa base multi-empresa, empresa nova nasce sozinha na -- recarga da madrugada. Ela nasceria com o pacote pago ligado. -- -- Esquecer de NEGAR entrega um produto pago de graca. Esquecer de CONCEDER gera -- um chamado. Os dois erros nao tem o mesmo custo, e por isso o default de -- conteudo pago tem de ser "ninguem ve". -- -- -- POR QUE PACOTE, E NAO CONCESSAO ITEM A ITEM -- -- A tentacao e espelhar o opt-out: uma tabela de concessao por item. Nao serve. -- -- "O projeto X tem pacote de suporte" e UMA decisao de negocio. Se ela virasse -- 1 concessao do servidor MCP + 12 dos documentos + 8 dos itens de menu, seria -- inoperavel -- e derivaria: alguem concede os documentos e esquece o menu, e o -- cliente ve as perguntas prontas de suporte que nao consegue responder. -- -- O pacote e o AGRUPADOR que faz a decisao ser uma so. Ele atravessa os tres -- dominios que ja tem heranca (contexto, conhecimento e o menu de perguntas) -- com o mesmo conceito. -- -- -- COMPATIBILIDADE: package_id NULL E TUDO QUE EXISTE HOJE -- -- Item de tenant sem pacote continua herdado por todos, e o opt-out continua -- valendo nele. Nada do que esta no ar muda de comportamento -- a coluna nasce -- NULL em toda linha existente. -- -- package_id IS NULL herdado por todos (o de hoje); nega-se com opt-out -- package_id = N so quem tem concessao de N enxerga -- -- As duas ferramentas convivem porque respondem a perguntas diferentes: opt-out -- e "todos MENOS este"; pacote e "NINGUEM, exceto quem contratou". -- -- -- O QUE O PACOTE NAO E -- -- Nao e natureza de projeto (0035). "Nao e uma empresa" e "nao contratou" sao -- estados diferentes, e junta-los faria alguem liberar a fonte do eSocial para -- um cliente ao conceder um pacote. -- -- Nao e alcance. Alcance continua sendo escopo de credencial. Uma sessao de -- TENANT enxerga o conteudo dos proprios pacotes sem concessao nenhuma: o -- conteudo e dele, e o pacote restringe o que um PROJETO herda, nao o que o -- dono ve. CREATE TABLE packages ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, tenant_id BIGINT UNSIGNED NOT NULL, -- Como se refere a ele na CLI e na API. Minusculo, sem espaco. slug VARCHAR(64) NOT NULL, -- Como aparece para uma pessoa. name VARCHAR(120) NOT NULL, description VARCHAR(255) NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uq_packages_slug (tenant_id, slug), CONSTRAINT fk_packages_tenant FOREIGN KEY (tenant_id) REFERENCES tenants(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; -- A CONCESSAO: quem contratou o que. -- -- Tabela de ligacao, como os opt-outs, e pelo motivo oposto: ali a ausencia de -- linha e o estado normal e a presenca e a excecao; aqui a ausencia e "nao -- contratou" e a presenca e o direito. E a inversao inteira do default. CREATE TABLE project_packages ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, project_id BIGINT UNSIGNED NOT NULL, package_id BIGINT UNSIGNED NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uq_project_packages (project_id, package_id), KEY idx_project_packages_package (package_id), CONSTRAINT fk_project_packages_project FOREIGN KEY (project_id) REFERENCES projects(id), -- CASCADE: apagado o pacote, a concessao dele nao significa mais nada. CONSTRAINT fk_project_packages_package FOREIGN KEY (package_id) REFERENCES packages(id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; -- --------------------------------------------------------------------------- -- A MARCA NOS TRES DOMINIOS QUE JA TEM HERANCA -- --------------------------------------------------------------------------- -- SET NULL e nao CASCADE ao apagar o pacote: o conteudo NAO deve sumir junto. -- Apagar um pacote e decisao comercial ("nao vendemos mais isto"); apagar os -- documentos e outra, e faze-las na mesma operacao destruiria trabalho de -- redacao por causa de uma mudanca de catalogo. Sem pacote, o item volta a ser -- herdado por todos -- o que e visivel e corrigivel, ao contrario do sumico. ALTER TABLE context_servers ADD COLUMN package_id BIGINT UNSIGNED NULL AFTER project_id, ADD KEY idx_context_servers_package (package_id), ADD CONSTRAINT fk_context_servers_package FOREIGN KEY (package_id) REFERENCES packages(id) ON DELETE SET NULL; ALTER TABLE knowledge_items ADD COLUMN package_id BIGINT UNSIGNED NULL AFTER project_id, ADD KEY idx_knowledge_items_package (package_id), ADD CONSTRAINT fk_knowledge_items_package FOREIGN KEY (package_id) REFERENCES packages(id) ON DELETE SET NULL; ALTER TABLE embed_prompts ADD COLUMN package_id BIGINT UNSIGNED NULL AFTER project_id, ADD KEY idx_embed_prompts_package (package_id), ADD CONSTRAINT fk_embed_prompts_package FOREIGN KEY (package_id) REFERENCES packages(id) ON DELETE SET NULL;