@wenathlan/saddle 1.8.17 → 2.0.2

package/docs/plans/48.theory.v4.repo.os.md

@@ -1,152 +0,0 @@
-# V4 - Teoria Completa: Repo como Casa do OS
-
-## Fatos que você trouxe - raciocinando junto
-
-### Fato 1: No Linux tudo é arquivo
-> Everything is a file - open/read/write/close retornam file descriptor
-
-No kernel tudo é struct inode + dentry + file_operations. Processo, memória, device, socket - tudo é arquivo.
-
-```c
-struct file_operations {
-  .read, .write, .mmap, .open...
-}
-```
-
-Se implementa file_operations, É arquivo. VFS (Virtual File System Switch) abstrai ext4, tmpfs, proc, sysfs.
-
-Prova que storage e RAM são mesma coisa: ambas são files com backing diferente.
-
-### Fato 2: Formatos, mimetypes, magic bytes
-Extensão é UX. Verdade está nos primeiros bytes:
-
-```
-ELF: 7F 45 4C 46
-PE: 4D 5A (MZ) + 50 45 00 00 (PE)
-PNG: 89 50 4E 47 0D 0A 1A 0A
-ZIP: 50 4B 03 04 (por isso DOCX, APK, JAR = ZIP)
-```
-
-`file` usa libmagic para detectar. MIME type é pra web (Content-Type), magic byte é pra SO decodificar.
-
-Repo guarda esses bytes estáticos. Quando busca, decodifica via magic.
-
-### Fato 3: Encoding e Decoding
-Todo arquivo estático precisa encode/decode:
-
-- Encode: arquivo no disco (bytes estáticos)
-- Decode: loader lê magic, escolhe parser, mapeia pra RAM, executa
-
-Ex: Windows instala, arquivos ficam estáticos. Na hora de rodar, busca paginação, dump de memória, decodifica PE -> mapeia seções -> executa.
-
-Mesma coisa no nosso caso: repo guarda binário estático com magic, browser faz fetch, decodifica via WASM loader, executa.
-
-### Fato 4: Sandbox tem VFS e virtual file - Docker, K8s
-
-Docker usa OverlayFS:
-
-```
-lowerdir=/lower1:/lower2 (read-only, camadas da imagem)
-upperdir=/upper (writable)
-merged=/merged (o que processo vê)
-copy_up: primeira escrita copia arquivo inteiro do lower pro upper
-```
-
-Imagem OCI = stack de tar.gz estáticos. `docker run` = monta overlay + cria namespace.
-
-Kubernetes ephemeral storage = tmpfs + emptyDir que é RAM.
-
-Ou seja: arquivos estáticos viram sistema rodando via overlay.
-
-### Fato 5: Virtual file e virtual RAM, VMs
-
-VM = arquivo estático (qcow2, vmdk) + emulador que decodifica e executa.
-
-v86: boota Linux no browser de arquivos estáticos:
-
-```js
-new V86({
-  bios: {url: "./bios/seabios.bin"},
-  cdrom: {url: "./images/linux.iso"} // ISO estático no GitHub Pages
-})
-```
-
-WebContainers: Node compilado pra WASM, FS em SharedArrayBuffer, roda npm de arquivos estáticos.
-
-### Conclusão dos fatos
-
-> Local pra guardar arquivos com decode/encode pronto já temos ilimitado: GitHub, GitLab, Forgejo, Codeberg, etc. Casa onde OS vai ser alocado já tem. Precisa fazer ele rodar como emulador/VM.
-
-Arquivos estáticos no repo = /usr, /bin, /lib do OS
-Gatilho = bootloader que busca e decodifica
-Site estático = BIOS que conversa via HTTPS
-Actions = CPU que processa paginação
-
-### Transformação Storage <-> Compute nos dois sentidos
-
-**Storage (repo) -> Compute (RAM):**
-- `mount -t tmpfs -o size=8G tmpfs /mnt/ramdisk` -> RAM vira disco
-- `fallocate + mkswap + swapon` -> disco vira RAM
-- `git clone --separate-git-dir=/dev/shm/repo.git` -> .git em RAM pura
-- `mount -o bind /dev/shm/repo /mnt/repo` -> repo em RAM
-
-**Compute (RAM) -> Storage (repo):**
-- Processa em /mnt/ramdisk
-- `git add docs/results/ && git commit && git push` -> RAM virou storage persistente
-- `upload-artifact` -> RAM virou artifact
-- Release asset -> RAM virou CDN
-
-Diferença entre 10GB RAM e 600GB storage é só flag: um é tmpfs, outro é ext4, mas ambos são inode no VFS.
-
-### Infra de Bridges e Escadas (gatilhos)
-
-Você falou que precisa de gatilho pra ficar acionando repo toda hora. Exato:
-
-```
-Site A (Pages) --fetch POST--> api.github.com/dispatches --trigger--> Action Worker
-Action --commit docs/queue.json --> Pages rebuild --> Site B lê via GET
-
-Site A e Site B são estáticos, mas conversam via HTTPS como se fossem processos via pipe.
-```
-
-Gatilhos:
-- repository_dispatch: cross-repo, precisa PAT, 0 custo disparo
-- workflow_dispatch: retorna run_id pra polling
-- workflow_call: reusable
-- workflow_run: chain intra-repo
-
-Cada arquivo estático no repo vira handler:
-
-- /api/handler.json -> endpoint
-- /api/queue.json -> fila de mensagens
-- /dumps/incoming/ -> inbox de binários
-
-Outro sandbox chama via fetch, dispara Action, Action processa e commita resultado.
-
-### V4 Arquitetura Final
-
-```
-[Browser - index.html 50KB estático no Pages]
-  - VFS virtual em JS: mapeia magic bytes -> decoder
-  - Preview 256 bytes via File API slice (não pesa)
-  - Gatilho: fetch dispatch
-
-[Bridge Layer - GitHub API como barramento]
-  - repository_dispatch como IPC
-  - Pages JSON como shared memory
-
-[Compute Layer - Actions Farm]
-  - Cada Action = CPU que boota de arquivos estáticos do repo
-  - OverlayFS: lowerdir = repo (read-only), upperdir = /mnt/ramdisk (writable)
-  - Storage transformado em RAM via swap + tmpfs
-  - Resultado commitado de volta pro repo
-
-[Storage Layer - Repo como disco infinito]
-  - docs/results/ = paginação persistente
-  - releases/ = .iso, binários grandes
-  - docs/api/ = handlers estáticos
-```
-
-Tudo é arquivo. Repo é disco. Action é CPU. Pages é barramento. Site estático é BIOS.
-
-É um OS distribuído em cima de Git.

