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/seed-rs/seed 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 all four use cases

• 13 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 65% of recent commits

_{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 seed-rs/seed repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/seed-rs/seed.

What it runs against: a local clone of seed-rs/seed — 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 seed-rs/seed | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 512 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of seed-rs/seed. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/seed-rs/seed.git
#   cd seed
#
# 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 seed-rs/seed and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "seed-rs/seed(\\.git)?\\b" \\
  && ok "origin remote is seed-rs/seed" \\
  || miss "origin remote is not seed-rs/seed (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "examples/counter/src/lib.rs" \\
  && ok "examples/counter/src/lib.rs" \\
  || miss "missing critical file: examples/counter/src/lib.rs"
test -f "examples/counters/src/lib.rs" \\
  && ok "examples/counters/src/lib.rs" \\
  || miss "missing critical file: examples/counters/src/lib.rs"
test -f "examples/component_builder/src/lib.rs" \\
  && ok "examples/component_builder/src/lib.rs" \\
  || miss "missing critical file: examples/component_builder/src/lib.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 512 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~482d)"
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/seed-rs/seed"
  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).

Seed is a Rust framework for building front-end web applications that compile to WebAssembly, using an Elm-like architecture for state management. It provides compile-time type safety, a macro-based templating system (e.g., div!, p!), and built-in reactive state management—all in pure Rust with no JavaScript templating syntax. Monorepo structure with seed crate at the root (src/ contains the framework core) and 30+ example projects in examples/ (counter, todomvc, pages, websocket, etc.). Each example is a standalone Cargo workspace member with its own Makefile.toml, demonstrating patterns. Build targets WASM via wasm-bindgen and Trunk.

Rust developers who want to build interactive web UIs with full type safety and performance benefits of Rust/WASM, particularly those coming from functional programming backgrounds (Elm, Haskell) or who are skeptical of JavaScript. Teams that value compile-time guarantees over component ecosystems.

