somora

The README clearly identifies local storage locations, user-selected external model services, the data sent by the daily update check, and two opt-out mechanisms. It also describes per-agent tool gates, builder workspace confinement, normal-user installation, confirmation before administrative access, plan approval, stopping, and takeover controls. Deductions apply because shell, tmux, browser, SSH, schedules, and external MCP integrations create a broad effects surface; the web client is explicitly LAN-trust with no authentication, while approval coverage, secret-at-rest protection, and log redaction are not fully established by the supplied files. Dependencies have constraints and a Node floor, but no supplied lockfile, vulnerability scan, SBOM, or supply-chain verification, and the recommended installation pipes a remote script into a shell. Stop and takeover controls are not rollback for filesystem or system changes. Repository, package, homepage, and MIT attribution are present, but the LICENSE names the copyright holder only as “suspect” and publisher identity is unknown.

README, package.json, and LICENSE are broadly consistent about the product name, MIT license, Node requirement, repository, and core positioning. The README also lists alternative model backends, hard and optional dependencies, and several backend-specific constraints. Deductions apply because most functional and end-to-end verification claims occur only in the README and cannot be checked against implementation or test contents in the supplied evidence. Availability still depends on external CLIs, model services, tmux, browsers, and native modules. Failure messaging is evidenced mainly for an unsupported Node version and a setup health check; the quality of network, authentication, tool, and service failure messages is not shown.

The source thoroughly distinguishes chat, team coordination, software-building, memory, voice, mobile, scheduled, and self-hosted-model scenarios. It clearly separates chat agents from builders by prompts, tools, memory behavior, workspace, and lifecycle, and documents optional features, backend differences, and operating requirements. Trigger precision is deducted because schedules, delegation, dream cycles, and skill activation are described conceptually, but their complete matching rules, conflict handling, and false-trigger protections are not present in the supplied files.

The README has strong installation, requirements, quickstart, architecture, client, status, and documentation navigation, with interactive, manual, and source-development paths. The complete MIT text agrees with package metadata. Naming is generally consistent, but the calendar-like version scheme and compatibility guarantees are unexplained. Examples are extensive, although no dedicated FAQ is supplied. Limitations such as active-development status, the Grok restriction, untested hosted media-provider paths, and unauthenticated LAN-trust access are disclosed, but there is no systematic known-issues inventory. A package version, update command, and issue tracker are identified, yet no changelog, release policy, support window, named maintainer, or security contact is shown; the “suspect” copyright label further weakens maintenance attribution.

Three clients, a shared queue, memory, documented artifact locations, task panels, and takeover controls give reasonably concrete accounts of how outputs become usable. A unified multi-model tool surface, delegation, and locally shared knowledge represent plausible value beyond a basic single-agent chat tool. Deductions apply because these benefits are primarily product claims and screenshot references, without implementation evidence or representative output artifacts in the supplied material. Requirements and optional services are disclosed, but model expense, resource consumption, operational burden, and the point at which deployment complexity outweighs benefit are not quantified.

The README routes many claims to named documentation sections and distinguishes implemented, optional, limited, and not-live-tested capabilities. package.json independently corroborates identity, version, entry point, Node floor, dependencies, scripts, and repository metadata, while LICENSE corroborates the license. Deductions apply because the referenced documentation, implementation, test results, and lockfile are not included, leaving many safety and feature claims traceable only to the same README. Fact and uncertainty are often separated, but statements such as “feature-complete,” “used daily,” and the compatibility matrix lack verification records in the supplied evidence.