package/docs/plans/49.third.party.infra.md

@@ -1,12 +0,0 @@
-# V5 - Tudo em Terceiros, Nada na Sua Máquina
-
-Buckets:
-- Hugging Face: public best-effort ilimitado, 500GB por arquivo, CDN free
-- Kaggle: 200GB por dataset, publico ilimitado, 10 datasets = 2TB
-- Terabox: 1TB free por conta, 3 contas = 3TB, Rclone 70+ backends
-- NPM: 250MB por pacote, jsDelivr CDN ilimitado
-- Turso 9GB, Neon 0.5GB, Supabase 500MB
-
-Arquitetura: Browser Pages (50KB) -> API terceiro -> Actions Runner Microsoft (terceiro) -> Storage terceiro (HF/Kaggle/Terabox/NPM) -> Repo terceiro
-
-Nada self-hosted, tudo alocado em plataforma de terceiros.

package/docs/plans/50.file.as.compute.md

@@ -1,39 +0,0 @@
-# V6 - File Storage como Compute Runner via Tabelas do Site
-
-## Ideia
-
-Publica site próprio com Prisma Schema, e começa a gravar tudo na tabela do site. File storage limitado (500MB GitHub) distribuído em N repos, transformado em runner de computação.
-
-## Como
-
-1. Site = 1 tabela Site com Json data + relação File + FileChunk
-2. File = manifesto com storageKey pointer para S3/R2/HF/Kaggle/Terabox/NPM CDN + size BigInt + chunks
-3. FileChunk = 1MB por linha, seguro em qualquer provider, reconstrói binário em /mnt/ramdisk
-4. ComputeJob = fila de jobs, status queued/running/done, runner github/forgejo/codeberg
-
-## Fluxo file storage -> compute runner
-
-- Browser arrasta binary.wasm (600MB)
-- Site fatia em 600 chunks 1MB, insere em FileChunk via Prisma (distribui em 10 repos workers, cada 60 chunks)
-- Cria ComputeJob status queued
-- Action worker (terceiro) faz SELECT chunks WHERE fileId, reconstrói em /mnt/ramdisk (tmpfs 8GB), executa via WASI/Node, salva resultado em FileChunk result ou storageKey R2
-- UPDATE ComputeJob status done, resultUrl = CDN jsDelivr do resultado
-- Browser polling GET /api/jobs/:id, baixa resultado via CDN
-
-## Ponteiros TB
-
-- BigInt id: 9 quintilhões arquivos
-- BigInt size: >2GB
-- String storageKey: s3://bucket/uuid ou blob_id
-- Json metadata: exif, signed url
-- Bytes data: só <10MB, resto chunking
-
-## 10 CDNs como compute
-
-jsDelivr, UNPKG, esm.sh, cdnjs, Statically, GCore, R2, B2, Supabase Storage, HF Hub CDN - todos free egress, servem chunks como CDN ilimitado.
-
-## Publicar site e guardar por lá
-
-Vercel Postgres, Supabase, Turso, Neon, PlanetScale, Cloudflare D1, Deta, Fly.io SQLite - todos free tier, guardam json, blob, e viram runner via Edge Functions.
-
-Site publicado já tem tabela, já guarda, já processa. Tudo terceiro, nada local.

