GrydFiles

FileReference só pode ser criada sobre Available. É a invariante central: tudo o mais no módulo existe para sustentá-la. A primeira referência é criada pelo próprio módulo, na saída para Available: o consumidor declara a intenção na confirmação e nunca a referência, e por isso não existe caminho em que ele precise contrariar esta regra para funcionar.

Na mesma leitura do antivírus, a partir do objeto gravado. Hash informado pelo cliente é ignorado, mesmo quando enviado.

A conferência é por assinatura de conteúdo, sempre — inclusive com ScanRequired: false, porque a leitura única já acontece para o hash. O objeto é apagado e o registro termina em Purged. No caminho síncrono (tipo declarado, antes da URL) a resposta é 422; no assíncrono (tipo verificado, no job) não há request para responder, e o motivo fica em rejectionCode.

Não existe transição de volta, nem por permissão elevada. O objeto vai para a quarentena e o motivo fica gravado para sempre: o nome da assinatura, na detecção pelo motor, ou o rejectionCode, no incidente de integridade do re-scan (RN-GF-18), que não tem assinatura.

clamd indisponível produz Failed e nova tentativa. Não há modo degradado, timeout que libere, nem flag de emergência. Sem motor, não há módulo: o host não sobe sem um motor de antivírus registrado. E motor registrado precisa ser motor de verdade: implementação que responde "limpo" sem ler o conteúdo libera tudo, e o registro de motor alternativo aceita qualquer implementação — por isso o monitor do scanner submete a amostra EICAR ao motor registrado, e motor que não a detecta é tratado como indisponível. Critérios de aceite: (a) host com o GrydFiles e sem motor registrado → falha na inicialização, com a mensagem que nomeia o registro que falta; (b) motor registrado que não detecta EICAR → o monitor o marca indisponível, o scan não libera nenhum arquivo (Failed e nova tentativa) e o operador é alertado.

Subida e descida pela superfície HTTP sempre por URL pré-assinada: nenhuma rota aceita ou devolve o conteúdo do arquivo. Exceção declarada: a IServerFileStore, em processo, para bytes que o servidor já tem. StoreAsync e OpenReadAsync movem bytes e só servem a consumidor declarado; ReleaseAsync não move byte e pode ser alcançado por rota do próprio dono — DELETE /reports/{id} apaga o relatório e libera a referência dele. O que o teste de arquitetura prova, e onde: (a) no GrydFiles.API, nenhum tipo depende do espaço de nomes da porta e nenhuma action recebe ou devolve conteúdo (IFormFile, Stream, byte[], FileResult); (b) no repositório do Gryd.IO, os assemblies que dependem da porta são exatamente os consumidores declarados — hoje seis: GrydReports.Application, GrydReports.Infrastructure, GrydNotifications.Application, GrydNotifications.Infrastructure, GrydAudit.Export e GrydAudit.Integrity (DEC-GF-06-1) —, e consumidor novo quebra o teste até ser declarado; produto que usa a porta repete a asserção (b) no próprio repositório. Que nenhuma rota do consumidor devolva os bytes que ele leu não se prova daqui: cada consumidor declarado responde por isso no próprio host. Critérios de aceite: assembly fora da lista que chama OpenReadAsync → o teste falha; action do GrydFiles.API que devolve Stream → o teste falha.

Não aparecem em DTO, resposta de API nem log de aplicação. Quem consome recebe fileId e, quando precisa, uma URL que vence. Dentro do módulo, a localização é preservada na lápide.

Objeto, registro e referência pertencem a um único tenant — ou ao produto, com tenantId nulo. Arquivo de outro tenant responde FILE_NOT_FOUND, igual a arquivo inexistente, e nenhum objeto é reaproveitado entre clientes, mesmo com sha256 idêntico: seria canal de inferência. Leitura sem tenant falha fechada: consulta sem tenant no contexto não devolve registro de tenant nenhum — só arquivo de produto —, e job que atravessa tenants (scan, varreduras) desliga o filtro só para selecionar candidatos, trata cada registro no tenant dele e nunca entrega veredito nem chama consumidor com o filtro desligado. É o requisito de tenant restaurado e leitura que falha fechada da página de Mensageria. Tenant nomeado é o tenant em vigor. As duas portas em processo recebem o tenant nomeado pelo chamador, a partir do registro do próprio consumidor — é o único contrato, porque job e repetição depois do commit rodam sem request e não têm contexto para ler. Nomear não é escolher: havendo tenant em vigor no contexto, o tenant nomeado precisa ser igual a ele, e diferente responde FILE_NOT_FOUND, nunca a leitura atendida; não havendo tenant em vigor, o escopo do tenant nomeado é aberto antes da leitura e a leitura acontece dentro dele. Nenhuma porta desliga o filtro de tenant para atender o tenant do parâmetro — desligar o filtro continua valendo só para o job que seleciona candidatos, que trata cada registro no tenant dele. Critério de aceite: IFileService.GetAsync sem tenant no contexto, sobre arquivo de um tenant → FILE_NOT_FOUND; IServerFileStore.OpenReadAsync com tenant nomeado diferente do tenant em vigor → FILE_NOT_FOUND e nada lido; a mesma chamada sem tenant em vigor → o escopo do tenant nomeado é aberto e a leitura alcança só arquivo dele.

retainUntil nunca é puxado para trás por API, e Permanent jamais entra no job de expurgo.

Nunca o contrário. purgedAt, purgeReason e purgeAuthorKind são gravados juntos, no mesmo método. purgeAuthorKind é Job, Authenticated — o usuário autenticado no contexto — ou Declared — o autor que o consumidor declarou na chamada em processo (RN-GF-27). purgedBy é nulo quando e somente quando o tipo é Job; com Declared, purgeDeclaredScope (o escopo que declarou) e purgeServiceExecutor (o executor de serviço que chamou) são obrigatórios, e nos outros dois tipos são nulos. Na eliminação com dupla custódia (RN-GF-25), purgedBy é quem executou e erasureRequestedBy, quem registrou o pedido. Nenhuma leitura da lápide ou da trilha apresenta autor declarado como usuário autenticado: o tipo acompanha o autor. Registro fora de Pending, sem purgedAt e cujo objeto não existe é defeito, e a varredura de consistência o reporta. Critérios de aceite: (a) expurgo pelo job de retenção → Job e purgedBy nulo; (b) expurgo pela rota → Authenticated, purgedBy do usuário, escopo e executor nulos; (c) eliminação repetida pelo job do consumidor, sem usuário e com o autor declarado → Declared, purgedBy do autor, e a lápide e a trilha mostram os dois: o escopo que declarou e o executor de serviço.

