@wenathlan/saddle 1.8.17 → 2.0.2

package/docs/talks9/README.md

@@ -1,198 +0,0 @@
-<p align="center">
-  <img src="docs/assets/saddlemark.svg" alt="Saddle" width="720" />
-</p>
-
-<p align="center">
-  <strong>Storage-backed jobs, scraping contracts and portable runners for Node.js.</strong><br />
-  <a href="https://github.com/iakadion/saddle/actions/workflows/ci.yml"><img src="https://github.com/iakadion/saddle/actions/workflows/ci.yml/badge.svg" alt="CI" /></a>
-  <a href="https://github.com/iakadion/saddle/releases/tag/v1.0.0"><img src="https://img.shields.io/badge/release-v1.0.0-d35d3d" alt="Release 1.0.0" /></a>
-  <a href="https://github.com/iakadion/saddle/blob/main/LICENSE"><img src="https://img.shields.io/badge/license-GPL--3.0-202a2f" alt="GPL 3.0 license" /></a>
-</p>
-
-Saddle is a **JavaScript ESM engine** for jobs that move data between storage, a working set, an injected runner and durable artifacts. It includes focused contracts for scraping, crawling, browser agents, queues, persistence, MCP transport, webhooks and package delivery without taking ownership of the caller's credentials or infrastructure.
-
-> **Core idea:** storage is the durable side of the working set; the runner is replaceable; the artifact is the boundary.
-
-<p align="center">
-  <img src="docs/assets/architecture.svg" alt="Saddle runtime architecture: storage, bridge, runner and artifact" width="100%" />
-</p>
-
-## Start here
-
-Saddle requires **Node.js 22 or newer**.
-
-```bash
-npm install @wenathlan/saddle
-```
-
-The public API uses injected transports. A caller can use the built-in `fetch`, a custom fetcher, a browser adapter, a storage backend or a runner without changing the core contracts.
-
-```js
-import { scrapeurl, formatforagent } from "@wenathlan/saddle";
-
-const result = await scrapeurl("https://example.com", {
-  format: "markdown"
-});
-
-const context = formatforagent(result, {
-  maxchunksize: 2000,
-  keypoints: 4
-});
-
-console.log(context.summary);
-console.log(context.chunks);
-```
-
-For a deterministic example with no network access:
-
-```bash
-node examples/publicapi.js
-```
-
-## What is included
-
-| Area | Contract | Result |
-| --- | --- | --- |
-| Jobs | `engine`, `scheduler`, `inprocess` | `prepare → process → sync → cleanup` |
-| Storage | local, chunked, S3-compatible, GitHub Contents, file hosting | durable objects and chunks |
-| Working set | memory bridge, modes, objects, transforms | storage-to-compute and compute-to-storage |
-| Scraping | robots, cache, extraction, schema, scraper | text, metadata, links and structured output |
-| Crawl | normalization, BFS crawler, persistent frontier | bounded domain-aware crawling |
-| Browser | fingerprint, session, replay and injected agent | browser actions without a vendor lock-in |
-| Operations | queues, idempotency, saga, retry, circuit breaker | controlled execution and recovery |
-| Protocols | JSON, NDJSON, SSE, blocks and MCP | transport-neutral messages |
-| Delivery | manifests, workflow registry, binary/container plans | package and runner surfaces |
-
-## Public API
-
-The root export is intentionally broad. Subpath exports are available for consumers that want a smaller dependency surface.
-
-| Export | Purpose |
-| --- | --- |
-| `saddleurl` | choose the fetch or injected browser path |
-| `scrapeurl` | fetch one URL and extract content |
-| `scrapehtml` | extract content from HTML without network access |
-| `extractcontent` | expose structured extraction directly |
-| `serializeresult` | serialize as JSON, text, Markdown, XML or Redis payload |
-| `formatforagent` | produce summary, key points, chunks, links and token count |
-| `batchscrape` | process bounded URL groups with progress callbacks |
-| `crawlurl` | run the crawl contract through the public surface |
-| `browseragent` | adapt navigation, click, type, screenshot, DOM and scroll |
-| `mcpserver` / `mcptransport` | expose optional MCP tools over JSONL or HTTP |
-| `nodeserver` | expose a Web Request/Response handler through Node HTTP |
-
-The complete API is documented in [`docs/libraryapi.md`](docs/libraryapi.md).
-
-## The execution model
-
-Saddle coordinates contracts instead of hiding providers behind a mandatory platform. A typical job looks like this:
-
-```js
-import {
-  engine,
-  eventbus,
-  inprocess,
-  localmemory,
-  localstorage,
-  scheduler
-} from "@wenathlan/saddle";
-
-const events = eventbus();
-const run = engine({
-  storage: localstorage("./.saddle-data"),
-  memory: localmemory(),
-  scheduler: scheduler([inprocess()]),
-  events
-});
-
-const result = await run.run(
-  { name: "example", input: { value: 42 } },
-  ({ job }) => ({ jobid: job.id, ok: true })
-);
-
-console.log(result.artifact);
-```
-
-The caller still chooses how to provide `fetcher`, browser transport, persistence, proxy pool, captcha solver, webhook secret and remote credentials. Saddle does not embed secrets, fixed hosts or a mandatory cloud vendor.
-
-## CLI
-
-The package includes the `saddle` executable.
-
-```bash
-saddle help
-saddle modes
-saddle runexample
-saddle mcp
-```
-
-The CLI keeps local execution explicit. Remote execution belongs to the configured forge, storage and workflow adapters.
-
-## Security boundaries
-
-Saddle follows a caller-owned infrastructure model.
-
-| Boundary | Policy |
-| --- | --- |
-| Credentials | injected at runtime; never committed |
-| Network | `http` and `https` URLs are validated; private targets are blocked by the API/MCP security layer |
-| Crawling | robots rules and crawl delay are explicit inputs to the crawl contract |
-| Storage | adapters are replaceable; the core does not assume one object store |
-| Runtime | Node HTTP is isolated in `server/node.js`; core contracts stay transport-oriented |
-| Failure | retry policy, circuit breaker, idempotency and saga compensation remain configurable |
-
-The engine is an orchestration layer, not a promise that every website, browser or external service can be automated. Operators remain responsible for authorization, terms of service and data handling.
-
-## Package surfaces
-
-The release is distributed through the following GitHub Packages registries.
-
-| Registry | Published artifact | Workflow |
-| --- | --- | --- |
-| GitHub npm | `@iakadion/saddle@1.0.0` | [`publishgithubnpm.yml`](.github/workflows/publishgithubnpm.yml) |
-| GHCR | `ghcr.io/iakadion/saddle:latest` | [`publishghcr.yml`](.github/workflows/publishghcr.yml) |
-| Maven | `io.devthink:saddle:1.0.0` | [`publishmaven.yml`](.github/workflows/publishmaven.yml) |
-| NuGet | `Saddle 1.0.0` | [`publishnuget.yml`](.github/workflows/publishnuget.yml) |
-| RubyGems | `saddle 1.0.0` | [`publishrubygems.yml`](.github/workflows/publishrubygems.yml) |
-
-The canonical JavaScript package name remains `@wenathlan/saddle` for the public npmjs workflow. GitHub Packages uses `@iakadion/saddle` because the GitHub Actions token is authorized for the repository owner namespace.
-
-## Development
-
-```bash
-npm ci
-npm test
-npm run check
-npm run formatcheck
-npm run pack:check
-```
-
-The test suite is deterministic and does not require network access or real credentials. `npm run pack:check` runs syntax checks, the JSDoc format audit, all tests and an npm pack dry-run.
-
-## Repository map
-
-```text
-core/          errors, events and identifiers
-domain/        jobs, artifacts, sessions and providers
-memory/        working-set bridge, modes, objects and transforms
-storage/       local, chunked, remote and file-hosting adapters
-scrape/        robots, cache, extraction, schema and scraper
-crawl/         URL normalization, crawler and persistent frontier
-queue/         queue, idempotency, saga and recovery
-browser/       fingerprint, session and agent contracts
-mcp/           optional server and JSONL/HTTP transport
-protocol/      JSON, NDJSON, SSE and block serializers
-workflow/      manifests, templates and registry
-tests/         deterministic engine coverage
-docs/          architecture, API, release and registry notes
-```
-
-The project deliberately uses a **root-based JavaScript ESM layout**. There is no `src/` directory and no TypeScript build requirement.
-
-## Current scope
-
-Version 1.0 establishes the engine contracts and a tested package surface. Browser implementations, provider credentials, persistent databases and production deployment remain caller-selected adapters. The next improvements should extend those contracts without coupling the core to one forge, registry, browser or storage vendor.
-
-## License
-
-Saddle is distributed under the [GNU General Public License v3.0](LICENSE).

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"