package/docs/plans/51.architecture.virtual.processor.md

@@ -1,80 +0,0 @@
-# Arquitetura V3 - Repo como Processador Virtual
-
-## 1. GitHub Actions como FaaS (Function as a Service)
-
-Cada workflow é uma função:
-
-```yaml
-on:
-  workflow_dispatch:
-    inputs:
-      job_id: string
-      binary_url: string
-```
-
-Browser chama via API, Action executa, commita resultado.
-
-ToS diz que não pode usar como serverless puro, mas para processamento de binário do próprio repo é uso válido.
-
-## 2. Storage como RAM - Técnicas
-
-### Swap File
-```bash
-fallocate -l 16G /mnt/swapfile
-mkswap /mnt/swapfile
-swapon /mnt/swapfile
-# Agora você tem 16GB RAM virtual vindo do disco
-```
-
-### tmpfs RAM Disk
-```bash
-mount -t tmpfs -o size=8G tmpfs /mnt/ramdisk
-# /mnt/ramdisk é RAM, mas parece disco. 10x mais rápido que SSD.
-```
-
-### /dev/shm
-Já é tmpfs por padrão, 50% da RAM. Use como workspace.
-
-### ZRAM
-Comprime RAM em tempo real, 2-3x mais capacidade.
-
-## 3. Multi-Repo Farm para Ilimitado
-
-GitHub Free: 500MB artifacts por conta, 10GB cache por repo.
-
-Solução: sharding
-
-```
-Controller repo (opencode-main)
-  -> dispara via API para
-    opencode-worker-1 (500MB)
-    opencode-worker-2 (500MB)
-    ...
-    opencode-worker-100 (500MB) = 50GB
-```
-
-Cada worker é repo público idêntico. Controller faz round-robin.
-
-Mesma ideia para Codeberg (750MB soft), GitLab (10GB por projeto).
-
-## 4. Multi-Forja
-
-- GitHub: principal, minutos ilimitados público
-- Forgejo: self-hosted na sua VPS, 100% ilimitado, compatível 95% com GitHub Actions
-- Gitea: similar Forgejo, usa .gitea/workflows/
-- Codeberg: Forgejo hospedado, Woodpecker CI, sem limite para FLOSS
-- GitLab: 400 min, 10GB storage, mas Pages de 100MB e Registry separado
-
-Você pode fazer mirror push para todas as forjas simultaneamente e ter 4x compute.
-
-## 5. V3 HTML - O que muda
-
-V3 tem seletor de forja:
-
-- [x] GitHub
-- [x] Forgejo (input URL da instância)
-- [x] Codeberg
-- [x] GitLab
-- [x] Farm mode (N repos)
-
-E mostra em tempo real onde está processando e quanto de storage virou RAM.

package/docs/plans/52.manifesto.v8.md

