If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/farm-fe/farm shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 4w ago
• 20 active contributors
• Distributed ownership (top contributor 31% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live farm-fe/farm repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/farm-fe/farm.

What it runs against: a local clone of farm-fe/farm — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in farm-fe/farm | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 61 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of farm-fe/farm. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/farm-fe/farm.git
#   cd farm
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of farm-fe/farm and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "farm-fe/farm(\\.git)?\\b" \\
  && ok "origin remote is farm-fe/farm" \\
  || miss "origin remote is not farm-fe/farm (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f ".cargo/config.toml" \\
  && ok ".cargo/config.toml" \\
  || miss "missing critical file: .cargo/config.toml"
test -f ".changeset/config.json" \\
  && ok ".changeset/config.json" \\
  || miss "missing critical file: .changeset/config.json"
test -f ".github/skills/farm-ready-gate/SKILL.md" \\
  && ok ".github/skills/farm-ready-gate/SKILL.md" \\
  || miss "missing critical file: .github/skills/farm-ready-gate/SKILL.md"
test -f ".agents/skills/rust-engineer/SKILL.md" \\
  && ok ".agents/skills/rust-engineer/SKILL.md" \\
  || miss "missing critical file: .agents/skills/rust-engineer/SKILL.md"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 61 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~31d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/farm-fe/farm"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Farm is an extremely fast, Vite-compatible web build tool written in Rust that solves the core problems of modern bundlers: excessive module requests during dev (hundreds/thousands of modules), inconsistency between dev and prod builds, and inflexible code-splitting. It achieves Vite-like HMR performance while maintaining unified build strategy and providing fine-grained control over bundle output through Rust-based architecture. Workspace monorepo with .cargo/config.toml coordinating members: crates/* contains the Rust core (compiler, bundler, plugins), packages/* wraps Node.js bindings (e.g., @farmfe/core npm package), rust-plugins/* houses Rust-based plugins. .agents/* contains AI-driven development guidance. Build artifacts flow through Rust (fast compilation/bundling) → TypeScript bindings → JavaScript/Node.js APIs.

Frontend engineers and build tooling maintainers working on large-scale web applications who need fast dev iteration, consistent builds across environments, and control over code-splitting without the performance degradation of webpack or the development shortcuts of Vite.

Actively maintained and production-ready: the repo shows continuous development (.changeset files, v0.13+ versioning), substantial codebase (1.9M Rust LOC, 800K TypeScript), published on npm as @farmfe/core, and documented ecosystem with Discord community. However, as a Rust rewrite of a relatively newer tool, it's less battle-tested than webpack but more proven than early Vite.

Moderate risk: Rust dependency compilation adds build complexity, monorepo structure across crates/* and packages/* requires careful version coordination, single-language barrier (Rust knowledge needed for core contributions). No obvious red flags on maintenance cadence, but ecosystem smaller than webpack/Vite means fewer community plugins and integrations available.

Active development evidenced by .changeset versioning system in place, skill agents in .agents/ (including rust-best-practices/, rust-engineer/) suggesting automated code quality checks, and self-improving-agent with post-bash hooks indicating CI/CD integration. TypeScript layer being maintained alongside Rust core.

git clone https://github.com/farm-fe/farm.git
cd farm
cargo build --release
cargo test
# or for Node.js integration:
npm install
npm run build

Daily commands:

# Development server (inferred from Vite compat):
farm dev

# Production build:
farm build

# Run tests:
cargo test
npm test

# Publish profile (optimized):
cargo build --profile release-publish

• .cargo/config.toml — Workspace Cargo configuration defining Rust edition, dependencies, and release profiles; essential for building and understanding the Farm project's compilation strategy.
• .changeset/config.json — Changeset configuration for managing versioning and releases; critical for understanding how changes are tracked and versioned across the monorepo.
• .github/skills/farm-ready-gate/SKILL.md — Defines the readiness gate criteria and validation process for Farm; necessary to understand quality standards and merge requirements.
• .agents/skills/rust-engineer/SKILL.md — Rust engineering guidelines and best practices specific to this Rust-based project; foundational for writing code that aligns with the codebase style.
• README.md — Project overview and value proposition as a Vite-compatible, Rust-based web build tool; essential context for understanding Farm's positioning and goals.
• .github/PULL_REQUEST_TEMPLATE.md — PR submission guidelines enforcing contribution standards; must-read for any contributor to ensure PRs meet acceptance criteria.
• .changeset/README.md — Instructions for creating changesets before committing; required knowledge for every contributor to properly document changes.

Add a new Rust crate to the workspace

1. Create a new directory under crates/ with a Cargo.toml manifest defining dependencies and metadata (crates/[new-crate-name]/Cargo.toml)
2. Update the workspace members list in the root Cargo.toml to include the new crate (.cargo/config.toml)
3. Create a changeset entry documenting the new crate addition (.changeset/[generated-name].md)
4. Ensure the crate follows Rust best practices and passes farm-ready-gate validation (.github/skills/farm-ready-gate/SKILL.md)

Create a changeset for a code change

1. Read the changeset guidelines to understand the format and versioning strategy (.changeset/README.md)
2. Create a new .md file in .changeset/ using the naming pattern (e.g., .changeset/blue-jobs-lick.md) (.changeset/[new-changeset].md)
3. Document the change with package name, version bump type (major/minor/patch), and change summary (.changeset/config.json)

Submit a pull request following contribution standards

1. Review the PR template requirements and checklist (.github/PULL_REQUEST_TEMPLATE.md)
2. Ensure code adheres to Rust engineering practices and style guidelines (.agents/skills/rust-engineer/SKILL.md)
3. Verify the change passes farm-ready-gate checks (quality, tests, documentation) (.github/skills/farm-ready-gate/SKILL.md)
4. Create accompanying changeset if this is a user-facing change (.changeset/README.md)

Add a new Rust plugin to the build system

1. Create plugin crate under rust-plugins/ with Cargo.toml defining the plugin interface (rust-plugins/[plugin-name]/Cargo.toml)
2. Register the plugin in the workspace members configuration (.cargo/config.toml)
3. Follow async/error-handling patterns established in Rust engineer skill guide (.agents/skills/rust-engineer/references/async.md)
4. Create a changeset documenting the plugin addition (.changeset/[plugin-changeset].md)

• Rust — Provides memory safety without GC and exceptional performance for a build tool that must handle large codebases; enables multi-threaded compilation with minimal overhead.
• Cargo Workspace (crates/ + packages/ + rust-plugins/)** — Monorepo structure enables code reuse across the core build engine, CLI, and plugin ecosystem while maintaining clear module boundaries and independent versioning.
• Changeset-based versioning — Allows fine-grained tracking of what changed in each release and automates changelog generation; scalable for a multi-crate workspace.
• GitHub Skills & Agents (.agents/, .github/skills/) — Encodes institutional knowledge and CI/CD workflows as code; enables automated validation (farm-ready-gate), documentation sync, and contribution process standardization.

• Vite-compatible design (not 100% feature parity with Webpack/Rollup)

  • Why: Vite is already the modern standard for dev tools; maximizes ecosystem adoption and reduces migration friction.
  • Consequence: Users expect plugin/config compatibility; any deviation must be carefully documented and justified.

• Release profile uses fat LTO and strip = true, high optimization

  • Why: Produces the smallest, fastest binary for end users.
  • Consequence: Slower builds (especially CI test builds use ci-test profile with relaxed settings); larger final binary for development.

• Monorepo with workspace members in crates/, packages/, rust-plugins/

  • Why: Shared dependencies, unified versioning, and coordinated releases.
  • Consequence: More complex dependency graph and CI/CD pipeline; requires discipline in managing interdependencies.

• Agent-driven skills (rust-engineer, farm-ready-gate, etc.)

  • Why: Scalable way to enforce standards and guide contributors without manual code review overhead.
  • Consequence: Depends on LLM/automation tooling that may have limitations; skill definitions must be maintained as codebase evolves.

• Does not support legacy JavaScript bundler configurations (Webpack/Rollup); targets modern Vite users
• Not a runtime or package manager; focuses solely on the build/bundling step
• Does not provide cross-platform package management like pnpm/yarn; assumes users manage dependencies separately
• Not intended for non-web targets (e.g., backend, native); web-first focus

Rust compilation: first build is slow due to dependencies and LTO profile; cache may not persist across CI runs. Monorepo coordination: changing a crate version requires updating dependents; use workspace resolution. Node.js bindings: native modules may require platform-specific build steps (Windows/Linux/macOS); check .agents/ hooks for CI quirks. Vite compat mode: Farm claims Vite plugin compatibility—verify actual plugin API coverage as edge cases may exist. Profile selection: release-publish with lto = "fat" and strip = true is for distribution; use standard release for local testing.

• Module Federation / Code Splitting Strategy — Farm's core differentiator is flexible code-splitting control; understanding how it partitions modules at compile-time vs. Vite's runtime approach is essential to using the tool effectively
• Source Maps and Position Tracking — Farm uses sourcemap crate (v9.2.2) and enhanced-magic-string for accurate dev/prod parity; knowing how source maps are preserved through Rust compilation is critical for debugging
• Vite Plugin Compatibility / Universal Plugin System — Farm v0.13+ claims Vite plugins work directly; this requires understanding how Vite's plugin hooks (resolveId, load, transform, etc.) are emulated in Rust, affecting custom plugin development
• Foreign Function Interface (FFI) / NAPI Bindings — Farm's architecture depends on Rust → Node.js FFI via NAPI (inferred from npm package structure); understanding call overhead and async boundary crossing is vital for performance optimization
• Static Analysis & Dependency Graph Resolution — Fast bundling requires pre-computing module dependency graphs in Rust; understanding traversal algorithms and caching strategies is essential for contributing to the bundler core
• Serialization Format (rkyv) — Farm uses rkyv (v0.8.10) for zero-copy serialization of build state and metadata; this is a performance-critical path and different from JSON, affecting cache format
• Hot Module Replacement (HMR) / Development Experience Consistency — Farm's main selling point over Vite is unified HMR strategy between dev and prod; understanding how it tracks and updates modules without fragmentation is key to the design philosophy

• vitejs/vite — Direct predecessor and feature comparison target; Farm aims to fix Vite's dev performance and dev/prod consistency issues
• webpack/webpack — Original bundler Farm benchmarks against; shared ecosystem of loaders and plugins but much slower
• swc-project/swc — Rust-based JavaScript compiler; Farm likely uses or was inspired by swc's approach to high-speed code transformation
• napi-rs/napi-rs — Critical dependency for Node.js + Rust FFI bindings; Farm uses this pattern to expose Rust bundler to npm packages
• parcel-bundler/parcel — Comparable zero-config bundler philosophy; Farm offers more control while maintaining ease-of-use, making it an alternative in same ecosystem

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive Rust integration tests for Farm's Vite-compatible module resolution

The repo is a Rust-based build tool claiming Vite compatibility, but there are no visible integration tests validating that Farm's module resolution matches Vite's behavior. This is critical for a tool positioning itself as a drop-in replacement. Integration tests should cover edge cases like circular dependencies, conditional exports, and package.json resolution ordering.

• [ ] Create crates/core/tests/vite_compat_resolution.rs with test fixtures
• [ ] Add tests validating package.json exports field handling against Vite's behavior
• [ ] Test symlink resolution and node_modules traversal matches Vite
• [ ] Reference .agents/skills/rust-engineer/references/testing.md for test patterns
• [ ] Run tests in CI profile defined in Cargo.toml [profile.ci-test]

Document and create missing SKILL.md for agent-browser skill with Farm-specific debugging scenarios

The .agents/skills/agent-browser directory has references and templates but no SKILL.md file defining the skill's purpose and usage. For a Rust build tool, browser automation skills should document debugging compiled artifacts, inspecting dev server output, and profiling bundle performance.

• [ ] Create .agents/skills/agent-browser/SKILL.md with Farm-specific debugging use cases
• [ ] Document how to use browser automation to test Farm's dev server HMR behavior
• [ ] Add scenarios for profiling build performance using browser devtools integration
• [ ] Reference existing templates in .agents/skills/agent-browser/templates/ as examples
• [ ] Link to proxy-support.md and profiling.md references in SKILL.md

Add GitHub Actions workflow to validate all .changeset/ files follow semantic versioning rules

The repo has 12+ uncommitted changesets (.changeset/*.md) and a .changeset/config.json, but no CI validation that changesets conform to the project's versioning scheme. This prevents changelog generation errors and ensures contributors understand the versioning process. The Farm workspace has multiple crates that need coordinated versioning.

• [ ] Create .github/workflows/changeset-validation.yml workflow
• [ ] Validate all .changeset/*.md files have proper YAML frontmatter (type: minor/major/patch)
• [ ] Ensure changeset descriptions reference specific crates from workspace members in Cargo.toml
• [ ] Fail CI if changesets lack proper formatting or affect undeclared packages
• [ ] Reference .agents/skills/creating-changesets/SKILL.md and references/scenarios.md for context

• Add integration tests under packages/ for the TypeScript/Node.js binding layer—the repo has Rust test coverage (#[cfg(test)]) but likely fewer end-to-end tests bridging Rust FFI to JS consumers; check .agents/skills/rust-engineer/references/testing.md for patterns.
• Document the .agents/skills/ directory structure and how to invoke agent guidance during development—no AGENTS.md or usage guide exists yet; create a walkthrough showing how to run rust-best-practices and self-improving-agent hooks.
• Implement missing plugin examples in rust-plugins/ for common use cases (e.g., Vue/Svelte loaders, CSS preprocessing)—visible from TypeScript/Vue file counts in repo but no concrete plugin boilerplate docs; add a template rust-plugins/plugin-template/ with skeleton and tests.

The Farm codebase demonstrates reasonable security posture as a Rust-based build tool. No critical vulnerabilities were identified in the visible configuration. Primary concerns are moderate: aggressive compiler optimizations that may complicate security audits, the need for regular dependency vulnerability scanning, and potential exposure of agent configuration templates. The project should implement automated dependency auditing in CI/CD and maintain clear documentation of security practices. The Rust ecosystem provides strong memory safety guarantees which mitigate common vulnerabilities. Recommendations focus on operational security and build artifact management rather than code-level issues.

• Medium · Potential Dependency Version Pinning Issues — Cargo.toml - [workspace.dependencies]. The workspace.dependencies in Cargo.toml uses specific versions without sufficient constraint specifications. Dependencies like 'rkyv = 0.8.10' and 'sourcemap = 9.2.2' are pinned to exact versions, which could allow transitive dependency vulnerabilities if minor/patch versions of dependencies are compromised. Consider using more explicit version constraints with security audits. Fix: Run 'cargo audit' regularly to identify known vulnerabilities. Consider using dependency scanning tools in CI/CD pipeline. Evaluate if stricter version constraints (e.g., =0.8.10) or caret/tilde specifications are appropriate based on stability requirements.
• Low · Aggressive Release Profile Configuration — Cargo.toml - [profile.release-publish]. The [profile.release-publish] configuration uses 'panic = abort' which disables panic unwinding. This can make debugging and error recovery difficult. Additionally, 'strip = true' removes symbols which may complicate security auditing and forensics. Fix: Consider keeping panic unwinding enabled in production builds unless there's a specific performance requirement. Maintain separate builds for security analysis with symbols intact. Document the rationale for aggressive stripping.
• Low · LTO and Codegen Unit Configuration — Cargo.toml - [profile.release-publish]. The release-publish profile uses 'lto = fat' and 'codegen-units = 1', which can obscure binary behavior during security audits and make reproducible builds more challenging. This aggressive optimization may complicate security analysis of the compiled artifacts. Fix: Maintain a separate debug/audit build configuration that disables LTO for security testing. Document the security implications of these optimizations. Ensure reproducible builds are verified for supply chain security.
• Low · Agent Skills Configuration Exposure — .agents/skills/agent-browser/references/ and templates/. The .agents/skills directory structure contains multiple configuration files and templates for browser automation, authentication, and form automation. These could potentially expose sensitive patterns or credentials if misconfigured. Fix: Review all template files and reference documentation for hardcoded credentials or sensitive patterns. Ensure authentication.md and session-management.md don't contain example credentials. Add pre-commit hooks to prevent credential commits.
• Low · Self-Improving Agent Memory Files — .agents/skills/self-improving-agent/memory/. The .agents/skills/self-improving-agent/memory/semantic-patterns.json may accumulate sensitive patterns or behaviors over time if the agent processes user code. No visible access controls on this directory. Fix: Implement access controls on agent memory files. Audit memory contents regularly for sensitive data leakage. Consider encrypting memory storage if agents process sensitive code or data.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.