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/Tencent/rapidjson 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.

WAIT — Stale — last commit 1y ago

• 39+ active contributors
• Distributed ownership (top contributor 15% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Non-standard license (Other) — review terms

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

What it runs against: a local clone of Tencent/rapidjson — 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 Tencent/rapidjson | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 488 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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 488 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~458d)"
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/Tencent/rapidjson"
  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).

RapidJSON is a header-only C++ library that parses and generates JSON documents at speeds comparable to strlen(), supporting both SAX (streaming) and DOM (in-memory tree) parsing styles. It handles UTF-8, UTF-16, and UTF-32 encoding with automatic detection and transcoding, and is optimized with optional SSE2/SSE4.2 acceleration while maintaining zero external dependencies. Header-only library structure: core parsing/generation logic lives in include/ directory (inferred from header-only claim); example programs in example/; test data organized in bin/ with subdirectories for encodings/, jsonchecker/ (compliance tests), and draft-04/ (JSON Schema). CMake-based build system with optional GTest integration (CMakeModules/FindGTestSrc.cmake).

C++ systems engineers and performance-critical applications (game engines, financial systems, embedded services) who need fast JSON serialization/deserialization without pulling in heavy dependencies like Boost or STL; also used by library maintainers building higher-level JSON abstractions in C++.

Production-ready and stable. Version 1.1.0 released, maintained by Tencent since 2015, integrated CI/CD via Travis CI and AppVeyor, comprehensive test suite in bin/jsonchecker/ with 31 JSON validity test cases. Last activity visible in repo structure suggests active maintenance, though commit recency data is not provided.

Low maintenance risk — header-only design means no build/linking fragility, and zero external dependencies eliminate supply chain concerns. Primary risk is single-maintainer model (Milo Yip) visible in copyright. No breaking changes evident from CHANGELOG.md snippet, and C++ ABI compatibility is inherent to the design. Risk of becoming dormant is moderate given 2015 creation date without visible recent activity indicators.

No specific recent changes visible from provided data. Repository shows stable 1.1.0 release and test infrastructure (Travis/AppVeyor CI configured in .travis.yml and appveyor.yml), suggesting maintenance mode rather than active feature development. Presence of comprehensive test data (31 JSON test files) indicates quality focus.

git clone https://github.com/Tencent/rapidjson.git
cd rapidjson
mkdir build && cd build
cmake ..
make

No npm/package manager needed — this is a header-only C++ library. To use: copy include/ directory into your project or install via cmake install.

Daily commands: This is a library, not an executable. To build examples and tests: cd build && cmake .. && make && ctest. To use in your project: include <rapidjson/document.h> and link against nothing (header-only). Example code exists in example/ directory (inferred from file structure but specific files not listed).

• include/rapidjson/document.h: Core DOM API — defines Document, Value, and object/array construction; primary entry point for most users
• include/rapidjson/reader.h: SAX-style streaming parser — implements token-level parsing and error handling
• include/rapidjson/writer.h: JSON generation API — serializes DOM trees or handles SAX output events back to JSON text
• include/rapidjson/allocators.h: Memory management — defines pluggable allocator interface; critical for embedded/high-perf scenarios
• include/rapidjson/encodings.h: UTF-8/16/32 support — handles encoding detection, transcoding, and surrogate pair logic
• CMakeLists.txt: Build configuration — controls test targets, example compilation, and GTest integration
• bin/jsonchecker/: Compliance test suite — 31 JSON test files validate parser correctness against RFC7159