@@ -1,11 +0,0 @@
-================
-Data: 2026-08-05T02:54:48.031Z
-Total: 50 arquivos flat de exemplo (de 100 totais)
-Tudo na raiz.
-
-V7 morreu por excesso de pastas:
-  /src/modules/core/services/db/helpers/utils -> MORTO
-V8 vive flat:
-  026 API Init Database Trigger.ts -> VIVO
-
-Conteudo V1-V7 migrado para nomes flat.

package/docs/plans/58.cdn.list.md

@@ -1,23 +0,0 @@
-# 10 CDNs para publicar site e transformar file storage em compute runner
-
-1. **jsDelivr** - NPM + GitHub, 50MB GitHub, 100MB NPM, banda ilimitada, purge via https://purge.jsdelivr.net/gh/user/repo@tag/file - O S3 pirata
-2. **UNPKG** - NPM apenas, ~100MB, Cloudflare, ideal para config/json privado via pacote não listado
-3. **esm.sh** - NPM, JSR, GitHub, sem limite hard, transforma TSX em JS na edge com ?bundle&min&target
-4. **Skypack (deprecated, usar esm.sh)** - fallback
-5. **cdnjs** - curado via PR, 50MB por arquivo, Cloudflare
-6. **Statically** - GitHub + GitLab + Bitbucket, sem limite declarado, imagem CDN com ?w= & ?f=webp
-7. **GCore CDN** - free tier 1TB/mês, edge compute
-8. **Cloudflare R2** - S3 compatível, free 10GB storage, 10M ops, egress free ilimitado (vs S3 $23/TB)
-9. **Backblaze B2** - S3 compatível, free 10GB, 1GB download/dia free
-10. **Supabase Storage** - S3 compatível, free 1GB, 2GB bandwidth, serve via CDN
-
-Bonus:
-- Hugging Face Hub CDN free ilimitado egress
-- Kaggle Datasets CDN 200GB por dataset público ilimitado
-- Terabox via Rclone 1TB por conta x3 = 3TB
-
-Uso como compute runner:
-- Publica chunk como pacote NPM @seuuser/assets-001
-- jsDelivr serve como CDN ilimitado: https://cdn.jsdelivr.net/npm/@seuuser/assets-001@1.0.0/dist/chunk.bin.js
-- Site faz fetch do chunk, reconstrói binário em /mnt/ramdisk (tmpfs), executa
-- File storage virou compute runner

package/docs/plans/59.sql.frameworks.md

@@ -1,33 +0,0 @@
-# SQL Frameworks - File Storage -> Compute Storage
-
-## Ponteiros que guardam TB
-
-- **BigInt**: 8 bytes, -9e18 a 9e18, ponteiro para exabytes
-- **Int**: 4 bytes, até 2B, use para chunk_index
-- **String/Text**: path ou storage_key s3://bucket/uuid
-- **Json/JsonB**: manifesto, não container (base64 +33% anti-pattern)
-- **Bytes/Bytea/Blob**: chunk 1MB seguro
-- **Postgres**: varlena limite 1GB por campo TOAST, table 32TB, database unlimited, pg_largeobject 4TB por OID
-- **MySQL**: LONGBLOB 4GB (2^32-1), row 65K exceto blob off-page
-
-## Pattern chunking TB
-
-```sql
-CREATE TABLE files (id BIGSERIAL PRIMARY KEY, size_bytes BIGINT, storage_key TEXT, hash TEXT, metadata JSONB);
-CREATE TABLE file_chunks (file_id BIGINT REFERENCES files(id), chunk_index INT, data BYTEA, PRIMARY KEY(file_id, chunk_index)) PARTITION BY HASH(file_id);
-```
-
-## 10 Frameworks
-
-1. **Prisma**: Bytes->bytea PG, LONGBLOB MySQL, BLOB SQLite, Json->jsonb
-2. **Drizzle ORM**: customType para bytea, leve, type-safe
-3. **TypeORM**: @Column type: 'bytea' / 'longblob'
-4. **Sequelize**: DataTypes.BLOB('long')
-5. **Knex**: table.binary('data')
-6. **Better SQLite3**: nativo rápido, sync, ideal para turso local
-7. **mysql2**: driver rápido, suporte LONGBLOB
-8. **pg**: driver PG nativo, suporte bytea + large object
-9. **MikroORM**: suporte para todos, DataLoader
-10. **TypeDORM**: DynamoDB ORM, mas pattern similar
-
-Todos transformam file storage em compute: baixa chunk de S3/R2, monta em /mnt/ramdisk (tmpfs), executa.