Não existe upload sem perfil, nem perfil sem tamanho máximo, lista de tipos e modo de retenção padrão. O perfil é sempre explícito: não há perfil padrão para o qual cair por omissão, e perfil incompleto derruba a aplicação na inicialização.

Preparada pela IFileAuditTrail do módulo na outbox e entregue a IAuditStore.SaveAsync depois do commit, porque leitura não passa por SaveChanges e o interceptor não a veria. A gravação durável e isolada por tenant é do GrydAudit: o armazenamento padrão, NullAuditStore, não guarda nada, por isso o host que compõe o módulo com ele não sobe e a URL não é emitida sem trilha durável. Quem baixou o quê é a pergunta que uma auditoria de vazamento faz primeiro.

Quem consome declara, no processo, uma referência esperada (expectedOwnerScope · expectedOwnerKey) — ao confirmar ou ao gravar conteúdo do servidor, e só sobre registro que o mesmo chamador reservou (RN-GF-22) —, que não referencia nada e nunca vem da rota HTTP. Na saída para Available, a mesma transação que muda o estado cria a FileReference e zera a referência esperada. Em toda transição de veredito grava-se, na mesma transação, o registro do veredito a entregar, que guarda o tenant do arquivo e o dono — ownerScope e ownerKey da referência esperada, ou de cada referência que o re-scan positivo liberou —, porque o veredito negativo zera a referência esperada e, sem o dono no registro, ninguém saberia a quem avisar. Todo desfecho — Available, Infected, reprovação e Failed — é entregue ao contrato de veredito do ownerScope depois do commit, pelo menos uma vez. O handler é idempotente e decide pelo estado atual do arquivo, não pelo conteúdo da mensagem. Roda fora de request, com o tenant gravado no registro do veredito restaurado e sem usuário: relê o arquivo pela IFileService.GetAsync, que não exige usuário (RN-GF-26), não executa comando em nome de pessoa (Ata B3) e falha fechado sem tenant; dono que não existe mais, ou que não aponta para este arquivo, é desfecho normal (libera a referência e confirma). Efeito do consumidor que falha não desfaz o veredito: a entrega se repete. ownerScope sem contrato registrado derruba a inicialização. Critérios de aceite: (a) processo derrubado entre o commit do veredito e a entrega → o handler recebe o veredito quando o processo volta; (b) a mesma entrega duas vezes → um efeito só; (c) entregas de Available e Infected do mesmo arquivo em ordem trocada → o consumidor termina em Infected; (d) handler sem tenant no contexto → nenhuma leitura, erro e nova tentativa; (e) Failed com tentativas esgotadas → o consumidor recebe o veredito; (f) veredito Infected sobre arquivo com referência esperada → a entrega chega ao ownerScope e à ownerKey declarados, embora o registro do arquivo já não guarde a referência esperada; (g) handler sem usuário no contexto e com tenant restaurado → relê o arquivo e conclui.

Em RetainUntil, o expurgo automático exige retainUntil vencido e nenhuma referência ativa, com a carência contada da última liberação. Referência ativa segura o objeto qualquer que seja a data; a data segura o objeto qualquer que seja a contagem. Guarda contada de um fato do dono se escreve empurrando retainUntil quando o fato acontece e liberando a referência quando o vínculo acaba. Critérios de aceite: (a) retainUntil vencido e uma referência ativa → o job não expurga; (b) referência liberada depois da data → expurgo só depois da carência; (c) referência liberada antes da data → expurgo só depois da data.

O job de retenção expurga um registro Available quando valem todas: nenhuma referência ativa; carência vencida desde a última liberação — ou desde o veredito, se nunca houve referência; retainUntil vencido, no modo RetainUntil; legalHold desligado; e modo diferente de Permanent. O predicado é reavaliado sob a trava do registro, no momento de apagar (RN-GF-20).

Pertencia à unicidade do conteúdo do dedupe, que não faz parte da v1 (bloco v2 em § Hash e referência). Não é reaproveitado por outra regra.

Esgotadas as três tentativas automáticas, POST /files/{id}/rescan recoloca o registro na fila — sem essa saída, falha de infraestrutura viraria arquivo morto que nenhum consumidor consegue abrir nem substituir. O acervo liberado é reprocessado pelo job de re-scan depois de atualização da base de assinaturas. Re-scan de Available não muda o estado: grava o FileScanAttempt, e o arquivo segue referenciável e baixável — inclusive quando a leitura é interrompida por erro de E/S, que é tentativa com erro e não veredito; só a detecção pelo motor ou a divergência de tamanho confirmada (RN-GF-18) o levam a Infected, liberando todas as referências ativas na mesma transação e entregando o veredito a cada ownerScope que as tinha. Critério de aceite: arquivo Available com duas referências ativas, re-scan com EICAR na base de teste → estado Infected, objeto na quarentena, as duas referências liberadas e dois vereditos entregues; durante um re-scan limpo, GET /files/{id}/download-url continua respondendo.

