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/nayuki/QR-Code-generator 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.

AVOID — Stale and unlicensed — last commit 1y ago

• 2 active contributors
• ⚠ Stale — last commit 1y ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 99% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected

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

What it runs against: a local clone of nayuki/QR-Code-generator — 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 nayuki/QR-Code-generator | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 500 days ago | Catches sudden abandonment since generation |

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

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

# 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 "java/src/main/java/io/nayuki/qrcodegen/QrCode.java" \\
  && ok "java/src/main/java/io/nayuki/qrcodegen/QrCode.java" \\
  || miss "missing critical file: java/src/main/java/io/nayuki/qrcodegen/QrCode.java"
test -f "java/src/main/java/io/nayuki/qrcodegen/QrSegment.java" \\
  && ok "java/src/main/java/io/nayuki/qrcodegen/QrSegment.java" \\
  || miss "missing critical file: java/src/main/java/io/nayuki/qrcodegen/QrSegment.java"
test -f "java/src/main/java/io/nayuki/qrcodegen/ReedSolomonGenerator.java" \\
  && ok "java/src/main/java/io/nayuki/qrcodegen/ReedSolomonGenerator.java" \\
  || miss "missing critical file: java/src/main/java/io/nayuki/qrcodegen/ReedSolomonGenerator.java"
test -f "python/qrcodegen.py" \\
  && ok "python/qrcodegen.py" \\
  || miss "missing critical file: python/qrcodegen.py"
test -f "rust/src/lib.rs" \\
  && ok "rust/src/lib.rs" \\
  || miss "missing critical file: rust/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 500 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~470d)"
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/nayuki/QR-Code-generator"
  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).

A high-quality QR Code generator library available in 6 languages (Java, TypeScript/JavaScript, Python, Rust, C++, C) that encodes data into QR symbols with support for all 40 versions and 4 error correction levels per QR Code Model 2 standard. It outputs raw module/pixel data and automatically selects optimal version, mask pattern, and encoding (numeric/alphanumeric/kanji/general text) to minimize code size. Language-specific monorepo: each major language has its own directory (java/, rust/, c/, cpp/, python/, typescript/) with self-contained source files, tests (qrcodegen-test.c, qrcodegen-demo.py, etc.), and Makefiles/pom.xml. Core algorithm is reimplemented per language rather than shared; java-fast/ and rust-no-heap/ are performance-optimized variants of their base implementations.

Backend engineers and full-stack developers building systems that need to generate QR codes programmatically—particularly those integrating QR generation across multiple language ecosystems or needing fine-grained control over encoding parameters rather than black-box solutions.

Highly mature, production-ready library: version 1.8.0 with MIT License, multi-language parity across 6 implementations, extensive documentation, and explicit test suites (qrcodegen-test.c, test coverage patterns across all ports). The architecture and API appear stable with no breaking changes indicated; actively maintained by Project Nayuki with clear documentation on the home page.

Minimal risk: single-maintainer (Project Nayuki) but project is well-established and not actively developed (no recent commit metadata visible in file list), so breaking changes are unlikely. No external dependencies listed in the Java pom.xml beyond Maven build plugins, reducing supply-chain exposure. The multi-language ports introduce maintenance burden if one language diverges, but the project's philosophy of 'nearly equal functionality' mitigates this.

No active development signals visible in the provided file list (no commit dates, PR counts, or issue timestamps). The project appears to be in maintenance mode with v1.8.0 as the current stable release. Focus is on keeping all 6 language ports in sync and documenting the stable API.

Clone the repository:

git clone https://github.com/nayuki/QR-Code-generator.git
cd QR-Code-generator

For Java: mvn clean package (uses pom.xml in java/ directory). For Python: python3 python/qrcodegen.py. For C: cd c && make. For Rust: cd rust && cargo build. For C++: cd cpp && make. For TypeScript: see typescript/ directory.

Daily commands: Each language has its own demo:

• Java: java -cp target/classes io.nayuki.qrcodegen.QrCodeGeneratorDemo (after Maven build)
• Python: python3 python/qrcodegen-demo.py
• C: cd c && make && ./qrcodegen-demo
• Rust: cd rust && cargo run --example qrcodegen-demo
• C++: cd cpp && make && ./QrCodeGeneratorDemo
• TypeScript: see typescript/ for Node.js or browser setup

