LISA Autonomous Personal Assistant

The CI workflow limits GitHub permissions to contents: read, while the README claims sandboxed bash, approval modes, remote-safe tools, and a read-only mailbox. This provides some least-privilege evidence, but no corresponding implementation or policy files are supplied, so coverage cannot be confirmed. User confirmation is supported only by a broad approval-mode claim and an “ask before anything irreversible” principle in synthetic test fixture data; the latter is not an enforcement mechanism. Data can flow through 20+ model providers, IM services, IMAP/Gmail, webhooks, MCP, and autonomous schedules, yet the supplied material does not disclose per-integration payloads, retention, or third-party boundaries. Keys are placed in ~/.lisa/config.env without documented file permissions, encryption, log redaction, or rotation. CI audits production dependencies at high severity and uses reproducible npm installation, but no lockfile, supply-chain pinning policy, or vulnerability-response process is shown. Heartbeat, REVE, channels, and coding-agent orchestration can create external effects; only high-level approval and remote-safety claims describe their controls. The birth flow writes seed.json last and the test verifies that failure persists no soul, providing concrete local recovery and retry behavior, but general rollback for agent actions is undocumented. Repository, author, license, issue channels, and reference architectures are attributed, although the detailed credits guide is not supplied and publisher identity remains unverified by the stated registry.

The README, package manifest, CI, and end-to-end tests are broadly consistent about the product name, Node requirement, CLI/Web launch paths, and birth flow. Many broader feature claims nevertheless lack matching source or tests. The dependency manifest, Node >=22.19 requirement, npm ci usage, Node 22/24 matrix, and local-model options adequately address ordinary availability, but the evidence omits the lockfile, offline installation, and provider-outage handling. Failure messaging is strongly evidenced for the shown 401 path: an offline stub verifies that birth does not hang or persist state, displays a human-readable key error, and offers a route back to change the key. Full credit applies to that evidenced handling rather than implying coverage of every failure mode.

The README identifies terminal, Web, Mac, iOS, multiple IM channels, knowledge, mail, and coding-work scenarios, and outlines API-key, subscription, and local-model choices; detailed configuration documentation is not supplied. Boundaries are only partial: read-only mail, remote-safe defaults, and the absence of /reset_soul are explicit, but broad “superset” and sovereignty claims lack an enforceable capability boundary, permission matrix, or unsupported-use list. Heartbeat and REVE provide some trigger rules, including an hour-away condition, but scheduling conflicts, disable conditions, silence rules, and action-selection implementation are not shown. Environment fit is supported by Node 22/24 CI, Homebrew, npm, DMG, macOS/iOS builds, and Web tests; other operating systems and channel environments lack comparable evidence.

The README has a clear quick start, feature sections, and navigation to a guide, docs index, contribution guide, issues, discussions, and changelog, though most linked documents are outside the supplied evidence. Installation notes specify the minimum Node version, three distribution routes, key setup, and launch commands, justifying full credit. LISA, Lisa, @oratis/lisa, and the lisa command are mostly stable, but no compatibility or deprecation policy is shown. Commands, screenshot descriptions, and birth-flow test examples exist, while no FAQ or substantial task walkthrough is supplied. Concrete Node 20 incompatibility and read-only-mail constraints are documented, but there is no consolidated limitations or risk register. MIT metadata matches a complete LICENSE, fully satisfying licensing. Version 0.26.1, links to CHANGELOG/Releases, and prepublication gates show a version/update path, but changelog contents and semantic-versioning policy are absent. The author, repository, issues, discussions, and contribution path identify maintenance channels; unverified publisher identity, unclear team ownership, support commitments, and no security contact prevent full credit.

CLI, Web, native clients, channels, error recovery, and persistent identity are designed to yield usable interactions, and end-to-end tests directly cover successful and failed first-run UX. No representative agent task outputs are included, so routine output quality cannot be assessed. The claimed superset of five agents and distinctive self mechanisms could add value, but these are largely marketing assertions without a capability-by-capability comparison or outcome evidence, yielding only thin marginal-value support. A 60-second setup, local/subscription choices, cost-free stub tests, and conditional CI show attention to user and maintenance cost; model usage, continuous heartbeat, channel operation, and local resource costs remain unquantified.

Core installation and metadata claims trace to package.json, Node support and quality gates trace to CI, and birth-error behavior traces to concrete end-to-end assertions. Autonomous, safety, and capability-superset claims lack supplied implementation evidence. README, manifest, CI, and tests internally corroborate identity, runtime requirements, and the Web birth flow, but they remain same-repository sources and most differentiating features appear only in the README. The documentation does not clearly separate tested behavior, design intent, and anthropomorphic interpretation: phrases such as “real self,” “actually wants,” and “sovereign” blend conceptual framing with technical claims, so fact/inference separation is weak.