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/serde-rs/serde 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

• Used by 1 trusted project: tauri-apps/tauri
• Last commit 2mo ago
• 7 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 57% 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 serde-rs/serde repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/serde-rs/serde.

What it runs against: a local clone of serde-rs/serde — 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 serde-rs/serde | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | 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 ≤ 93 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 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 "serde_core/src/lib.rs" \\
  && ok "serde_core/src/lib.rs" \\
  || miss "missing critical file: serde_core/src/lib.rs"
test -f "serde_derive/src/lib.rs" \\
  && ok "serde_derive/src/lib.rs" \\
  || miss "missing critical file: serde_derive/src/lib.rs"
test -f "serde_derive/src/internals/ast.rs" \\
  && ok "serde_derive/src/internals/ast.rs" \\
  || miss "missing critical file: serde_derive/src/internals/ast.rs"
test -f "serde_core/src/ser/mod.rs" \\
  && ok "serde_core/src/ser/mod.rs" \\
  || miss "missing critical file: serde_core/src/ser/mod.rs"
test -f "serde_core/src/de/mod.rs" \\
  && ok "serde_core/src/de/mod.rs" \\
  || miss "missing critical file: serde_core/src/de/mod.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 93 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~63d)"
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/serde-rs/serde"
  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).

Serde is a high-performance serialization framework for Rust that provides derive macros and trait implementations to convert Rust data structures to/from any data format (JSON, YAML, TOML, MessagePack, etc.). It is the de facto standard serialization solution in Rust, used by virtually every library that needs to work with structured data. Monorepo with 5 crates: serde/ (core traits like Serialize/Deserialize), serde_core/ (lower-level implementations and type conversions), serde_derive/ (proc-macro for #[derive] attributes), serde_derive_internals/ (internal macro infrastructure), and test_suite/ (comprehensive integration tests). Core separation allows zero-dependency base library while keeping derive machinery separate.

Rust developers building libraries or applications that need to serialize/deserialize data structures. Library maintainers use serde_derive (the proc-macro crate) to provide derive support for their custom types. Data format implementers (like serde_json authors) implement Serde's Serializer/Deserializer traits to support their formats.

Serde is production-ready and extremely mature. It maintains MSRV of 1.56 (published Oct 2021) with serde_derive at 1.71, has comprehensive CI via .github/workflows/ci.yml, and is the most widely-used serialization crate in the Rust ecosystem. Active maintenance is evidenced by the workspace structure and multiple related crates.

Serde has minimal risk: it has no runtime dependencies (core crate is dependency-free), minimal build dependencies (only proc-macro2, quote, syn for the derive crate), and a stable API. The only risk is that derive-related changes require careful attention since serde_derive_internals is tightly coupled and affects all downstream derive users.

The repository structure shows active maintenance with CI workflows, though specific PR/issue data isn't visible in the provided file list. The separation of serde_core suggests ongoing effort to optimize and maintain backward compatibility.

git clone https://github.com/serde-rs/serde.git
cd serde
cargo build
cargo test

Daily commands: Not a binary project. To verify functionality: cargo test --all runs all tests in the workspace. For specific crate: cargo test -p serde or cargo test -p serde_core.

• serde_core/src/lib.rs — Main entry point defining the Serialize and Deserialize traits—all serialization frameworks depend on these core trait definitions.
• serde_derive/src/lib.rs — Procedural macro entry point generating Serialize and Deserialize implementations; every user relying on #[derive(...)] depends on this.
• serde_derive/src/internals/ast.rs — Abstract syntax tree and metadata extraction for derive macro inputs; foundation for all code generation logic.
• serde_core/src/ser/mod.rs — Core serialization trait implementations and infrastructure; defines the contract all serializers must satisfy.
• serde_core/src/de/mod.rs — Core deserialization trait implementations and visitor pattern; defines the contract all deserializers must satisfy.
• serde_derive/src/ser.rs — Serialization code generator for structs and enums; produces the actual Serialize trait implementations.
• serde_derive/src/de.rs — Deserialization code generator for structs and enums; produces the actual Deserialize trait implementations.

Add Serialize/Deserialize support for a new standard library type

1. Define the serialization logic in the type-specific impl block (serde_core/src/ser/impls.rs)
2. Define the deserialization logic and visitor in the corresponding section (serde_core/src/de/impls.rs)
3. Add test cases to verify serialization and deserialization roundtrips (test_suite/tests/regression.rs)

Add a new serde attribute to customize serialization behavior

1. Add the attribute variant to the symbol enum and parsing logic (serde_derive/src/internals/attr.rs)
2. Update AST structures to store the new attribute metadata (serde_derive/src/internals/ast.rs)
3. Implement code generation logic in the serializer generator (serde_derive/src/ser.rs)
4. Implement code generation logic in the deserializer generator (serde_derive/src/de.rs)
5. Add regression tests validating the new attribute behavior (test_suite/tests/macros/mod.rs)

Add support for a new enum tagging strategy

1. Create a new file in serde_derive/src/de/ for the tagging strategy (e.g., enum_customtagged.rs) (serde_derive/src/de/enum_externally.rs)
2. Implement the deserialization logic using the Visitor pattern (serde_derive/src/de.rs)
3. Add conditional logic to select the tagging strategy during code generation (serde_derive/src/internals/attr.rs)
4. Add comprehensive test cases for the new tagging strategy (test_suite/tests/regression.rs)

• Procedural macros (syn, quote, proc-macro2) — Enables compile-time code generation for Serialize/Deserialize implementations without runtime overhead; allows attribute-driven customization.
• Trait-based design (Serializer, Deserializer, Visitor) — Decouples data structures from serialization formats; enables multiple format implementations to reuse core framework.
• Workspace with multiple crates (serde, serde_core, serde_derive, serde_derive_internals) — Separates concerns: core traits stable across versions, derive macro can iterate faster, internals isolated, minimal binary bloat.
• no_std support via feature flags — Enables use in embedded and constrained environments; minimal allocator dependency.

• Separate serde_core and serde crates

  • Why: serde_core defines minimal trait surface for format implementors; serde adds convenience helpers. Reduces transitive dependencies.
  • Consequence: Slight additional complexity in workspace management, but better modularity for downstream users.

• Visitor pattern for deserialization instead of direct reconstruction

  • Why: Allows deserializers to work with streaming data and incomplete information without materializing entire structures upfront.
  • Consequence: More indirection and trait objects; harder to statically reason about all possible deserializations, but enables zero-copy and streaming formats.

• Procedural macro code generation instead of reflection at runtime

  • Why: Zero runtime overhead; type-safe code; fully customizable via attributes; catches errors at compile time.
  • Consequence: Longer compile times; larger binary size per crate; macro hygiene complexity; requires quote+syn dependencies.

• Generic trait bounds over concrete trait objects in derived code

  • Why: Enables monomorphization and specialization; avoids vtable indirection; improves inlining.
  • Consequence: Generated code can be verbose; increases binary size if not carefully optimized; limits dynamic dispatch scenarios.

• Real-time or streaming-first serialization (Serde focuses on complete data structures).
• Automatic migration of data across schema versions (applications must handle versioning).
• Built-in encryption or compression (delegated to format implementations).
• Validation of deserialized data against schemas (applications provide custom validators via Visitor).
• Introspection or reflection API (Serde is declarative only, not introspective at runtime).

The serde_derive and serde_derive_internals crates have a tight coupling; changes to one almost always require changes to the other. The private modules (serde/src/private/, serde_core/src/private/) expose internal APIs that external data format crates depend on—breaking changes here ripple through the ecosystem. Be careful when modifying the Visitor trait or Serializer interface, as these affect all downstream data format implementations.

• Visitor Pattern (Type-Driven Deserialization) — Serde's deserialization uses Visitor trait (serde_core/src/de/mod.rs) to let formatters guide type construction—understanding this pattern is essential to implementing custom Deserialize impls and data formats
• Zero-Cost Abstraction — Serde achieves performance on par with hand-written serialization code through monomorphization and inlining; no runtime overhead from trait dispatch
• Procedural Macros (syn/quote/proc-macro2) — serde_derive uses these to parse Rust code at compile time and generate Serialize/Deserialize implementations; critical for understanding how #[derive(Serialize)] works
• Trait-Based Polymorphism — Serde separates data types (Serialize/Deserialize) from format encoders (Serializer/Deserializer traits); this design enables format-agnostic serialization
• Self-Describing vs Non-Self-Describing Data — Serde supports both; some formatters (JSON, YAML) are self-describing while others (MessagePack, bincode) are not—the framework handles both via is_human_readable()
• Attribute Macros and Custom Derives — Users customize serialization behavior with #[serde(...)] attributes (flatten, rename, skip, etc.); the derive_internals crate parses and validates these

• serde-rs/json — Reference implementation of a data format on top of Serde; essential for understanding how Serializer/Deserializer are used in practice
• dtolnay/serde-ignored — Companion library providing IgnoredAny and ignore attributes, extends core Serde functionality
• tokio-rs/serde_json — Industry-standard JSON format implementation that depends on Serde core traits
• serde-rs/serde_derive — The procedural macro crate that generates Serialize/Deserialize trait implementations from #[derive] attributes
• ron-rs/ron — Rusty Object Notation format built on Serde; demonstrates how to implement a complete format using Serde's interfaces

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 tests for serde_core/src/de/value.rs deserialization edge cases

The value.rs module handles deserialization into serde_json-like dynamic values but lacks dedicated test coverage. Currently, deserialization implementations exist in serde_core/src/de/impls.rs, but there are no specific unit tests in serde_core/src/de/ validating edge cases like deeply nested structures, null handling, and type mismatches. This is critical since value.rs is a public API entry point.

• [ ] Create serde_core/src/de/value_tests.rs with tests for each Value variant
• [ ] Add tests for nested value deserialization and circular reference handling
• [ ] Add tests for error cases (e.g., type mismatches, invalid data)
• [ ] Test integration with various deserializer implementations
• [ ] Add tests validating the behavior matches serde_json's Value deserialization

Add MIRI and UB sanitizer CI workflow for memory safety validation

The repo has a basic CI workflow (.github/workflows/ci.yml) but lacks memory safety checks. Given serde's low-level serialization/deserialization work with potentially unsafe code in serde_derive and serde_core, adding MIRI (Rust's memory model interpreter) and UB (undefined behavior) sanitizer jobs would catch subtle memory bugs early. This is especially important for a foundational crate used by many projects.