Depois do veredito, nenhum caminho de escrita alcança o objeto que é servido e referenciado: a URL de upload, que continua válida até vencer, não troca o conteúdo de arquivo já liberado, e o sha256 gravado é o dos bytes que o download entrega. A URL de upload é assinada para um objeto, uma operação, o Content-Type e — onde o provedor assina tamanho — o tamanho declarado; onde não assina, a confirmação confere o tamanho. Em todo provedor, o scan lê no máximo sizeBytes + 1 bytes: leitura que passa de sizeBytes, ou que chega ao fim antes dele sem erro de E/S, recusa o arquivo com FILE_OBJECT_CHANGED_UNPROCESSABLE — um PUT depois da confirmação não passa por conferência nenhuma, e a SAS do Azure não assina tamanho. Objeto que mudou depois da leitura do scan não é liberado: o registro que ainda não foi liberado termina em Purged com rejectionCode = FILE_OBJECT_CHANGED_UNPROCESSABLE, e a ocorrência vai para a trilha. No re-scan de arquivo já liberado, nunca Purged: divergência de tamanho confirmada sobre Available é incidente de integridade. Confirmada quer dizer: a leitura passou de sizeBytes — interrupção nenhuma produz bytes a mais —, ou terminou antes dele sem erro de E/S e o tamanho que o storage informa para o objeto também difere de sizeBytes. Leitura cortada por erro de E/S, timeout ou queda de conexão não é divergência: grava a tentativa com erro e o arquivo segue Available (RN-GF-17). No incidente, o arquivo sai do download pelo caminho do re-scan positivo (Available → Infected, com o objeto lido copiado para a quarentena como evidência, rejectionCode = FILE_OBJECT_CHANGED_UNPROCESSABLE e o veredito entregue a cada dono), e a guarda continua valendo: retainUntil, legalHold e Permanent seguram o registro como seguram qualquer quarentena (RN-GF-14, RN-GF-24). Expurgar ali apagaria a prova justamente do arquivo que precisa de investigação. Vale também para a quarentena e para a lápide: o objeto copiado para a quarentena é a versão que o scan leu — cópia a partir de chave que nenhuma URL de escrita alcança, ou condicionada à versão lida no scan (ETag no S3 e no Azure, generation no GCS) —, e o sha256 que a lápide da quarentena guarda é o do conteúdo guardado. Cópia recusada pela condição não põe na quarentena conteúdo que o scan não leu: o registro fica Infected, nunca é servido, e a ocorrência vai para a trilha como incidente. Critérios de aceite, nos três provedores: (a) PUT repetido com a mesma URL depois de Available → o download entrega os bytes cujo sha256 está gravado; (b) PUT repetido entre a confirmação e o veredito → ou o conteúdo servido é o escaneado, ou o arquivo não é liberado — nunca liberado com conteúdo que o scan não leu; (c) PUT maior que o declarado, antes ou depois da confirmação → recusado pelo storage, na confirmação ou na leitura do scan, e nunca liberado nem servido; (d) PUT entre a leitura do scan positivo e a cópia para a quarentena → o objeto da quarentena tem o sha256 gravado, ou a cópia é recusada e o incidente está na trilha; (e) re-scan de Available com retainUntil futuro cuja leitura passa de sizeBytes → Infected, fora do download, incidente na trilha, retainUntil intacto e nenhum Purged; (f) re-scan de Available com a conexão com o storage cortada no meio da leitura → tentativa com erro gravada, arquivo Available e nenhum veredito entregue. O exemplo de implementação está em § Upload.

Registro em Scanning sem varredura em andamento nem agendada, ou em Failed com tentativa automática restante e nenhuma agendada, volta à fila sozinho depois de ScanRequeueAfterMinutes — padrão de 45 minutos, sempre maior que a soma das esperas de re-tentativa e dos timeouts (hoje cerca de 29 minutos), para não duplicar trabalho em curso. A recolocação é idempotente: o job de scan ignora registro que já tem veredito. Failed com as três tentativas esgotadas não volta sozinho: fica com alerta ao operador e sai pela RN-GF-17. Critério de aceite: processo derrubado entre o commit da confirmação e o enfileiramento → o arquivo recebe veredito sem ação humana, em até ScanRequeueAfterMinutes mais o intervalo da varredura.

Criar referência e expurgar disputam o mesmo registro e são mutuamente exclusivos: o expurgo trava o registro e reavalia o predicado sob a trava; a criação de referência trava o mesmo registro — ou confere a sua versão — e recusa com FILE_PURGED_CONFLICT se o expurgo venceu. Ligar e retirar guarda disputam o mesmo registro. Ligar ou retirar guarda — em processo ou pela rota — trava o registro, e o expurgo reavalia as guardas por detentor sob a trava, nunca com o retrato que a consulta de pré-condição devolveu (RN-GF-25): a consulta não reserva nada. Guarda ligada entre a consulta e o expurgo vence, e a recusa por guarda nova não é um erro qualquer: o expurgo responde FILE_LEGAL_HOLD_CONFLICT e a resposta devolve o estado — os detentores ativos e purgedAt nulo —, para o consumidor tratar o pedido como bloqueado, e nunca como concluído. O consumidor só publica a eliminação quando a resposta traz purgedAt; do lado do Nexio, é assim que o Anexo deixa de publicar attachment.erased sobre bytes presos. Retirar guarda corre a mesma trava. Sem ela, o expurgo concorrente recusaria trazendo um detentor que acabou de sair, e o consumidor trataria como bloqueado um pedido preso por guarda que já não existe: a lista de detentores que a recusa devolve é sempre a de depois da retirada que venceu a trava. E a retirada sobre registro que o expurgo já venceu é recusada com FILE_PURGED_CONFLICT, como a criação de referência — sobre lápide não há guarda a retirar e nada muda; a repetição sem efeito da RN-GF-27 vale sobre registro vivo. Critério de aceite: criação de referência e job de expurgo concorrentes sobre um arquivo sem referência e com carência vencida → ou a referência existe e o objeto também, ou o registro está Purged e a criação respondeu FILE_PURGED_CONFLICT; nunca referência ativa sobre objeto apagado. Ligar guarda e expurgo concorrentes sobre o mesmo arquivo → ou a guarda está ativa e o objeto também, com a recusa do expurgo trazendo o detentor e purgedAt nulo, ou o registro está Purged e o pedido de guarda respondeu FILE_PURGED_CONFLICT; nunca guarda ativa sobre objeto apagado, nem purgedAt gravado com guarda ativa. Retirar guarda e expurgo concorrentes sobre arquivo cuja última guarda é essa → ou a retirada gravou primeiro e o expurgo, reavaliando sob a trava, apagou, ou o expurgo gravou primeiro e a retirada respondeu FILE_PURGED_CONFLICT; a recusa do expurgo por guarda nunca lista detentor já retirado. Duas retiradas concorrentes sobre o mesmo arquivo — a repetição do mesmo detentor, ou dois detentores ao mesmo tempo — serializam na mesma trava: cada guarda sai uma vez, a segunda chamada do mesmo detentor não produz efeito novo e devolve o estado atual (RN-GF-27), e o legalHold derivado nunca fica ligado sem detentor ativo nem desligado com detentor ativo.