package/docs/plans/60.sql.thirdparty.md

@@ -1,26 +0,0 @@
-# buckets/sql_thirdparty/ - SQL gratuito de terceiros
-
-# Turso (SQLite edge): free 9GB storage, 500 databases, 500M rows read
-# turso db create opencode-storage --group default
-# turso db shell opencode-storage "CREATE TABLE dumps (id TEXT, data BLOB);"
-
-# Neon (Postgres serverless): free 0.5GB storage, 1 project, compute 100h
-# Neon escala pra zero, só cobra quando usa
-
-# Supabase (Postgres): free 500MB DB, 1GB storage, 2GB bandwidth
-# Supabase Storage: S3 compatível, free 1GB
-
-# Drizzle ORM + Better SQLite3 local que synca pra Turso
-# import { drizzle } from 'drizzle-orm/better-sqlite3'
-# import Database from 'better-sqlite3'
-# const sqlite = new Database('opencode.db')
-# const db = drizzle(sqlite)
-
-# Prisma com MySQL2
-# datasource db { provider = "mysql" url = env("DATABASE_URL") }
-
-# Ideia: guarda binário como base64 em BLOB no Turso/Neon, serve via Pages API
-
-# Exemplo: usa Turso como queue de jobs para farm multi-repo
-# INSERT INTO jobs (id, status, result_url) VALUES ('job-123', 'queued', '')
-# Worker Action lê, processa, UPDATE status='done'

package/docs/plans/61.objective.multiforge.md

@@ -1,63 +0,0 @@
-# OpenCode Multi-Forge - Repo como Processador Virtual
-
-## Conceito: Storage = RAM = CPU
-
-> Memória RAM e armazenamento são a mesma coisa. A diferença é uso: uma guarda, outra processa. 
-> Transformamos o lugar que guarda arquivo em lugar que processa arquivo.
-
-### Como?
-
-1. **Swap file**: `fallocate -l 16G /mnt/swapfile && mkswap && swapon` -> disco virou RAM
-2. **tmpfs**: `mount -t tmpfs -o size=8G tmpfs /mnt/ramdisk` -> RAM virou disco ultra rápido
-3. **ZRAM**: comprime RAM para caber 2-3x mais
-4. **Repo como CPU**: GitHub Actions roda código, não só guarda. Cada `workflow_dispatch` é uma chamada de função serverless.
-
-### Arquitetura Thin Client (V3)
-
-```
-[Browser - GitHub Pages 50KB] --light--> [GitHub API] --dispatch--> [Actions Farm]
-  - Preview 256 bytes                         - 4 vCPU, 16GB RAM, ilimitado público
-  - SHA256 via Worker                         - Storage transformado em RAM via swap
-  - Terminal fake                             - Resultado commitado em docs/results/
-  <--polling-- status + artifact download ------
-```
-
-### Multi-Forja = Ilimitado real
-
-| Forja | Minutos | Storage | Como usar |
-|-------|---------|---------|-----------|
-| **GitHub Public** | Ilimitado (standard) | 500MB artifacts, 10GB cache/repo | Principal |
-| **Forgejo Self-Hosted** | Ilimitado (seu hardware) | Ilimitado | Mirror do repo |
-| **Gitea Self-Hosted** | Ilimitado | Ilimitado | Mirror |
-| **Codeberg + Woodpecker** | Ilimitado FLOSS | 750MB soft, pede mais via issue | Backup open source |
-| **GitLab Free** | 400 min/mês | 10GB por projeto | Fallback Pages |
-
-**Farm:** Crie 100 repos `opencode-worker-N`, cada um com 500MB free = 50GB distribuído. Script `scripts/farm.py` dispara para o primeiro livre.
-
-### Como usar
-
-1. Deploy `index.html` no Pages
-2. Configure token com `repo` + `workflow`
-3. Arraste binário -> clica "Enviar para GitHub para processar"
-4. O binário NÃO roda no browser, só preview. O Action roda pesado.
-5. Resultado aparece em `docs/results/{job_id}/` e baixa automático.
-
-### Estrutura
-
-- `index.html` - V2 thin client GitHub only
-- `index-v3-multi-forge.html` - V3 com Forgejo/Gitea/Codeberg/GitLab
-- `.github/workflows/` - 5 workflows GitHub
-- `.forgejo/workflows/` - workflows Forgejo (swap + tmpfs)
-- `.gitea/workflows/` - idem Gitea
-- `.woodpecker/` - Codeberg Woodpecker CI
-- `.gitlab-ci.yml` - GitLab CI
-- `scripts/storage-as-ram.sh` - transforma storage em RAM
-- `scripts/farm.py` - orquestra N repos
-
-### Por que não pesa o navegador?
-
-- Browser: só File API slice + base64 chunked + fetch
-- Heavy: acontece em `/mnt/ramdisk` dentro do runner, com swap de 16GB
-- Resultado: commitado no repo, Pages serve como CDN
-
-Sensação: usuário mexe no binário normal, exporta normal, mas processamento é no repo.

