compras/docs/decisao-instalacao-sgf.md

Decisão de instalação da integração de requisições no SGF

Estado posterior de desenvolvimento: candidata 040fb0cb67a77d61 acrescenta consultas/cotações/adjudicação ao módulo, com testes completos em cópias e preparação parcial em 8039. Relatório e hashes actuais. Existe extensão de schema própria; os planos anteriores de instalação real abaixo não se aplicam automaticamente à nova candidata. Não há autorização de instalação real, DCL, contas ou configuração Tempo. SGF real mantém 0.1.1. A confirmação da adjudicação na demonstração permanece pendente por decisão de não criar quarta identidade, sem alterar mínimos ou independência.

Estado posterior — apenas demonstração 8039: correcção de leitura incorporada na sucessora OPERATIONAL-CANDIDATE-166e397e3ca63f02, manifesto 166e397e3ca63f02d3dc57651c8eecf50e1fc314410c78e05386b518d3a661de, ZIP SHA-256 620660d76329c800f3c6b18a521c03ccdadce09502d2a7744e1e91b77560f785. Entrega e matriz actualizadas. Nenhuma instalação real autorizada ou executada: SGF real permanece 0.1.1. Planos/IDs do destino real e da candidata anterior abaixo são históricos e não autorizam aplicar esta sucessora; devem ser reconferidos se a implantação real voltar a ser solicitada.

Candidata corrigida — decisão actualizada em 02/11/2026

Preparação técnica concluída em isolamento; nenhuma instalação ou alteração de acessos autorizada no destino. Esta secção sucede à proposta histórica abaixo. O SGF permanece em 0.1.1. A recomendação passa a ser rever esta candidata para uma futura instalação técnica inicialmente desactivada; não há bloqueante de código conhecido no percurso básico ensaiado. A autorização da operação, o backup/restauro dos dados reais e a aprovação das alterações SQL continuam indispensáveis antes de executar.

Identificação	Valor conferido
Destino	C:\laragon\www\sgf-tempo; URL http://127.0.0.1:8000
Base/ligação normal	sgf_tempo_dev, PostgreSQL 127.0.0.1:55432, runtime sgf_dev_app
Candidata corrigida	OPERATIONAL-CANDIDATE-401ce31ae5f2dd20 — identificação por conteúdo, não activação de 0.1.2
ZIP privado	storage/app/private/candidate-archives/OPERATIONAL-CANDIDATE-401ce31ae5f2dd20.zip na origem Compras
SHA-256 ZIP	59dbdc64c4d9f14dfb4025a6177b829d136a4e2cb633ca036b10b5ae3197e703
SHA-256 manifesto	a6478223e17a5430652f0fcbf31a44a931ae2a99cd90b151c98d2df5df43c10b
Plano de código, destino	d29833b1c48b9d666522d20d87040d5ad30370cf114c9a70f272cd041eea59e9
Plano de schema, destino	169e6e863f28b67740f07b6e7cbc664fbe585a7760a83dccebc8d482ad8ab792
ID de aplicação previsto	a6478223e17a5430652f0fcb — usar sempre o ID efectivamente devolvido

Dependências, configuração e permissões

A migração passa à revisão 2, com 16 tabelas novas: as 14 anteriores mais cb_ui_commands e cb_consumption_sources. Inclui constraints e histórico imutável. Mantém o alargamento e o CHECK do catálogo de permission_grants, preservando dados e direitos anteriores. Não executa a migração 46 de Compras. Tabelas preexistentes incompatíveis ou uma revisão 1 anterior exigem reconciliação explícita, não são sobrescritas. Neste destino não existe nenhuma dessas tabelas.

O ecrã /purchasing/internal-requisitions/budget-setup permite criar centros e preparar/aprovar dotações com os serviços orçamentais existentes. Campos de valores/ano começam vazios; não existem centros, dotações, contas ou concessões sintéticas no pacote. Criar centro exige purchasing_requisitions.configure e purchasing_budget.create; dotações mantêm autorização e aprovação independente. Movimentos genéricos/consumo fora do percurso de requisição estão fechados nesta composição. O catálogo administrativo inclui os direitos e rótulos vindos do servidor, com frontend compilado no pacote; delegação indevida e consulta sem gestão são recusadas. Instalar não outorga direitos funcionais.

