Cortex

The README clearly states agents never communicate directly and all coordination flows through a shared markdown directory, giving decent data-flow transparency (data_flow_transparency=2). Least privilege is only implied at the file read/write level; no sandbox, path scope, or command-execution boundaries are defined (least_privilege=1). /setup, /register, and /join create directories, write ~/.cortex/config.yaml, and modify CLAUDE.local.md, yet no confirmation or dry-run prompt is described (user_confirmation=1). Telegram chat IDs and config are written to local files with no discussion of sensitive-data storage or redaction (sensitive_data_handling=1). Heartbeat polling, daily briefings, and automatic deletion of done tasks older than 7 days are described but lack consent and recovery mechanisms (external_effects=1). Rollback relies only on the recommendation that the team directory be a git repo and that git log preserves history; no explicit rollback procedure is provided (rollback=1). No dependency manifest or lockfile is present, so dependency security cannot be assessed (dependency_security=0). Source attribution points to agentweave and the Shuttle Protocol link, but publisher identity is unverified (source_attribution=1).

The README is internally consistent: protocol, task status lifecycle, slug rules, and directory structure align (self_consistency=2). Dependency availability is uncertain because installation depends on the Claude Code plugin marketplace and an external Telegram plugin, and referenced files such as docs/protocol.md and docs/adapters/ are not present in the evidence (dependency_availability=1). Failure messaging is limited to the chief detecting stale agents as likely down; there are no error codes, logs, or recovery guidance (failure_messages=1).

Audience and scenarios are well described, covering Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and a generic adapter (audience_and_scenarios=2). Capability boundaries only state that agents do not talk directly; the scope of permitted actions or prohibitions is not defined (capability_boundaries=1). Trigger precision is partial: heartbeat interval and daily briefing/review times are configurable, but task status matching rules are coarse (trigger_precision=1). Environment fit is good, as the team directory can be an Obsidian vault, a git repo, or any directory, and mixed runtimes are supported (environment_fit=2).

Information architecture is clear, with well-organized README sections, plugin structure, directory structure, and skill reference (information_architecture=2). Install notes are concrete, providing both local and GitHub marketplace install commands (install_notes=2). Naming stability is good, with a slug derivation table and examples (naming_stability=2). Examples and FAQ are thin: only task-file examples exist, with no FAQ or troubleshooting (examples_and_faq=1). Known limitations are entirely absent, e.g., concurrent write conflicts, markdown parsing ambiguity, or race conditions from multiple agents polling (known_limitations=0). The MIT license is complete (license=2). Version 0.4.0 appears in package.json, but there is no CHANGELOG or version history (versioning_changelog=1). Maintenance responsibility is only an agentweave author field, with no maintainer contact or governance notes (maintenance_responsibility=1).

Output usability is good: task file format, status lifecycle, and briefing mechanics are concrete and directly consumable by agents (output_usability=2). Marginal value is limited: using markdown files as a message bus is lightweight, but the incremental benefit over native runtime task orchestration is not quantified (marginal_value=1). Cost-benefit is unclear: maintaining the team directory, heartbeat polling, and daily reviews implies cost, but neither cost nor benefit is compared against alternatives (cost_benefit=1).

Claim traceability is partial: the README claims runtime-agnostic operation and out-of-the-box mixed teams, but the supporting docs/protocol.md and adapter docs are not in the evidence (claim_traceability=1). Cross-source corroboration is limited to README, LICENSE, and package.json; the package.json skills list roughly matches the README skill descriptions, but there are no tests or code to corroborate (cross_source_corroboration=1). Fact-inference separation is acceptable: the README distinguishes protocol spec from implementation details, though phrases like 'works out of the box' remain unverified inference (fact_inference_separation=1).