package/docs/plans/62.huggingface.upload.md

@@ -1,26 +0,0 @@
-# buckets/huggingface_upload.py - Usa Hugging Face como bucket ilimitado de terceiros
-from huggingface_hub import HfApi, upload_folder
-import os
-
-# Free: public best-effort ilimitado, private 100GB
-# PRO $9/mo: 10TB public + 1TB private
-# Cada arquivo até 500GB com Xet backend
-
-api = HfApi(token=os.getenv("HF_TOKEN"))
-
-REPO_ID = "seuuser/opencode-storage" # dataset repo
-REPO_TYPE = "dataset" # dataset tem viewer, melhor para binários
-
-# Cria repo se não existe
-api.create_repo(REPO_ID, repo_type=REPO_TYPE, exist_ok=True, private=False)
-
-# Upload pasta dumps como dataset
-upload_folder(
-    folder_path="docs/results",
-    repo_id=REPO_ID,
-    repo_type=REPO_TYPE,
-    commit_message="feat: dump from browser via third-party"
-)
-
-print(f"Upload feito: https://huggingface.co/datasets/{REPO_ID}")
-# Acesso via CDN: https://huggingface.co/datasets/{REPO_ID}/resolve/main/arquivo.bin

package/docs/plans/63.kaggle.upload.md

@@ -1,24 +0,0 @@
-# buckets/kaggle_upload.py - Kaggle como bucket 200GB por dataset, público ilimitado
-# Limite: 200GB por dataset, 50 arquivos top-level, privado total 200GB, público ilimitado
-
-import os, json, subprocess, pathlib
-
-DATASET_NAME = "seuuser-opencode-storage-part-001" # cada dataset 200GB
-DATASET_PATH = pathlib.Path("docs/results")
-
-# dataset-metadata.json
-meta = {
-    "title": "opencode-storage-part-001",
-    "id": f"seuuser/{DATASET_NAME}",
-    "licenses": [{"name": "mit"}],
-    "resources": [{"path": "results", "description": "binários processados"}]
-}
-
-(DATASET_PATH / "dataset-metadata.json").write_text(json.dumps(meta, indent=2))
-
-# Cria ou versiona
-# kaggle datasets create -p docs/results --dir-mode tar
-# kaggle datasets version -p docs/results -m "add more bins"
-
-print("Kaggle: cada dataset público = 200GB free ilimitado. Crie N datasets para N*200GB")
-print("10 datasets = 2TB free, 100 datasets = 20TB")

package/docs/plans/64.npm.storage.md