Ligação migradora: usar sgf_dev_owner (ou principal DBA autorizado equivalente) exclusivamente no processo CLI migrador, com CONNECT à base, USAGE/CREATE no schema e autoridade de proprietário para alterar permission_grants, criar tabelas, constraints, sequências, funções e triggers. Não requer superutilizador, criação de bases/roles ou promoção do runtime. As credenciais devem ser fornecidas por canal privado ao processo, nunca no ZIP, argumentos, logs ou .env persistente. Se existir cache de configuração, invalidá-lo na janela aprovada e conferir current_database()/current_user antes do DDL; variáveis de ambiente não substituem silenciosamente um cache privilegiado. O runtime continua com a sua ligação habitual.

O plano SQL exacto proposto para sgf_dev_app não foi aplicado. Contém GRANT e REVOKE apenas nos 16 novos objectos/sequências: SELECT em todos; INSERT nos cadastros/comandos/históricos necessários; UPDATE apenas em cb_budgets, ir_requests, ir_steps, ir_policies; USAGE apenas nas sequências com INSERT. Sem DELETE/TRUNCATE, UPDATE de históricos, ownership, CREATE ou alteração global de default privileges. Remove ACLs directas mais amplas herdadas dos defaults e de PostgreSQL PUBLIC nesses novos objectos; não altera direitos públicos funcionais nem as 87 tabelas existentes. Conferir também pertenças/inheritance e privilégios efectivos: outra role herdada pode exigir proposta adicional. Qualquer execução efectiva desse plano, incluindo revogações, exige confirmação separada. Não é executado pelo instalador.

Classificação actual das pendências

Elemento	Decisão actual
Duas tabelas em falta	Resolvido na candidata, incluídas na migração revisionada e no restauro verificado.
Centros/dotações	Implementado e ensaiado pela interface/API. Valores reais e aprovação da empresa continuam pendentes para activação; não presumidos.
Catálogo administrativo	Implementado, compilado e ensaiado, ainda não instalado nem com direitos atribuídos no destino.
SQL migrador/runtime	Mapa e separação ensaiados. Confirmar operador/ligação e alterações SQL reais antes da instalação; não há concessão automática.
Equipamentos/peças	Fora do âmbito, rejeitados no servidor. Não bloqueiam consumíveis, serviços e outros; não converter tipos para contornar essa exclusão.
Navegação modular	Aceitação técnica anterior reutilizada; entrada, selecção de módulo e assets desta composição conferidos na reprodução. Revisão visual, associações antigas e volume continuam separados.
Dois administradores/configuração real	Pendentes para entrega/activação. Não criar nem promover utilizadores automaticamente.
Contratações para terceiros	Excluídas do SGF; nenhuma introduzida nesta candidata.

Prova nova e limites

Prova da candidata corrigida: 157 controlos aprovados (incluem conferência individual das ACLs das 87 tabelas anteriores), usando cópia do código actual e exportação só de estrutura, sem contas/dados reais importados. A migração produziu 103 tabelas na base descartável; owner e runtime eram roles distintas, restritas e sintéticas. Foram ensaiados falha transaccional de migração, instalação vazia, centros/dotações, três tipos básicos, reserva, identidade independente, histórico/consulta, revogação, contexto forjado, navegação, catálogo/compilação frontend, proibições DDL/DML, actualização e reversão de código. O restauro em segunda base reconciliou 103 impressões digitais de tabelas, schema/triggers, origem, decisão e reserva, incluindo acesso pelo runtime sem DDL. Bases e roles de teste foram removidas.

As provas anteriores de concorrência, adaptadores, caches e navegação modular permanecem válidas e não foram repetidas integralmente. Esta reprodução não é backup/restauro dos dados reais do SGF, nem aprovação visual integral ou entrega comercial de todos os módulos. O destino foi lido para schema/metadados e reconferido: permissões/pertenças/auditoria, estrutura e ponteiro preservados.

Procedimento exacto proposto — não executar sem confirmação

