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/json 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

• Last commit 4w ago
• 14 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 85% 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/json repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/serde-rs/json.

What it runs against: a local clone of serde-rs/json — 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/json | 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 | Last commit ≤ 57 days ago | Catches sudden abandonment since generation |

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

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

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 57 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~27d)"
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/json"
  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-json is a Rust library that provides strongly-typed serialization and deserialization of JSON data via the Serde framework. It offers three JSON handling modes: parsing raw JSON text into a Value enum for untyped operations, deserializing into user-defined Rust structs for type safety, and serializing Rust types back to JSON. It includes a custom lexical float parser (in src/lexical/) for accurate number handling and supports no-std environments. Single-crate library under src/: lib.rs is the public API facade, value/ module handles the untyped Value enum and indexing, ser.rs and de.rs implement Serde traits, lexical/ contains the custom high-precision float parser (~30 files), io/ wraps reading sources, and error.rs provides error types. Fuzz testing harness in fuzz/ for robustness.

Rust developers building applications that need to parse, validate, or manipulate JSON data—from web service backends deserializing API payloads, to configuration file readers, to CLI tools working with structured data. Contributors are typically Rust library maintainers and performance enthusiasts interested in serialization efficiency.

Highly mature and production-ready. Version 1.0.149 with stable API, comprehensive test suite under tests/, active CI/CD in .github/workflows/ci.yml, and maintained by Serde core developers (David Tolnay, Erick Tryzelaar). The 2021 edition and MSRV of Rust 1.71 indicate active maintenance aligned with current Rust standards.

Low risk for core functionality—minimal dependencies (itoa, memchr, indexmap optional, serde_core), all well-maintained. Main risks are: custom lexical parser in src/lexical/ is complex and subtle (float parsing correctness), single maintainer model, and any numeric precision edge cases could affect downstream users. Breaking changes unlikely given v1.0 stability promise.

Unable to determine from provided repo data—no git commit history, PR list, or issue tracker visible. Check .github/workflows/ci.yml for current test matrix and Cargo.toml version (1.0.149) to infer recent activity. Repository README mentions this is the canonical Serde JSON implementation actively maintained.

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

Daily commands: This is a library, not a runnable application. For development: cargo build compiles, cargo test runs unit tests, cargo test --doc runs doc examples. Run fuzzer with cd fuzz && cargo fuzz run from_slice (requires cargo-fuzz).

• src/lib.rs: Public API surface; entry point for all crate functionality including from_str, from_slice, Value type, and to_string functions
• src/value/mod.rs: Defines the core Value enum (Null, Bool, Number, String, Array, Object) and its core methods—essential to understand for untyped JSON work
• src/de.rs: Implements the Serde Deserializer trait; contains all logic for parsing JSON into Rust types, handles all JSON syntax and type coercion
• src/ser.rs: Implements the Serde Serializer trait; handles converting Rust types to JSON representation with proper escaping and formatting
• src/lexical/mod.rs: Facade for custom high-precision float parser; critical for numeric accuracy; complex algorithm worth understanding before modifying number handling
• src/number.rs: Wraps numeric values with lossless representation; preserves original text and provides type conversions to i64, u64, f64
• src/error.rs: Error type Error with line/column tracking; all parse failures surface through this; important for user-facing error messages
• Cargo.toml: Feature gates for preserve_order, raw_value, unbounded_depth; controls optional dependencies and platform support

Adding features: Update Cargo.toml [features] section and guard code with #[cfg(feature = "...")]. Fixing parser bugs: Edit src/de.rs (main deserializer) or src/lexical/*.rs (number parsing). Adding Value operations: Modify src/value/mod.rs or src/value/index.rs. Error handling: Check src/error.rs. Serialization: Edit src/ser.rs for custom implementations. All changes should have tests added under tests/ or inline doc tests.

Numeric precision: The lexical submodule uses complex algorithms (Grisu3-style, cached powers) to parse floats accurately—modifying it risks silent regressions. Feature interactions: preserve_order feature swaps Map to use indexmap; code must not assume BTreeMap-like ordering without this. No-std support: Some features require alloc; runtime code may fail silently without heap in no-std mode. Serialization format: Pretty-printing behavior is fixed; there's no config object to customize indentation or field order (see ser.rs). The raw_value feature: Allows storing unparsed JSON text; complex lifetime handling in src/raw.rs.