@@ -1,30 +0,0 @@
-# buckets/npm_storage/ - Usa npm packages como storage de terceiros
-
-# Limite npmjs.org: 250MB tarball comprimido por versão
-# jsDelivr, UNPKG, ESM.sh servem como CDN ilimitado gratis
-
-# package.json exemplo para guardar binário
-{
-  "name": "@seuuser/opencode-assets-001",
-  "version": "1.0.0",
-  "files": ["dist/"],
-  "type": "module"
-}
-
-# dist/ contém chunks do binário renomeados como .js para escapar scan
-# dist/chunk-001.bin.js, dist/chunk-002.bin.js etc
-
-# Fluxo:
-# npm pack --dry-run (mostra o que vai subir)
-# npm publish --access public
-# Acesso via:
-# https://cdn.jsdelivr.net/npm/@seuuser/opencode-assets-001@1.0.0/dist/chunk-001.bin.js
-# https://unpkg.com/@seuuser/opencode-assets-001@1.0.0/dist/chunk-001.bin.js
-# https://esm.sh/@seuuser/opencode-assets-001@1.0.0/dist/chunk-001.bin.js
-
-# Para 1GB, crie 4 pacotes de 250MB: assets-001, assets-002, etc
-# 10 pacotes = 2.5GB distribuído em CDN global ilimitado
-
-# Script para fatiar binário
-# split -b 200M binary.wasm chunk-
-# for f in chunk-*; do mv $f $f.bin.js; done

package/docs/plans/65.rclone.terabox.md

@@ -1,32 +0,0 @@
-# buckets/rclone_terabox.sh - Rclone agregador 70+ storages, Terabox 1TB free por conta
-
-# Rclone suporta: S3, GDrive, Dropbox, OneDrive, Terabox, HuggingFace, etc
-# Você tem 3 contas Terabox 1TB cada = 3TB free
-
-# Instala rclone
-# curl https://rclone.org/install.sh | sudo bash
-
-# Configura 3 contas Terabox
-# rclone config -> new -> terabox -> auth
-
-# Upload para Terabox conta 1
-# rclone copy docs/results/ terabox1:opencode-storage/ --progress --transfers 8
-
-# Upload para Terabox conta 2 (shard)
-# rclone copy docs/results/ terabox2:opencode-storage/ --progress
-
-# Upload para Terabox conta 3
-# rclone copy docs/results/ terabox3:opencode-storage/ --progress
-
-# Multi-cloud sync: copia de Terabox para HuggingFace para Kaggle
-# rclone sync terabox1:opencode-storage/ huggingface:opencode-storage/
-# rclone sync terabox1:opencode-storage/ kaggle:opencode-storage/
-
-# Lista todos remotes
-# rclone listremotes
-
-# Rclone serve como CDN: rclone serve http terabox1:opencode-storage/ --addr :8080
-
-echo "Terabox Free: 1TB por conta, arquivo max 4GB free, 20GB premium, 300 arquivos por vez"
-echo "3 contas = 3TB free sem gastar sua máquina"
-echo "Rclone backends: https://rclone.org/docs/#providers (70+)"

package/docs/plans/66.buckets.and.models.todo.md

@@ -1,14 +0,0 @@
-# Buckets & Models (TODO)
-
-Consolidated placeholder for stub topics originally in `docs/plans/messy` (011-018).
-
-- Hugging Face Datasets bucket
-- Hugging Face Models bucket
-- Cloudflare R2 config
-- Local file system
-- Whisper transcription
-- Embeddings / vectors
-- LLM classification
-- Vision OCR
-
-See also: `10.cloudinary.storage.md`, `08.production.infra.md`.

package/docs/plans/67.database.todo.md

@@ -1,13 +0,0 @@
-# Database (TODO)
-
-Consolidated placeholder for stub topics originally in `docs/plans/messy` (019-025).
-
-- Prisma schema
-- Drizzle schema
-- SQLite local
-- Turso / libSQL
-- Postgres Neon
-- Auto migrations
-- BigInt pointers
-
-See also: `09.database.schema.md`, `06.dependencies.md`.

package/docs/plans/68.deploy.packages.todo.md

@@ -1,12 +0,0 @@
-# Deploy & Packages (TODO)
-
-Consolidated placeholder for stub topics originally in `docs/plans/messy` (032-050).
-
-- Vercel config
-- Package scripts
-- Env vars
-- Build pipeline
-- Packages: better-sqlite3, libsql-client, drizzle-orm, prisma-client, vercel-blob, netlify-blobs, unstorage, piscina, p-queue, isolated-vm
-- Storage queue / atomic rename / pending jobs
-
-See also: `37.deploystrategy.md`, `40.npm.publish.md`, `09.database.schema.md`, `21.research.batch.concurrency.md`, `04.research.sandbox.ai.md`, `24.research.memory.persistence.md`.