• java/src/main/java/io/nayuki/qrcodegen/QrCode.java — Core QR code generation engine; implements the primary algorithm for encoding data, error correction, and module placement across all versions and error correction levels.
• java/src/main/java/io/nayuki/qrcodegen/QrSegment.java — Data segment abstraction that encodes text in optimal formats (numeric, alphanumeric, byte, kanji); critical for understanding capacity and encoding strategy.
• java/src/main/java/io/nayuki/qrcodegen/ReedSolomonGenerator.java — Error correction implementation using Reed-Solomon codes; essential for understanding how QR codes achieve fault tolerance.
• python/qrcodegen.py — Single-file Python reference implementation; demonstrates the canonical algorithm design that other language ports follow.
• rust/src/lib.rs — Rust port with zero unsafe code and comprehensive type safety; shows how the core algorithm adapts to memory-safe constraints.
• c/qrcodegen.c — Low-level C implementation with manual memory management; reveals performance-critical sections and platform constraints.
• typescript-javascript/qrcodegen.ts — TypeScript source that compiles to JavaScript for browser environments; entry point for web-based QR code generation.

Add support for a new encoding mode (e.g., Hanzi Chinese)

1. Extend QrSegment.Mode enum and add bit-width constants (java/src/main/java/io/nayuki/qrcodegen/QrSegment.java)
2. Implement character counting and encoding logic in the segment class (java/src/main/java/io/nayuki/qrcodegen/QrSegment.java)
3. Update capacity tables in QrCode.java for the new mode across all QR versions (java/src/main/java/io/nayuki/qrcodegen/QrCode.java)
4. Port changes to all language implementations (Python, Rust, C, C++, TypeScript) (python/qrcodegen.py)
5. Add test case in the demo showing new mode usage (java/QrCodeGeneratorDemo.java)

Optimize error correction for a specific language target

1. Profile ReedSolomonGenerator performance with test data (java/src/main/java/io/nayuki/qrcodegen/ReedSolomonGenerator.java)
2. Implement memoization lookup table in the fast variant (java-fast/io/nayuki/fastqrcodegen/Memoizer.java)
3. Benchmark and verify error correction output matches canonical implementation (java/src/main/java/io/nayuki/qrcodegen/QrCode.java)
4. Document performance improvement in language-specific README (java-fast/Readme.markdown)

Port QR generator to a new programming language

1. Study the Python reference implementation to understand the algorithm (python/qrcodegen.py)
2. Create core module with QrCode equivalent class and initialization logic (java/src/main/java/io/nayuki/qrcodegen/QrCode.java)
3. Implement QrSegment for data encoding and capacity lookup (java/src/main/java/io/nayuki/qrcodegen/QrSegment.java)
4. Port ReedSolomonGenerator for error correction (java/src/main/java/io/nayuki/qrcodegen/ReedSolomonGenerator.java)
5. Create demo application showing all features (java/QrCodeGeneratorDemo.java)
6. Add language-specific README with build and usage instructions (python/Readme.markdown)

• Multi-language implementation (Java, Python, Rust, C++, C, TypeScript) — Maximizes accessibility across ecosystems; enables validation of algorithm correctness through independent ports; serves diverse deployment contexts (server, embedded, browser)
• Reed-Solomon error correction — QR Code Model 2 standard requirement; allows recovery from up to 30% data loss; polynomial arithmetic over GF(256)
• Bit-level encoding with dynamic segment modes — Minimizes QR code size; numeric mode uses 3.33 bits/digit, alphanumeric 5.5 bits/char vs. 8 bits/byte for general text
• Penalty-based format optimization — QR Code spec uses penalty function to find optimal data placement; detects finder-like patterns and color runs to maximize scanner reliability

• Monolithic single-file implementations (Python, TypeScript) vs. modular Java structure

  • Why: Python/TypeScript target simplicity and ease of understanding; Java targets enterprise reusability with package structure
  • Consequence: Python code is <1000 lines but requires reading full file; Java is split across 5+ files, adding navigation overhead but enabling dependency injection