• [ ] Add new GitHub Actions job in .github/workflows/ci.yml for MIRI testing
• [ ] Configure MIRI to run against serde_core/src/de/impls.rs and serde_core/src/ser/impls.rs
• [ ] Add another job for running tests with cargo-ubsan (undefined behavior sanitizer)
• [ ] Document in CONTRIBUTING.md how contributors should run these checks locally
• [ ] Ensure both jobs run on every PR and handle expected failures gracefully

Extract and document the proc-macro code generation patterns in serde_derive/src/bound.rs and related files

The serde_derive crate has complex trait bound generation logic spread across bound.rs and de/struct_.rs/de/enum_.rs but lacks internal documentation. The bound inference logic is crucial for users implementing custom derive macros, but the heuristics are undocumented. Creating a dedicated internal documentation module explaining when and why bounds are inferred would help future maintainers and contributors understand this non-obvious logic.

• [ ] Create serde_derive/src/bound_documentation.rs with detailed comments explaining trait bound inference rules
• [ ] Document the recursive bound inference algorithm and edge cases (e.g., PhantomData, generic constraints)
• [ ] Add examples showing how bounds differ between #[serde(bound = ...)], default inference, and PhantomData cases
• [ ] Add code comments to serde_derive/src/bound.rs explaining the primary functions (e.g., infer_ty_param_bounds)
• [ ] Update CONTRIBUTING.md with a section on 'Understanding Trait Bound Generation'