@@ -1,80 +0,0 @@
-# Viabilidade do Saddle: Uma Análise Técnica da Transformação de Armazenamento Remoto em Memória Computacional
-
-## Fundamentos Tecnológicos da Transformação de Armazenamento em Memória
-
-A premissa central do framework Saddle, conforme descrito, é a transformação de serviços de armazenamento de terceiros — como Hugging Face, Kaggle e Terabox — numa única entidade de memória computacional virtual, incluindo RAM, GPU e CPU [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. Esta abstração radical, que postula que "bytes de armazenamento e bytes de memória computacional são os mesmos bytes", depende de uma arquitetura complexa e interdependente de três pilares tecnológicos fundamentais: a montagem de sistemas de ficheiros remotos, a criação de um sistema de ficheiros temporário em memória rápida, e a implementação de troca de dados comprimidos para ampliar a capacidade de memória virtual [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A análise detalhada de cada componente revela tanto a robustez dos seus componentes individuais quanto os riscos sistémicos inerentes à sua síntese.
-
-O mecanismo primário para unificar os diversos serviços de armazenamento é a utilização de Filesystem in Userspace (FUSE), uma tecnologia que permite a implementação de sistemas de ficheiros sem necessidade de modificar o kernel do sistema operativo [[6](https://gist.github.com/jacky9813/8bb473869a24ce0e493a0aa0c9b577d6), [21](https://rclone.org/commands/rclone_mount/)]. O utilitário `rclone` serve como a ponte crucial nesta arquitetura, permitindo montar qualquer um dos serviços suportados (Cloudflare R2, GitHub, S3, etc.) como um sistema de ficheiros local através de FUSE [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE), [21](https://rclone.org/commands/rclone_mount/)]. A viabilidade desta abordagem está bem estabelecida; existem documentações técnicas extensas sobre como configurar o kernel Linux para suportar FUSE, e ferramentas como o `AnimMouse/setup-rclone` demonstram a integração prática desta tecnologia em ambientes automatizados como o GitHub Actions [[6](https://gist.github.com/jacky9813/8bb473869a24ce0e493a0aa0c9b577d6), [18](https://github.com/marketplace/actions/setup-rclone-action)]. No entanto, a transparência desta camada de abstração esconde um custo significativo em termos de consumo de memória e desempenho de E/S. Relatos de utilizadores indicam consistentemente que as montagens `rclone` podem consumir quantidades substanciais de RAM, mesmo em estado inativo. Um caso notável documentou um aumento drástico no consumo de memória residente de cerca de 1.8GB para mais de 7GB após uma atualização de versão, resultando na terminação por força do processo pelo mecanismo de "Out-of-Memory" (OOM) do kernel [[16](https://github.com/rclone/rclone/issues/2157)]. Outro relato descreve um monte que cresceu o consumo de RAM de 137K para além de 4GB ao longo de dois dias, devido a um processo de enumeração de diretórios em segundo plano que continuava a carregar metadados na memória [[19](https://forum.rclone.org/t/rclone-mount-memory-leaks-gdrive-enumeration/16475)]. Para o Saddle, cujo objetivo é criar um "disco virtual" ilimitado agregando múltiplos serviços, este consumo de RAM oculto representa o risco mais crítico. Se o custo marginal de expandir o armazenamento virtual se traduzir num custo proibitivo de memória, a proposta de valor de um sistema gratuito ou de baixo custo será invalidada. Adicionalmente, o desempenho de E/S via FUSE está intrinsecamente ligado à latência da rede e à eficiência da implementação específica. Testes de utilizadores mostraram que a velocidade de escrita em um sistema de ficheiros `tmpfs` montado para trabalhos do GitLab Runner era de apenas 60 MB/s, comparável a um disco rígido padrão e muito abaixo das expectativas de um sistema de memória ideal [[22](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29651)]. Situações de alta concorrência de I/O também podem exacerbar estes problemas; um servidor Java com um monte OneDrive falhou em gerir o tráfego de pico, enquanto o desempenho era estável com ficheiros locais, sugerindo que a plataforma `rclone` pode não ser adequada para cargas de trabalho intensivas em E/S [[24](https://forum.rclone.org/t/rclone-mount-performance-issue/43184)].
-
-Para mitigar os gargalos de desempenho do armazenamento remoto e fornecer uma camada de acesso rápido, o Saddle propõe uma hierarquia de memória virtual construída sobre tecnologias nativas do Linux, nomeadamente `tmpfs`, `zram` e `union-fs`. A arquitetura parece consistir numa camada de disco (o volume FUSE montado), uma camada de cache de memória (`tmpfs`) para ficheiros ativamente utilizados, e uma camada de troca (`zram`) para alargar ainda mais a capacidade de memória virtual [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. O `tmpfs` é um sistema de ficheiros em memória RAM que funciona como uma área de trabalho temporária extremamente rápida [[5](https://spin.atomicobject.com/protecting-ubuntu-root-filesystem/)]. A sua principal limitação é o tamanho, que por defeito corresponde a metade da RAM física disponível, e qualquer tentativa de escrever um ficheiro maior que este limite provavelmente levará à falha do sistema [[5](https://spin.atomicobject.com/protecting-ubuntu-root-filesystem/)]. A estratégia do Saddle parece depender de um `tmpfs` dinâmico, mas a sua gestão eficiente sob carga pesada permanece um desafio. Por outro lado, o `zram` é um módulo do kernel que cria um dispositivo de bloco comprimido directamente na memória RAM [[10](https://docs.kernel.org/admin-guide/blockdev/zram.html), [12](https://www.infradead.org/~mchehab/kernel_docs/admin-guide/blockdev/zram.html)]. Quando utilizado como espaço de troca (`swapon`), permite ao sistema operativo mover páginas de memória inativas para este dispositivo comprimido, efectivamente aumentando a quantidade total de "memória" disponível para além da RAM física. Existem guias detalhados sobre como configurar múltiplos dispositivos `zram` com algoritmos de compressão avançados como `zstd`, optimizando o desempenho para cargas específicas [[9](https://bbs.archlinux.org/viewtopic.php?id=261842), [14](https://forums.gentoo.org/viewtopic.php?t=1126471)]. A combinação de `tmpfs` como cache rápido e `zram` como swap é a parte mais inovadora desta arquitectura. Uma discussão técnica sugere que esta abordagem é tecnicamente factível para contenção, pois permite que o espaço seja partilhado dinamicamente entre os dados em cache e a troca, evitando a alocação prévia exigida por métodos alternativos [[8](https://forum.puppylinux.com/viewtopic.php?t=6043)]. No entanto, a literatura apresenta contradições sobre a eficiência deste modelo. Uma perspectiva argumenta que usar `zram` como um sistema de ficheiros (ext4) é ineficiente porque a mesma informação pode residir duas vezes na RAM: uma vez dentro do dispositivo `zram` comprimido e outra vez no cache de página do sistema operativo [[13](https://www.reddit.com/r/linuxadmin/comments/sseos8/zram_vs_tmpfs/)]. Outra visão defende que `zram` é superior ao `tmpfs` para muitos propósitos devido à sua capacidade de armazenar muito mais dados graças à compressão [[11](http://nixventure.blogspot.com/2017/07/discovering-zram-and-replacing-all-tmpfs.html)]. A viabilidade prática do modelo do Saddle depende criticamente de encontrar um equilíbrio que minimize a sobrecarga da compressão/descompressão e evite que o consumo de RAM do `rclone` domine os recursos disponíveis para a camada de cache e troca.
-
-| Componente Tecnológico | Propósito no Saddle | Vantagens Comprovadas | Riscos e Limitações Identificadas |
-| :--- | :--- | :--- | :--- |
-| **Filesystem in Userspace (FUSE)** | Montar serviços de armazenamento remoto (Hugging Face, Kaggle, etc.) como um sistema de ficheiros local. | Abstração de alto nível para sistemas de ficheiros remotos; vasto suporte de ferramentas como o rclone [[21](https://rclone.org/commands/rclone_mount/)]. | Consumo elevado de RAM (vazamentos e enumeração de diretórios) [[16](https://github.com/rclone/rclone/issues/2157), [19](https://forum.rclone.org/t/rclone-mount-memory-leaks-gdrive-enumeration/16475)]; desempenho de E/S limitado pela latência da rede [[22](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29651), [24](https://forum.rclone.org/t/rclone-mount-performance-issue/43184)]. |
-| **rclone** | Ferramenta de linha de comando para gerir transferências e montar sistemas de ficheiros remotos via FUSE. | Suporte para centenas de backends de armazenamento; integração com pipelines de CI/CD (ex: GitHub Actions) [[18](https://github.com/marketplace/actions/setup-rclone-action)]. | Regressões de desempenho entre versões [[16](https://github.com/rclone/rclone/issues/2157)]; configuração complexa para otimização (cache, buffers, transfers) [[24](https://forum.rclone.org/t/rclone-mount-performance-issue/43184)]. |
-| **tmpfs** | Sistema de ficheiros em RAM para uso como cache de memória e ponto de montagem temporário. | Velocidade de E/S extremamente rápida, próxima da RAM [[5](https://spin.atomicobject.com/protecting-ubuntu-root-filesystem/)]. | Tamanho limitado (por defeito, metade da RAM); potencial para falhas se o limite for ultrapassado [[5](https://spin.atomicobject.com/protecting-ubuntu-root-filesystem/)]. |
-| **zram** | Módulo do kernel para criar um dispositivo de bloco comprimido em RAM para uso como swap. | Amplia a capacidade de memória virtual além da RAM física; I/O muito mais rápido que o disco físico [[10](https://docs.kernel.org/admin-guide/blockdev/zram.html)]. | Sobrecarga de CPU para compressão/descompressão; a eficácia depende do tipo de dados (melhor para dados compressíveis) [[14](https://forums.gentoo.org/viewtopic.php?t=1126471)]. |
-| **union-fs / mergerfs** | Agregar múltiplos sistemas de ficheiros (incluindo o FUSE mount) num único ponto de montagem lógico. | Flexibilidade na gestão de armazenamento heterogéneo [[23](https://github.com/trapexit/mergerfs/issues/869)]. | Não é uma solução de cache de memória; pode introduzir complexidade e potenciais gargalos de desempenho [[23](https://github.com/trapexit/mergerfs/issues/869)]. |
-
-Em suma, embora os blocos de construção individuais para a arquitetura de memória virtual do Saddle sejam tecnologias maduras e bem compreendidas, a sua integração numa solução coesa e escalável é onde reside a maior incerteza técnica. A premissa de que "armazenamento bytes and compute-memory bytes are the same bytes" é uma simplificação poderosa para a concepção do sistema, mas a realidade operacional envolverá um compromisso constante entre a latência do armazenamento remoto, o consumo de memória do software de montagem, a velocidade do cache de memória e a eficiência da troca comprimida. A viabilidade do projeto depende da capacidade de projetar e otimizar estas interacções para minimizar os gargalos e manter o consumo de recursos dentro de limites sustentáveis, especialmente em relação à memória RAM, que é o recurso mais escasso e crítico nestes ambientes.
-
-## Arquitetura de Orquestração Distribuída e Utilização de Recursos Gratuitos
-
-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 `@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.
-
-A tabela seguinte resume as características e limitações das plataformas de computação propostas, destacando os desafios para a orquestração distribuída pelo Saddle.
-
-| Plataforma | Tipo de Recurso | Limitações Chave | Viabilidade para Saddle |
-| :--- | :--- | :--- | :--- |
-| **GitHub Actions** | Runners Alojados e Codespaces | Tempo de execução máximo por job (ex: 6 horas); limitações de memória (ex: 14 GB); custo para minutos excedentes [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. | Baixa-média. O risco de falhas por falta de memória é alto [[27](https://github.com/actions/runner/issues/1051), [28](https://github.com/microsoft/AL-Go/issues/781)]. A orquestração depende de múltiplas plataformas para mitigar isto. |
-| **GitLab CI** | Minutos de CI Mensais | Limite de 400 minutos/mês no plano gratuito [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. | Média. A quota de tempo é um fator limitante importante que requer gestão eficiente da carga de trabalho. |
-| **Forgejo / Gitea** | Auto-hospedado | Capacidade teoricamente ilimitada, mas dependente da infraestrutura subjacente e da manutenção do executor [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. | Alta. Oferece recursos estáveis e previsíveis, sendo uma boa base para executores confiáveis. |
-| **ModelScope** | Caderneta Jupyter VM | Disponibilidade e política de uso para tarefas computacionais prolongadas são incertas [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. | Baixa. A natureza imprevisível e potencialmente restritiva torna-o um recurso de baixa confiança. |
-| **Registos de Pacotes (npm, Docker)** | Execução de Código | Permite a execução de código como parte de processos de build ou deploy. Pode ser usado como um executor de tarefas simples [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. | Baixa. As capacidades computacionais e as quotas são geralmente muito limitadas. |
-
-A estratégia de utilizar uma frota heterogénea de plataformas de terceiros é tecnicamente viável e representa uma abordagem moderna à computação distribuída. No entanto, o sucesso do Saddle não estará no seu conhecimento das APIs individuais, mas na sofisticação do seu motor de orquestração. Este motor precisa de ser um "mestre do campo", capaz de tomar decisões dinâmicas sobre onde executar cada parte de uma tarefa complexa. Ele deve ponderar o custo implícito (consumo de memória, tempo de execução, risco de falha) de cada plataforma e alavancar a fragmentação para construir uma máquina virtual coesa e resiliente. O desafio principal é transformar a instabilidade e a heterogeneidade inerentes a este modelo em uma vantagem competitiva, proporcionando um ambiente de execução aparentemente homogéneo e de alto desempenho, tudo enquanto opera "nas sombras" de gigantes da tecnologia, sem violar os seus termos de serviço.
-
-## Gestão de Infraestrutura, Automação e Contornos de Segurança
-
-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 `@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 `@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
-
-A avaliação da viabilidade do Saddle não pode ser puramente teórica; ela exige uma análise crítica do seu desempenho real e dos riscos operacionais inerentes ao seu modelo de funcionamento descentralizado. Ao examinar as evidências disponíveis, surgem paralelos interessantes com soluções comerciais de computação acelerada e emergem claramente os gargalos que podem limitar a eficácia do sistema. A proposta de valor do Saddle — um sistema de memória virtual gratuito e ilimitado — colide diretamente com as realidades físicas da computação: a latência da rede, a capacidade finita dos recursos de hardware e a complexidade da gestão distribuída.
-
-Uma análise comparativa revela que, embora o Saddle aspire a criar uma experiência de memória local, ele dependerá de uma stack de software complexa que, por si só, introduz significativos atrasos. Soluções comerciais como o Depot, que se focam em acelerar pipelines de CI/CD, oferecem uma perspetiva valiosa. O Depot implementa um acelerador de disco em memória de nível de bloco, que intercepta as operações de E/S do disco e as redireciona para uma área de memória RAM [[25](https://news.ycombinator.com/item?id=43506574)]. Esta abordagem de nível inferior é fundamentalmente diferente da do Saddle, que depende do sistema de ficheiros do kernel e de ferramentas como o `rclone`. A vantagem do Depot é o controlo explícito: pode-se instruir o sistema para persistir imagens de Docker ou outros artefactos grandes em RAM, garantindo que não sejam evitados pelo algoritmo de substituição de página LRU (Least Recently Used) do kernel, que age de forma oportunista [[25](https://news.ycombinator.com/item?id=43506574)]. O Saddle, ao contrário, está sujeito ao comportamento do sistema de ficheiros padrão, o que significa que o seu "cache" de memória pode ser menos eficiente e mais difícil de prever. Além disso, o Depot utiliza ramdisks de verdade (dispositivos de bloco em RAM montados como sistemas de ficheiros), que oferecem desempenho de E/S superior ao de um `tmpfs` tradicional, especialmente para operações aleatórias [[26](https://medium.com/@akhilesh-mishra/your-github-actions-runners-are-slow-and-you-are-paying-too-much-for-them-5406577314fe)]. Embora o Saddle tente simular esta capacidade com a sua hierarquia `tmpfs`/`zram`, a sobrecarga da camada de FUSE e do `rclone` provavelmente irá mascarar a maioria, senão toda, a vantagem de desempenho potencial.
-
-Os riscos operacionais do Saddle são multifacetados e estão intrinsecamente ligados à sua dependência de infraestruturas de terceiros. O primeiro e mais óbvio risco é a instabilidade. Os runners de plataformas como GitHub Actions ou GitLab CI são recursos partilhados, sujeitos a reinicializações, atualizações e falhas de hardware que estão fora do controlo do Saddle. Uma tarefa computacional complexa e de longa duração pode ser interrompida a qualquer momento, exigindo um mecanismo robusto de verificação e recomeço, o que adiciona complexidade ao fluxo de trabalho. A segunda categoria de riscos está relacionada com os limites e as políticas das plataformas. Como já mencionado, os limites de tempo, memória e armazenamento são severos e variam entre plataformas [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE), [27](https://github.com/actions/runner/issues/1051), [28](https://github.com/microsoft/AL-Go/issues/781)]. O Saddle precisará de um motor de orquestração extraordinariamente sofisticado para navegar nestes territórios, tomando decisões informadas sobre onde executar cada sub-tarefa. A mudança de políticas por parte de uma plataforma-chave (por exemplo, Microsoft introduzindo uma taxa para runners auto-hospedados no final de 2025) pode alterar drasticamente o equilíbrio de custos e benefícios do modelo de negócio do Saddle [[26](https://medium.com/@akhilesh-mishra/your-github-actions-runners-are-slow-and-you-are-paying-too-much-for-them-5406577314fe)].
-
-A seguir, uma tabela que sintetiza os principais riscos operacionais e as suas consequências potenciais:
-
-| Categoria de Risco | Descrição do Risco | Consequência Potencial para o Saddle |
-| :--- | :--- | :--- |
-| **Instabilidade de Recursos** | Dependência de runners de terceiros que podem falhar, reiniciar ou serem desativados inesperadamente. | Interrupção de tarefas de longa duração; necessidade de lógica complexa de verificação e recomeço; resultados inconsistentes. |
-| **Consumo Oculto de Memória** | O processo de montagem `rclone` consome RAM de forma significativa, que não é creditada ao job da tarefa. | Redução da RAM disponível para a computação real; risco de falhas por falta de memória ("Out-of-Memory"); anulação da economia pretendida. [[16](https://github.com/rclone/rclone/issues/2157), [19](https://forum.rclone.org/t/rclone-mount-memory-leaks-gdrive-enumeration/16475)] |
-| **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 `@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.
-
-## Conclusões sobre a Viabilidade Prática e Potencial Futuro
-
-Após uma análise aprofundada dos componentes técnicos, da arquitetura de orquestração e dos riscos operacionais inerentes, a viabilidade prática do framework Saddle emerge como uma possibilidade intermediária, marcada por avanços significativos na fronteira da engenharia de sistemas, mas também por riscos substantivos que ameaçam a sua estabilidade e desempenho. O projeto não é impossível, mas representa um protótipo de engenharia sofisticada que combina peças de software existentes numa nova e ambiciosa configuração. A sua viabilidade final dependerá da capacidade de mitigar os gargalos identificados, principalmente aqueles relacionados com o consumo de memória e a performance de E/S.
-
-A premissa central do Saddle — transformar armazenamento em memória — é tecnicamente viável em princípio, graças à existência de tecnologias maduras como FUSE para montar sistemas de ficheiros remotos, e `tmpfs` e `zram` para criar uma hierarquia de memória virtual [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE), [5](https://spin.atomicobject.com/protecting-ubuntu-root-filesystem/), [10](https://docs.kernel.org/admin-guide/blockdev/zram.html), [21](https://rclone.org/commands/rclone_mount/)]. A integração destas tecnologias em um ecossistema automatizado, como demonstrado pela existência de acções GitHub para instalar o `rclone`, valida a viabilidade de criar um ambiente de execução dinâmico em plataformas de terceiros [[18](https://github.com/marketplace/actions/setup-rclone-action)]. No entanto, a síntese destes componentes numa máquina virtual coesa é onde reside a maior incerteza. A evidência indica que o processo de montagem remota via `rclone` pode ter um custo de memória oculto significativo, com relatos de utilizadores de consumo excessivo de RAM que podem levar a falhas de sistema [[16](https://github.com/rclone/rclone/issues/2157), [19](https://forum.rclone.org/t/rclone-mount-memory-leaks-gdrive-enumeration/16475)]. Este consumo de RAM, combinado com a alocação de `tmpfs` e `zram`, pode criar um ciclo vicioso onde o "custo" de expansão do armazenamento virtual se traduz num "custo" de memória proibitivo, anulando a economia pretendida e representando o risco mais proeminente para o projeto. Adicionalmente, a performance de E/S através de FUSE é inerentemente limitada pela latência da rede e pode ser inadequada para cargas de trabalho intensivas, como demonstrado por benchmarks que mostram velocidades comparáveis a discos rígidos padrão [[22](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29651), [24](https://forum.rclone.org/t/rclone-mount-performance-issue/43184)].
-
-A estratégia de orquestração distribuída, que alarga os recursos de computação através de múltiplas plataformas gratuitas como GitHub Actions, GitLab CI e ModelScope, é uma jogada estratégica e tecnicamente viável [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A capacidade de fragmentar e distribuir cargas de trabalho para evitar os limites de recursos de uma única plataforma é um conceito poderoso. Contudo, o sucesso desta estratégia depende de um motor de orquestração excepcionalmente robusto, capaz de gerir a heterogeneidade, as variações de políticas e a instabilidade inerentes a esta frota de recursos de terceiros. O desafio não está em fazer a chamada à API, mas em gerir o ciclo de vida completo de uma tarefa distribuída de forma resiliente e eficiente. A incerteza mais crítica neste domínio é a estratégia do Saddle para contornar os CAPTCHAs, que são um obstáculo fundamental para o acesso programático a muitos dos serviços que pretende utilizar [[1](https://cdn.qwenlm.ai/b9f87ac9-82a2-4ffc-aa86-c8227a70fa27/0d3870e4-eec0-4114-af59-4bc61f73c724_README.TXT?key=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZV91c2VyX2lkIjoiYjlmODdhYzktODJhMi00ZmZjLWFhODYtYzgyMjdhNzBmYTI3IiwicmVzb3VyY2VfaWQiOiIwZDM4NzBlNC1lZWMwLTQxMTQtYWY1OS00YmM2MWY3M2M3MjQiLCJyZXNvdXJjZV9jaGF0X2lkIjpudWxsfQ.bRWGBFygDqaxP7GECDPmmu2ZKBTDEMX99ciQ64K2NlE)]. A ausência de evidências concretas sobre a implementação e fiabilidade desta funcionalidade representa um ponto de risco elevado.
-
-Se bem-sucedido, o Saddle poderia democratizar o acesso a poder de computação, permitindo que indivíduos e pequenos grupos realizassem tarefas computacionais que hoje exigem investimentos significativos em infraestrutura de nuvem. O seu potencial futuro reside na sua capacidade de se tornar uma camada de abstração de baixo nível, transparente para o utilizador final, que mascara a complexidade da gestão distribuída e dos recursos de terceiros. No entanto, se falhar, o resultado mais provável será um sistema frustrantemente lento e instável, com custos de RAM ocultos que tornam a sua proposta de "gratuito" questionável. Em conclusão, a pesquisa indica que o framework Saddle é uma hipótese de implementação tecnicamente desafiadora, mas não impossível. A sua validação prática requer uma implementação extremamente cuidadosa, otimização de baixo nível e uma aceitação explícita dos compromissos de desempenho inevitáveis.