Toda lápide gravada sem pedido de expurgo — pelos cinco caminhos de job (job:retencao, job:pending-expirado, job:quarentena-vencida, job:tipo-reprovado e job:objeto-alterado) e pela rejeição de tamanho na confirmação (rejeicao:tamanho-divergente) — sai sem originalFileName. No expurgo manual, o nome sai quando o pedido traz redactFileName, e sempre no ato de eliminação (RN-GF-25). O sha256 fica na lápide como prova de integridade (§ Hash e referência). Critério de aceite: depois de cada um desses seis caminhos, GET /files/{id} devolve a lápide com originalFileName nulo.

A referência esperada só é declarada sobre registro em Pending que o mesmo chamador reservou (createdBy), no mesmo tenant, na confirmação pela IFileService — ou na própria gravação pela IServerFileStore, que cria o registro. Referência direta sobre Available é só do mesmo chamador que reservou, ou propagação a partir de uma referência ativa do mesmo ownerScope no mesmo arquivo, que o chamador nomeia. Fora disso — registro fora de Pending, reservado por outra pessoa, já esperado por outro dono, ou Available sem posse nem referência de origem — a resposta é FILE_REFERENCE_NOT_ALLOWED_CONFLICT (409) e nada muda; arquivo de outro tenant continua respondendo FILE_NOT_FOUND (RN-GF-08). A mesma confirmação repetida pelo mesmo chamador, com o mesmo dono, devolve o estado atual. Sem esta regra, o fileId que chega do cliente amarra ao documento de uma pessoa o arquivo que outra subiu, e o CanRead do dono verdadeiro fica contornado. Vale também para a leitura em processo: IServerFileStore.OpenReadAsync recebe, além do tenant, o dono que lê — o par (ownerScope, ownerKey) — e só devolve bytes se esse par tem referência ativa no arquivo (a esperada vira ativa na liberação, e antes dela não há conteúdo a ler); sem ela, FILE_REFERENCE_NOT_ALLOWED_CONFLICT (409) e nenhum byte lido. O escopo sozinho não basta: outro dono do mesmo escopo — outra notificação, outro relatório — já pode ter referência no arquivo. Sem isso, o módulo que recebe fileId de um chamador e lê o conteúdo no servidor entrega por e-mail, ou em qualquer saída sua, arquivo que o chamador nunca subiu. Critérios de aceite: (a) A reserva e sobe; B confirma o mesmo fileId declarando um dono seu → 409 e nenhuma referência nasce para B; (b) arquivo Available que A subiu, B pede referência direta sem referência de origem → 409; (c) segundo dono sobre registro já esperado → 409 com o código, nunca 500; (d) A repete a confirmação com o mesmo dono → o mesmo estado, nenhum efeito novo; (e) OpenReadAsync com um par sem referência ativa no arquivo → 409 e nenhum byte; (f) e-mail com anexo cujo fileId outra pessoa subiu, com ou sem persistência da notificação → recusado antes do envio, e nenhum byte sai.

