Rovai AI

Evidence shows an Electron desktop plus Rust Core/Host, and SECURITY.md enumerates risk surfaces (approval/permission bypass, cross-Camp data leakage, path traversal, symlink escape, credential isolation), indicating awareness of permission boundaries. However, the repository contains no verifiable permission model, default permission tiers, approval trigger conditions, or data-flow inventory; README defers to external docs. least_privilege = 1: per-teammate permission configuration is asserted but not evidenced. user_confirmation = 1: SECURITY.md implies an approval mechanism and an explicit highest-permission mode, but no default confirmation policy is shown. data_flow_transparency = 1: the architecture diagram and the statement that agents and project files stay on the connected host are directional only; no concrete inventory of storage, logs, or export scope. sensitive_data_handling = 1: SECURITY.md asks reporters to redact credentials and private paths, showing intent, but there is no evidence of secret storage, encryption, or isolation implementation. dependency_security = 2: package.json pins exact versions, CI uses --frozen-lockfile and --ignore-scripts, and all GitHub Actions are pinned by commit SHA — verifiable supply-chain hygiene; no dependency audit/vulnerability scanning is shown, so not full marks. external_effects = 1: README states that finishing a run, completing a mission, and merging code are separate actions, and SECURITY.md flags repeated external actions after cancellation, but no idempotency or external-effect inventory exists. rollback = 1: SECURITY.md mentions cancellation/recovery and update integrity, but no rollback procedure, data migration reversal, or recovery steps are documented in-repo. source_attribution = 1: LICENSE and package.json attribute murray17, but publisher identity is unverified and README leans on external sites and video that cannot be cross-checked in-repo.

self_consistency = 2: workspace version 0.4.5 in Cargo.toml matches package.json 0.4.5, and Rust 1.85 / Node 24 claims agree across README, Cargo.toml, package.json, and CI; no contradictions found. dependency_availability = 2: exact-version dependencies with pnpm-lock.yaml and --frozen-lockfile, plus complete Node 24 and Rust stable setup steps in CI, support reproducibility; no offline/mirror guidance, and one dependency is a beta (dingtalk-stream 2.1.6-beta.1). failure_messages = 1: CI has a fail-closed path-detection fallback that enables all checks, which is good practice, but runtime error messaging, diagnostics, and user-visible failure semantics have no in-repo evidence; SECURITY.md only asks reporters for logs.

audience_and_scenarios = 2: README targets teams using installed coding agents and names concrete scenarios — desktop, self-hosted Server, browser remote access, Feishu/DingTalk channels. capability_boundaries = 2: README states that model choice, permissions, Skills, and MCP depend on the agent and host platform, and that Desktop and Server keep separate data without migration or sync — clear boundaries. trigger_precision = 1: no verifiable definition of agent triggers, delegation rules, or scheduling semantics; only narrative about the Mission board and scheduled work. environment_fit = 1: README lists macOS arm64/x64 and Windows x64, and CI covers Linux/Windows/macOS plus a Debian VM, so environment coverage has evidence; Linux desktop is absent from the README support list and runtime prerequisites beyond minimum OS are unspecified, hence the deduction.

information_architecture = 2: README is well-sectioned by capability, configuration, missions, remote access, quick start, architecture, and docs, with links to docs/development and docs/architecture. install_notes = 2: source build steps (pnpm install --frozen-lockfile, pnpm dev) plus desktop download and Server install entry points are given, but installation detail is largely hosted externally and incomplete in-repo. naming_stability = 2: package name rovai-ai, product name Rovai AI, appId ai.rovai.desktop, and binaries rovai-core/rovai-host/rovai are consistent. examples_and_faq = 1: README has screenshots, a video, and a small first-task walkthrough, but no FAQ, common-error guidance, or configuration examples. known_limitations = 1: SECURITY.md notes the project is pre-release and older builds need upgrades, and README mentions Server 'release limitations', but there is no consolidated limitations list. license = 3: full MIT text in LICENSE, MIT declared in Cargo.toml and package.json, and a matching README badge — three-way corroboration. versioning_changelog = 1: version 0.4.5 is consistent across Cargo.toml and package.json, but there is no CHANGELOG file; release notes point to build/release-notes.md and external Releases. maintenance_responsibility = 1: SECURITY.md provides a private vulnerability channel and response commitment, but publisher identity is unverified and there is no maintainer list, governance, or support lifecycle.

output_usability = 2: positioned as a multi-agent collaboration workspace with shared conversations, execution visibility, file preview, Mission board, and collaborative memory; the output shape is understandable for the target user, though no runnable sample output or artifact is included. marginal_value = 2: lasting teammate identity, cross-task memory, and multi-agent division of labor differentiate it from a single-agent CLI, and README describes this concretely; no quantified comparison against existing tools. cost_benefit = 1: Cargo.toml comments indicate 100-250 MB runtime binaries, the build needs Rust 1.85+ and Node 24+, and users must separately install and sign in to multiple coding agents — high cost with no in-repo performance, resource, or benefit measurements, so only 1.

claim_traceability = 1: most capability claims point to external rovai.dev docs, and in-repo implementation and test evidence is limited, so claims cannot be traced individually. cross_source_corroboration = 1: version, license, and platform support are partially corroborated across README, Cargo.toml, package.json, and CI, but core capability claims lack a second in-repo source. fact_inference_separation = 1: README blends marketing narrative with facts ('lasting teams', 'grows together') and does not clearly separate shipped features from planned ones, making fact versus inference hard to distinguish.