LOOM / 07

State & Roadmap

LOOM is a working development system being opened up, explained and made easier to use. It is not yet a turnkey product.

A public baseline, not a finished appliance

The 2026-09-15 developer preview is a clean-history source baseline. It includes the backend, command-line interfaces, documentation, instruction packs and example configuration, with private machine state and historical operator logs excluded.

The important distinction is between code that exists, a workflow that has been exercised, and a general claim of support. The snapshot below reflects the public source dated September 15, 2026. It is not a live health dashboard, a promise about a reader's installation, or a percentage-complete estimate.

Projects & applications: Implemented: file-first projects, declarations, project context, plan/apply/status and managed prerequisites.; Exercised: a real WebDAV service reached deployment and device use.; Remaining: broader application use, Portal parity and fresh application-data recovery evidence.
Knowledge & provenance: Implemented: source ingestion, exact citations, typed search, candidates, decisions and cases.; Exercised: coding-agent candidate registration and retrieval.; Remaining: representative PDF/OCR/embedding processing and a longer decision/reconciliation lifecycle in ordinary project work.
Storage & recovery: Implemented: custody catalogs, physical archives, inactive restore, Borg history and strict historical recovery compatibility.; Remaining: larger project archive/reactivation scenarios and recovery acceptance for newly deployed applications.
Agents & devices: Exercised: optional Hermes/MINA sessions, messaging and paired Mac computer use through terminal and gateway.; Remaining: general agent SSH integration, additional real workflows and clearer portability.
Execution & operations: Implemented: capability routing, jobs, events, schedules and worker policies.; Remaining: project schedule acceptance, guided installation and a unified model-driven automation adapter.

Evidence register for the reviewed public snapshot. Remaining work does not erase implemented behavior, and successful development use does not establish universal support.

First, make the existing system easier to live with

The near-term priority is not a larger command catalogue. It is a shorter path from an intention to a useful result: ordinary project files, discoverable context, a complete prerequisite report, actionable errors and operations that explain how to resume after a partial failure.

Guided CLI installation and configuration should build on the existing setup primitives. That includes hardware, node identities, credentials, networking and recovery prerequisites. It should not pretend a real disk layout or account binding can be inferred safely from a generic example.

Documentation and interface consistency are part of that work. Portal project forms still need to catch up with the file-first CLI. Maintainer-specific assumptions need to become explicit operator configuration. These illustrated pages provide orientation; a separately rendered documentation site and fuller real interface visuals remain future publication work.

Then follow whole workflows

The most useful next checks follow actual work: create a project, develop it with an agent, deploy an application, record a decision, retrieve its evidence, change that decision, archive the project and later return to it. Each step can reveal a gap that a component-level success misses.

Process representative Notes material through queues, extraction, chunking, optional embeddings and OCR. Distinguish an intentionally disabled worker from a failed one.
Verify fresh application-data protection and recovery for a selected deployment, rather than borrowing confidence from an older unrelated backup.
Exercise larger archive, inactive restore and explicit reactivation flows with their search and citation consequences.
Use project schedules and automation lifecycle controls in normal operation, with visible identity, concurrency and failure behavior.

This is a development system with recovery mechanisms, not a reason to build a second replica platform for every patch. Focused checks and direct use on owned data are the intended feedback loop.

Extend deliberately

General authorized SSH between nodes, clearer agent workspace portability and a bounded LOOM-owned agentic-run adapter are planned extensions. Agent-specific instructions belong to projects or identities; the shared adapter should own execution history and failure semantics without creating a competing scheduler.

Additional installation targets and packaged releases follow a repeatable reference setup. Mobile/iOS control, further connectors and broader autonomy remain deferred ideas, not capabilities promised by this preview. The roadmap is directional and carries no release-date commitment.

Inspect it, try it, improve it

You can read the source and build the CLI without running the entire system. The installation guide separates that from provisioning a functioning host. The checked-in Nix host is an evaluation example with synthetic identities and disk labels, not a configuration to activate unchanged.

LOOM is released under Apache-2.0. Useful contributions simplify a real workflow, fix a reproducible bug or make a confusing boundary understandable. You do not need a particular agent, Basecamp account or access to the maintainer's machines.

Read the contribution guide, then use GitHub issues for bounded bugs and proposals. Include the relevant version, expected behavior and a small reproduction. Keep credentials, private paths and user content out of public reports.