• Serde Visitor Pattern — Core abstraction in src/de.rs and src/ser.rs; understanding how visit_* methods are called is essential to debug or extend deserialization
• Lexical Number Parsing (Grisu3-style) — Custom implementation in src/lexical/ handles float parsing with guaranteed accuracy; subtle algorithm you must understand before fixing numeric bugs
• Lossless Number Representation — src/number.rs stores both the original text and parsed value; preserves user intent (e.g., 1.0 vs 1) which matters in APIs and data validation
• No-std and Alloc-only Support — Features in Cargo.toml enable use in embedded/WASM; code must conditionally use Vec, String via alloc, not std, impacting trait bounds and error handling
• Insertion-order Preserving Maps — The preserve_order feature swaps the underlying Map type from BTreeMap to indexmap; affects iteration order and serialization determinism in user code
• Raw Value Borrowing — The raw_value feature (src/raw.rs) allows storing unparsed JSON text; complex lifetime mechanics to avoid copying; useful for transparent forwarding in APIs
• IEEE 754 Rounding and Precision — Lexical parser in src/lexical/rounding.rs and src/lexical/float.rs handles edge cases (subnormals, overflow) that silently corrupt numeric data if mishandled

• serde-rs/serde — Parent framework that serde-json implements; defines the Serializer/Deserializer traits and visitor pattern used throughout
• dtolnay/serde-json — Mirror/alternative source control; same maintainer (David Tolnay), used for historical context
• vectordotdev/vrl — Vector's expression language uses serde-json for JSON manipulation in data pipelines; exemplary downstream user
• tokio-rs/tokio — Async Rust runtime commonly paired with serde-json for parsing JSON from network I/O (HTTP, WebSocket)
• napi-rs/napi-rs — Bridges Rust and Node.js; serde-json used to exchange JSON between Rust and JavaScript layers

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 regression tests for lexical parsing edge cases

The repo has an extensive lexical float parsing implementation (src/lexical/) with 7 test modules in tests/lexical/, but only 3 regression tests exist (tests/regression/). The lexical module is complex and critical for correctness. Adding targeted regression tests for known float parsing edge cases (denormals, subnormals, rounding boundaries, extreme exponents) would catch future regressions in number parsing without duplicating unit tests.

• [ ] Review existing lexical test modules (tests/lexical/algorithm.rs, float.rs, parse.rs, etc.) to identify untested edge cases
• [ ] Create tests/regression/lexical_edge_cases.rs with cases for: denormalized floats, subnormal numbers, extreme exponents (e.g., 1e308, 1e-308), precision loss boundaries, and rounding behavior
• [ ] Reference src/lexical/algorithm.rs and src/lexical/float.rs to understand implementation details
• [ ] Run tests with MIRI to catch undefined behavior in edge cases

Add benchmark suite for serialization/deserialization performance across Value types

The repo lacks organized benchmarks despite serialization/deserialization being core functionality. With features like preserve_order (using indexmap), raw_value, and unbounded_depth, performance characteristics vary significantly. A dedicated benches/ directory would help contributors and maintainers track performance regressions and optimize hot paths.

• [ ] Create benches/ directory with cargo benchmark template
• [ ] Add benches/json_parsing.rs benchmarking: from_str with various JSON sizes (small, medium, large), nested objects, arrays, and numeric precision cases
• [ ] Add benches/json_serialization.rs benchmarking: to_string and to_vec with different Value types and optional features (preserve_order, raw_value)
• [ ] Document in CONTRIBUTING.md how to run benchmarks and compare baseline performance
• [ ] Reference src/ser.rs, src/de.rs, and src/value/mod.rs in benchmarks

Add fuzz target for number parsing and round-trip serialization consistency

The repo has a fuzz target for from_slice (fuzz/fuzz_targets/from_slice.rs) but lacks coverage for the critical lexical number parsing path and round-trip consistency. A dedicated fuzz target would catch subtle bugs in Number parsing (src/number.rs), float conversion, and serialization consistency without manual test creation.

• [ ] Create fuzz/fuzz_targets/number_roundtrip.rs using arbitrary crate to generate random numbers and JSON structures
• [ ] Implement fuzzing logic: parse JSON number -> serialize back -> parse again, verify consistency
• [ ] Add specific focus on src/number.rs Number type and src/lexical/parse.rs for edge cases
• [ ] Test with cargo +nightly fuzz --fuzz-dir=fuzz run number_roundtrip -- -max_len=1000
• [ ] Document findings in fuzz/README.md or CONTRIBUTING.md