1. Extrair o ZIP para pasta privada de staging no próprio destino; conferir os hashes acima, manifesto e os dois planos de leitura. Nenhuma instalação cliente depende da pasta Compras. Repetir planos imediatamente antes da janela: divergência exige reconciliação. Não executar comandos a partir de outro bundle antigo.
2. Pelo procedimento DBA autorizado, guardar backup integral custom de somente sgf_tempo_dev, código/configuração, documentos externos e ACLs, com hash e corte registados, em pasta privada fora da raiz web. Ensaiar esse backup real numa base nova e conferir ownership, ACLs, constraints/triggers, contagens/digests e arranque restrito. pg_restore --list não basta. Não parar o cluster 55432 nem usar sgf.ps1 stop.
3. Na janela aprovada, colocar apenas este projecto em manutenção e parar os seus escritores. Executar plan e migrate com a ligação migradora temporária. Aplicar somente o plano SQL expressamente confirmado, numa transacção própria; conferir privilégios efectivos e preservação das ACLs anteriores. Voltar ao runtime para as verificações normais.
4. Aplicar código com o manifesto e plano de código reconferidos; registar o ID retornado. Recompilar caches nativos com o runtime, preservando a configuração operacional desactivada. Conferir arranque e inacessibilidade das operações desactivadas. Não alterar packages/purchasing/current.json, atribuir direitos, preencher valores ou activar âmbitos nesta operação.
5. Comandos parametrizados (executar através do PHP fixado do SGF; <B> é o staging extraído, <H> o destino acima; restantes valores vêm dos planos/backup/operador, nunca são presumidos):

php <B>/scripts/sgf-internal-install.php plan <H>
php <B>/scripts/sgf-internal-install.php privileges-plan <H> sgf_dev_app
php <B>/scripts/sgf-internal-install.php migrate <H> <schema-target-sha> <backup-file> <backup-sha> <operator> <manifest-sha>
php <B>/scripts/sgf-code-deploy.php plan <H> <B> <manifest-sha>
php <B>/scripts/sgf-code-deploy.php apply <H> <B> <manifest-sha> <code-target-sha> <operator> --offline
php <B>/scripts/sgf-code-deploy.php cache <H> <deployment-id> <operator> --offline

6. Falha de migração: rollback transaccional; se resultado do commit for incerto, inspeccionar ledger/assinatura antes de retry. Falha de aplicação/caches: manter manutenção, php <B>/scripts/sgf-code-deploy.php rollback <H> <deployment-id> <operator> --offline, conferir hashes e reconstruir os caches da versão reposta quando aplicável. Na primeira instalação, regressar ao host sem bundle; não inventar versão anterior. A reversão de código preserva schema, dados e ACLs e não os recupera.
7. Falha de dados/schema: preservar estado falhado; restaurar o backup para outra base, reconciliar operações posteriores ao corte, revogações e documentos, conferir com runtime restrito e decidir separadamente a troca de ligação/caches. Não executar down, apagar tabelas ou restaurar por cima da base activa. Mudança de base exige novo fingerprint operacional. Direitos SQL não são revertidos indiscriminadamente com o código.

Próxima decisão do proprietário: confirmar ou recusar uma operação concreta de instalação técnica desactivada, incluindo ligação migradora e plano SQL. Não foi pedida nem inferida essa confirmação nesta preparação. Activação funcional e configuração real ficam para decisão própria.

---

Registo histórico anterior — sucedido pela candidata corrigida acima

Data: 02/11/2026. Estado: proposta para decisão; instalação não autorizada nem executada.

Recomendação concreta

Não confirmar ainda a instalação desta candidata como percurso operacional. Os mecanismos e provas isoladas permanecem válidos, mas a conferência do destino revelou lacunas de implantação que esses ensaios com roles proprietárias e cadastros sintéticos não cobriam: ligação de migração/privilégios SQL da aplicação e preparação operacional de centros/dotações pela interface.

A operação futura proposta é instalação técnica de schema e código, inicialmente desactivada, no destino abaixo, sem outorga automática de direitos, sem dados de Compras e sem mudar o pacote activo 0.1.1. Antes de pedir a confirmação dessa operação, fechar o plano de privilégios e de recuperação do destino. A disponibilização aos utilizadores exige ainda resolver o cadastro/orçamento e a configuração nominativa. Não há autorização para executar migrate, apply, cache, concessões, manutenção ou paragem/reinício de serviços nesta decisão.

Destino conferido, não uma instalação genérica