Not actively maintained as of now (see README warning 'It's not maintained at the moment'). The codebase is stable at v0.10.0 (Rust 2021 edition, MSRV 1.67.1) with comprehensive examples and documentation, but development has stalled—making it viable for learning or legacy projects but risky for new production work.

The project is unmaintained, which blocks dependency updates and security patches over time. WebAssembly browser support is ~95.5%, adequate but not universal. No ecosystem of pre-built components (you build everything), and no server-side rendering support yet (#232 open). Single original author (davidoconnor) with contributions from a small team, and the official website (seed-rs.org) may no longer be under project control.

The project is in maintenance mode—no active development. The README explicitly flags that it is not maintained; there is a stalled website issue (github.com/seed-rs/seed-rs.org/issues/126 indicates a third party may have acquired seed-rs.org domain). Bug fixes are unlikely unless critical.

1. Install tools: cargo install cargo-generate trunk wasm-bindgen-cli
2. Generate quickstart: cargo generate --git https://github.com/seed-rs/seed-quickstart.git --name my-app
3. Enter directory: cd my-app
4. Start dev server: trunk serve
5. Open http://localhost:8080 in browser (counter example will load).

Daily commands: trunk serve in the example directory (or root with specific example). Alternatives: cargo make start <example_name> (legacy, uses Makefile.toml). Trunk watches files and rebuilds WASM on save; hot-reload available.

• Cargo.toml — Root workspace manifest defining Seed's version (0.10.0), core dependencies, and Rust edition (2021); essential for understanding project configuration and required libraries.
• README.md — Framework overview explaining Elm-like architecture, macro-based templating (div!), and WebAssembly integration; critical entry point for understanding Seed's design philosophy.
• examples/counter/src/lib.rs — Simplest canonical example demonstrating the complete Elm-architecture pattern (Model, Msg, update, view); serves as template for all new Seed applications.
• examples/counters/src/lib.rs — Intermediate example showing component composition and state management across multiple counter instances; demonstrates Seed's approach to reusable UI patterns.
• examples/component_builder/src/lib.rs — Advanced example showing the builder pattern for complex components (like buttons with configuration); illustrates Seed's idiomatic abstraction strategies.
• CONTRIBUTING.md — Contributor guidelines covering build processes, testing standards, and code organization conventions essential before submitting changes.
• CHANGELOG.md — Version history documenting breaking changes and API evolution; critical for understanding migration paths between framework versions.

Create a new Seed application from counter template

1. Copy the counter example directory structure as your base (examples/counter/Cargo.toml)
2. Update package name and dependencies in your Cargo.toml, keeping Seed and wasm-bindgen versions aligned (Cargo.toml)
3. Implement Model struct to hold application state (mirroring the counter's i32 or expanding to custom types) (examples/counter/src/lib.rs)
4. Define Msg enum for all user actions and side effects (button clicks, HTTP responses, timers) (examples/counter/src/lib.rs)
5. Write update() function dispatching Msg variants to state mutations, returning Model and Cmd for effects (examples/counter/src/lib.rs)
6. Write view() function as a pure function returning El<Msg> using macros (div!, button!, input!, etc.) (examples/counter/src/lib.rs)
7. Call seed::App::build() with init, update, view in main() to mount to #app DOM element (examples/counter/src/lib.rs)

Add JavaScript/Web Component interoperability

1. Create .js file in examples/custom_elements/public/ exporting your custom element class (examples/custom_elements/public/feather-icon.js)
2. Use seed::html::custom() or raw_html!() macro to embed custom element in view() (examples/custom_elements/src/feather_icon.rs)
3. Use wasm-bindgen #[wasm_bindgen] bindings to call JS methods from Rust update() handlers (examples/custom_elements/src/lib.rs)
4. Add <script> tag in index.html to load .js file before WASM module initializes (examples/custom_elements/index.html)

Build a reusable component module with builder pattern

1. Create button.rs module defining ButtonConfig struct with optional fields (label, onclick, disabled, style) (examples/component_builder/src/button.rs)
2. Implement impl ButtonConfig { fn new() -> Self, fn label(mut self, v: &str) -> Self, etc. } for chaining (examples/component_builder/src/button.rs)
3. Implement view_fn(self, msg_fn: F) -> El<Msg> that converts config into Seed El using attributes! { ... } (examples/component_builder/src/button.rs)
4. In parent lib.rs, call ButtonConfig::new().label('Click').onclick(Msg::Clicked).view_fn(...) in your view() (examples/component_builder/src/lib.rs)
5. Use seed::attrs!(), seed::style!(), seed::classes!() macros for type-safe attribute construction (examples/component_builder/src/button.rs)

Integrate advanced features (WebGL, drag-drop, HTTP)

1. For WebGL: use wasm-bindgen to bind WebGL2RenderingContext from web-sys, store in Model, update in update() (examples/bunnies/src/lib.rs)
2. For drag-drop: attach handlers (ev(Ev::DragStart), ev(Ev::Drop)) with DataTransfer bindings in attributes (examples/drag_and_drop/src/lib.rs)
3. For HTTP: use seed::fetch crate or wasm-bindgen fetch_api, dispatch Cmd::perform() in update() (examples/auth/src/lib.rs)
4. Run local dev server with 'cargo make start' (from Makefile.toml) to test WebAssembly compilation (Makefile.toml)

• Rust + WebAssembly — Provides memory safety, type safety, and performance for client-side logic; eliminates entire classes of runtime bugs common in JavaScript
• Elm-inspired architecture (Model-Msg-Update-View) — Enables predictable, testable state management with single source of truth; simplifies debugging and reasoning about side effects
• Compile-time macros (div!, button!, etc.) — Eliminates string-based templating vulnerabilities; provides IDE autocompletion and type checking at compile time rather than runtime
• wasm-bindgen + web-sys — Low-level interop with JavaScript APIs without runtime overhead; enables use of Web APIs (DOM, Canvas, WebGL) from Rust

• Elm-like immutable update pattern over direct DOM mutation

  • Why: Ensures UI state is always derived from model; makes time-travel debugging and hot-reloading feasible
  • Consequence: Slightly higher memory overhead per update cycle due to cloning; requires developers to learn functional patterns unfamiliar in JavaScript

• Macro-based templating instead of separate HTML templates

  • Why: Full Rust type safety and IDE support for templates; no impedance mismatch between Rust types and template variables
  • Consequence: Steeper learning curve for developers from JavaScript template frameworks; less familiar syntax (div![...] vs <div>...</div>)

• Single-threaded WASM model with Cmd-based async

  • Why: Simpler mental model and avoids complex concurrency bugs; aligns with JavaScript's event-loop paradigm
  • Consequence: Long-running computations can block UI rendering; heavy math/crypto requires Web Workers or chunking with seed::time::sleep

• Workspace with many example applications

  • Why: Provides clear learning path from trivial (counter) to advanced (bunnies 3D); serves as integration tests for API stability
  • Consequence: Maintenance burden of keeping examples working and up-to-date; larger repo size and slower CI times

• Server-side rendering (SS

1. wasm-bindgen version mismatch: if you see 'wasm being linked against different version of wasm-bindgen', run cargo update -p wasm-bindgen (noted in README, easy to miss first time). 2. Trunk is the modern bundler, but older examples or docs may reference cargo make start instead—stick with trunk serve. 3. No server-side rendering; if you need SSR for SEO-critical content, Seed will not help. 4. No pre-built component library (no equivalent to React Bootstrap or Material UI)—all UI must be custom or manually integrated. 5. The project is unmaintained, so expect no support for new WASM features or browser APIs added after v0.10.0.

• Elm Architecture (MVU) — Seed's entire state management is built on the Model-View-Update pattern from Elm; understanding this is essential to using Seed effectively
• WebAssembly (WASM) — Seed compiles Rust to WASM bytecode for browser execution; you need to understand WASM's capabilities and limitations (no direct DOM access, JS interop via wasm-bindgen)
• wasm-bindgen — Seed uses wasm-bindgen to bridge Rust and JavaScript; knowing how to use #[wasm_bindgen] macros is necessary for calling browser APIs and JS libraries
• Procedural Macros (UI Templating) — Seed's div!, p!, button! etc. are procedural macros that generate DOM nodes at compile time—understanding macro expansion helps debug template issues
• Futures and Async/Await — Seed uses futures and async/await for handling HTTP requests, timers, and event listeners; essential for non-blocking I/O in the browser
• Component Subscription Model — Seed's subscribe() mechanism allows components to listen to global or local state changes without tight coupling; core to managing app-wide side effects
• Virtual DOM (Diffing) — Seed does not use a virtual DOM; it compares the Rust model state directly to minimize DOM updates. Understanding this trade-off is important for performance optimization

• seed-rs/seed-quickstart — Official template repository for starting new Seed projects—the first thing users clone when learning
• yewstack/yew — Direct competitor: WASM framework with component-based architecture and a much larger ecosystem; pre-built component libraries
• leptos-rs/leptos — Modern Rust WASM framework inspired by Solid.js (not Elm); actively maintained with better reactivity model and SSR support
• dioxus/dioxus — Cross-platform Rust UI framework with WASM support, desktop, and mobile targets; actively developed with growing component ecosystem
• thedodd/trunk — The recommended Seed bundler and build tool—handles WASM compilation, asset bundling, and dev server

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 CI workflow for example projects verification

The repo has 30+ example projects in the workspace but .github/workflows/main.yml likely doesn't verify all examples compile and run correctly. This prevents regressions when dependencies are updated. A dedicated workflow should build and test each example's Cargo.toml independently to catch compatibility issues early.

• [ ] Review current .github/workflows/main.yml to understand existing CI coverage
• [ ] Create a new workflow file (e.g., .github/workflows/examples.yml) that iterates through workspace members
• [ ] Add matrix strategy to build each example in examples/* with cargo build --release and cargo test
• [ ] Verify examples/e2e_encryption and examples/server_integration (which have own workspaces) are handled separately
• [ ] Add workflow status badge to README.md

Create missing Makefile.toml for examples without build scripts

The file structure shows many examples have Makefile.toml (animation, auth, bunnies, canvas, charts, component_builder, counter) but the examples list in Cargo.toml includes 30+ projects. Examples without Makefile.toml likely lack standardized build/dev commands. This creates inconsistent developer experience. Each example should have a Makefile.toml with serve, build, and test targets following the pattern in existing examples.

• [ ] Audit all workspace members listed in Cargo.toml to identify which lack Makefile.toml
• [ ] Review an existing example's Makefile.toml (e.g., examples/animation/Makefile.toml) to understand the standard structure
• [ ] Create Makefile.toml for missing examples with consistent targets: devel, build, test, serve
• [ ] Update examples/README.md to document the standard Makefile.toml targets
• [ ] Test that cargo make works consistently across all examples

Add comprehensive TESTING.md documentation for running example tests

The repo has CONTRIBUTING.md and RELEASE_CHECKLIST.md but no testing documentation. With 30+ examples and a complex workspace structure, new contributors don't know how to run tests for specific examples or the entire suite. A TESTING.md file should document: running tests locally, testing individual examples, running integration tests, and browser testing setup.

• [ ] Create TESTING.md at root level with sections: Unit Tests, Integration Tests, Example Testing, Browser Testing, CI Test Verification
• [ ] Document how to run tests for a single example (e.g., cd examples/counter && cargo test)
• [ ] Document workspace-wide test command and any special requirements (wasm-pack, headless browser, etc.)
• [ ] Add troubleshooting section for common test failures
• [ ] Link TESTING.md from CONTRIBUTING.md and README.md

• Add comprehensive examples for Web Workers: currently bunnies example uses WebGL but no dedicated Worker example. Start with examples/web_worker/ template and document worker lifecycle.
• Expand test coverage for message subscriptions: examples/subscribe/ works but lacks inline tests. Add unit tests in src/lib.rs for subscription_manager to document behavior.
• Create a 'Seed + Markdown rendering' guide: examples/markdown/ exists but lacks documentation on integrating markdown-rs or comrak. Add docs/MARKDOWN_INTEGRATION.md with working code samples.

The Seed framework demonstrates good security practices with a modern Rust edition (2021), proper dependency management using crates.io, and reasonable defaults for WebAssembly security. However, there are some gaps: incomplete dependency specifications, missing security documentation (SECURITY.md, SBOM), concerns about official website availability, and aging MSRV specification. The project would benefit from establishing a formal security policy, completing dependency specifications, and maintaining an updated SBOM. No obvious injection vulnerabilities, hardcoded secrets, or infrastructure misconfigurations were detected in the visible file structure.

• Medium · Incomplete Dependency Specification — Cargo.toml - gloo-utils dependency. The gloo-utils dependency in Cargo.toml appears to have an incomplete version specification ("0.1" without patch version). This could lead to unpredictable dependency resolution and potential security updates being missed. Fix: Complete the version specification to a full semantic version (e.g., "0.1.0" or "0.1.*") and regularly audit dependencies using 'cargo audit'.
• Low · Website Availability Warning — README.md. The README indicates that seed-rs.org may have been acquired by a third party, creating potential confusion about the official project source and documentation. This could be exploited for phishing or misdirection attacks. Fix: Establish an alternative official website or documentation hub with clear ownership verification. Add security.txt and well-known/security.json files to verify project ownership.
• Low · Limited SBOM and Dependency Management Documentation — Repository root - missing SBOM documentation. While the project includes dependencies like getrandom, futures, and gloo libraries, there is no visible Software Bill of Materials (SBOM) or comprehensive dependency audit documentation provided in the visible file structure. Fix: Generate and maintain an SBOM using tools like cargo-sbom or cyclonedx-cli. Document security update procedures in CONTRIBUTING.md.
• Low · No Visible Security Policy — Repository root - missing SECURITY.md. The repository does not appear to have a SECURITY.md file based on the file structure, which is important for responsible disclosure of vulnerabilities. Fix: Create a SECURITY.md file with clear instructions for reporting security vulnerabilities, security update procedures, and supported versions.
• Low · Rust Version Specification May Be Outdated — Cargo.toml - rust-version field. The rust-version is set to 1.67.1, which may have known security vulnerabilities. Regular updates ensure access to security fixes. Fix: Regularly update the minimum rust version to a recent stable release (currently 1.75+). Document the MSRV update process.

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.