Flyto2 Core

Trust: Docs declare a filesystem sandbox (FLYTO_SANDBOX_DIR) and SSRF guards (private ranges and cloud metadata blocked by default), with CI coverage tests forcing every path/URL module through the guard — a strong least-privilege design. Deduction: the sandbox defaults to the process working directory (self-described as rarely right for servers), and the guard implementation code itself is outside the supplied evidence. User confirmation: workflows are executed as code and can send notifications/write files, yet no pre-execution confirmation mechanism is described — only 'run workflows from trusted sources' — score 1. Data flow transparency: execution traces, evidence snapshots, and data lineage are concretely described. Sensitive data: SECURITY.md prescribes ${env.API_KEY} patterns, log redaction, and file permissions; the redaction mechanism itself is not shown in code. Dependency security: pyproject dependency floors carry GHSA IDs and rationale comments (interruptible regex, Pillow ACE fix, pytest tmpdir); CI runs pip-audit and npm audit with lockfile drift checks — full marks. External effects: SSRF guard with per-redirect revalidation and DNS-rebinding protection is concretely described; but browsers execute arbitrary page JS and port.check can be explicitly enabled — boundaries are disclosed, not removed. Rollback: 'replay --from-step N' with state snapshots is the core pitch (score 2), but no undo for produced artifacts like file.write. Source attribution: only 'Flyto2 Team <[email protected]>' with an unverified publisher; no governance or backing entity — score 1.

Reliability: Self-consistency is good — README, SECURITY.md, pyproject (2.32.0, py3.10 floor with rationale), and CI agree, including candid correction of past errors (uninstallable 3.9 floor; Playwright 1.40 floor causing TypeError). Deduction: the 480-module/88-category/41-recipe counts cannot be item-checked from the provided files. Dependency availability: optional extras are cleanly grouped and requirements.txt delegates to pyproject; but very recent floors (aiohttp>=3.14.3) may block older distributions with no fallback documented. Failure messages: modules return structured {'ok': False, 'error_code': 'SSRF_BLOCKED'} and traces record per-step status; examples are ample but real error paths are unexecuted.

Adaptability: Audience and scenarios are clear (developers, CI, MCP clients) with CLI/MCP/HTTP/Python entry points. Capability boundaries: the 'Known Security Considerations' section candidly discloses code-execution, network, and browser risks and advises isolation — score 2; but the 480-module surface (cloud/k8s/AWS) is not itemized. Trigger precision: only communication.webhook_trigger is glimpsed; trigger behavior, dedup, auth are nearly absent from evidence — score 1. Environment fit: py3.10–3.13 declared and verified per-version in a CI matrix; headless defaults and FLYTO_VSCODE_LOCAL_MODE show deployment awareness.

Convention: Information architecture is excellent — README links RECIPES, TOOL_CATALOG, CONFIGURATION, PLUGIN_SDK, MODULE_SPECIFICATION, WHITEPAPER, ARCHITECTURE, plus an mcp-name annotation — full marks. Install notes: three extras, playwright install chromium, a 30-second example — full marks. Naming stability: prefixed module namespaces with a CI brand-identity check, but package name flyto-core vs import name core is a mild inconsistency. Examples: three recipes, YAML workflow, and Python API examples; no FAQ. Known limitations: support table (only 2.32.x), honest dependency-floor rationale, and CI's explanation of excluded browser tests; no standalone limitations doc. License: full Apache-2.0 text present and consistent — full marks. Versioning: 2.32.0 consistent across files, CI release-drift check, CHANGELOG linked but its content is not in evidence. Maintenance: CONTRIBUTING, maintainer fields, 48-hour response commitment; single team, no external maintainers — score 2.

Effectiveness: Output usability — structured traces, JSON reports, screenshots, and output_schema on composite modules give clear output contracts. Marginal value: replay-from-step plus per-step traces is a genuine differentiator vs raw Playwright/scripts, with a concrete comparison table; but the claim rests entirely on documentation — no execution was performed in this review. Cost-benefit: single pip install, opt-in extras, module reuse reduce glue code; however, a 480-module surface is a large audit/maintenance burden whose long-term cost is not discussed.

Verifiability: Claim traceability — '480 modules', '41 recipes', and the fail-the-build coverage tests point at concrete files (tests/core/test_write_sink_coverage.py, security/advisories.), but most referenced files were not supplied, so claims can only be checked for internal consistency, not against artifacts — score 1. Cross-source corroboration: README, SECURITY.md, pyproject, and CI mutually confirm versions, boundaries, and dependency rationale — strong internal agreement, but all from one publisher with no independent verification (MseeP badges are self-declared) — score 1. Fact/inference separation: pyproject comments clearly separate 'what the historical error was' from 'what the current choice is', CI comments justify each exclusion, and marketing slogans are visually distinct from factual claims — score 2.