Elemento	Valor
Projecto SGF local	C:\laragon\www\sgf-tempo
URL configurada	http://127.0.0.1:8000 — não é publicação num domínio
Ambiente/PHP	local; PHP 8.4.27 pelo wrapper do SGF
Base efectiva	PostgreSQL sgf_tempo_dev, 127.0.0.1:55432
Role da aplicação	sgf_dev_app — sem CREATE no schema public e sem autoridade para ALTER em permission_grants
Proprietário existente da tabela de permissões	sgf_dev_owner — LOGIN e CREATE em public confirmados; credenciais não consultadas nem registadas
Estado anterior	87 tabelas public; fundação de identidade presente; nenhum cb_*, ir_* ou sgc_installations da candidata
Configuração de integração	Bundle/ficheiro operacional ausentes; manutenção inactiva; configuração Laravel não compilada no instante da leitura
Pacote instalado de Compras	0.1.1, ponteiro SHA-256 81899e531e9eec449717e694d8bdc106a9e220a828f5491ce918c1d2dc612787
Revisão Git SGF observada	fcf0ada22701337acd4c84b404207b8400f490a2; não substitui a conferência dos ficheiros locais em curso

Inventário por transacção PostgreSQL READ ONLY, sem migrar: prova da decisão. As contagens/impressões digitais preservadas incluem 89 concessões, duas pertenças e 162 eventos de auditoria. Há uma empresa, uma unidade e uma concessão de administração da empresa; não foram enumerados nomes, emails ou credenciais. A base sgf_tempo_test, a instância modular isolada em 8039/cluster 55439 e as demonstrações anteriores não são este destino e não podem ser reiniciadas/resetadas por arrasto.

O registo antigo de processo web não foi tomado como confirmação de processo actualmente activo. Na janela futura, conferir o PID/executável/instante de arranque e vinculação ao projecto antes de actuar. Não usar sgf.ps1 stop indiscriminadamente: esse comando também pára o cluster PostgreSQL 55432, partilhado com outras bases.

Candidata exacta e planos de leitura

Referência	Valor
Identidade da candidata	OPERATIONAL-CANDIDATE-5fae7cf7f99c42ba — versão identificada por conteúdo, não 0.1.2
Directório	C:\laragon\www\compras\storage\app\private\candidates\OPERATIONAL-CANDIDATE-5fae7cf7f99c42ba
ZIP	C:\laragon\www\compras\storage\app\private\candidate-archives\OPERATIONAL-CANDIDATE-5fae7cf7f99c42ba.zip
SHA-256 ZIP, reconferido	d14a3261d5aaab80f96250af781c700ab53376021f4638e3aee43c15ff37ceed
SHA-256 manifesto	b1ec47f7a9ad87e0b232bac41e402d4a00ee5f03f00a79b93effc692ce8b39a2
Impressão de destino do plano de código	bab719ee4e08555a8e1de694dd3a93df82680c7aba653613f0714dd76e4065d6
Impressão de destino do plano de schema	169e6e863f28b67740f07b6e7cbc664fbe585a7760a83dccebc8d482ad8ab792
ID previsto de primeira aplicação	b1ec47f7a9ad87e0b232bac4 — reconfirmar no retorno real da CLI

Os dois comandos plan passaram no destino e só leram/conferiram estado. Isso não executa nem valida a capacidade de escrever DDL com a role runtime, e schema_prepared=false. Os hashes são uma fotografia: repetir os planos de leitura imediatamente antes de uma operação aprovada; divergência impede usar esta decisão antiga como autorização para sobrescrever o destino.

Alterações previstas, sem efeitos já aplicados

Código: criar o bundle local packages/internal-requisitions; aplicar sobreposições conferidas apenas a Permissions.php, IdentityWorkflow.php, BudgetAdapter.php, AppServiceProvider.php e ModuleNavigation.php. Guardar backups/journal em storage/app/private/module-deployments; tratar os caches padrão. Preservar restantes ficheiros/trabalho local. Não alterar packages/purchasing/current.json, activar 0.1.2, publicar ou copiar a base de Compras.

Schema, revisão 1: acrescentar 14 tabelas: sete cb_* (centres, origins, budgets, budget_entries, budget_consumptions, budget_reinforcements, audit), seis ir_* (requests, steps, events, commands, policies, policy_versions) e sgc_installations. Sem dados sintéticos iniciais. Alargar permission_grants.permission de 40 para 100 e estender o CHECK unitário com os novos valores, preservando a expressão e os registos anteriores. Acrescentar FKs, unicidade e triggers de origem/versão/aprovação independente/histórico imutável. Os dados e decisões existentes não são classificados nem reescritos. A migração 46 de Compras não é aplicada no SGF.