• Add more comprehensive documentation examples in serde_core/src/de/mod.rs for the Visitor pattern, which is non-obvious to new users implementing custom deserializers
• Improve test coverage for edge cases in serde_core/src/de/ignored_any.rs (IgnoredAny type)—this is frequently used but has minimal example coverage
• Add benchmarks comparing serialization performance across different derive macro strategies by creating a new benches/ directory and benchmarking serde_core/src/ser/impls.rs implementations against common patterns

The Serde codebase demonstrates strong security posture. As a serialization framework, it has minimal attack surface with no obvious injection vectors, hardcoded credentials, or misconfigurations detected. The workspace uses well-established dependencies (proc-macro2, quote, syn) with reasonable version constraints. The use of multiple license files (MIT/Apache 2.0) and organized CI/CD workflows via GitHub Actions indicates mature security practices. The main considerations are standard Rust ecosystem best practices: regular dependency audits via cargo audit, monitoring security advisories for proc-macro dependencies, and maintaining MSRV (Minimum Supported Rust Version) compatibility as documented.

• Low · Proc-macro2 dependency without pinned version — Cargo.toml (workspace.dependencies). The proc-macro2 dependency is specified as version 1.0.74 without a patch version lock. While this is standard practice in workspace dependencies, consider using more restrictive versioning for security-critical procedural macro code. Fix: Consider pinning to exact version (=1.0.74) if strict reproducibility is required, though current semver constraints are acceptable.
• Low · Syn dependency with default-features disabled — Cargo.toml (workspace.dependencies). The syn crate has default-features = false, which reduces attack surface but may cause subtle issues if features are required elsewhere. This is generally good but warrants verification. Fix: Verify that all required syn features are explicitly enabled where needed across the workspace members.

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.