Omniforge

One system. Every language. One universal execution fabric.

Omniforge is a local-first distributed execution fabric. Jobs are routed to independently executable language workers that speak a shared protocol called OFP, the Omniforge Protocol. The project is no longer a collection of disconnected examples. It is a cooperating runtime where different languages perform real work inside one larger system.

The repository now also carries a broader catalog layer in languages/, where each tracked language directory has concrete metadata, a toolchain manifest, and example code without being falsely counted as an operational worker.

Omniforge is also being upgraded into a polyglot autonomous reliability platform while keeping the Omniforge name. The goal is a self-healing software runtime built out of specialized language workers rather than a rebrand into a different product identity.

Omniforge is also intentionally presented as a rainbow repository: a visibly broad, multi-language codebase where the language surface is part of the identity rather than hidden in the background.

The CLI is the single public entry point for the repository:

python omniforge.py help-topics

Build a release artifact with:

powershell -ExecutionPolicy Bypass -File scripts/build-cli-release.ps1

Artifacts are written to dist/:

• dist/omniforge-cli-latest.zip
• dist/omniforge-cli-dev-<timestamp>.zip

Generated caches, workspace-local shims, temporary job inputs, and release staging output are intentionally local-only and ignored through .gitignore.

Audit language catalog drift against the actual worker/runtime state:

python omniforge.py languages doctor

Clear safe local clutter on demand:

python omniforge.py cleanup
python omniforge.py cleanup --dry-run

cleanup clears CLI state, stale release artifacts, safe cache paths, and orphaned repo helper processes. It preserves current source files, runtime shim directories, and dist/omniforge-cli-latest.zip.

Badge layout for validated OFP workers:

Container-ready workers:

Still blocked:

Omniforge accepts jobs such as parsing data, applying rules, validating records, computing statistics, or producing artifacts. A coordinator resolves the requested capability, selects a worker based on language and capability metadata, dispatches the job, and collects structured results.

The next product direction is incident-driven:

• observe applications, repositories, services, and infrastructure
• classify incidents
• route investigations to specialized workers
• produce structured repair plans
• verify repairs
• store incident learnings for future routing and evaluation

Current implemented vertical slice:

• apps/coordinator/: Go coordinator, registry, scheduler, and pipeline runner
• apps/cli/: Python CLI that wraps the coordinator and provides local UX
• protocol/: OFP schemas, fixtures, and specification
• workers/: independently executable workers in multiple languages
• pipelines/: cross-language pipeline definitions
• tests/: end-to-end verification

The first real Omniforge pipeline is data-intelligence.

It runs:

1. Python worker parses and cleans CSV rows
2. Ruby worker applies rule-based classifications
3. JavaScript worker validates transformed records
4. Go worker computes summary statistics
5. Rust worker compresses the final artifact

This is a real pipeline with real data flow. It does not use mocked worker responses.

Client
  |
  v
Omniforge CLI
  |
  v
Go Coordinator
  |
  +-- Registry
  +-- Scheduler
  +-- Pipeline Runner
  +-- Worker Process Manager
  |
  v
Language Workers (stdio + OFP JSON messages)

Workers communicate over newline-delimited JSON messages. OFP v1 now defines 31 message types across:

• handshake and session control
• discovery and capability negotiation
• job execution and cancellation
• artifact transfer
• health, metrics, and tracing

The protocol is versioned as ofp/1.

Core minimum messages still implemented broadly today:

• HELLO
• REGISTER
• JOB_START
• JOB_PROGRESS
• JOB_RESULT
• JOB_ERROR
• SHUTDOWN

Implemented now in the coordinator and the stable Python, Ruby, JavaScript, and Go worker slice:

• WELCOME
• REGISTER_ACK
• JOB_ACCEPTED
• JOB_LOG
• JOB_CANCEL
• SHUTDOWN_ACK

The CLI now exposes timed cancellation for real testing:

python omniforge.py run data.csv-transform --language python --input .cache/job-python.json --cancel-after-ms 25

Expanded OFP v1 messages now documented for adoption:

