@wenathlan/saddle 1.8.14 → 1.8.15

package/docs/plans/41.o.que.falta.md

@@ -8,7 +8,7 @@
 
 ## Sumário
 
-`@devthink/webscrape` é um toolkit all-in-one que combina scraping, serialização multi-formato, AI formatting e chunking para RAG — um posicionamento único no mercado. No entanto, 3 gaps críticos impedem a adoção em produção: ausência de anti-detection real, queue persistente e suporte Docker. Este documento lista tudo que falta, priorizado por impacto.
+`@wenathlan/webscrape` é um toolkit all-in-one que combina scraping, serialização multi-formato, AI formatting e chunking para RAG — um posicionamento único no mercado. No entanto, 3 gaps críticos impedem a adoção em produção: ausência de anti-detection real, queue persistente e suporte Docker. Este documento lista tudo que falta, priorizado por impacto.
 
 ---
 
@@ -146,7 +146,7 @@
 - Puppeteer: `chrome-devtools-mcp`
 
 **Implementação necessária:**
-1. Criar pacote `@devthink/webscrape-mcp`
+1. Criar pacote `@wenathlan/webscrape-mcp`
 2. Expor endpoints como MCP tools: `scrape`, `crawl`, `batch`, `extract`, `serialize`
 3. Usar SDK oficial `@modelcontextprotocol/sdk`
 4. Adicionar configuração MCP ao `cli.ts`

package/docs/plans/42.pesquisa.concorrencia.md

@@ -1,7 +1,7 @@
 # Competitive Research: webscrape vs. 7 Competitors
 
 > **Date:** 2026-06-08
-> **Objective:** Deep analysis of 7 direct/indirect competitors to identify gaps, opportunities, and architectural insights for the `@devthink/webscrape` toolkit.
+> **Objective:** Deep analysis of 7 direct/indirect competitors to identify gaps, opportunities, and architectural insights for the `@wenathlan/webscrape` toolkit.
 
 ---
 
@@ -601,7 +601,7 @@ Request → [Downloader Middlewares] → Downloader → [Spider Middlewares] →
 **Impact:** Cannot be used by AI agents (Claude, Cursor, Windsurf) natively.
 
 **Recommendation:**
-- Create `@devthink/webscrape-mcp` package
+- Create `@wenathlan/webscrape-mcp` package
 - Expose scrape/crawl/batch endpoints as MCP tools
 - Integrate with Claude Desktop, VS Code, Cursor
 

package/docs/plans/43.plan.universal.architecture.md

@@ -2,7 +2,7 @@
 
 ## 1. Visão Geral
 
-A biblioteca `@devthink/webscrape` precisa funcionar em **TODOS os modos**:
+A biblioteca `@wenathlan/webscrape` precisa funcionar em **TODOS os modos**:
 
 | Modo | Como funciona |
 |------|--------------|
