@wenathlan/saddle 1.8.13 → 1.8.15

package/docs/talks9/Viabilidade do Saddle_ Uma An/303/241lise T/303/251cnica da Transforma/303/247/303/243o de Armazenamento Remoto em Mem/303/263ria Computacional.md"

@@ -22,7 +22,7 @@ Em suma, embora os blocos de construção individuais para a arquitetura de mem
 
 A estratégia de negócio e técnica do Saddle assenta numa premissa poderosa: a orquestração distribuída de cargas de trabalho computacionais utilizando plataformas de código aberto e gratuitas como backend [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. Em vez de construir e manter a sua própria infraestrutura de nuvem, o framework visa agir como um "bot" multi-plataforma, inscrevendo-se como uma aplicação de terceiros e alocando recursos de computação em serviços como GitHub Actions & Codespaces, GitLab CI, Forgejo/Gitea, e até mesmo cadernetas Jupyter em plataformas como ModelScope [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. Esta abordagem descentralizada promete uma escalabilidade teoricamente ilimitada com um custo operacional próximo de zero, um diferencial competitivo significativo. A viabilidade desta estratégia depende não apenas da existência dessas plataformas, mas também da sua capacidade de serem integradas, orquestradas e geridas de forma eficiente, superando as suas inherentemente variáveis e limitadas naturezas.
 
-A plataforma primária mencionada para a execução de cargas de trabalho é o GitHub Actions [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A integração seria alcançada através da publicação do pacote `@devthink/saddle` num registo público como o npm, que por sua vez seria consumido por fluxos de trabalho de ações [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A viabilidade desta integração é corroborada pela existência de acções personalizadas, como o `AnimMouse/setup-rclone`, que demonstram a capacidade de automatizar a instalação e configuração de ferramentas complexas como o rclone dentro de um ambiente de runner do GitHub [[18](https://github.com/marketplace/actions/setup-rclone-action)]. Estas acções permitem passar credenciais e configurações como segredos codificados em Base64, resolvendo o problema da autenticação programática [[18](https://github.com/marketplace/actions/setup-rclone-action)]. No entanto, a utilização de GitHub Actions não está isenta de desafios. Os runners nativos têm limitações bem definidas em termos de tempo de execução e recursos de memória. Relatos de utilizadores mostram que até mesmo runners auto-hospedados podem sofrer de esgotamento de memória, levando a falhas inesperadas no início de um job [[28](https://github.com/microsoft/AL-Go/issues/781)]. Da mesma forma, fluxos de trabalho de ações nativos podem falhar com erros de "out of memory" mesmo quando funcionam perfeitamente noutras configurações, indicando a fragilidade dos recursos alojados [[27](https://github.com/actions/runner/issues/1051)]. O Saddle pretende mitigar este risco fragmentando a carga de trabalho e distribuindo-a simultaneamente por múltiplas plataformas, criando um grande agrupamento de recursos de computação dispersos geograficamente. Este modelo de "multi-tenancy" de recursos de terceiros é a essência da sua proposta.
+A plataforma primária mencionada para a execução de cargas de trabalho é o GitHub Actions [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A integração seria alcançada através da publicação do pacote `@wenathlan/saddle` num registo público como o npm, que por sua vez seria consumido por fluxos de trabalho de ações [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A viabilidade desta integração é corroborada pela existência de acções personalizadas, como o `AnimMouse/setup-rclone`, que demonstram a capacidade de automatizar a instalação e configuração de ferramentas complexas como o rclone dentro de um ambiente de runner do GitHub [[18](https://github.com/marketplace/actions/setup-rclone-action)]. Estas acções permitem passar credenciais e configurações como segredos codificados em Base64, resolvendo o problema da autenticação programática [[18](https://github.com/marketplace/actions/setup-rclone-action)]. No entanto, a utilização de GitHub Actions não está isenta de desafios. Os runners nativos têm limitações bem definidas em termos de tempo de execução e recursos de memória. Relatos de utilizadores mostram que até mesmo runners auto-hospedados podem sofrer de esgotamento de memória, levando a falhas inesperadas no início de um job [[28](https://github.com/microsoft/AL-Go/issues/781)]. Da mesma forma, fluxos de trabalho de ações nativos podem falhar com erros de "out of memory" mesmo quando funcionam perfeitamente noutras configurações, indicando a fragilidade dos recursos alojados [[27](https://github.com/actions/runner/issues/1051)]. O Saddle pretende mitigar este risco fragmentando a carga de trabalho e distribuindo-a simultaneamente por múltiplas plataformas, criando um grande agrupamento de recursos de computação dispersos geograficamente. Este modelo de "multi-tenancy" de recursos de terceiros é a essência da sua proposta.
 
 Além do GitHub, o Saddle alarga a sua rede de recursos a outras plataformas de CI/CD e desenvolvimento. O GitLab Free oferece um número limitado de minutos de CI mensais (400 min/mês) e tem restrições no tamanho do projeto (10 GB), o que implica uma gestão cuidadosa dos artefactos e da duração dos jobs para não exceder os quotas [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. Serviços como o Codeberg, frequentemente associado a motores de CI como o Woodpecker, oferecem quotas adicionais (ex: 750 MB para projetos de código aberto livre), expandindo ainda mais o ecossistema de recursos disponíveis [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A inclusão de plataformas como o ModelScope, que fornece cadernetas Jupyter VMs gratuitas, e servidores auto-hospedados de Forgejo/Gitea ou outros registos de pacotes, mostra uma ambição de maximizar a utilização de qualquer recurso computacional disponível [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A viabilidade desta estratégia de diversificação depende inteiramente da robustez do motor de orquestração do Saddle. Este motor deve ser capaz de interpretar uma tarefa, avaliar as quotas e limitações de cada plataforma-alvo, distribuir partes da carga de forma inteligente, monitorizar o progresso, e recuperar de falhas que são inerentes a ambientes tão heterogéneos e pouco controláveis. A complexidade não reside tanto em iniciar um trabalho numa plataforma, mas em gerir o ciclo de vida completo de uma tarefa distribuída através de uma frota de serviços com diferentes políticas, níveis de serviço e taxas de falha.
 
@@ -42,11 +42,11 @@ A estratégia de utilizar uma frota heterogénea de plataformas de terceiros é
 
 Para além da arquitetura de armazenamento e orquestração, a viabilidade prática do Saddle depende criticamente da sua capacidade de gerir uma infraestrutura complexa e dinâmica. Este gestor de infraestrutura deve lidar com a automação de pré-requisitos nos ambientes de execução, a superação de barreiras de acesso programático como os CAPTCHAs, e a distribuição eficiente do próprio pacote de software. Cada um destes elementos representa um conjunto distinto de desafios técnicos e operacionais que, se mal executados, podem comprometer todo o sistema.
 
-Um dos requisitos operacionais mais básicos para o Saddle é a capacidade de preparar o ambiente de execução antes de poderem ser iniciadas as cargas de trabalho computacionais. Dado que os runners das plataformas de terceiros (como GitHub Actions ou GitLab CI) começam num estado limpo, todas as dependências, como o utilitário `rclone` e as suas configurações de remoto, precisam de ser instaladas e configuradas dinamicamente. A viabilidade desta automação é demonstrada pela existência de acções GitHub personalizadas, como o `AnimMouse/setup-rclone`, que automatizam precisamente este processo [[18](https://github.com/marketplace/actions/setup-rclone-action)]. Estas acções podem instalar uma versão específica do `rclone`, configurá-lo a partir de um segredo codificado em Base64 (uma prática necessária devido aos limites de tamanho de segredos de 48 KB), e até mesmo gerir tokens de API expirados [[18](https://github.com/marketplace/actions/setup-rclone-action)]. A estratégia do Saddle de distribuir o pacote `@devthink/saddle` através de registos públicos como o npm e o GitHub Packages é o meio ideal para entregar o script de orquestração que invocará estas acções de pré-instalação [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A entrega do pacote através de uma CDN pública como o jsDelivr garante uma distribuição global rápida e eficiente [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A repackagem do pacote para formatos complementares, como um nó para a ferramenta de automação n8n, uma extensão de navegador CRX, ou aplicações nativas para Android/iOS, demonstra uma ambição de integração profunda que vai além de simples execução de scripts de linha de comandos [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. No entanto, a complexidade da configuração de `rclone`, que pode envolver ficheiros de configuração grandes e a gestão de múltiplos sistemas de ficheiros remotos, representa um ponto de fricção. A necessidade de comprimir e codificar em Base64 grandes ficheiros de configuração para caber nos limites de segredos de algumas plataformas adiciona uma camada de complexidade à automação [[18](https://github.com/marketplace/actions/setup-rclone-action)].
+Um dos requisitos operacionais mais básicos para o Saddle é a capacidade de preparar o ambiente de execução antes de poderem ser iniciadas as cargas de trabalho computacionais. Dado que os runners das plataformas de terceiros (como GitHub Actions ou GitLab CI) começam num estado limpo, todas as dependências, como o utilitário `rclone` e as suas configurações de remoto, precisam de ser instaladas e configuradas dinamicamente. A viabilidade desta automação é demonstrada pela existência de acções GitHub personalizadas, como o `AnimMouse/setup-rclone`, que automatizam precisamente este processo [[18](https://github.com/marketplace/actions/setup-rclone-action)]. Estas acções podem instalar uma versão específica do `rclone`, configurá-lo a partir de um segredo codificado em Base64 (uma prática necessária devido aos limites de tamanho de segredos de 48 KB), e até mesmo gerir tokens de API expirados [[18](https://github.com/marketplace/actions/setup-rclone-action)]. A estratégia do Saddle de distribuir o pacote `@wenathlan/saddle` através de registos públicos como o npm e o GitHub Packages é o meio ideal para entregar o script de orquestração que invocará estas acções de pré-instalação [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A entrega do pacote através de uma CDN pública como o jsDelivr garante uma distribuição global rápida e eficiente [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A repackagem do pacote para formatos complementares, como um nó para a ferramenta de automação n8n, uma extensão de navegador CRX, ou aplicações nativas para Android/iOS, demonstra uma ambição de integração profunda que vai além de simples execução de scripts de linha de comandos [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. No entanto, a complexidade da configuração de `rclone`, que pode envolver ficheiros de configuração grandes e a gestão de múltiplos sistemas de ficheiros remotos, representa um ponto de fricção. A necessidade de comprimir e codificar em Base64 grandes ficheiros de configuração para caber nos limites de segredos de algumas plataformas adiciona uma camada de complexidade à automação [[18](https://github.com/marketplace/actions/setup-rclone-action)].
 
 Um obstáculo mais significativo à automação programática é a proliferação de sistemas de verificação humana, mais conhecidos como CAPTCHAs, usados por muitos serviços web para impedir o acesso de bots. O Saddle reconhece este desafio e afirma ter uma estratégia para o contornar, especificamente mencionando o uso de "Vision-Language Models (VLM ONNX) and token-based APIs" para bypass de captchas como hCaptcha, Cloudflare Turnstile e reCAPTCHA [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. Esta é uma declaração de alto nível que carece de detalhes técnicos concretos nas fontes fornecidas. O uso de modelos de aprendizagem de máquina para resolver CAPTCHAs é um campo de investigação ativo, mas a implementação prática, a fiabilidade em larga escala, o custo computacional e, crucialmente, a conformidade com os termos de serviço das plataformas-alvo (como Google para reCAPTCHA) são questões profundamente incertas. Nenhuma das fontes consultadas refere projetos de código aberto maduros ou frameworks que realizem esta tarefa de forma robusta e generalizável. Portanto, esta funcionalidade representa o maior ponto de incerteza e risco para o projeto. Se a estratégia de bypass de CAPTCHAs falhar, o Saddle ficaria bloqueado para acesso programático a uma vasta gama de serviços essenciais, desde os próprios serviços de armazenamento até às plataformas de orquestração. A sua eficácia seria o verdadeiro teste de viabilidade, separando a visão do produto real.
 
-Finalmente, a distribuição e a segurança do pacote `@devthink/saddle` são aspectos fundamentais. A escolha de distribuir o pacote através de múltiplos registos (npm, Maven, NuGet, etc.) e de o espelhar automaticamente para o jsDelivr é uma estratégia sólida para garantir a resiliência e a disponibilidade [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. Esta redundância ajuda a mitigar a falha de um único ponto de distribuição. No entanto, ao tornar-se uma biblioteca executável que se torna uma máquina virtual wherever it is installed [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)], o pacote adquire um poder considerável. Ele terá permissões para montar sistemas de ficheiros, criar processos, e aceder a segredos (como chaves de API) armazenados nas plataformas de terceiros onde é executado. A segurança deste pacote torna-se, portanto, um requisito não negociável. Qualquer vulnerabilidade nele poderia ser explorada para comprometer a segurança dos recursos de armazenamento e computação acessados pelos runners. A governança do projeto, a auditoria de código regular e a comunicação transparente sobre as permissões necessárias e como são geridas são cruciais para ganhar a confiança da comunidade de desenvolvedores e dos proprietários das plataformas que apoiam o Saddle. A complexidade da arquitetura, com o pacote a ser repackaged para tantos formatos diferentes, também aumenta a superfície de ataque e o potencial para erros de implementação em certas camadas de abstração. Em última análise, a gestão de infraestrutura do Saddle é um exercício de engenharia sofisticada, onde a automação bem-sucedida, a superação de barreiras de segurança e a distribuição segura do núcleo do software devem funcionar em perfeita sintonia para sustentar toda a visão do projeto.
+Finalmente, a distribuição e a segurança do pacote `@wenathlan/saddle` são aspectos fundamentais. A escolha de distribuir o pacote através de múltiplos registos (npm, Maven, NuGet, etc.) e de o espelhar automaticamente para o jsDelivr é uma estratégia sólida para garantir a resiliência e a disponibilidade [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. Esta redundância ajuda a mitigar a falha de um único ponto de distribuição. No entanto, ao tornar-se uma biblioteca executável que se torna uma máquina virtual wherever it is installed [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)], o pacote adquire um poder considerável. Ele terá permissões para montar sistemas de ficheiros, criar processos, e aceder a segredos (como chaves de API) armazenados nas plataformas de terceiros onde é executado. A segurança deste pacote torna-se, portanto, um requisito não negociável. Qualquer vulnerabilidade nele poderia ser explorada para comprometer a segurança dos recursos de armazenamento e computação acessados pelos runners. A governança do projeto, a auditoria de código regular e a comunicação transparente sobre as permissões necessárias e como são geridas são cruciais para ganhar a confiança da comunidade de desenvolvedores e dos proprietários das plataformas que apoiam o Saddle. A complexidade da arquitetura, com o pacote a ser repackaged para tantos formatos diferentes, também aumenta a superfície de ataque e o potencial para erros de implementação em certas camadas de abstração. Em última análise, a gestão de infraestrutura do Saddle é um exercício de engenharia sofisticada, onde a automação bem-sucedida, a superação de barreiras de segurança e a distribuição segura do núcleo do software devem funcionar em perfeita sintonia para sustentar toda a visão do projeto.
 
 ## Análise Comparativa de Desempenho e Riscos Operacionais
 
@@ -65,7 +65,7 @@ A seguir, uma tabela que sintetiza os principais riscos operacionais e as suas c
 | **Desempenho de I/O Inconsistente** | A performance de E/S via FUSE é variável, sensível à latência da rede e à carga do servidor remoto. | Desempenho geral mais lento do que a RAM local; gargalos de E/S que limitam a velocidade da computação; experiências de usuário frustrantes. [[22](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29651), [24](https://forum.rclone.org/t/rclone-mount-performance-issue/43184)] |
 | **Dependência de CAPTCHAs** | A necessidade de contornar sistemas de verificação humana para obter acesso programático a serviços. | Bloqueio total de acesso a serviços importantes se a estratégia de bypass falhar; dependência de tecnologias de IA voláteis e potencialmente ilegais. [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)] |
 | **Complexidade de Gestão** | A necessidade de gerir uma frota heterogénea de plataformas com diferentes APIs, limites e políticas. | Altíssima complexidade de desenvolvimento do motor de orquestração; dificuldade em otimizar a alocação de recursos; aumento do custo de manutenção. |
-| **Segurança e Governança** | O pacote `@devthink/saddle` possui privilégios elevados nos ambientes onde é executado. | Vulnerabilidades de segurança que podem ser exploradas para comprometer os recursos de armazenamento e computação dos utilizadores. [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)] |
+| **Segurança e Governança** | O pacote `@wenathlan/saddle` possui privilégios elevados nos ambientes onde é executado. | Vulnerabilidades de segurança que podem ser exploradas para comprometer os recursos de armazenamento e computação dos utilizadores. [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)] |
 
 Em última análise, a proposta do Saddle é menos uma implementação de um framework existente e mais um experimento de fronteira na engenharia de sistemas. A sua viabilidade prática não será determinada por um único fator, mas por uma série de compromissos. O sistema funcionará melhor para cargas de trabalho que são tolerantes à latência, resilientes a interrupções e cujos dados são suficientemente compressíveis para minimizar o impacto do `zram`. Para tarefas que exigem desempenho de memória de baixa latência e alta confiabilidade, como treinar modelos de IA de grande escala, o Saddle provavelmente não será competitivo em relação a soluções de nuvem dedicadas. No entanto, para tarefas mais moderadas, como compilação de software, processamento de dados em pequena escala ou como um ambiente de desenvolvimento interativo leve, a sua proposta de valor de um sistema de memória virtual gratuito e descentralizado pode ser extremamente atraente. A chave para o seu sucesso reside em gerir ativamente estes riscos, aceitando as suas limitações e construindo uma camada de abstração que torne a complexidade subjacente invisível ao utilizador final.
 

package/docs/talks9/conversa.txt

@@ -34,7 +34,7 @@ Em suma, embora os blocos de construção individuais para a arquitetura de mem
 
 A estratégia de negócio e técnica do Saddle assenta numa premissa poderosa: a orquestração distribuída de cargas de trabalho computacionais utilizando plataformas de código aberto e gratuitas como backend . Em vez de construir e manter a sua própria infraestrutura de nuvem, o framework visa agir como um "bot" multi-plataforma, inscrevendo-se como uma aplicação de terceiros e alocando recursos de computação em serviços como GitHub Actions & Codespaces, GitLab CI, Forgejo/Gitea, e até mesmo cadernetas Jupyter em plataformas como ModelScope . Esta abordagem descentralizada promete uma escalabilidade teoricamente ilimitada com um custo operacional próximo de zero, um diferencial competitivo significativo. A viabilidade desta estratégia depende não apenas da existência dessas plataformas, mas também da sua capacidade de serem integradas, orquestradas e geridas de forma eficiente, superando as suas inherentemente variáveis e limitadas naturezas.
 
-A plataforma primária mencionada para a execução de cargas de trabalho é o GitHub Actions . A integração seria alcançada através da publicação do pacote `@devthink/saddle` num registo público como o npm, que por sua vez seria consumido por fluxos de trabalho de ações . A viabilidade desta integração é corroborada pela existência de acções personalizadas, como o `AnimMouse/setup-rclone`, que demonstram a capacidade de automatizar a instalação e configuração de ferramentas complexas como o rclone dentro de um ambiente de runner do GitHub . Estas acções permitem passar credenciais e configurações como segredos codificados em Base64, resolvendo o problema da autenticação programática . No entanto, a utilização de GitHub Actions não está isenta de desafios. Os runners nativos têm limitações bem definidas em termos de tempo de execução e recursos de memória. Relatos de utilizadores mostram que até mesmo runners auto-hospedados podem sofrer de esgotamento de memória, levando a falhas inesperadas no início de um job . Da mesma forma, fluxos de trabalho de ações nativos podem falhar com erros de "out of memory" mesmo quando funcionam perfeitamente noutras configurações, indicando a fragilidade dos recursos alojados . O Saddle pretende mitigar este risco fragmentando a carga de trabalho e distribuindo-a simultaneamente por múltiplas plataformas, criando um grande agrupamento de recursos de computação dispersos geograficamente. Este modelo de "multi-tenancy" de recursos de terceiros é a essência da sua proposta.
+A plataforma primária mencionada para a execução de cargas de trabalho é o GitHub Actions . A integração seria alcançada através da publicação do pacote `@wenathlan/saddle` num registo público como o npm, que por sua vez seria consumido por fluxos de trabalho de ações . A viabilidade desta integração é corroborada pela existência de acções personalizadas, como o `AnimMouse/setup-rclone`, que demonstram a capacidade de automatizar a instalação e configuração de ferramentas complexas como o rclone dentro de um ambiente de runner do GitHub . Estas acções permitem passar credenciais e configurações como segredos codificados em Base64, resolvendo o problema da autenticação programática . No entanto, a utilização de GitHub Actions não está isenta de desafios. Os runners nativos têm limitações bem definidas em termos de tempo de execução e recursos de memória. Relatos de utilizadores mostram que até mesmo runners auto-hospedados podem sofrer de esgotamento de memória, levando a falhas inesperadas no início de um job . Da mesma forma, fluxos de trabalho de ações nativos podem falhar com erros de "out of memory" mesmo quando funcionam perfeitamente noutras configurações, indicando a fragilidade dos recursos alojados . O Saddle pretende mitigar este risco fragmentando a carga de trabalho e distribuindo-a simultaneamente por múltiplas plataformas, criando um grande agrupamento de recursos de computação dispersos geograficamente. Este modelo de "multi-tenancy" de recursos de terceiros é a essência da sua proposta.
 
 Além do GitHub, o Saddle alarga a sua rede de recursos a outras plataformas de CI/CD e desenvolvimento. O GitLab Free oferece um número limitado de minutos de CI mensais (400 min/mês) e tem restrições no tamanho do projeto (10 GB), o que implica uma gestão cuidadosa dos artefactos e da duração dos jobs para não exceder os quotas . Serviços como o Codeberg, frequentemente associado a motores de CI como o Woodpecker, oferecem quotas adicionais (ex: 750 MB para projetos de código aberto livre), expandindo ainda mais o ecossistema de recursos disponíveis . A inclusão de plataformas como o ModelScope, que fornece cadernetas Jupyter VMs gratuitas, e servidores auto-hospedados de Forgejo/Gitea ou outros registos de pacotes, mostra uma ambição de maximizar a utilização de qualquer recurso computacional disponível . A viabilidade desta estratégia de diversificação depende inteiramente da robustez do motor de orquestração do Saddle. Este motor deve ser capaz de interpretar uma tarefa, avaliar as quotas e limitações de cada plataforma-alvo, distribuir partes da carga de forma inteligente, monitorizar o progresso, e recuperar de falhas que são inerentes a ambientes tão heterogéneos e pouco controláveis. A complexidade não reside tanto em iniciar um trabalho numa plataforma, mas em gerir o ciclo de vida completo de uma tarefa distribuída através de uma frota de serviços com diferentes políticas, níveis de serviço e taxas de falha.
 
@@ -54,11 +54,11 @@ A estratégia de utilizar uma frota heterogénea de plataformas de terceiros é
 
 Para além da arquitetura de armazenamento e orquestração, a viabilidade prática do Saddle depende criticamente da sua capacidade de gerir uma infraestrutura complexa e dinâmica. Este gestor de infraestrutura deve lidar com a automação de pré-requisitos nos ambientes de execução, a superação de barreiras de acesso programático como os CAPTCHAs, e a distribuição eficiente do próprio pacote de software. Cada um destes elementos representa um conjunto distinto de desafios técnicos e operacionais que, se mal executados, podem comprometer todo o sistema.
 
-Um dos requisitos operacionais mais básicos para o Saddle é a capacidade de preparar o ambiente de execução antes de poderem ser iniciadas as cargas de trabalho computacionais. Dado que os runners das plataformas de terceiros (como GitHub Actions ou GitLab CI) começam num estado limpo, todas as dependências, como o utilitário `rclone` e as suas configurações de remoto, precisam de ser instaladas e configuradas dinamicamente. A viabilidade desta automação é demonstrada pela existência de acções GitHub personalizadas, como o `AnimMouse/setup-rclone`, que automatizam precisamente este processo . Estas acções podem instalar uma versão específica do `rclone`, configurá-lo a partir de um segredo codificado em Base64 (uma prática necessária devido aos limites de tamanho de segredos de 48 KB), e até mesmo gerir tokens de API expirados . A estratégia do Saddle de distribuir o pacote `@devthink/saddle` através de registos públicos como o npm e o GitHub Packages é o meio ideal para entregar o script de orquestração que invocará estas acções de pré-instalação . A entrega do pacote através de uma CDN pública como o jsDelivr garante uma distribuição global rápida e eficiente . A repackagem do pacote para formatos complementares, como um nó para a ferramenta de automação n8n, uma extensão de navegador CRX, ou aplicações nativas para Android/iOS, demonstra uma ambição de integração profunda que vai além de simples execução de scripts de linha de comandos . No entanto, a complexidade da configuração de `rclone`, que pode envolver ficheiros de configuração grandes e a gestão de múltiplos sistemas de ficheiros remotos, representa um ponto de fricção. A necessidade de comprimir e codificar em Base64 grandes ficheiros de configuração para caber nos limites de segredos de algumas plataformas adiciona uma camada de complexidade à automação .
+Um dos requisitos operacionais mais básicos para o Saddle é a capacidade de preparar o ambiente de execução antes de poderem ser iniciadas as cargas de trabalho computacionais. Dado que os runners das plataformas de terceiros (como GitHub Actions ou GitLab CI) começam num estado limpo, todas as dependências, como o utilitário `rclone` e as suas configurações de remoto, precisam de ser instaladas e configuradas dinamicamente. A viabilidade desta automação é demonstrada pela existência de acções GitHub personalizadas, como o `AnimMouse/setup-rclone`, que automatizam precisamente este processo . Estas acções podem instalar uma versão específica do `rclone`, configurá-lo a partir de um segredo codificado em Base64 (uma prática necessária devido aos limites de tamanho de segredos de 48 KB), e até mesmo gerir tokens de API expirados . A estratégia do Saddle de distribuir o pacote `@wenathlan/saddle` através de registos públicos como o npm e o GitHub Packages é o meio ideal para entregar o script de orquestração que invocará estas acções de pré-instalação . A entrega do pacote através de uma CDN pública como o jsDelivr garante uma distribuição global rápida e eficiente . A repackagem do pacote para formatos complementares, como um nó para a ferramenta de automação n8n, uma extensão de navegador CRX, ou aplicações nativas para Android/iOS, demonstra uma ambição de integração profunda que vai além de simples execução de scripts de linha de comandos . No entanto, a complexidade da configuração de `rclone`, que pode envolver ficheiros de configuração grandes e a gestão de múltiplos sistemas de ficheiros remotos, representa um ponto de fricção. A necessidade de comprimir e codificar em Base64 grandes ficheiros de configuração para caber nos limites de segredos de algumas plataformas adiciona uma camada de complexidade à automação .
 
 Um obstáculo mais significativo à automação programática é a proliferação de sistemas de verificação humana, mais conhecidos como CAPTCHAs, usados por muitos serviços web para impedir o acesso de bots. O Saddle reconhece este desafio e afirma ter uma estratégia para o contornar, especificamente mencionando o uso de "Vision-Language Models (VLM ONNX) and token-based APIs" para bypass de captchas como hCaptcha, Cloudflare Turnstile e reCAPTCHA . Esta é uma declaração de alto nível que carece de detalhes técnicos concretos nas fontes fornecidas. O uso de modelos de aprendizagem de máquina para resolver CAPTCHAs é um campo de investigação ativo, mas a implementação prática, a fiabilidade em larga escala, o custo computacional e, crucialmente, a conformidade com os termos de serviço das plataformas-alvo (como Google para reCAPTCHA) são questões profundamente incertas. Nenhuma das fontes consultadas refere projetos de código aberto maduros ou frameworks que realizem esta tarefa de forma robusta e generalizável. Portanto, esta funcionalidade representa o maior ponto de incerteza e risco para o projeto. Se a estratégia de bypass de CAPTCHAs falhar, o Saddle ficaria bloqueado para acesso programático a uma vasta gama de serviços essenciais, desde os próprios serviços de armazenamento até às plataformas de orquestração. A sua eficácia seria o verdadeiro teste de viabilidade, separando a visão do produto real.
 
-Finalmente, a distribuição e a segurança do pacote `@devthink/saddle` são aspectos fundamentais. A escolha de distribuir o pacote através de múltiplos registos (npm, Maven, NuGet, etc.) e de o espelhar automaticamente para o jsDelivr é uma estratégia sólida para garantir a resiliência e a disponibilidade . Esta redundância ajuda a mitigar a falha de um único ponto de distribuição. No entanto, ao tornar-se uma biblioteca executável que se torna uma máquina virtual wherever it is installed , o pacote adquire um poder considerável. Ele terá permissões para montar sistemas de ficheiros, criar processos, e aceder a segredos (como chaves de API) armazenados nas plataformas de terceiros onde é executado. A segurança deste pacote torna-se, portanto, um requisito não negociável. Qualquer vulnerabilidade nele poderia ser explorada para comprometer a segurança dos recursos de armazenamento e computação acessados pelos runners. A governança do projeto, a auditoria de código regular e a comunicação transparente sobre as permissões necessárias e como são geridas são cruciais para ganhar a confiança da comunidade de desenvolvedores e dos proprietários das plataformas que apoiam o Saddle. A complexidade da arquitetura, com o pacote a ser repackaged para tantos formatos diferentes, também aumenta a superfície de ataque e o potencial para erros de implementação em certas camadas de abstração. Em última análise, a gestão de infraestrutura do Saddle é um exercício de engenharia sofisticada, onde a automação bem-sucedida, a superação de barreiras de segurança e a distribuição segura do núcleo do software devem funcionar em perfeita sintonia para sustentar toda a visão do projeto.
+Finalmente, a distribuição e a segurança do pacote `@wenathlan/saddle` são aspectos fundamentais. A escolha de distribuir o pacote através de múltiplos registos (npm, Maven, NuGet, etc.) e de o espelhar automaticamente para o jsDelivr é uma estratégia sólida para garantir a resiliência e a disponibilidade . Esta redundância ajuda a mitigar a falha de um único ponto de distribuição. No entanto, ao tornar-se uma biblioteca executável que se torna uma máquina virtual wherever it is installed , o pacote adquire um poder considerável. Ele terá permissões para montar sistemas de ficheiros, criar processos, e aceder a segredos (como chaves de API) armazenados nas plataformas de terceiros onde é executado. A segurança deste pacote torna-se, portanto, um requisito não negociável. Qualquer vulnerabilidade nele poderia ser explorada para comprometer a segurança dos recursos de armazenamento e computação acessados pelos runners. A governança do projeto, a auditoria de código regular e a comunicação transparente sobre as permissões necessárias e como são geridas são cruciais para ganhar a confiança da comunidade de desenvolvedores e dos proprietários das plataformas que apoiam o Saddle. A complexidade da arquitetura, com o pacote a ser repackaged para tantos formatos diferentes, também aumenta a superfície de ataque e o potencial para erros de implementação em certas camadas de abstração. Em última análise, a gestão de infraestrutura do Saddle é um exercício de engenharia sofisticada, onde a automação bem-sucedida, a superação de barreiras de segurança e a distribuição segura do núcleo do software devem funcionar em perfeita sintonia para sustentar toda a visão do projeto.
 
 ## Análise Comparativa de Desempenho e Riscos Operacionais
 
@@ -77,7 +77,7 @@ A seguir, uma tabela que sintetiza os principais riscos operacionais e as suas c
 | **Desempenho de I/O Inconsistente** | A performance de E/S via FUSE é variável, sensível à latência da rede e à carga do servidor remoto. | Desempenho geral mais lento do que a RAM local; gargalos de E/S que limitam a velocidade da computação; experiências de usuário frustrantes. [[22,24]] |
 | **Dependência de CAPTCHAs** | A necessidade de contornar sistemas de verificação humana para obter acesso programático a serviços. | Bloqueio total de acesso a serviços importantes se a estratégia de bypass falhar; dependência de tecnologias de IA voláteis e potencialmente ilegais.  |
 | **Complexidade de Gestão** | A necessidade de gerir uma frota heterogénea de plataformas com diferentes APIs, limites e políticas. | Altíssima complexidade de desenvolvimento do motor de orquestração; dificuldade em otimizar a alocação de recursos; aumento do custo de manutenção. |
-| **Segurança e Governança** | O pacote `@devthink/saddle` possui privilégios elevados nos ambientes onde é executado. | Vulnerabilidades de segurança que podem ser exploradas para comprometer os recursos de armazenamento e computação dos utilizadores.  |
+| **Segurança e Governança** | O pacote `@wenathlan/saddle` possui privilégios elevados nos ambientes onde é executado. | Vulnerabilidades de segurança que podem ser exploradas para comprometer os recursos de armazenamento e computação dos utilizadores.  |
 
 Em última análise, a proposta do Saddle é menos uma implementação de um framework existente e mais um experimento de fronteira na engenharia de sistemas. A sua viabilidade prática não será determinada por um único fator, mas por uma série de compromissos. O sistema funcionará melhor para cargas de trabalho que são tolerantes à latência, resilientes a interrupções e cujos dados são suficientemente compressíveis para minimizar o impacto do `zram`. Para tarefas que exigem desempenho de memória de baixa latência e alta confiabilidade, como treinar modelos de IA de grande escala, o Saddle provavelmente não será competitivo em relação a soluções de nuvem dedicadas. No entanto, para tarefas mais moderadas, como compilação de software, processamento de dados em pequena escala ou como um ambiente de desenvolvimento interativo leve, a sua proposta de valor de um sistema de memória virtual gratuito e descentralizado pode ser extremamente atraente. A chave para o seu sucesso reside em gerir ativamente estes riscos, aceitando as suas limitações e construindo uma camada de abstração que torne a complexidade subjacente invisível ao utilizador final.