• WELCOME
• REGISTER_ACK
• CAPABILITIES
• CAPABILITY_QUERY
• CAPABILITY_RESPONSE
• PING
• PONG
• HEARTBEAT
• HEALTH_REPORT
• WORKER_STATUS
• METRICS_SNAPSHOT
• JOB_ACCEPTED
• JOB_LOG
• JOB_STREAM
• JOB_CANCEL
• JOB_CANCELLED
• ARTIFACT_PUT
• ARTIFACT_GET
• ARTIFACT_REF
• ARTIFACT_CHUNK
• ARTIFACT_COMPLETE
• TRACE_START
• TRACE_STOP
• SHUTDOWN_ACK

Omniforge now includes worker-connected specialist bots. These are ordinary OFP workers that inherit a language assignment from either:

• an explicit assignedLanguage
• or a delegateWorkerId from another registered worker

They then return options for what that language does best using the local capability registry plus a language-specialty map.

Current bot capabilities:

• bot.language-plan
• bot.execution-options
• bot.pipeline-handoff

Example:

python omniforge.py run bot.language-plan --language omniforge-bot --input workers/specialist-bot/examples/language-plan.json

Current operational workers:

• Python: data.csv-transform
• Ruby: rules.evaluate
• JavaScript: data.validate
• Go: statistics.summary
• Rust: system.compress
• Java: text.word-count
• C: system.file-hash
• C++: algorithm.sort
• C#: system.process-info
• F#: math.statistics
• VB: text.reverse
• PowerShell: system.environment
• Awk: text.tokenize
• Bash: text.uppercase
• Perl: text.regex
• TypeScript: text.slugify
• sh: text.lowercase
• Lua: text.template
• Batch: text.length
• CMake: text.replace-cmake
• findstr: text.search-findstr

Current support levels are tracked honestly in docs/support-matrix.md.

Catalogued language directories and their admission boundary are tracked in docs/language-catalog.md.

Container packs are documented in docs/CONTAINERS.md. The repo now includes docker-compose.yml plus systems, functional, scientific, and full development images so extra OFP languages can run inside containers instead of requiring direct host installs.

Reliability-platform foundation documents now live in:

• docs/ARCHITECTURE.md
• docs/WORKERS.md
• docs/LANGUAGE-ROLES.md
• docs/PROTOCOL.md
• docs/SAFETY.md
• docs/INCIDENT-LIFECYCLE.md
• docs/REPAIR-POLICY.md
• docs/THREAT-MODEL.md
• docs/RUNBOOKS.md
• docs/ROADMAP.md

python omniforge.py workers list
python omniforge.py capabilities
python omniforge.py pipeline run pipelines/data-intelligence.yaml --input examples/data/customers.csv
python omniforge.py run text.template --language lua --input examples/data/template-input.json
python omniforge.py toolchains detect

python omniforge.py pipeline run pipelines/data-intelligence.yaml --input examples/data/customers.csv

The final result includes:

• cleaned records
• rule classifications
• validation summary
• aggregate statistics
• compressed artifact

omniforge/
├── apps/
│   ├── cli/
│   └── coordinator/
├── protocol/
│   ├── conformance/
│   ├── fixtures/
│   ├── schemas/
│   └── specifications/
├── workers/
│   ├── go/
│   ├── javascript/
│   ├── lua/
│   ├── python/
│   ├── ruby/
│   └── rust/
├── pipelines/
├── toolchains/
├── docs/
├── examples/
├── tests/
└── .github/

The current implementation is local-first and process-isolated. Workers are spawned as separate OS processes and communicate only through OFP messages over stdio. The repository documents the intended stronger isolation model in docs/security.md.

Current implemented safeguards:

• protocol validation at the message layer
• process boundaries between coordinator and workers
• explicit capability routing
• structured worker errors
• graceful worker shutdown

Not yet implemented in code:

• CPU and memory enforcement
• filesystem sandboxing per worker
• container isolation
• worker authentication
• network policy enforcement

Those gaps are listed clearly in the roadmap and support matrix.

The long-term goal is broad language participation, but a language is only counted when it has a real execution path.

A worker is considered operational only when it has:

• metadata
• launch command
• OFP handshake
• at least one capability
• automated test coverage

• add official SDKs for core languages
• add registry persistence and benchmark history
• add more workers from installed runtimes
• add containerized language packs
• add dashboard and job inspection UI
• add stronger sandboxing and resource limits

This phase implements a functioning Omniforge core and a real cross-language pipeline. It does not yet satisfy the full 30-language target from the long-range vision. Unsupported and partially supported languages are listed honestly in docs/support-matrix.md.