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/apache/fory 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 today
• 12 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 75% 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 apache/fory repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/apache/fory.

What it runs against: a local clone of apache/fory — 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 apache/fory | 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 main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

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

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

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "MODULE.bazel" \\
  && ok "MODULE.bazel" \\
  || miss "missing critical file: MODULE.bazel"
test -f ".agents/repo-reference.md" \\
  && ok ".agents/repo-reference.md" \\
  || miss "missing critical file: .agents/repo-reference.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"

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

Apache Fory is a blazingly-fast multi-language serialization framework that uses JIT compilation (Java), static code generation (Rust/C++/Go), and zero-copy techniques to achieve up to 170x performance improvement over traditional serializers. It defines the xlang serialization format for seamless cross-language data exchange with reference preservation, polymorphism support, and schema evolution. Monorepo with language-specific directories: java/ (core JIT engine and serialization), python/ (CPython bindings), cpp/, rust/, go/, dart/, swift/, csharp/, typescript/, kotlin/, scala/ alongside docs/, benchmarks/, and .agents/ (AI/automation guidance). Code generation logic likely in build phase via Bazel; format specification in docs/specification/xlang_serialization_spec.md.

Distributed systems engineers, polyglot microservices teams, and performance-critical application developers who need efficient serialization across Java, Python, C++, Rust, Go, Dart, Swift, C#, TypeScript, and Kotlin without sacrificing ease of use or cross-language compatibility.

Actively developed and production-ready: Apache incubation project with multi-language implementations (Java 5.8M LOC, Python 2.3M, C++ 2M, Rust 1.7M), comprehensive CI/CD (.github/workflows/ with containerized and native builds), and published to major package registries (Maven Central, Crates.io, PyPI, npm, NuGet, pub.dev). Recent focus on stabilization post-rebranding from Fury to Fory (0.11+).

Medium-low risk for production use but with multi-language maintenance burden: 8 active language implementations require synchronized updates across monorepo; xlang format is core but adds specification stability concerns; Bazel build system (.bazelrc, .bazelversion) requires specific expertise; agent-based CI (.agents/) suggests some build automation complexity. No obvious single-maintainer risk given Apache governance structure.

Post-rebranding stabilization (Fury→Fory in 0.11+): package name migrations (.agents/repo-reference.md references both names), multi-language alignment, performance optimization CI/CD agents (.agents/skills/fory-performance-optimization/), code review automation (.agents/skills/fory-code-review/), and language-specific compliance (see .agents/languages/ for per-language standards).

git clone https://github.com/apache/fory && cd fory && bazel build //java:all (Java) or cd go/fory && go build ./... or cd python && python -m pip install -e . (Python). See .bazelrc and individual language directories for language-specific setup.

Daily commands: Java: bazel run //java:fory-benchmark; Go: cd benchmarks/go && go run main.go (see go.mod replace directive); Python: pyfory with native C++ backend. Containerized CI in .github/workflows/build-containerized-pr.yml, native CI in build-native-pr.yml.

• README.md — Entry point documenting Fory's mission as a blazingly fast multi-language serialization framework; defines core value propositions and links to all language implementations.
• MODULE.bazel — Bazel workspace configuration defining all build dependencies and module setup; essential for understanding the monorepo build orchestration across 11+ languages.
• .agents/repo-reference.md — High-level repository structure and conventions; required reading for understanding how this AI-augmented project is organized and how agents contribute.
• CONTRIBUTING.md — Contribution guidelines covering multi-language development, CI/CD workflows, and Apache ASF licensing requirements; mandatory for any pull request.
• .github/workflows/ci.yml — Primary CI pipeline validating builds, tests, and benchmarks across all language targets; defines the gate for all commits.
• BUILD — Root Bazel build file defining top-level targets and cross-language test orchestration; loads all language-specific builds.
• .bazelrc — Bazel configuration flags and platform-specific settings; critical for reproducible builds across containerized and native CI environments.

Add Support for a New Language

1. Create language convention document at .agents/languages/{lang}.md defining compiler flags, memory model, and FFI strategy (.agents/languages/cpp.md)
2. Add language target to MODULE.bazel with toolchain registration and transitive dependency declarations (MODULE.bazel)
3. Create benchmarks/{lang}/ directory with language-specific benchmark harness following the cpp/csharp/dart pattern (benchmarks/cpp/benchmark.cc)
4. Add .github/workflows/release-{lang}.yaml following the Maven/npm/Crates release template for automated package publishing (.github/workflows/release-java-snapshot.yaml)
5. Register language in .agents/skills/fory-code-review/references/validation-command-matrix.md with required build/test commands (.agents/skills/fory-code-review/references/validation-command-matrix.md)