POST /files/{id}/references e DELETE /files/{id}/references/{referenceId} só criam e liberam referência de ownerScope que o registro do escopo declara gerido pela superfície HTTP — nenhum, por padrão. Escopo de módulo que consome em processo (nexio.*, gryd.report-execution, gryd.notification-attachment) é recusado com FILE_OWNER_SCOPE_FORBIDDEN (403), na criação e na liberação, qualquer que seja a permissão; e a criação pela rota obedece à RN-GF-22. Sem isso, quem tem upload:files prende um arquivo para sempre com dono inventado — e a eliminação por titular esbarra numa referência que ninguém solta — ou libera a referência do documento de outro módulo e entrega o arquivo ao expurgo. Contrapartida no produto: produto que autoriza arquivo pelo dono — o Nexio — não mapeia /files/* e nenhum papel de tenant recebe upload:files, read:files, retain:files ou purge:files; a pessoa sobe e baixa pelas rotas do próprio produto, que chamam a IFileService depois do CanRead do dono. As quatro têm alcance de tenant no catálogo, e compor papel só barra permissão de plataforma — hoje o administrador do tenant as põe num papel. Que o produto possa impedir isso é requisito do catálogo da plataforma, e está na demanda. Critérios de aceite: (a) POST /files/{id}/references com ownerScope nexio.attachment → 403 e nenhuma referência; (b) DELETE de uma referência gryd.report-execution pela rota → 403 e a referência continua ativa; (c) no produto que autoriza pelo dono, nenhum papel de tenant — semeado ou composto pelo administrador do tenant — tem upload:files, read:files, retain:files ou purge:files, e a composição é recusada; e nenhuma rota /files/* responde nos hosts dele. Como o GrydAuth cumpre. A opção GrydAuth:Roles:TenantAssignable:Deny é de adesão (vazia por padrão — o produto que autoriza pelo dono a declara no appsettings) e age ao conceder: recusa a composição do papel, a atribuição, a concessão direta e a vinculação, e derruba a subida se um template do seed concede um código negado; não limpa papel composto antes de ligá-la (DEC-GF-07-1 a 07-3).

Registro Infected só é expurgado pela varredura quando valem todas: QuarantineRetentionDays contados do veredito positivo; retainUntil vencido, no modo RetainUntil; legalHold desligado; e modo diferente de Permanent (RN-GF-09). Vence o prazo mais tarde. A única exceção é o ato de eliminação a pedido do titular, com as conferências da RN-GF-25 — guarda de qualquer detentor continua recusando. A transição Available → Infected libera as referências ativas sem tocar em retentionMode, retainUntil nem legalHold, que já estão gravados no registro antes da liberação; liberar por infecção não encerra guarda nem inicia carência. O consumidor ainda pode estender retainUntil ou ligar legalHold sobre o Infected — a guarda, por ato de pessoa ou com o autor declarado (RN-GF-27); o handler do veredito, que roda sem usuário, não liga guarda (RN-GF-13). Sem isso, a prova sob guarda de um documento fechado some 365 dias depois de o re-scan achar uma assinatura nova. Critérios de aceite: (a) Infected há 400 dias com retainUntil daqui a três anos → não expurga, e expurga só depois da data; (b) Infected vencido com legalHold → não expurga; (c) Available com duas referências e retainUntil futuro, re-scan positivo → referências liberadas e retainUntil intacto no registro.

Expurgo manual de registro em RetainUntil com retainUntil futuro, ou de registro em Permanent, é recusado com FILE_RETENTION_NOT_EXPIRED_CONFLICT (409), a menos que o pedido seja o ato de eliminação: marcação explícita (erasure) e motivo obrigatório. Permanent não tem data que vença: fora do ato de eliminação não sai por caminho nenhum, nem com purge-permanent:files e um motivo qualquer. Estado. O expurgo manual sem a marcação alcança só Available. O ato de eliminação alcança também Infected — quarentena, inclusive incidente de integridade, antes de QuarantineRetentionDays e em qualquer modo — e Failed, com as mesmas conferências desta regra: o pedido do titular não espera a quarentena, que em RetainUntil dura até a data e em Permanent não vence. A prova do incidente que fica é a lápide — nome da assinatura ou rejectionCode, sha256 quando houver, as tentativas de varredura —; quem precisar dos bytes para perícia liga guarda legal por caso, e a guarda vence o titular. Pending e Scanning são recusados pelo estado (FILE_NOT_AVAILABLE_CONFLICT), e a consulta de pré-condição responde o mesmo, para o consumidor esperar. O expurgo automático da quarentena não muda (RN-GF-24). Quem pede a eliminação. Pela rota POST /files/{id}/purge, com purge:files; em Permanent, também com purge-permanent:files de pessoa no contexto (arquivo de produto: purge:product-files). Em processo, o consumidor registrado para o escopo (RN-GF-28), sem conferência de permissão: em RetainUntil, com o usuário autenticado ou o autor declarado (RN-GF-27); em Permanent, só com dupla custódia declarada — o pedido traz dois autores declarados, quem registrou o pedido e quem o executou, que precisam ser usuários diferentes (a comparação é por usuário: o módulo não conhece CPF nem conflito de interesse). Um autor só, ou os dois iguais, é recusado com FILE_ERASURE_DUAL_CUSTODY_CONFLICT (409), e a permissão de pessoa no contexto não substitui o segundo autor nesse caminho. Os dois autores são conferidos, não só comparados: cada um precisa ser usuário existente, ativo e do tenant do arquivo — id vazio, id que não existe, usuário inativo ou usuário de outro tenant é recusado com FILE_ERASURE_AUTHOR_INVALID_UNPROCESSABLE (422) antes de qualquer efeito. Em arquivo de produto, o tenant conferido é o de quem pede: arquivo de produto tem tenantId nulo (RN-GF-08) e usuário nenhum pertence a ele, de modo que exigir o tenant do arquivo não teria solução — nenhum autor passaria nunca. Nesse caso os dois autores são usuários do tenant do consumidor que pede, existentes, ativos, do mesmo tenant entre si e distintos, conferidos do mesmo jeito e com o mesmo código. Sem isso, dupla custódia é aritmética de dois guids diferentes, e um deles inventado. O tenant de quem pede é o tenant nomeado pelo consumidor (RN-GF-08): havendo tenant em vigor no contexto, o nomeado é igual a ele; não havendo — a repetição depois do commit roda sem request —, o escopo do nomeado é aberto antes da conferência. Pedido em processo que não nomeia tenant nenhum não tem contra o que conferir os autores e é recusado com FILE_ERASURE_AUTHOR_INVALID_UNPROCESSABLE, nada apagado. E em processo nenhuma permissão de módulo entra neste caminho. Pela rota, arquivo de produto continua exigindo purge:product-files de pessoa no contexto. Em processo, no ato de eliminação, a permissão não é conferida — ele é só de pessoa autenticada no contexto e nunca de autor declarado (RN-GF-28) —, e exigi-lo deixaria sem caminho justamente a repetição do job depois do commit, com os dois autores declarados e sem usuário. O que ocupa o lugar dele, onde não há tenant para separar quem alcança o quê, é a tríade da RN-GF-28 mais o vínculo: consumidor registrado para o escopo, dupla custódia declarada e ao menos um par do próprio escopo com referência ativa nomeado no pedido — eliminação em processo de arquivo de produto sem referência ativa do escopo de quem pede é recusada com FILE_OWNER_SCOPE_FORBIDDEN (403), porque sem tenant a referência é o único vínculo entre o consumidor e o arquivo. Com usuário no contexto, o executor é ele: o pedido nomeia como segundo autor declarado quem registrou o pedido, e esse autor declarado, diferente do usuário do contexto, não dá 401 — é a exceção declarada da RN-GF-27 (f). O executor gravado em purgedBy é o usuário do contexto, quem registrou vai em erasureRequestedBy e o ato fica gravado como autenticado. Sem usuário no contexto, os dois autores vêm declarados e o ato fica gravado como declarado (RN-GF-10). O expurgo grava os dois autores, o escopo que declarou e o executor de serviço (RN-GF-10). A eliminação apaga sempre o nome original e é ato de controle — registro isolado por tenant, gravado na transação do expurgo, com os autores, o motivo e a marcação (Ata B11; do lado do Nexio, é o ato "revogar para eliminação" do Anexo). Sem trilha durável não há eliminação: com a trilha padrão (NullAuditStore) o ato não teria registro, e é recusado com FILE_AUDIT_TRAIL_UNAVAILABLE (503), nada apagado. Referência ativa de outro dono (FILE_STILL_REFERENCED_CONFLICT) e guarda de qualquer detentor (FILE_LEGAL_HOLD_CONFLICT, RN-GF-27) recusam também a eliminação: a guarda legal vence o pedido do titular. O pedido em processo nomeia a lista de pares do próprio escopo — o ownerScope do consumidor e um ou mais ownerKey —, porque arquivo propagado tem mais de um par do mesmo escopo e liberar um só nunca chegaria a expurgar: as referências ativas de todos os pares nomeados são liberadas na mesma transação do expurgo e nenhuma conta como impedimento. Referência ativa de outro escopo continua recusando (FILE_STILL_REFERENCED_CONFLICT); referência ativa do próprio escopo que a lista não nomeia recusa igual — é o consumidor que diz quais cópias o pedido alcança; e par de outro escopo nomeado na lista é recusado com FILE_OWNER_SCOPE_FORBIDDEN (403, RN-GF-28). Arquivo referenciado por dois escopos não tem caminho automático — e na v1 não ocorre. Cada consumidor só nomeia os pares do próprio escopo, e a referência ativa do outro escopo recusa: dois consumidores com referência ativa no mesmo arquivo e um pedido de eliminação do titular é impasse, porque nenhum dos dois libera a referência do outro e o módulo não coordena os dois. Na v1 o caso não ocorre — o Nexio é o único consumidor de escopo de anexo —, e o que fica escrito é o risco conhecido: a recusa é FILE_STILL_REFERENCED_CONFLICT, não há caminho automático, e a saída é cada consumidor liberar a sua referência pelo seu próprio ato. Quando entrar o segundo consumidor de escopo, a coordenação entre consumidores é pedido de plataforma. Toda recusa vem antes de qualquer efeito — nenhuma referência liberada, nome apagado ou registro de ato —, mas a tentativa recusada do ato de eliminação vai à trilha, com o código, os autores e os detentores da guarda quando houver: o job que repete o ato e é recusado todos os dias não pode ficar sem rastro nenhum. A consulta de pré-condição não tem efeito e não gera tentativa. Pré-condição conferível antes de gravar: a IFileService responde em processo, sem efeito nenhum, se aquela eliminação seria aceita agora — com as mesmas conferências, na mesma ordem, e o mesmo código que o expurgo daria — no modo execução, que é o que confere tudo (estado, marcação e motivo, dupla custódia, referência de outro dono, guarda de qualquer detentor, trilha durável); no modo registro as conferências são o subconjunto do parágrafo seguinte —, para o consumidor conferir antes de gravar o próprio ato e nunca publicar eliminação que o módulo vai recusar. A consulta tem dois modos, e o modo vem no pedido. No modo registro — chamado antes de gravar o pedido, quando só existe quem está registrando — ela confere tudo menos a presença do segundo autor: estado, marcação e motivo, o autor ou os autores que vierem (existentes, ativos e do tenant conferido), a lista de pares, referência de outro escopo, guarda de qualquer detentor e trilha durável; a falta do segundo autor não é recusa, e FILE_ERASURE_DUAL_CUSTODY_CONFLICT não sai por ela nesse modo. Se os dois autores vierem já no registro, os dois são comparados, e dois autores iguais respondem FILE_ERASURE_DUAL_CUSTODY_CONFLICT também no modo registro: o que o modo dispensa é o segundo autor que ainda não existe, nunca a igualdade de dois que já vieram — responder aceite a um pedido que já se sabe recusável faria o consumidor gravar um pedido que o expurgo recusa depois. No modo execução — chamado antes de executar, com os dois autores já conhecidos — ela confere tudo, dupla custódia inclusive. Um modo só não serve: conferir a dupla custódia no registro recusaria todo pedido de titular, e não conferi-la na execução deixaria o consumidor publicar eliminação que o expurgo recusa. A consulta não reserva nada: guarda ligada por outro detentor entre a consulta e o expurgo vence, o expurgo responde FILE_LEGAL_HOLD_CONFLICT e o consumidor trata o pedido como bloqueado, nunca como concluído. Ordem das recusas. A guarda é conferida antes da referência (DEC-GF-19-7); só importa quando as duas recusas valem juntas. Critérios de aceite: (a) expurgo sem a marcação, com retainUntil futuro → 409 e nada apagado; (b) com a marcação e o motivo → Purged, originalFileName nulo e o ato na trilha com autor e motivo; (c) eliminação com referência ativa de outro dono → FILE_STILL_REFERENCED_CONFLICT; (d) arquivo Permanent expurgado sem a marcação, com purge-permanent:files e motivo → 409 e nada apagado; (e) eliminação com a trilha padrão registrada → 503 e nada apagado; (f) eliminação de Permanent em processo com um autor declarado só, ou com quem registrou igual a quem executou → FILE_ERASURE_DUAL_CUSTODY_CONFLICT, nada apagado, a referência do par ativa e nada na trilha; (g) eliminação de Permanent em processo, sem usuário no contexto, com dois autores diferentes → Purged, lápide com Declared, quem executou em purgedBy, quem registrou em erasureRequestedBy, escopo e executor de serviço, e nenhuma permissão conferida; (h) eliminação sobre arquivo com guarda de qualquer detentor — do consumidor, de outro consumidor ou da plataforma — → FILE_LEGAL_HOLD_CONFLICT antes de qualquer efeito: referência do par ativa, nome intacto, nenhum registro de eliminação; (i) no modo execução, para cada caso de (a) a (h), a consulta de pré-condição com o mesmo pedido responde o mesmo código, ou o aceite, e não grava nada; no modo registro vale o mesmo para (a) a (e), (g) e (h), e o caso (f) responde o aceite quando o pedido não traz o segundo autor, porque nesse modo ele ainda não existe (m) — vindo os dois autores e iguais, o código sai também no modo registro (s); (j) Infected em quarentena há dez dias, em RetainUntil com data daqui a cinco anos, eliminação com a marcação, o motivo e os autores → Purged, lápide com a assinatura e o sha256, sem nome original; o mesmo pedido sem a marcação → recusado pelo estado e nada apagado; (k) Infected em Permanent com dois autores diferentes → Purged; com guarda de qualquer detentor → FILE_LEGAL_HOLD_CONFLICT; (l) Scanning → FILE_NOT_AVAILABLE_CONFLICT no expurgo e na consulta; (m) consulta no modo registro com um autor declarado só → responde o aceite, e a mesma consulta no modo execução → FILE_ERASURE_DUAL_CUSTODY_CONFLICT; (n) eliminação em processo com usuário no contexto e o autor do registro declarado, diferente dele → Purged, purgedBy o usuário do contexto, erasureRequestedBy o autor do registro, ato gravado como autenticado e nenhum 401; (o) eliminação com um dos dois autores inexistente, inativo ou de outro tenant → FILE_ERASURE_AUTHOR_INVALID_UNPROCESSABLE, nada apagado e nenhuma referência liberada; (p) arquivo com dois pares do mesmo escopo e a lista nomeando os dois → Purged com as duas referências liberadas na mesma transação; a mesma eliminação com a lista nomeando um par só → FILE_STILL_REFERENCED_CONFLICT e nada apagado; (q) tentativa recusada do ato de eliminação → a trilha registra a tentativa com o código, e nenhuma referência foi liberada — quando a recusa é sobre o que prende o arquivo (vínculo do produto, guarda, referência) e depois de os autores serem conferidos; recusa de pedido (autor, motivo, contrato), de estado, de marcação ou de trilha não grava linha, e o (f) é a exceção declarada (DEC-GF-19-4); (r) eliminação de arquivo de produto (tenantId nulo) com dois autores distintos do tenant do consumidor que pede → Purged; a mesma com um dos autores de outro tenant → FILE_ERASURE_AUTHOR_INVALID_UNPROCESSABLE e nada apagado; a mesma em processo, sem usuário no contexto e sem nenhuma permissão em lugar nenhum, com o tenant do consumidor nomeado e um par do próprio escopo com referência ativa na lista → Purged; em processo sobre arquivo de produto sem referência ativa do escopo de quem pede → FILE_OWNER_SCOPE_FORBIDDEN e nada apagado; pela rota, sem purge:product-files de pessoa no contexto → 403 e nada apagado; (s) consulta no modo registro com os dois autores já no pedido e iguais → FILE_ERASURE_DUAL_CUSTODY_CONFLICT e nada gravado; o mesmo pedido sem o segundo autor → aceite.

Pela IFileService, reservar, confirmar, emitir URL de download, expurgar e ligar ou desligar legalHold exigem autor identificado: o usuário autenticado no contexto — ou, só para ligar e retirar guarda e para a eliminação, o autor declarado na chamada em processo (RN-GF-27), gravado sempre como declarado e nunca como autenticado (RN-GF-10). A consulta de pré-condição da eliminação (RN-GF-25) aceita os mesmos autores nos seus dois modos — no modo registro, com o autor que está registrando só — e não grava nada. Sem usuário no contexto e sem autor declarado, a operação é recusada com FILE_CALLER_UNAUTHORIZED (401) antes de qualquer efeito — nunca exceção sem código, nunca registro, guarda desligada ou trilha sem autor. Ler metadado (GetAsync) não exige usuário: é por ela que o handler do veredito relê fora de request (RN-GF-13). Conteúdo que o servidor gera ou recebe sem pessoa do outro lado entra pela IServerFileStore. Critério de aceite: ReserveAsync e GetDownloadUrlAsync chamados sem usuário → 401 com o código, nenhum registro criado e nenhuma URL emitida; desligar legalHold sem usuário e sem autor declarado → 401 e a guarda continua ligada; GetAsync sem usuário e com tenant → devolve o registro.

Guarda por detentor. legalHold é derivado: ligado enquanto houver ao menos um detentor com guarda ativa. Detentor é o consumidor registrado que ligou a guarda em processo, pelo seu ownerScope (RN-GF-28), ou a plataforma, que liga pela rota PUT /files/{id}/retention. Cada detentor liga e retira a sua guarda, e só a sua: há no máximo uma guarda ativa por detentor, com autor, tipo de autor, motivo e quando. O módulo não conta casos — o consumidor que tem vários casos sobre o mesmo arquivo retira a sua guarda quando o último caso dele acaba. Ligar sobre a guarda de outro detentor acrescenta a sua e nunca troca nem apaga a do outro: ligar em processo sobre a guarda da plataforma deixa as duas ativas, e PUT legalHold: true sobre a guarda de um consumidor também. O mesmo detentor repetindo o mesmo ato não produz efeito novo, e a guarda já ativa mantém autor e motivo originais. Quem retira. Em processo, o consumidor retira a guarda do seu escopo sem release-hold:files — é o fim de um ato por caso que ele autorizou e registrou do lado dele (Ata B13) —; retirar quando o seu escopo não tem guarda ativa sobre registro vivo não produz efeito e devolve o estado atual, para a repetição do ato concluir; sobre registro que o expurgo já venceu, a retirada é recusada com FILE_PURGED_CONFLICT (RN-GF-20). Pela rota, legalHold: false retira a guarda da plataforma e exige release-hold:files; sobre arquivo cuja guarda restante é só de consumidor, é recusado com FILE_OWNER_SCOPE_FORBIDDEN (403) e nada muda — nenhuma permissão retira a guarda de outro detentor. A resposta da guarda e a recusa de expurgo listam os detentores ativos. O autor viaja como dado, e marcado. Ligar e retirar guarda e a eliminação (RN-GF-25), chamados em processo, aceitam o autor declarado — o usuário que praticou o ato já gravado pelo consumidor —, para que a repetição depois do commit, que roda sem usuário, conclua. O autor declarado não é identidade: não concede permissão, não habilita nenhuma outra operação e não existe na rota HTTP, onde o autor é sempre o usuário autenticado. A trilha e a lápide distinguem autor autenticado de autor declarado e, no declarado, gravam o escopo que o declarou e o executor de serviço que chamou — o job ou serviço do consumidor, também declarado por ele (RN-GF-10). Com usuário no contexto, o autor declarado, se vier, precisa ser ele — diferente → FILE_CALLER_UNAUTHORIZED (401) — e o ato fica gravado como autenticado. A eliminação com dupla custódia é a exceção declarada (RN-GF-25): ela leva dois autores, e com usuário no contexto ele é o executor; o outro autor — quem registrou o pedido — vem declarado e é diferente dele, sem 401. A exceção é só essa, e só para o autor do registro: qualquer outro autor declarado diferente do usuário do contexto segue 401. Conferir antes, registrar junto. Escopo, autor e trilha são conferidos antes de qualquer mudança, e recusa não deixa guarda retirada nem registro sem autor. Ligar e retirar são ato de controle (Ata B11): os dois vão à trilha, com o registro gravado na mesma transação da mudança, nunca depois do commit. Retirar exige a trilha durável da RN-GF-25 (FILE_AUDIT_TRAIL_UNAVAILABLE, 503); ligar nunca é recusado por falta de trilha, porque recusar deixaria a prova sem guarda. Onde a guarda vale. Ligar guarda é aceito em Available e Infected, únicos estados em que toda purga a honra; em Pending, Scanning e Failed a resposta é FILE_NOT_AVAILABLE_CONFLICT (409) (DEC-GF-18-1). Critérios de aceite: (a) o consumidor liga a guarda por ato de pessoa e a repetição depois do commit chama sem usuário, com o autor declarado → guarda do escopo ativa, trilha com o autor marcado como declarado, o escopo e o executor de serviço, nenhum 401; (b) o mesmo escopo retira em processo, sem release-hold:files, com o autor declarado → a guarda dele sai e a trilha registra o autor declarado; (c) PUT /files/{id}/retention com legalHold: false sobre arquivo só com guarda de consumidor, mesmo com release-hold:files → 403 e a guarda continua; (d) eliminação repetida sem usuário, com o autor declarado → Purged, lápide e trilha com o autor declarado, o escopo e o executor; (e) retirar sem usuário e sem autor declarado → 401 e nada gravado; (f) usuário no contexto e autor declarado diferente → 401 e nada gravado, menos na eliminação da RN-GF-25, onde o autor do registro vem declarado e diferente do usuário do contexto, que é o executor → aceita, sem 401, com o executor em purgedBy; (g) guarda da plataforma ativa e o consumidor liga em processo → as duas ativas; a plataforma retira pela rota → legalHold continua ligado pela guarda do consumidor, e o expurgo responde FILE_LEGAL_HOLD_CONFLICT; (h) guarda de consumidor ativa e PUT legalHold: true → as duas ativas; o consumidor retira a dele → legalHold continua ligado pela guarda da plataforma; (i) dois consumidores com guarda no mesmo arquivo e um retira → o arquivo continua preso pelo outro; (j) processo derrubado logo depois do commit de ligar ou de retirar → o registro do ato está na trilha.

A IFileService e a IServerFileStore são chamadas em processo por módulo consumidor que já autorizou o seu chamador. Nelas permissão de módulo não é conferida — upload:files, read:files, retain:files e purge:files são policies da superfície HTTP —, e o módulo não define identidade de serviço: nenhum job ou serviço "carrega" permissão para chamar a porta. O que vale em processo são três coisas: (1) consumidor registrado — todo ownerScope que chega à IFileService, na referência esperada, na referência direta, na guarda e na eliminação, só é aceito do consumidor registrado para ele (o mesmo registro do contrato de veredito, RN-GF-13), como a RN-GF-06 (b) já exige para a IServerFileStore; escopo sem registro é recusado com FILE_OWNER_SCOPE_FORBIDDEN (403) antes de qualquer efeito; (2) o ato — posse, guarda e eliminação (RN-GF-22, RN-GF-25, RN-GF-27); (3) o autor declarado marcado (RN-GF-10, RN-GF-27). A permissão específica (*:product-files, release-hold:files, purge-permanent:files) é conferida só onde esta página a nomeia e só de pessoa autenticada no contexto — arquivo de produto, guarda da plataforma, eliminação de Permanent pela rota —; nunca de autor declarado, nunca de serviço. Sem o item (1), qualquer assembly do processo que passe nexio.attachment retira a guarda do Anexo ou pede a eliminação de um anexo, e não há permissão nenhuma para barrar. E o escopo deixa de ser parâmetro de quem chama. O problema é que escopo passado como texto não se prova por teste: os escopos são constantes de compilação, o compilador as embute em cada chamador e nenhum teste de dependência entre assemblies vê quem passou nexio.attachment — a asserção “só o consumidor registrado passa o escopo” é inverificável enquanto o escopo for argumento. E porta alcançada por texto ou por Type repete o mesmo defeito um nível acima: se a porta de um escopo se resolve por chave de texto, por Type montado em execução ou por reflexão — IServiceProvider.GetService(Type) —, quem resolve também não deixa dependência entre assemblies, e nenhum teste estático vê quem pegou a porta de nexio.attachment. E o caminho não se fecha olhando só o escopo sem registro: o mesmo Type montado em execução carrega o tipo-marca de um escopo registrado — o nome do tipo em texto, resolvido por reflexão — e o contêiner devolve a porta, sem que o assembly que pediu referencie o do consumidor; verificação que se limite a escopo sem registro não alcança esse pedido, e o teste estático continua sem vê-lo. O padrão já existe no repositório do framework (JobExecutionAdapters.cs:235, :303 e HangfireJobActivator.cs:43, no HEAD e4eb5a4f) — não é hipótese. O requisito: o registro do consumidor devolve a ele uma porta amarrada ao seu escopo, e é por essa porta que ele reserva, confirma, declara referência, liga e retira guarda e pede eliminação; nas assinaturas dessa porta o escopo não aparece, e a porta sem escopo deixa de ser alcançável pelo consumidor. A porta de cada escopo só se resolve por um tipo-marca do próprio consumidor — um tipo que mora no assembly registrado para o escopo, de modo que resolver aquela porta obrigue a referenciar esse assembly e a dependência apareça; chave de texto e Type montado em execução não resolvem porta de escopo nenhum. Como a plataforma amarra o escopo à porta, e por qual mecanismo o tipo-marca chega ao registro, é decisão dela (Ata A1) — a spec pede o efeito, não a forma. O que o teste de arquitetura confere muda junto: não quem passa o texto, mas quem resolve a porta de cada escopo — os assemblies que resolvem a porta de nexio.attachment são exatamente o consumidor registrado para ele; produto que registra escopo repete a asserção no próprio repositório. Critérios de aceite: (a) assembly fora do registro que resolve a porta do escopo nexio.attachment → o teste de arquitetura falha, e continua falhando se esse assembly declarar a mesma constante de escopo por conta própria — o teste olha a resolução da porta pelo tipo-marca do consumidor, não o texto, e a resolução por reflexão não escapa dele, porque não devolve porta nenhuma (e); (b) chamada em processo com ownerScope sem registro → 403 e nada gravado; (c) eliminação completa em processo, sem usuário e sem purge:files em lugar nenhum → aceita; a mesma pela rota, por usuário sem purge:files → 403; (d) nenhuma assinatura da porta entregue ao consumidor tem parâmetro de escopo, e o consumidor não alcança, por caminho nenhum, uma porta em que o escopo seja argumento; (e) em execução, falha — na resolução quando o contêiner distingue o pedido, e na primeira chamada quando o pedido é por Type montado em execução, porque o contêiner devolve o mesmo Type nos dois casos e a porta confere, a cada chamada, que o assembly chamador referencia o do tipo-marca (DEC-GF-09-1) — e nenhuma chamada chega à IFileService com aquele escopo — em dois casos: pedir ao contêiner a porta de um escopo não registrado, por tipo-marca de quem não registrou, por chave de texto ou por Type montado em execução; e pedir a porta de um escopo registrado — nexio.attachment — por Type montado em execução, por tipo-marca obtido em execução ou pelo tipo-marca de quem não registrou aquela porta, que é o pedido sem referência estática ao assembly do consumidor: é a verificação que o teste estático não dá, porque o que ela reprova não aparece como dependência entre assemblies.