-- SESSAO DE TENANT, e o usuario final com nome.
--
-- 1. ESCOPO DA SESSAO
--
-- A 0022 nasceu com uma regra dura: sessao SEMPRE de projeto. A razao era boa
-- -- alcance de tenant no navegador expoe todos os clientes de uma vez -- mas
-- ela cortava um caso legitimo: o ADMIN GERAL do ERP, logado no painel dele,
-- que precisa do agente consolidado sobre todas as empresas. E exatamente a
-- persona para a qual a chave de escopo de tenant existe.
--
-- O que torna isso defensavel e que a sessao NAO e a chave:
--
--   chave de tenant (ctx_)      permanente, sem origem, roda SQL, sem teto
--   sessao de tenant (ctxs_)    expira, presa a UMA origem, teto de perguntas,
--                               NAO roda SQL -- so pergunta em linguagem natural
--
-- Continua sendo o alcance mais perigoso do sistema, entao: `project` e o
-- padrao, `tenant` exige uma chave EMISSORA de tenant e um pedido EXPLICITO.
--
-- 2. A CONFIGURACAO SEGUE A MESMA CAMADA
--
-- Se a sessao pode ser de tenant, a configuracao do modelo tambem precisa ser
-- -- senao uma sessao consolidada teria de emprestar a chave de LLM de um
-- projeto qualquer, o que seria arbitrario e invisivel no rastro.
--
-- A camada de cima e a AUSENCIA de projeto, como em 0019 (semantica), 0021
-- (context servers) e no knowledge:
--
--   project_id = 7      configuracao daquele projeto
--   project_id IS NULL  configuracao do TENANT, usada pela sessao consolidada
--                       e herdada por projeto que nao tenha a sua
--
-- A UNIQUE precisa da mesma correcao de 0021: em InnoDB um indice UNIQUE
-- aceita qualquer numero de linhas com NULL, entao (project_id) sozinho
-- deixaria a camada NOVA sem protecao -- varias configuracoes de tenant
-- conviveriam e ninguem saberia qual gasta. Coluna gerada COALESCE resolve.
--
-- 3. QUEM E O USUARIO FINAL
--
-- end_user guardava um identificador so. Sao duas coisas com usos diferentes:
-- o ID interno do cliente, estavel, que serve para filtrar e limitar; e o
-- rotulo humano (nome, e-mail), que e o que aparece no historico de correcao.
-- "Corrigido por u-4711" nao ajuda ninguem seis meses depois.
--
-- ATENCAO A DADO PESSOAL: um e-mail no rotulo entra na trilha de auditoria e
-- fica la. O campo aceita o que o cliente mandar, e a decisao e dele -- mas
-- precisa ser consciente, nao efeito colateral.

-- ------------------------------------------------- configuracao: camada tenant
ALTER TABLE embed_configs
  MODIFY COLUMN project_id BIGINT UNSIGNED NULL;

ALTER TABLE embed_configs
  ADD COLUMN scope_project_id BIGINT UNSIGNED
    AS (COALESCE(project_id, 0)) VIRTUAL AFTER project_id;

-- A FK para `projects` se apoia na UNIQUE antiga como indice. Derrubar a
-- UNIQUE antes de existir outro indice comecando por project_id da erro 1553
-- ("needed in a foreign key constraint") -- o mesmo tropeco que a 0021
-- documentou. Cria-se o substituto ANTES.
ALTER TABLE embed_configs
  ADD INDEX idx_embed_configs_project (project_id);

ALTER TABLE embed_configs
  DROP INDEX uq_embed_configs_project;

ALTER TABLE embed_configs
  ADD UNIQUE KEY uq_embed_configs_camada (tenant_id, scope_project_id);

-- ------------------------------------------------------------- sessao
ALTER TABLE embed_sessions
  ADD COLUMN scope VARCHAR(16) NOT NULL DEFAULT 'project' AFTER config_id,
  ADD COLUMN end_user_label VARCHAR(190) NULL AFTER end_user;

-- Numa sessao de TENANT nao ha um projeto, e escolher um qualquer seria
-- mentira na trilha. tenant_id continua NOT NULL: e a barreira de verdade.
ALTER TABLE embed_sessions
  MODIFY COLUMN project_id BIGINT UNSIGNED NULL;

CREATE INDEX idx_embed_sessions_scope ON embed_sessions (scope);