Optimize Serialization Performance for a Bottleneck

1. Run benchmark suite for the target language using the established benchmark harness (e.g., benchmarks/cpp/run.sh) (benchmarks/cpp/run.sh)
2. Consult .agents/skills/fory-performance-optimization/references/bottleneck-playbook.md to classify the bottleneck (allocation, copy, dispatch, etc.) (.agents/skills/fory-performance-optimization/references/bottleneck-playbook.md)
3. Invoke the performance optimization agent via SKILL.md and provide benchmark baseline; agent will generate optimized codepaths (.agents/skills/fory-performance-optimization/SKILL.md)
4. Validate optimization does not regress other languages using bazel test //benchmarks:all and regenerate benchmark report (benchmarks/cpp/benchmark_report.py)

Propose a Change to Core Serialization Schema

1. Review .agents/skills/fory-code-review/references/review-checklist.md to understand API stability and breaking-change criteria (.agents/skills/fory-code-review/references/review-checklist.md)
2. Create a design document (markdown) and add it to the corresponding language folder under .agents/languages/ or root docs/ (.agents/languages/java.md)
3. Update schema definition files (IDL, proto, or codegen input) and run bazel build //... to validate cross-language code generation (BUILD)
4. Extend benchmarks for all affected languages to measure serialization/deserialization latency before and after the change (benchmarks/cpp/benchmark.cc)
5. Submit PR; the code-review agent will automatically validate against red-flags in references/lesson-derived-red-flags.md (.agents/skills/fory-code-review/references/lesson-derived-red-flags.md)

• Bazel — Hermetic, deterministic polyglot builds across 11+ languages with fine-grained caching and cross-compilation support; essential for monorepo consistency.
• JIT Compilation (mentioned in tagline) — Achieves 'blazingly

Bazel required for full build (not Maven/Cargo/pip alone); xlang format versioning tied to package version (breaking changes affect cross-language compatibility); Fury→Fory rebranding means old docs/imports invalid for 0.11+; Go module replace directive in benchmarks/go/go.mod points to local ../../../go/fory (path-dependent, breaks outside repo structure); .agents/ directory is automation guidance not runnable code; multi-language CI requires all 8 languages in test environment (see .github/workflows/build-containerized-*); Swift and Dart implementations lagging (876K, 873K LOC vs Java 5.8M).

• JIT Compilation for Serialization — Fory's Java impl generates bytecode at runtime to inline hot paths and eliminate virtual calls; understanding this is essential to grasping the 170x performance claim and why Fory outperforms reflection-based serializers
• Zero-Copy Deserialization — Core technique used across all Fory implementations to avoid allocation and memcpy overhead; critical for understanding why Fory beats protobuf and msgpack in benchmarks/
• Static Code Generation — Rust, C++, Go impls use compile-time codegen instead of runtime reflection; a key design choice separating languages and explaining performance distribution in benchmarks/
• xlang Format & Binary Wire Protocol — Fory's serialized format specification defines cross-language interoperability; must understand metadata packing, reference tables, and polymorphic type encoding to contribute meaningful changes
• Object Reference Preservation & Cycle Detection — xlang format supports shared and circular references across language boundaries; complex feature that explains why Fory is more than a simple codec and requires special handling in serialization and deserialization
• Metadata Packing & Class Schema Evolution — Fory compresses type metadata and supports forward/backward compatibility; essential for understanding framework design trade-offs and why schema evolution isn't free
• Polyglot Monorepo Build Orchestration — Bazel manages 8 languages with shared dependencies and xlang format compliance; critical for understanding PR validation flow (.agents/validation-command-matrix.md) and why language-specific changes may affect others

• protocolbuffers/protobuf — Industry-standard serialization with schema versioning; Fory benchmarks against protobuf as performance baseline
• apache/arrow — Cross-language columnar data format; complements Fory for analytics workloads requiring efficient columnar serialization
• capnproto/capnproto — Zero-copy serialization competitor with compile-time code generation; direct comparison for Fory's performance claims
• google/flatbuffers — Zero-copy serialization library also boasting multi-language support and compile-time codegen; architectural peer
• thrift-community/thrift — RPC framework with serialization layer; Fory targets same polyglot microservices use case with simpler API

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 integration test workflow for Go benchmarks

