Inno Agent

Trust scores are conservative. Least_privilege(1): the agent runs bash, files, a WebSocket terminal, IM channels and cron with OS sandbox only optional (pi-sandbox, requires ripgrep); deducted for non-sandboxed default. User_confirmation(1): `closeBehavior: ask` and 409 blocker details exist, but no described confirmation gate for dangerous bash/file writes. Data_flow_transparency(2): memory writes are stated to go through inspectable/editable tools (L1), architecture and layout are clear; deducted for describing flows only at README level with no code-level audit-log evidence. Sensitive_data_handling(1): API keys sit in plaintext config. which the server hot-rewrites; showcase export claims sanitization but runtime protections lack evidence. Dependency_security(1): npm overrides pin axios and xlsx is vendored — some care shown, but no audit policy and transitive Pi SDK deps unassessed. External_effects(1): proactive messaging to Feishu/WeChat/QQ, scheduled jobs, workspace writes — broad effects with unspecified default authorization. Rollback(1): no update/rollback mechanism described; the server hot-rewrites config with no backup mentioned. Source_attribution(2): Pi SDK (Mario Zechner, MIT) properly credited, honest 'kernel never modified' claim, citation block present; deducted because publisher is registry-unverified and macOS builds are unsigned.

Self_consistency(2): the Non-goals section explicitly states single-process/no-multi-tenant constraints consistent with the architecture; deducted because the root README says no test runner is wired up while the release workflows run vitest as a gate — a mild, possibly temporal, tension. Dependency_availability(2): Content Hub has local caching plus bundled offline presets, showing remote-unavailability design; deducted because the default hub is a third-party repo outside the maintainer's control. Failure_messages(2): 409 session_busy with blocker details surfaced to the UI is a concrete, designed failure path; deducted because it is the only documented instance and no unified error-handling policy is described.

Audience_and_scenarios(3): an exceptionally clear single-learner positioning with a 'Why' stance, explicit non-goals, Simple Mode presets for non-technical users, and use-case docs — full marks justified. Capability_boundaries(2): concurrency/multi-user boundaries are well drawn, but the agent's operational limits (what it may execute) are thinly described. Trigger_precision(1): L3 recall is called 'threshold-gated' and cron is natural-language, but threshold values and false-trigger handling have no static evidence; environment trigger conditions are undefined. Environment_fit(2): three-tier path resolution (flag > env > default), Docker, three delivery forms, Node >=20.6 engines — good coverage; deducted for unexplained platform dependencies (WeChat bridge modes, ripgrep scattered across docs).

Information_architecture(3): README → QUICKSTART → backend README → docs/ layering, layout table, route table, and deployment layout are all present — full marks. Install_notes(3): three install paths with complete commands, a config template, and API-key steps, plus a dedicated system-dependency doc. Naming_stability(2): `inno` CLI, package names and path conventions are consistent, but the project is at 0.5.x and the default provider name 'innospark' against an example baseUrl is mildly confusing; no stability commitment stated. Examples_and_faq(2): QUICKSTART, skill tutorial and use-cases exist; no general FAQ or product-level troubleshooting beyond the showcase handbook. Known_limitations(3): the Non-goals section is a textbook limitations statement with a design-discussion issue link — full marks. License(3): full MIT text in-repo with dependency licensing noted. Versioning_changelog(2): semver tag-driven release workflows with prerelease rules are complete, but no CHANGELOG file or per-version change notes are shown. Maintenance_responsibility(1): Contributing section and a WeChat community group exist, but there is no governance, maintainer list, or response commitment; long-term maintenance path is unclear for a personal repo.

Output_usability(2): traceable tool-writes to L1/L2, session replay, i18n and themes show output designed for the learning use case; deducted because these are claims with no static mechanism detail on output-quality constraints. Marginal_value(2): 'layered memory over flat chat summary' and 'durable facts go to tools' form a genuine differentiation argument against general coding agents, with an intended technical report; deducted because the differentiated effect cannot be statically verified. Cost_benefit(2): the deliberately single-process architecture reduces complexity and local models (Ollama) can control spend; deducted that the Electron + full-stack + SQLite footprint is not light for a personal companion, users bear LLM API costs, and no cost estimate is given.

Claim_traceability(2): design decisions link to issue #124, doc paths are concrete and checkable, release workflows gate on vitest; deducted because headline claims (three-layer memory benefit, L2 retrieval quality) lack statically checkable data in-scope — the eval script exists but no results are shown. Cross_source_corroboration(1): an arXiv report, a third-party hub repo and the Pi SDK npm package are referenced, but all fall outside this review's scope and cannot be corroborated; deducted for lack of an independent second source within scope. Fact_inference_separation(2): Non-goals and stance sections clearly separate factual constraints from design positions, and the showcase's 'real UI' claim has a code-level mechanism; deducted for marketing-style phrasing ('real session', future-dated artifacts) unverifiable statically.