Permissões funcionais: o catálogo candidato acrescenta seis direitos de requisição (view, prepare, configure, approve.department_head, approve.procurement, approve.finance) e os sete direitos do orçamento comum já desenvolvido. A criação de unidades continua a conceder apenas unit.view/unit.edit. Instalar o catálogo não concede nenhum novo direito a administradores, perfis de desenvolvimento ou outros utilizadores. A atribuição inicial nominativa e auditada exige âmbito habilitado explicitamente; as seguintes usam a administração nativa. Requerente e decisores continuam a exigir identidades distintas. A concessão de purchasing_budget.record é necessária para reserva/libertação, sem substituir a autorização de requisição.

Privilégios PostgreSQL: são outra camada. sgf_dev_app não deve receber CREATE, ownership ou a palavra-passe do proprietário. A execução de DDL exige a ligação de migração autorizada (sgf_dev_owner ou principal autorizado equivalente), só nessa execução e sem reescrever .env com credenciais privilegiadas. Depois, a aplicação precisa dos privilégios mínimos nas novas tabelas/sequências. O instalador desta candidata não entrega esses GRANTs à role runtime; as provas anteriores usaram role proprietária nas bases descartáveis. Falta fechar/ensaiar esse mapa com as duas roles separadas. O plano deve permitir leitura do registo de instalação, operações de requisição/política, append-only do histórico, reserva/auditoria e locks orçamentais necessários, sem UPDATE/DELETE sobre históricos ou grants genéricos sobre todo o schema. Nenhum GRANT é executado nesta análise.

Bloqueantes e elementos fora do âmbito

Questão	Classificação e impacto
Ligação de migração e privilégios SQL runtime	Bloqueante para executar a instalação tal como está com a ligação normal. A ligação actual não pode executar o DDL. Definir execução migradora e mapa mínimo de acesso a tabelas/sequências, preservar o runtime restrito e ensaiar a separação antes de aplicação.
Centros e dotações de orçamento em instalação vazia	Bloqueante para disponibilizar o percurso básico neste destino. Não existem cb_*; o formulário candidato só selecciona centros existentes e a configuração exige pelo menos um. Não há no percurso entregue cadastro/associação inicial de centros pela interface. Os ensaios prepararam essas fontes e a dotação aprovada por fixtures; não importar fixtures nem criar SQL manual como configuração comercial.
Interface orçamental SGF existente	Bloqueante para a preparação operacional pela interface sem correcção. BudgetWorkspace consulta cb_ui_commands e cb_consumption_sources, ausentes no destino e no schema de 14 tabelas. A reserva pelo motor comum foi ensaiada; isso não declara entregue o bootstrap administrativo/orçamental completo. Não ampliar consumo/facturas por arrasto: integrar o recorte necessário ou manter esse percurso fechado até completar a sua composição.
Catálogo administrativo de permissões	Implementado e testado na candidata; ainda não instalado. No destino, Permissions::UNIT continua só com dois direitos. Aplicar a sobreposição resolve a presença/gestão dos novos nomes; não resolve sozinho DCL PostgreSQL, centros/dotações ou atribuições nominativas. Não classificar como falta de implementação do catálogo nem como acessos já configurados.
Duas administrações nominativas	Pendente para entrega/activação, não condição para copiar código desactivado. O destino tem uma concessão access.manage; a regra da entrega exige duas administrações permanentes da empresa. Não criar conta/perfil ou outorgar direitos automaticamente para satisfazer a contagem.
Âmbito/configuração e dotação reais	Pendente para activação: seleccionar empresa/unidade, centros/fontes, intervenientes, política/limites, responsáveis e dotação aprovada pelas regras usuais. Não retirar a exigência de orçamento para contornar a falta de preparação.
Equipamentos/peças	Fora do âmbito deste percurso básico. Não impedem consumíveis, serviços e outros de completar requisição/submissão/aprovação/consulta quando as dependências acima estiverem preparadas. Equipamentos/peças não têm o seu percurso técnico SGF entregue; não os registar como other para contornar isso.
Navegação modular	Tecnicamente aceite em 02/11/2026 na entrega própria. Não é bloqueante técnico da candidata. Revisão visual/recargas, associações antigas e volume/paginação mantêm o âmbito separado dessa aceitação. Não repetir as suites para resolver a instalação.

