Ailice

The code and README indicate that AIlice can control the local environment by default and can launch modules using configured commands; the README also describes system administration and script execution. Least privilege and control of external effects are therefore weak (0). Users can configure modules and services, but the materials do not show confirmation gates for high-impact actions (1). The README describes API-key configuration, chat-history storage, and service communication, but gives limited detail on data retention and transfer boundaries (data-flow transparency 1; sensitive-data handling 1). It recommends a VM or Docker to limit risk, but the evidence offers little about recovery beyond those containment suggestions (rollback 1). Dependencies include wildcards and broad version ranges, with no security audit or mitigation shown (dependency security 0). An author and MIT license are identified, but no clear security-reporting or maintenance contact process is shown (source attribution 1).

The README's described capabilities partly match the entry-point code, but it includes both older and newer model examples, and `ailice` and `ailice_web` have different implementation details; self-consistency is partial (1). The dependency set is broad and many versions are not locked; the README also warns that optional features can cause dependency conflicts (dependency availability 1). The code logs exceptions and retries module startup, but some initialization errors are printed before exiting, with limited recovery guidance for users (failure messages 1).

The README covers research, coding, documents, speech, and system administration, and explains local and commercial model configuration (audience and scenarios 2). It explicitly identifies missing Windows command execution, limited Windows testing, and risks from local control and public exposure (capability boundaries 2). Example tasks are concrete, but the general-purpose autonomous framing does not clearly specify when to invoke each capability or decline a task (trigger precision 1). Installation guidance covers Ubuntu, macOS, Windows/WSL, Docker, CUDA, and optional features, though support is not equally mature across environments (environment fit 2).

The README has a table of contents and organized installation, configuration, and model sections, though the supplied packet does not include the complete documentation (information architecture 2). Installation steps, system requirements, and optional dependencies are covered, but users must still make some security and environment decisions themselves (install notes 2). Product name, command entry points, and agent types are mostly stable in the supplied material (naming stability 2). The README includes many concrete examples and practical tips, but no clear FAQ section is evident (examples and FAQ 2). It documents Windows limitations, model hardware needs, Google access restrictions, and temporary removal of sharing (known limitations 2). The full license text matches the metadata (license 3). The README has dated update notices but no clear release history or mapping to the reviewed revision (versioning and changelog 1). An author email is present, but ongoing maintenance responsibility, cadence, and issue-handling path are unclear (maintenance responsibility 1).

The product offers a web chat interface, model selection, history storage, and tool modules, but the materials do not establish output quality, format stability, or reusable-result guarantees (output usability 1). The agent-tree design, module extension, and multi-model configuration could add value for complex tasks, with relevant scenarios supplied in the README (marginal value 2). The README describes substantial local-model hardware needs and model downloads for speech and optional features, but provides no task-level cost estimates or comparison of alternatives (cost-benefit 1).

Most capability claims are project assertions; some configuration and startup behavior can be matched to code and package configuration, but evidence for actual task outcomes is limited (claim traceability 1). The README, entry-point code, dependency configuration, and installation workflow provide some corroboration of project structure and setup, but the workflow is manually triggered and the packet does not establish that it ran (cross-source corroboration 1). The README sometimes places goals, example tasks, and claimed capabilities side by side without consistently distinguishing demonstrations from verified results (fact-inference separation 1).