The repo has Go benchmarks (go.mod references fory v0.18.0-alpha.0) but there's no dedicated CI workflow for validating Go benchmark compilation and execution. Currently, only containerized and native build workflows exist. Adding a Go-specific benchmark validation workflow would catch regressions early and ensure the Go bindings remain stable across releases.

• [ ] Create .github/workflows/benchmark-go.yml that runs go mod tidy and go test ./... in benchmarks/go/
• [ ] Add Go version matrix (1.24.0 as minimum based on go.mod)
• [ ] Reference .agents/languages/go.md for language-specific best practices
• [ ] Validate msgpack and protobuf dependencies don't have conflicts

Add release CI workflow for Go packages

The repo has release workflows for Java, Python, Rust, JavaScript, Dart, and C#, but notably missing is a Go release workflow. Given that .github/workflows/release-*.yaml files exist for other languages and the Go module is part of the monorepo structure (go/fory), a dedicated Go release workflow would enable consistent multi-language release automation.

• [ ] Create .github/workflows/release-go.yaml following the pattern of release-rust.yaml and release-java-snapshot.yaml
• [ ] Reference .agents/languages/go.md for Go-specific release procedures
• [ ] Configure semantic versioning and tag detection for Go packages
• [ ] Add publishing to pkg.go.dev via Go module proxy

Document Fory serialization schema validation testing matrix

The repo has .agents/skills/fory-code-review/references/validation-command-matrix.md which is mentioned but the skill documentation doesn't have a complete cross-language validation test matrix. Given 11 supported languages (Java, Python, Rust, Go, JavaScript, Kotlin, Scala, C#, Swift, Dart, C++), there should be documented test scenarios for schema compatibility across language boundaries, especially for the zero-copy and JIT compilation features.

• [ ] Create .agents/testing/cross-language-validation.md documenting test scenarios for serialization schema validation
• [ ] Reference all language files in .agents/languages/ to ensure each language's specific validation concerns are covered
• [ ] Create a matrix showing which language pairs have been validated for serialization/deserialization round-trips
• [ ] Link to existing validation-command-matrix.md and expand with concrete test commands per language pair

• Add missing xlang format validation tests in {cpp,go,typescript,csharp}/ by porting Java test cases from java/core/src/test/ to demonstrate cross-language deserialization correctness
• Complete .agents/languages/{dart,swift}.md with build commands, test runners, and code generation patterns (Dart and Swift are smallest impls and likely under-documented)
• Create language-agnostic benchmark harness in benchmarks/ to auto-generate performance reports for all 8 languages instead of per-language scripts, enabling easy performance regressions detection in CI

The Go benchmark module has a generally acceptable security posture with minor concerns. The primary issue is the potentially invalid Go version specification (1.24.0), which should be corrected. Indirect dependencies are present but appear legitimate. The local replace directive is a development pattern that requires careful management in production pipelines. No hardcoded secrets, injection vulnerabilities, or critical infrastructure misconfigurations were detected in the analyzed files. Regular dependency audits and version management updates are recommended.

• Medium · Outdated Go Version in go.mod — benchmarks/go/go.mod (line: go 1.24.0). The go.mod file specifies Go 1.24.0, which may not exist or be the latest stable version. This could indicate the dependency file is from the future or misconfigured. Go version constraints should match released versions. Fix: Update to the latest stable Go version (e.g., go 1.22.x or go 1.23.x depending on release date). Verify the correct Go version is specified in go.mod.
• Low · Indirect Dependency Not Explicitly Managed — benchmarks/go/go.mod (line: require github.com/vmihailenco/tagparser/v2 v2.0.0 // indirect). The go.mod file includes an indirect dependency (github.com/vmihailenco/tagparser/v2) that is not explicitly required. While marked as indirect, ensure this dependency chain is intentional and regularly audited. Fix: Run 'go mod tidy' to ensure all indirect dependencies are necessary. Regularly audit dependencies with 'go list -u -m all' and use 'go mod graph' to understand the dependency tree.
• Low · Local Replace Directive in go.mod — benchmarks/go/go.mod (line: replace github.com/apache/fory/go/fory => ../../go/fory). The go.mod uses a local replace directive (replace github.com/apache/fory/go/fory => ../../go/fory). While acceptable for development, this can cause issues if committed to production builds or CI/CD pipelines without proper handling. Fix: Ensure replace directives are only used for local development. For CI/CD and releases, use properly tagged versions. Consider using conditional build tags or separate go.mod files for different environments.

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.