@@ -404,7 +404,7 @@ export default defineConfig({
 
 ```json
 {
-  "name": "@devthink/webscrape",
+  "name": "@wenathlan/webscrape",
   "version": "2.0.0",
   "type": "module",
   "main": "./dist/index.js",

package/docs/plans/44.reference.md

@@ -81,7 +81,7 @@ files, and deployment payloads with edge caching.
 
 ### NPM Publishing
 
-Package `@devthink/saddle` available as both library and
+Package `@wenathlan/saddle` available as both library and
 CLI binary.
 
 ## Architecture Rules (from arch skill)

package/docs/plans/45.robotarchitecture.md

@@ -175,13 +175,13 @@ CMD ["node", "server.js"]
 
 ## NPM Package Publishing
 
-Saddle can be published as an NPM package `@devthink/saddle` for
+Saddle can be published as an NPM package `@wenathlan/saddle` for
 distribution as both a library and a CLI tool.
 
 ### Package Structure
 
 ```
-@devthink/saddle/
+@wenathlan/saddle/
 ├── lib/
 │   ├── browser.js        (agent browser engine)
 │   ├── bot.js            (multi-platform bot engine)
@@ -200,7 +200,7 @@ distribution as both a library and a CLI tool.
 
 | Mode | Entry Point | Usage |
 |------|------------|-------|
-| Library | `require('@devthink/saddle')` | Import as Node module |
+| Library | `require('@wenathlan/saddle')` | Import as Node module |
 | CLI | `saddle --command capture` | Run as terminal command |
 | Binary | `node_modules/.bin/saddle` | Direct execution |
 

package/docs/plans/46.scdnintegration.md

@@ -144,7 +144,7 @@ class SCDNClient {
 
 ```typescript
 // In browser capture module
-import { SCDNClient } from '@devthink/saddle/deploy'
+import { SCDNClient } from '@wenathlan/saddle/deploy'
 
 async function uploadCaptureSession(
   sessionData: SessionData,

package/docs/plans/README.md

@@ -2,7 +2,7 @@
 
 Binary computing agent, agent browser, computer-use, scraper and packager.
 
-> **Storage turned into memory.** Saddle runs on other people's computers (GitHub Actions, Forgejo, Gitea, GitLab, Codeberg, free Docker containers) and turns unlimited third-party storage buckets into virtual RAM/GPU/CPU. **Nothing runs on the operator's local machine.** Ships as a library, CLI, binary, n8n node, CRX extension, Android/iOS and Tauri desktop app. Package `@devthink/saddle` — published to npm, GitHub Packages, Maven, NuGet, RubyGems and GitHub Containers (auto-mirrored to jsDelivr). It is simultaneously **sandbox + virtual machine + webhook server + workflow orchestrator (n8n-style) + packager + deployment system + integration platform** — sometimes each *is* the other three; the virtual VMs expose vCPU/VRAM/vGPU/virtual processing to the user, 100% on the internet, 100% virtual.
+> **Storage turned into memory.** Saddle runs on other people's computers (GitHub Actions, Forgejo, Gitea, GitLab, Codeberg, free Docker containers) and turns unlimited third-party storage buckets into virtual RAM/GPU/CPU. **Nothing runs on the operator's local machine.** Ships as a library, CLI, binary, n8n node, CRX extension, Android/iOS and Tauri desktop app. Package `@wenathlan/saddle` — published to npm, GitHub Packages, Maven, NuGet, RubyGems and GitHub Containers (auto-mirrored to jsDelivr). It is simultaneously **sandbox + virtual machine + webhook server + workflow orchestrator (n8n-style) + packager + deployment system + integration platform** — sometimes each *is* the other three; the virtual VMs expose vCPU/VRAM/vGPU/virtual processing to the user, 100% on the internet, 100% virtual.
 
 This document is the single source of truth, arranged as a progressive arc: **Foundation (1–6)**, **Engine (7–17)**, **Productization (18–31)**. Nothing here is attributed to external tooling; it is the project's own architecture.
 
@@ -368,7 +368,7 @@ Where a platform has no formal app portal (Telegram, Matrix), the robot is still
 
 Sources: `api.kilo.ai`, `opencode.ai/zen`, `openrouter.ai`. Count with `js-tiktoken` / `gpt-tokenizer`.
 
-22. **Packaging & Publishing** — `@devthink/saddle` as **lib + CLI** (`saddle`); install `npm install @devthink/saddle` (global for CLI). Package layout: `lib/index.js` + `bin/saddle.js` (`node:util parseArgs{command, platform, token, verbose}`, default `help`), exports map subpaths `./browser, ./bot, ./captcha, ./memory-engine, ./deploy` (import/require dual) + `./index.cjs`. Scripts: `"build":"tsc"`, `"test":"vitest run"`, `"lint":"biome check ."`, `"typecheck":"tsc --noEmit"`, `"prepublishOnly":"npm run build && npm test"`, `"prepare":"husky"`. Version: semver `npm version patch|minor|major` + `git push --follow-tags`. Library API: `import { SaddleRobot } from '@devthink/saddle'; await robot.start(); await robot.executeCommand(cmd)`. `npm publish --access public` → auto-mirror jsDelivr/UNPKG/esm.sh.
+22. **Packaging & Publishing** — `@wenathlan/saddle` as **lib + CLI** (`saddle`); install `npm install @wenathlan/saddle` (global for CLI). Package layout: `lib/index.js` + `bin/saddle.js` (`node:util parseArgs{command, platform, token, verbose}`, default `help`), exports map subpaths `./browser, ./bot, ./captcha, ./memory-engine, ./deploy` (import/require dual) + `./index.cjs`. Scripts: `"build":"tsc"`, `"test":"vitest run"`, `"lint":"biome check ."`, `"typecheck":"tsc --noEmit"`, `"prepublishOnly":"npm run build && npm test"`, `"prepare":"husky"`. Version: semver `npm version patch|minor|major` + `git push --follow-tags`. Library API: `import { SaddleRobot } from '@wenathlan/saddle'; await robot.start(); await robot.executeCommand(cmd)`. `npm publish --access public` → auto-mirror jsDelivr/UNPKG/esm.sh.
 
 | Registry | What |
 |----------|------|

package/docs/plans/missing-facts.md

@@ -118,7 +118,7 @@ FILE: 40.npm.publish.md
 - Pre-publish checklist
 - As library (npm install) and CLI (npm install -g, saddle --command)
 - Binary entry point: saddle.js
-- Scoped package structure: @devthinking/saddle/
+- Scoped package structure: @wenathlaning/saddle/
 - Versioning strategy: semver (patch/minor/major)
 - 10-step pre-publish checklist
 - No mention of these npm details

package/docs/registryresearch.md

@@ -34,15 +34,15 @@ The live GHCR workflow `31544093172` completed successfully, and the public pack
 
 ## live verification
 
-The first `publishgithubnpm.yml` run failed with HTTP 403 because `@devthink/saddle` was not an authorized package namespace for the `iakadion/saddle` workflow. The corrected run `31543249301` completed successfully after rewriting the package name in the CI workspace to `@iakadion/saddle`. However, the repository Packages page still returned an empty listing immediately afterward, and the available GitHub API token could not read the user package namespace. The next verification must query the owner package page directly and inspect the workflow publish logs before treating the successful exit code as visible package availability.
+The first `publishgithubnpm.yml` run failed with HTTP 403 because `@wenathlan/saddle` was not an authorized package namespace for the `iakadion/saddle` workflow. The corrected run `31543249301` completed successfully after rewriting the package name in the CI workspace to `@iakadion/saddle`. However, the repository Packages page still returned an empty listing immediately afterward, and the available GitHub API token could not read the user package namespace. The next verification must query the owner package page directly and inspect the workflow publish logs before treating the successful exit code as visible package availability.
 
 The v1.7.0 release verification used workflow logs as the available artifact evidence. GitHub npm run `31549603859` published `@iakadion/saddle@1.7.0`; GHCR run `31549603838` pushed `ghcr.io/iakadion/saddle:1.7.0` and `latest`; Maven retry run `31549802841` uploaded `io.devthink:saddle:1.7.0`; RubyGems retry run `31549804286` registered `saddle (1.7.0)`; and NuGet retry run `31549972311` created and pushed `Saddle.1.7.0.nupkg`. The GitHub package-list API was not readable with the available integration token, so these statements are limited to successful workflow upload evidence rather than an independent package-page listing.
 
-The first public npmjs run `31549603849` used OIDC and returned HTTP 404. Retry `31551708958` used the configured `NPM_TOKEN` secret, and retry `31551771374` confirmed that the masked secret reached the runner after newline normalization; both still returned HTTP 404 for `@devthink/saddle`. The identity-check retry `31552368723` reached `npm whoami` with a masked token but npm returned HTTP 401. The remaining blocker is the token itself or its account/scope permission: the owner must replace `NPM_TOKEN` with a valid raw npm access token authorized to publish `@devthink/saddle`. The exposed token from the prior conversation remains deliberately unused.
+The first public npmjs run `31549603849` used OIDC and returned HTTP 404. Retry `31551708958` used the configured `NPM_TOKEN` secret, and retry `31551771374` confirmed that the masked secret reached the runner after newline normalization; both still returned HTTP 404 for `@wenathlan/saddle`. The identity-check retry `31552368723` reached `npm whoami` with a masked token but npm returned HTTP 401. The remaining blocker is the token itself or its account/scope permission: the owner must replace `NPM_TOKEN` with a valid raw npm access token authorized to publish `@wenathlan/saddle`. The exposed token from the prior conversation remains deliberately unused.
 
 The cross-runtime workflow `31552266171` and its manual rerun `31552272176` completed successfully. The matrix ran the root probe on Node, Bun and Deno and the deterministic Node suite. The root entry no longer imports filesystem, Node HTTP, persistent queue, file-session or local-memory adapters; those remain explicit Node-only subpaths.
 
-Release `v1.8.0` was created from commit `9ddfd6c`. GitHub npm run `31556461901`, GHCR run `31556461887`, NuGet run `31556461883` and RubyGems run `31556461991` completed successfully for `1.8.0`. Maven run `31556461885` initially failed because setup-java rejects `latest`; after changing the workflow to JDK 26, manual run `31556549154` completed successfully. Public npmjs run `31556461909` produced the `@devthink/saddle@1.8.0` tarball but the registry rejected the PUT with HTTP 404 `Scope not found`; no public npmjs publication is claimed.
+Release `v1.8.0` was created from commit `9ddfd6c`. GitHub npm run `31556461901`, GHCR run `31556461887`, NuGet run `31556461883` and RubyGems run `31556461991` completed successfully for `1.8.0`. Maven run `31556461885` initially failed because setup-java rejects `latest`; after changing the workflow to JDK 26, manual run `31556549154` completed successfully. Public npmjs run `31556461909` produced the `@wenathlan/saddle@1.8.0` tarball but the registry rejected the PUT with HTTP 404 `Scope not found`; no public npmjs publication is claimed.
 
 The active package identity on main is now `@wenathlan/saddle`. The repository has since transferred to `wenathlan`; the authenticated `iakadion` account retains administrator permission. Release `v1.8.2` is the first release prepared against the transferred repository owner for GitHub Packages npm, Maven and GHCR.
 

package/docs/release17notes.md

@@ -21,4 +21,4 @@ The release was prepared with the deterministic Node test runner, format checks,
 
 ## Registry targets
 
-The release workflows target GitHub Packages npm, npmjs through OIDC Trusted Publishing, GHCR, Maven, NuGet and RubyGems. Each package is verified from its workflow result before being reported as published. npmjs publication remains conditional on the one-time Trusted Publisher configuration for `@devthink/saddle`.
+The release workflows target GitHub Packages npm, npmjs through OIDC Trusted Publishing, GHCR, Maven, NuGet and RubyGems. Each package is verified from its workflow result before being reported as published. npmjs publication remains conditional on the one-time Trusted Publisher configuration for `@wenathlan/saddle`.

package/docs/releasenotes-1.8.14.md

@@ -14,7 +14,7 @@ Saddle 1.8.14 carries the active code and release-facing manifests forward from
 
 ## Artifact contract
 
-The active workflows derive names from the `v1.8.14` release tag. The expected artifact family is listed below; attached-asset counts and registry conclusions must be updated only after the release workflows finish.
+The active workflows derive names from the `v1.8.14` release tag. The release was verified with 38 uploaded assets listed below; iOS remains unavailable because Apple signing and provisioning are caller-owned and were not configured.
 
 | Surface | Expected artifact family |
 |---|---|
@@ -28,22 +28,37 @@ The active workflows derive names from the `v1.8.14` release tag. The expected a
 
 Signing remains explicit. `unsigned`, `ci-test-key`, `caller-owned`, `notarized` and a provider-reported status are distinct states. These notes do not claim SignPath approval or production signing.
 
+## Verified attached assets
+
+The release contains **38 uploaded assets**. Desktop artifacts are unsigned, Android artifacts use the explicitly labeled `ci-test-key`, the container is `caller-owned` and the extension is unsigned.
+
+| Surface | Attached assets | Signing |
+|---|---|---|
+| Linux desktop | `saddle.browser.1.8.14.arm64.appimage`, `saddle.browser.1.8.14.arm64.deb`, `saddle.browser.1.8.14.arm64.rpm`, `saddle.browser.1.8.14.x64.appimage`, `saddle.browser.1.8.14.x64.deb`, `saddle.browser.1.8.14.x64.rpm` | `unsigned` |
+| Windows desktop | `saddle.browser.1.8.14.arm64.exe`, `saddle.browser.1.8.14.arm64.msi`, `saddle.browser.1.8.14.x64.exe`, `saddle.browser.1.8.14.x64.msi`, `saddle.browser.1.8.14.x86.exe`, `saddle.browser.1.8.14.x86.msi` | `unsigned` |
+| macOS desktop | `saddle.browser.1.8.14.arm64.app.zip`, `saddle.browser.1.8.14.arm64.dmg`, `saddle.browser.1.8.14.x64.app.zip`, `saddle.browser.1.8.14.x64.dmg` | `unsigned` |
+| Android | `saddle.apk.1.8.14.apk`, `saddle.aab.1.8.14.aab` | `ci-test-key` |
+| Container | `saddle.container.1.8.14.tar.gz` | `caller-owned` |
+| Browser extension | `saddle.extension.1.8.14.zip` | `unsigned` |
+| Manifests | Nine `manifest.*.1.8.14.json` files covering Android, container, Linux, macOS and Windows | metadata |
+| Checksums | Nine `sha256.*.1.8.14` files covering Android, container, Linux, macOS and Windows | integrity metadata |
+
 ## Registry publication
 
 The six registry workflows derive the version from the same `v1.8.14` release tag through `.github/actions/releaseversion`. GHCR is listed first in the package order and must build, scan, push, pull and smoke-test the published image before the job is successful. The remaining workflows publish GitHub Packages npm, public npmjs, Maven, NuGet GitHub Packages and RubyGems from the same validated version. Public `nuget.org` is not targeted by the current repository workflow.
 
-| Registry | Workflow | Version | Expected result |
+| Registry | Workflow | Version | Verified result |
 |---|---|---:|---|
-| GHCR | `publishghcr.yml` | `1.8.14` | build, scan, push, pull and smoke test |
-| GitHub Packages npm | `publishgithubnpm.yml` | `1.8.14` | tag-derived package |
-| Public npmjs | `publishnpmjs.yml` | `1.8.14` | tag-derived package |
-| Maven GitHub Packages | `publishmaven.yml` | `1.8.14` | tag-derived package |
-| NuGet GitHub Packages | `publishnuget.yml` | `1.8.14` | tag-derived package |
-| RubyGems GitHub Packages | `publishrubygems.yml` | `1.8.14` | tag-derived package |
+| GHCR | `publishghcr.yml` | `1.8.14` | success; run `31806235613` also pulled, inspected and smoke-tested the image |
+| GitHub Packages npm | `publishgithubnpm.yml` | `1.8.14` | success; run `31806235570` |
+| Public npmjs | `publishnpmjs.yml` | `1.8.14` | success; run `31806235515` |
+| Maven GitHub Packages | `publishmaven.yml` | `1.8.14` | success; run `31806235540` |
+| NuGet GitHub Packages | `publishnuget.yml` | `1.8.14` | success; run `31806235606` |
+| RubyGems GitHub Packages | `publishrubygems.yml` | `1.8.14` | success; run `31806235523` |
 
 ## Verification policy
 
-Local gates must pass before the tag is created. The release notes must be amended with effective asset names and workflow conclusions only after remote verification. Production signing remains pending until caller-owned certificates and provider configuration are supplied.
+Local gates passed before the tag was created. Desktop run `31806235468` completed successfully. The release-event mobile run `31806235484` correctly refused to claim production signing because the Android secrets were absent; manual run `31806605994` with `allow_test_signing=true` completed successfully and attached the APK/AAB as `ci-test-key`. Production signing remains pending until caller-owned certificates and provider configuration are supplied.
 
 ## References
 

package/docs/releasenotes-1.8.15.md

@@ -0,0 +1,37 @@
+# Saddle 1.8.15
+
+Saddle 1.8.15 adds transport-neutral contracts for verified storage, bounded working sets, isolated transformations, provider selection and immutable delivery. The shared core remains declarative: it does not create runners, start containers, register service workers, mutate DNS, transfer artifacts or execute binaries without a caller-owned adapter.
+
+## Changes
+
+| Area | Change |
+|---|---|
+| Storage | Added verified pool reads, primary/mirror/fan-out writes, quorum evidence, operation budgets, range reads, repair plans and verified-source restore plans. |
+| Memory | Added bounded working-set admission, capability-gated bridge plans, materialization transitions and declarative cleanup plans. |
+| Transformations | Added magic-byte classification, bounded WASM plans, isolated adapters, archive inspection limits and cache eligibility controls. |
+| Providers | Added capability-based selection, caller preferences, dry-run rendering, integrity-bound handoff and cancellation plans with unknown remote state preserved. |
+| Delivery | Added immutable chunk manifests, verification without evaluation, PWA/CDN capability reports, Mini App validation requirements and DNS/application bridge descriptors. |
+| Validation | Active tests increased to 132 while the 69 legacy tests remain green; package, flat native, web and audit gates passed. |
+
+## Artifact contract
+
+The release workflows derive artifact names and package versions from `v1.8.15`. The following artifact families are expected from the release pipelines; signing remains explicit and is never inferred from a filename.
+
+| Surface | Artifact family |
+|---|---|
+| Linux desktop | `saddle.browser.1.8.15.<architecture>.deb`, `.rpm`, `.appimage` |
+| Windows desktop | `saddle.browser.1.8.15.<architecture>.exe`, `.msi` |
+| macOS desktop | `saddle.browser.1.8.15.<architecture>.dmg`, `.app.zip` |
+| Android | `saddle.apk.1.8.15.apk`, `saddle.aab.1.8.15.aab` |
+| iOS | `saddle.ipa.1.8.15.ipa`, `saddle.app.1.8.15.app.zip` |
+| Container | `saddle.container.1.8.15.tar.gz` |
+| Browser extension | `saddle.extension.1.8.15.zip` |
+
+## Publication and verification policy
+
+The six registry workflows publish from the same validated release tag, in container-first order: GHCR, GitHub Packages npm, public npmjs, Maven, NuGet GitHub Packages and RubyGems. GHCR must build, scan, push, pull, inspect its OCI version label and complete a smoke check. Production signing remains caller-owned; the release does not claim SignPath approval, Apple notarization or a production Android signing key unless a workflow reports those states.
+
+## References
+
+[1]: https://github.com/wenathlan/saddle "Saddle source repository"
+[2]: https://github.com/wenathlan/saddle/releases "Saddle release archive"

package/docs/talks9/README (2).md

@@ -2,7 +2,7 @@
 
 Binary computing agent, agent browser, computer-use, scraper and packager.
 
-> **Storage turned into memory.** Saddle runs on other people's computers (GitHub Actions, Forgejo, Gitea, GitLab, Codeberg, free Docker containers) and turns unlimited third-party storage buckets into virtual RAM/GPU/CPU. **Nothing runs on the operator's local machine.** Ships as a library, CLI, binary, n8n node, CRX extension, Android/iOS and Tauri desktop app. Package `@devthink/saddle` — published to npm, GitHub Packages, Maven, NuGet, RubyGems and GitHub Containers (auto-mirrored to jsDelivr). It is simultaneously **sandbox + virtual machine + webhook server + workflow orchestrator (n8n-style) + packager + deployment system + integration platform** — sometimes each *is* the other three; the virtual VMs expose vCPU/VRAM/vGPU/virtual processing to the user, 100% on the internet, 100% virtual.
+> **Storage turned into memory.** Saddle runs on other people's computers (GitHub Actions, Forgejo, Gitea, GitLab, Codeberg, free Docker containers) and turns unlimited third-party storage buckets into virtual RAM/GPU/CPU. **Nothing runs on the operator's local machine.** Ships as a library, CLI, binary, n8n node, CRX extension, Android/iOS and Tauri desktop app. Package `@wenathlan/saddle` — published to npm, GitHub Packages, Maven, NuGet, RubyGems and GitHub Containers (auto-mirrored to jsDelivr). It is simultaneously **sandbox + virtual machine + webhook server + workflow orchestrator (n8n-style) + packager + deployment system + integration platform** — sometimes each *is* the other three; the virtual VMs expose vCPU/VRAM/vGPU/virtual processing to the user, 100% on the internet, 100% virtual.
 
 This document is the single source of truth, arranged as a progressive arc: **Foundation (1–6)**, **Engine (7–17)**, **Productization (18–31)**. Nothing here is attributed to external tooling; it is the project's own architecture.
 
@@ -368,7 +368,7 @@ Where a platform has no formal app portal (Telegram, Matrix), the robot is still
 
 Sources: `api.kilo.ai`, `opencode.ai/zen`, `openrouter.ai`. Count with `js-tiktoken` / `gpt-tokenizer`.
 
-22. **Packaging & Publishing** — `@devthink/saddle` as **lib + CLI** (`saddle`); install `npm install @devthink/saddle` (global for CLI). Package layout: `lib/index.js` + `bin/saddle.js` (`node:util parseArgs{command, platform, token, verbose}`, default `help`), exports map subpaths `./browser, ./bot, ./captcha, ./memory-engine, ./deploy` (import/require dual) + `./index.cjs`. Scripts: `"build":"tsc"`, `"test":"vitest run"`, `"lint":"biome check ."`, `"typecheck":"tsc --noEmit"`, `"prepublishOnly":"npm run build && npm test"`, `"prepare":"husky"`. Version: semver `npm version patch|minor|major` + `git push --follow-tags`. Library API: `import { SaddleRobot } from '@devthink/saddle'; await robot.start(); await robot.executeCommand(cmd)`. `npm publish --access public` → auto-mirror jsDelivr/UNPKG/esm.sh.
+22. **Packaging & Publishing** — `@wenathlan/saddle` as **lib + CLI** (`saddle`); install `npm install @wenathlan/saddle` (global for CLI). Package layout: `lib/index.js` + `bin/saddle.js` (`node:util parseArgs{command, platform, token, verbose}`, default `help`), exports map subpaths `./browser, ./bot, ./captcha, ./memory-engine, ./deploy` (import/require dual) + `./index.cjs`. Scripts: `"build":"tsc"`, `"test":"vitest run"`, `"lint":"biome check ."`, `"typecheck":"tsc --noEmit"`, `"prepublishOnly":"npm run build && npm test"`, `"prepare":"husky"`. Version: semver `npm version patch|minor|major` + `git push --follow-tags`. Library API: `import { SaddleRobot } from '@wenathlan/saddle'; await robot.start(); await robot.executeCommand(cmd)`. `npm publish --access public` → auto-mirror jsDelivr/UNPKG/esm.sh.
 
 | Registry | What |
 |----------|------|

package/docs/talks9/README.md

@@ -22,13 +22,13 @@ Saddle is a **JavaScript ESM engine** for jobs that move data between storage, a
 Saddle requires **Node.js 22 or newer**.
 
 ```bash
-npm install @devthink/saddle
+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 "@devthink/saddle";
+import { scrapeurl, formatforagent } from "@wenathlan/saddle";
 
 const result = await scrapeurl("https://example.com", {
   format: "markdown"
@@ -95,7 +95,7 @@ import {
   localmemory,
   localstorage,
   scheduler
-} from "@devthink/saddle";
+} from "@wenathlan/saddle";
 
 const events = eventbus();
 const run = engine({
@@ -155,7 +155,7 @@ The release is distributed through the following GitHub Packages registries.
 | 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 `@devthink/saddle` for the public npmjs workflow. GitHub Packages uses `@iakadion/saddle` because the GitHub Actions token is authorized for the repository owner namespace.
+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
 

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.