• Add comprehensive roundtrip tests in tests/ comparing serialized → deserialized values for edge cases in src/lexical/ number parsing (subnormals, Infinity, very large exponents): Numeric edge cases are known risky; the codebase has a float_roundtrip feature but unclear test coverage of lexical algorithm boundaries
• Document the visitor protocol in src/de.rs with inline comments showing the exact order of method calls for different JSON types (e.g., array → visit_seq → visit_u64 for each element): Deserialization flow is non-obvious; new contributors struggle to add custom deserializer logic without understanding Serde's callback order
• Add explicit tests in tests/ for all combinations of preserve_order + indexmap to ensure Map iteration and serialization order is consistent: preserve_order is an optional feature that changes behavior; risk of silent bugs where tests pass without it but fail in users' code with it enabled

The serde-rs/json codebase demonstrates generally good security practices with fuzzing infrastructure and dual licensing. However, there are notable concerns: (1) the presence of non-standard dependency names ('serde_core', 'zmij') that warrant verification against the official repository to rule out supply chain attacks, (2) an unusual conditional dependency configuration that may indicate misconfiguration or obfuscation, and (3) lack of visible automated dependency vulnerability scanning in CI/CD. No hardcoded secrets, injection vulnerabilities, or infrastructure misconfigurations were identified in the available file structure. Immediate action is recommended to verify the legitimacy

• High · Unusual Dependency: 'serde_core' and 'zmij' — Cargo.toml - dependencies section. The Cargo.toml references 'serde_core' (version 1.0.220) and 'zmij' (version 1.0) as dependencies. These appear to be non-standard or potentially typosquatted package names. The actual Serde crate is typically 'serde', not 'serde_core'. This could indicate either: (1) a supply chain attack via typosquatting, (2) a misconfiguration, or (3) forked/unofficial dependencies. The 'zmij' package is also uncommon and warrants verification. Fix: Verify that 'serde_core' and 'zmij' are legitimate and approved dependencies. Cross-check against the official serde-rs/json repository on GitHub. Consider using the standard 'serde' crate instead of 'serde_core' if this is a deviation. Run 'cargo audit' to check for known vulnerabilities in all dependencies.
• Medium · Conditional Dependency Configuration Anomaly — Cargo.toml - target.'cfg(any())'.dependencies section. The Cargo.toml contains a target-specific dependency declaration: [target.'cfg(any())'.dependencies] for the 'serde' crate. The cfg(any()) condition is always true and appears unusual. This could indicate an attempt to hide or obfuscate a dependency condition, or it may be a misconfiguration that affects build reproducibility. Fix: Clarify the purpose of this conditional dependency. If 'serde' should always be available, move it to the main [dependencies] section. If it's conditionally required, use a proper feature flag or platform-specific configuration (e.g., [target.'cfg(unix)'.dependencies]). Ensure build configurations are transparent and reproducible.
• Medium · No Dependency Vulnerability Scanning in CI/CD — .github/workflows/ci.yml (content not fully visible). While a CI workflow exists (.github/workflows/ci.yml), there is no visible evidence of automated dependency scanning (e.g., via cargo audit, cargo deny, or GitHub's Dependabot) in the provided file structure. This means security vulnerabilities in transitive dependencies may not be detected automatically. Fix: Integrate cargo audit or cargo deny into the CI/CD pipeline to automatically scan for known vulnerabilities. Enable GitHub's Dependabot feature to receive alerts for vulnerable dependencies. Consider using tools like safety-cli for additional supply chain verification.
• Low · Fuzzing Target Without Visible Input Validation Documentation — fuzz/fuzz_targets/from_slice.rs and src/de.rs. The codebase includes fuzzing infrastructure (fuzz/fuzz_targets/from_slice.rs), which is good practice for JSON parsing. However, there is no visible documentation or security notes about input validation, maximum recursion depth handling, or DoS prevention mechanisms in the provided file structure. Fix: Document security considerations in fuzzing targets and deserialization code. Verify that the JSON parser implements safeguards against: (1) deeply nested JSON (stack overflow), (2) extremely large number values, (3) unbounded string lengths. Use the 'unbounded_depth' feature flag responsibly and document its security implications.
• Low · Missing SECURITY.md Policy — Repository root. The repository does not include a SECURITY.md file (visible in the file listing), which is a best practice for disclosing security vulnerabilities responsibly. This makes it unclear how security issues should be reported. Fix: Create a SECURITY.md file following the GitHub security policy template. Include instructions for reporting security vulnerabilities privately, expected response times, and contact information. Reference: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories

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.