Backup, restauro e recuperação — procedimento proposto, não executado

1. Antes de qualquer escrita aprovada: reconferir raiz, URL/base/roles, hashes e estado dos ficheiros/contas/auditoria. Guardar o código/configuração anterior e documentos/ficheiros externos. Reservar directório privado por execução em C:\laragon\data\sgf-tempo\backups\purchasing\<data-id>, fora da raiz pública e sem sobrescrever backups anteriores. O backup de configuração pode conter segredos; não o distribuir com o ZIP.
2. Backup integral apenas de sgf_tempo_dev: PostgreSQL 17 pg_dump --format=custom com host 127.0.0.1, porta 55432, ligação autorizada e ficheiro privado. Registar hash, instante de corte, código/manifesto/schema, inventário das 87 tabelas e ACLs/roles pertinentes. Credenciais por mecanismo privado como PGPASSFILE; nunca nos argumentos/logs. Não parar o cluster inteiro nem exportar/substituir outras bases.
3. Restauro para base nova vazia: criar sgf_tempo_dev_restore_<id> pelo procedimento DBA autorizado, restaurar o dump e conferir dados, documentos externos, tabelas, constraints/triggers, ACLs, contagens/digests de acessos/pertenças/auditoria e arranque com roles distintas. Os ensaios anteriores provaram restauro isolado, mas não substituem o ensaio desta base e dos seus privilégios. pg_restore --list só lê o índice. Se usar --no-owner --no-privileges, repor/validar explicitamente as ownerships/ACLs, incluindo CONNECT/USAGE, antes de ligar o runtime. Não converter o runtime em proprietário para fazer o ensaio passar.
4. Janela de aplicação, só depois dos bloqueantes e da confirmação: manutenção, parar apenas serviços de escrita desse projecto; preparar schema pela ligação migradora; aplicar o mapa SQL aprovado; conferir preservação. Aplicar código e compilar caches pelas CLIs aprovadas, com destino/manifesto reconferidos. Não outorgar direitos funcionais, habilitar âmbitos ou abrir o módulo por arrasto. Reiniciar/conferir serviços próprios mantendo o acesso fechado até decisão de activação.
5. Falha de schema antes do commit: rollback transaccional e conferência com o inventário anterior. Se a ligação se perder durante o commit, inspeccionar revisão/schema antes de repetir. Não executar migrações down ou apagar histórico para forçar retry.
6. Falha de código/aplicação parcial: manter serviços parados/manutenção; sgf-code-deploy.php rollback para o ID devolvido/registado; conferir backups/hashes. A rotina repõe ficheiros/bundle anterior, recusa alterações locais e não reverte dados/schema/concessões. Depois de cache nativo recompilado, invalida-o; executar cache para a versão reposta, quando houver bundle anterior, e reiniciar/conferir antes de reabrir. Na primeira instalação, voltar ao host sem bundle não cria uma versão anterior de requisições. O ponteiro 0.1.1 continua preservado.
7. Corrupção ou incompatibilidade de dados/schema: preservar também o estado que falhou; restaurar para outra base, nunca por cima da base activa. Reconciliar operações posteriores ao backup, configurações e revogações para não perder decisões ou reabrir direitos. Só trocar a ligação da aplicação após conferência e decisão registada; uma base restaurada com outro nome requer nova impressão de destino operacional e caches recompilados. Conservar a base anterior para diagnóstico. Rollback de código não é restauro de dados.

Os comandos parametrizados e contratos das CLIs estão em transferencia-sgf.md. Não pedir confirmação para executar um procedimento ainda incompleto: primeiro resolver os bloqueantes identificados, actualizar/ensaiar a candidata e apresentar os novos hashes se houver alteração. O ZIP actual permanece imutável e disponível como evidência, não aprovado para implantação operacional.

Actualiza??o de 02/11/2026: a proposta desactivada anterior foi substitu?da pela candidata utiliz?vel 401ce31ae5f2dd20, ainda N?O instalada. Fonte vinculativa actual: C:/laragon/www/sgf-tempo/docs/PURCHASING_INSTALLATION_PROPOSAL.md. Mant?m-se 0.1.1, aus?ncia de concess?es e decis?o posterior de instala??o/configura??o.