For parser/generator logic: edit headers in include/ (primary contribution area). For tests: add JSON test cases to bin/jsonchecker/ (follow naming pattern fail1.json–fail31.json for invalid JSON, or add positive cases). For encoding support: modify transcode/detection logic (likely in include/rapidjson/encodings.h, inferred). For performance: check include/rapidjson/allocators.h and SSE2/SSE4.2 codepaths (likely ifdef'd).

Header-only design means compile times can be slow for large projects (no forward declarations possible). No runtime type checking — DOM operations assume correct key/index access or crash (use HasMember/IsArray guards). Default allocator is not thread-safe; multi-threaded code must use custom allocators or synchronize. SSE2/SSE4.2 optimizations are opt-in via defines; generic C++ path may be slower than expected on older CPUs. No automatic null-character handling in strings; UTF-8 nulls must be escaped as \u0000 per JSON spec.

• SAX (Simple API for XML) parsing — RapidJSON's streaming parser is SAX-based; understanding event-driven parsing (OnString, OnNumber callbacks) is critical for memory-constrained scenarios and pipeline processing
• DOM (Document Object Model) — RapidJSON's tree-based API builds a DOM; knowing its in-memory 16-byte-per-value layout and traversal patterns is essential for efficient queries and mutations
• UTF-8/UTF-16/UTF-32 encoding and transcoding — RapidJSON's killer feature is automatic encoding detection and transcoding; understanding surrogate pairs, byte order marks (BOM), and code unit vs. code point is non-trivial
• Zero-copy parsing and move semantics — RapidJSON achieves strlen()-comparable speed through zero-copy string handling and C++11 move semantics; critical for understanding why it outperforms alternatives
• Memory allocators and custom allocation strategies — Pluggable allocator interface (MemoryPoolAllocator, CrtAllocator) allows stack-based or arena-based allocation; essential for embedded and high-frequency trading systems
• SSE2/SSE4.2 SIMD optimization — RapidJSON optionally uses SIMD for string scanning and number parsing; understanding CPU-specific code paths explains performance variance across architectures
• RFC 7159 / ECMA-404 JSON specification compliance — RapidJSON's test suite (bin/jsonchecker/) validates strict RFC7159 compliance; understanding grammar rules (no trailing commas, escape sequences, number precision) matters for compatibility

• nlohmann/json — Modern C++ JSON alternative with similar DOM API but C++11 STL-based; most popular competitor in C++17+ codebases
• open-source-parsers/jsoncpp — Earlier C++ JSON library with object-oriented design; slower than RapidJSON but more flexible for legacy codebases
• jqlang/jq — JSON query/transformation tool; complements RapidJSON for data extraction workflows (parse with RapidJSON, query with jq)
• Tencent/rapidxml — Sister project by original authors; same design philosophy (fast, header-only) applied to XML parsing
• google/gson — Java/Kotlin JSON library; not in C++ ecosystem but architecturally similar (SAX + DOM patterns, custom allocators)

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 encoding validation tests for UTF-8/UTF-16/UTF-32 variants

The repo contains encoding test data files (bin/encodings/*.json) for UTF-8, UTF-16BE/LE, UTF-32BE/LE with and without BOM, but there's no visible corresponding test suite that validates the parser against these encodings. This is critical for a JSON parser that claims to support multiple encodings. Adding unit tests that parse each encoding variant and verify correct handling would catch regressions.

• [ ] Create test/encodings_test.cpp that iterates through bin/encodings/*.json files
• [ ] Add tests for each encoding variant (UTF-8, UTF-8 BOM, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE with/without BOM)
• [ ] Verify correct parsing of non-ASCII characters in each encoding
• [ ] Add encoding detection tests to ensure the parser correctly identifies BOM markers
• [ ] Integrate test into CMakeLists.txt test suite

Add GitHub Actions CI workflow to replace/complement Travis CI and AppVeyor

The repo uses .travis.yml (Linux) and appveyor.yml (Windows) for CI, but both services have deprecated or changed their free tier offerings. GitHub Actions is native to GitHub and would provide faster, more reliable builds. This modernizes the CI infrastructure and makes it easier for contributors to see test results.

• [ ] Create .github/workflows/ci.yml with matrix strategy for Linux (GCC/Clang) and Windows (MSVC)
• [ ] Add CMake build, test, and code coverage steps (can reuse .travis.yml and appveyor.yml logic)
• [ ] Add coverage reporting integration (Codecov or Coveralls via GitHub Actions)
• [ ] Verify all existing test suites pass on new CI
• [ ] Update README.md badges to point to GitHub Actions workflow status

Add JSON Schema validation test suite from bin/jsonschema directory

The repo contains bin/jsonschema/ (appears to be a git submodule with official JSON Schema test suite), but there's no visible test code that validates RapidJSON's schema validation implementation against the official test cases. This would ensure spec compliance and catch edge cases in schema validation logic.

• [ ] Create test/jsonschema_test.cpp that loads test cases from bin/jsonschema/bin/jsonschema_suite
• [ ] Parse official JSON Schema test suite format (typically per-specification test vectors)
• [ ] Add parametrized tests for schema validation, covering all draft versions present in bin/jsonschema
• [ ] Verify both pass and fail cases match expected behavior
• [ ] Document any known deviations from official schema spec in test file comments

• Add positive-case JSON examples to bin/ (currently only fail*.json exist for compliance testing; missing valid.json files to verify parser accepts correct input)
• Document the custom allocator interface with a runnable example in example/ showing how to integrate with arena/pool allocators for embedded systems
• Create a CMake option to disable SSE2/SSE4.2 codepaths for easier cross-platform CI (currently no visible RAPIDJSON_USE_SSE2 guard in CMakeLists.txt)

RapidJSON demonstrates a generally strong security posture as a C++ JSON parser library. No critical or high-severity vulnerabilities were identified in the static analysis. The codebase lacks obvious injection risks, hardcoded secrets, or exposed credentials. Minor issues identified relate to metadata inconsistencies in package.json (version mismatch, license field, missing author) rather than code security vulnerabilities. The extensive test data (jsonchecker, jsonschema suites) indicates good test coverage. Recommendations focus on correcting administrative metadata to ensure proper version tracking and licensing compliance.

• Low · Outdated Package Version — package.json. The package.json specifies version 1.0.4, but the README indicates the release version is v1.1.0. This version mismatch could indicate the package metadata is out of date and may not reflect the current security patches available in newer versions. Fix: Update the version field in package.json to match the actual release version (v1.1.0) and verify all dependencies are current with security patches.
• Low · Non-Specific License Declaration — package.json - license field. The package.json declares an ISC license, but RapidJSON is typically released under the MIT License according to the README (Copyright 2015 THL A29 Limited, Tencent). This mismatch could cause legal/compliance issues. Fix: Update the license field to accurately reflect the actual license (MIT) used by the project.
• Low · Missing Author Information — package.json - author field. The package.json has an empty author field, while the README clearly attributes the work to Tencent and Milo Yip. Missing author metadata reduces accountability and may complicate attribution. Fix: Populate the author field with proper attribution: 'Tencent, Milo Yip' or similar.

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.