• Canonical reference in Python vs. optimized Java-fast with memoization

  • Why: Python clarity-first design ensures algorithm correctness; Java-fast uses precomputed lookup tables for 2–3× speedup
  • Consequence: Java-fast trades memory (~100KB tables) for speed; Python remains the source of truth for algorithm validation

• No unsafe code in Rust implementation vs. raw pointer use in C

  • Why: Rust safety guarantees prevent entire classes of bugs; C enables direct hardware control and minimal overhead
  • Consequence: Rust version slightly slower due to bounds checking; C version requires manual auditing for correctness

• Output raw module array vs. image file generation

  • Why: Raw output is format-agnostic and composable; user can render as PNG, SVG, terminal, PDF, etc.
  • Consequence: Library doesn't include image codecs; users must implement rendering layer

Java version divergence: pom.xml compiles for both Java 8 (excluding module-info.java) and Java 9+ (with modules). Ensure JDK version matches your target. Language parity assumptions: java-fast/ and rust-no-heap/ are intentionally divergent optimizations; don't assume feature parity with base implementations. No external dependencies by design: if integrating into a framework (Spring, etc.), you must manually handle image output—the library outputs raw module data, not PNG/JPEG. Kanji encoding (Java-only): QrSegmentAdvanced.java enables Japanese text compression but doesn't exist in other language ports; this is documented in the README but easy to overlook when switching languages.

• Reed-Solomon error correction — QR codes use RS codes to recover from damage; understanding polynomial remainder computation in ReedSolomonGenerator.java is key to grasping how this library ensures data integrity
• QR Code Model 2 specification — The ISO/IEC 18004 standard that defines all 40 versions, 4 error correction levels, finder patterns, and timing modules; this library is a faithful implementation of this spec
• Mask pattern optimization (penalty scoring) — QR codes apply 8 different XOR masks and select the one with the lowest 'penalty score' (fewer finder-like patterns); this library's unique strength is more accurate penalty detection than competitors
• Segment mode encoding (numeric/alphanumeric/kanji/byte) — Different data types compress differently; QrSegment.java auto-detects the optimal mode per chunk of input to minimize QR size—kanji mode (Java-only) saves ~30% space for Japanese text
• Version auto-selection with min/max constraints — QR has 40 versions (21×21 to 177×177 modules); this library searches the smallest version that fits the data within user-specified bounds, balancing scanability vs. density
• Bit-level packing and endianness handling — BitBuffer.java manages sub-byte data alignment for QR encoding; understanding bit shifting and byte order is essential for porting or extending the library
• Multi-language algorithm parity — The library reimplements the same algorithm in 6 languages with nearly identical APIs; understanding how to maintain parity (e.g., integer overflow behavior, floating-point precision) across languages is critical for bug fixes

• davidshimjs/qrcodejs — Pure JavaScript QR code generator alternative; lighter-weight but less configurable than this library's TypeScript port
• psf/requests — Not directly related but commonly paired: HTTP libraries that need QR codes for OAuth flows, webhooks, or API credential display
• zxing/zxing — Barcode/QR decoder library (counterpart); this repo generates QR codes while ZXing decodes them—often used together in full QR workflows
• google/brotli — Data compression library; relevant if you need to shrink QR payload by pre-compressing data before encoding with this library
• nayuki/Minimal-JSON — Another Project Nayuki library; demonstrates similar philosophy of compact, well-documented, multi-language implementations

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 cross-language integration tests comparing output across all 6 implementations

The repo has implementations in Java, TypeScript/JavaScript, Python, Rust, C++, and C, but lacks automated verification that all implementations produce identical QR codes for the same input. This is critical for a library claiming 'nearly equal functionality' across languages. Currently only individual language test files exist (qrcodegen-test.c, etc.), but no cross-compilation/cross-language test suite.

• [ ] Create a new test/cross-language-tests/ directory with a reference test data file (JSON) containing input strings and expected QR module outputs
• [ ] Add a Python script (test/cross-language-tests/verify-outputs.py) that compiles/runs each language implementation with test data and compares the raw module output
• [ ] Update each language's test file to output deterministic, comparable JSON or binary format (e.g., add output mode to qrcodegen-demo programs)
• [ ] Document in Readme.markdown how to run cross-language verification

