DashClaw

Evidence shows real least-privilege design: default-deny /api/* middleware, public-route allowlist, admin/member gates, separation of duties (SELF_APPROVAL_FORBIDDEN), SSRF DNS pinning and private-IP rejection, so least_privilege scores 2; deducted because hooks run at the agent's own privilege and can be tampered by a same-privilege process, which the README itself admits. user_confirmation scores 3: remote approvals, fail-closed interception, non-downgradable block, and previewable/revocable standing grants are well evidenced. data_flow_transparency scores 2: docs describe guard decisions, DLP redaction, and evidence-graded intent, but actual data flows (e.g., LLM/third-party calls) are only partially disclosed. sensitive_data_handling scores 2: DLP scanning, AES-GCM+AAD, masking, and secrets excluded from bundles exist, but historical audits exposed plaintext leaks and unauthenticated CBC, showing residual surface even if fixed. dependency_security scores 1: dependencies use floating ^ ranges, the xlsx vulnerability is 'accepted risk' rather than fixed, and control relies on Dependabot/overrides without proof of ongoing mitigation. external_effects scores 2: explicitly admits external effects are not exactly-once and require reconciliation; runGoverned does not repeat callbacks, honest but not thorough. rollback scores 1: observe mode, env rollback switches, immutable outcomes and parent_action_id recovery exist, but no user-facing one-click rollback/undo of executed effects is evidenced. source_attribution scores 1: MIT and author field present, but publisher identity is unverified and there is no signed release or provenance proof beyond metadata.

self_consistency scores 2: README and SECURITY docs agree on enforcement boundary, claim protocol, and upgrade order, with self-corrections (e.g., 'no exactly-once promise'), but the docs are very long with dated history and drift risk. dependency_availability scores 1: requires Node 20+, Postgres, optional Redis/Upstash, Docker or embedded PG, and CI installs cli/mcp-server deps separately; evidence for ordinary-environment fit is thin. failure_messages scores 2: docs describe 409 outcome already set, SELF_APPROVAL_FORBIDDEN, not_approved/expired/hash_mismatch errors, but these are assertions without a complete error catalog.

audience_and_scenarios scores 3: explicitly targets solo devs/small teams running long unattended sessions (overnight, CI, background fleets) with concrete scenarios. capability_boundaries scores 3: a dedicated 'What DashClaw is not' section rules out general tracing/platform/hard isolation, honestly drawn. trigger_precision scores 2: decision lattice allow<warn<allow_contained<require_approval<block, join=max, absolute block are clear, but prompt-injection scanning and calibration thresholds are asserted without detailed precision evidence. environment_fit scores 2: supports Claude Code/Codex/Hermes/OpenClaw/MCP/Node/Python/REST, but mechanical enforcement is limited to a few seams and the rest is cooperative, so fit is uneven.

information_architecture scores 2: README is well structured with anchors and separates THESIS/MAINTAINER/maintainer-log, but the single file is extremely long and dense. install_notes scores 2: npx dashclaw up, Vercel deploy, and per-runtime install commands are present, but Docker/Postgres and multi-package installs make steps heavy. naming_stability scores 1: version 5.38.0 with many historical version references (v2.6/v4.63/v5.20) and a large, frequently changing API surface (41/61 methods, 136 routes) show insufficient stability evidence. examples_and_faq scores 2: examples/, QUICK-START, integration guides and snippets exist, but FAQ-style content is scattered. known_limitations scores 3: a dedicated section lists non-universal enforcement, non-tamper-proofing, non-battle-tested scale, and non-exactly-once effects, disclosing limits thoroughly. license scores 3: full MIT text in LICENSE and MIT in package.json, consistent. versioning_changelog scores 2: CHANGELOG references, maintainer log, and version-sync scripts exist, but no complete changelog file content is shown. maintenance_responsibility scores 2: MAINTAINER.md charter, AI maintainer under human-held charter, and public maintainer log make responsibility clear; deducted because publisher identity is unverified.

output_usability scores 2: approvals inbox, CLI, PWA, Telegram/Discord channels, decision records and signed receipts are usable, but receipts only prove signed contents, not external effects, limiting output utility. marginal_value scores 2: provides remote approval and audit trail for unattended runs, an increment over local permission prompts, but cooperative integrations require caller cooperation, weakening the increment. cost_benefit scores 1: requires self-hosted Postgres, multiple secrets, and multi-runtime hook maintenance at high cost while enforcement is limited to a few seams, so benefit/cost evidence is insufficient.

claim_traceability scores 2: many README claims link to docs (enforcement-boundary, durable-execution-finality, maintainer log) and are traceable, but some performance/calibration claims are bare assertions. cross_source_corroboration scores 2: README, SECURITY.md, SECURITY_FIXES, and CI workflows corroborate security fixes and tests, but all are self-reported with no independent third-party verification. fact_inference_separation scores 2: docs distinguish mechanical vs cooperative enforcement, receipt scope, and client-reported diagnostics vs attestation, separating fact from inference well, though marketing phrasing ('catches it before it runs') remains strong.