Add GitHub Actions CI workflow for all 6 language implementations

The repo lacks visible CI/CD configuration (.github/workflows/). With implementations in C, C++, Java (Maven), Python, Rust (Cargo), and TypeScript, contributors cannot quickly validate that their changes work across all platforms. This is especially important for a multi-language library where platform-specific issues (e.g., integer overflow in C) could slip through.

• [ ] Create .github/workflows/ci.yml with matrix jobs for: Java (Maven test), Python (pytest), Rust (cargo test), C/C++ (gcc/clang via Makefile), TypeScript (npm/tsc)
• [ ] Add separate job for rust-no-heap variant with no_std validation
• [ ] Ensure cross-language test script (from PR idea #1) runs as final validation step
• [ ] Add badge to Readme.markdown linking to GitHub Actions status

Add missing per-implementation benchmarking suite and performance documentation

The README mentions 'compact implementation size' as a secondary goal and the existence of a 'rust-no-heap' variant, but there is no documented performance profile, memory usage comparison, or benchmarking harness across the 6 implementations. Contributes often need to know: which version is fastest? Which uses least memory? This is critical context for users choosing between implementations.

• [ ] Create benchmarks/ directory with language-specific benchmark files: benchmarks/java/QrBench.java, benchmarks/python/qrbench.py, benchmarks/rust/benches/qrbench.rs, benchmarks/cpp/qrbench.cpp, benchmarks/c/qrbench.c, benchmarks/typescript/qrbench.ts
• [ ] Each benchmark should measure: encode time for QR v1-v40, v10, v40 across all error correction levels; peak memory allocation
• [ ] Add benchmarks/README.markdown documenting how to run each benchmark and interpret results
• [ ] Document Rust vs Rust-no-heap trade-offs with actual measurements in rust/Readme.markdown and rust-no-heap/Readme.markdown

• Add comprehensive unit tests for TypeScript port: typescript/ directory exists but test suite structure is unclear in the file list; create a test runner (Jest or Mocha) and port the qrcodegen-test.c assertions to TypeScript/JavaScript
• Document the QrSegmentAdvanced.java kanji encoding logic with inline examples: the file exists but lacks usage examples for junior developers; add Javadoc comments showing how to encode 'こんにちは' efficiently
• Add a Python 3.10+ type hints refactor to python/qrcodegen.py: library predates widespread type annotation; add from __future__ import annotations and type hints to improve IDE support and documentation

The QR Code generator library has a strong security posture overall. It is a self-contained utility library with minimal external dependencies, which significantly reduces the attack surface. No hardcoded secrets, injection vulnerabilities, or critical misconfigurations were identified in the provided file structure. The primary security concerns are outdated Maven plugin versions that should be updated to their latest releases. The codebase follows a straightforward, well-documented implementation approach which aids in security auditing. Recommendations focus on dependency management hygiene and keeping build tools current.

• Medium · Outdated Maven Compiler Plugin — java/pom.xml. The maven-compiler-plugin version 3.8.1 is outdated and may contain known vulnerabilities. Current recommended version is 3.11.0 or later. Fix: Update maven-compiler-plugin to version 3.11.0 or latest available version to patch known security issues.
• Medium · Outdated Maven Javadoc Plugin — java/pom.xml. The maven-javadoc-plugin version 3.1.1 is outdated. Current recommended version is 3.5.0 or later. This plugin is used during the build process and may have known vulnerabilities. Fix: Update maven-javadoc-plugin to version 3.5.0 or latest available version.
• Low · Outdated Maven Source Plugin — java/pom.xml. The maven-source-plugin version 2.2.1 is outdated. Current recommended version is 3.2.1 or later. Fix: Update maven-source-plugin to version 3.2.1 or latest available version for improved stability and security.
• Low · Missing Security Dependencies Declaration — java/pom.xml. The pom.xml does not explicitly declare or constrain any security-related dependencies. While this library itself is a QR code generator with minimal external dependencies, best practice would be to explicitly list all transitive dependencies. Fix: Consider using dependency management with explicit version constraints and regular dependency audits via 'mvn dependency:check' or similar tools.

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.