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/google/draco 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 1d ago
• 23+ active contributors
• Distributed ownership (top contributor 28% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

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

What it runs against: a local clone of google/draco — 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 google/draco | 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 ≤ 31 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "google/draco(\\.git)?\\b" \\
  && ok "origin remote is google/draco" \\
  || miss "origin remote is not google/draco (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 "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "cmake/draco_options.cmake" \\
  && ok "cmake/draco_options.cmake" \\
  || miss "missing critical file: cmake/draco_options.cmake"
test -f "BUILDING.md" \\
  && ok "BUILDING.md" \\
  || miss "missing critical file: BUILDING.md"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "cmake/draco_targets.cmake" \\
  && ok "cmake/draco_targets.cmake" \\
  || miss "missing critical file: cmake/draco_targets.cmake"

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

Draco is a C++ library that compresses and decompresses 3D geometric meshes and point clouds using specialized algorithms (like edgebreaker and entropy coding) to achieve 10-100x size reduction. It provides encoders/decoders in C++, JavaScript/WebAssembly, Python, and C#, enabling efficient storage and transmission of 3D graphics across web, mobile, and desktop platforms. Core monolithic structure: src/draco/ contains the compression engine (draco_encoder, draco_decoder libraries), src/draco/tools/ has command-line utilities (draco_encoder, draco_decoder binaries), src/draco/transcoder/ implements glTF extension support. Separate build targets for C++ (native), Emscripten (JS/WASM via cmake/draco_emscripten.cmake), and language bindings (Python in src/draco/python, C# in src/draco/csharp). Cross-platform toolchains in cmake/toolchains/ for Android, iOS, ARM Linux, etc.

3D graphics engineers, glTF toolkit developers, and web developers building 3D viewers or CAD applications who need to reduce mesh/point-cloud file sizes for faster loading and lower bandwidth. Google uses this internally for Google Maps 3D, Poly, and other 3D services.

Production-ready and actively maintained. Version 1.5.7 released recently with security fixes and normalized attribute support. Strong CI/CD setup (.github/workflows/ci.yml), comprehensive CMake build system, and versioned releases deployed to Google's GStatic CDN. The C++ core (2.8M lines) indicates a substantial, well-tested codebase.

Standard open source risks apply.

Recent work (v1.5.7) focused on normalized attributes in Emscripten encoder API, security fixes, and partial glTF extension support (EXT_mesh_features, EXT_structural_metadata in v1.5.4). CI workflow active (.github/workflows/ci.yml), Dependabot configured for dependency updates. Gemini AI-assisted issue triage enabled (gemini-*.yml workflows).

git clone https://github.com/google/draco.git
cd draco
mkdir build && cd build
cmake ..
cmake --build . --config Release

Or for Node.js: npm install draco3d from npm registry (package.json shows v1.5.7).

Daily commands: Native: ./draco_encoder input.obj -o output.drc and ./draco_decoder output.drc -o decoded.obj (built binaries in build/examples/ or build/bin/). JavaScript: node draco_nodejs_example.js (per package.json test script). Web: include gstatic CDN versioned decoders (https://www.gstatic.com/draco/versioned/decoders/1.5.7/*) or build Emscripten version with cmake -DDRACO_EMSCRIPTEN=ON ...

• CMakeLists.txt — Root build configuration defining all compilation targets, dependencies, and platform-specific settings across the entire Draco library.
• cmake/draco_options.cmake — Central configuration file for all build-time options (WASM, Emscripten, feature flags) that fundamentally shape the compiled artifacts.
• BUILDING.md — Essential guide documenting build procedures, toolchain setup, and platform-specific compilation instructions for contributors.
• README.md — Project overview, versioning strategy, GStatic CDN guidance, and quick-start documentation required before contributing.
• cmake/draco_targets.cmake — Defines all CMake targets (encoder/decoder libraries, executables) and their cross-platform compilation rules.
• cmake/toolchains — Cross-compilation toolchain files for 15+ target platforms (Android, iOS, Linux ARM variants) essential for multi-platform support.

Add Support for a New Compression Algorithm

1. Create encoder/decoder implementation in src/compression/[algorithm_name]/ (src)
2. Add CMake option to enable/disable the algorithm in cmake/draco_options.cmake (cmake/draco_options.cmake)
3. Register the algorithm in the core encoder/decoder factory classes (src)
4. Add unit tests in the corresponding test directory structure (src)
5. Update documentation with compression performance characteristics in docs/ (docs)

Enable Draco for a New Platform/Architecture

1. Create new toolchain file in cmake/toolchains/[platform].cmake following existing patterns (aarch64-linux-gnu.cmake, arm64-ios.cmake) (cmake/toolchains)
2. Configure compiler flags, intrinsics, and platform-specific settings in the toolchain file (cmake/toolchains)
3. Add CMake conditional logic to cmake/draco_targets.cmake if platform-specific targets needed (cmake/draco_targets.cmake)
4. Add CI workflow step in .github/workflows/ci.yml for multi-platform testing (.github/workflows/ci.yml)
5. Document build instructions and platform-specific notes in BUILDING.md (BUILDING.md)

Add a New Language Binding or API

1. Create language-specific wrapper directory following pattern of javascript/ or python/ (CMakeLists.txt)
2. Define CMake targets and build rules in cmake/draco_targets.cmake for the new binding (cmake/draco_targets.cmake)
3. Implement encoder/decoder wrappers exposing core C++ API to the target language (javascript)
4. Add option flag in cmake/draco_options.cmake to conditionally enable the new binding (e.g., ENABLE_[LANGUAGE]_API) (cmake/draco_options.cmake)
5. Create example usage scripts and add CI test coverage in .github/workflows/ci.yml (.github/workflows/ci.yml)

Optimize Compression for Specific Geometry Types

1. Add conditional compilation paths in src/compression/attributes/ or src/compression/geometry/ for specialized codecs (src)
2. Create feature flag in cmake/draco_options.cmake to enable/disable the optimization (e.g., ENABLE_POINT_CLOUD_OPTIMIZATION) (cmake/draco_options.cmake)
3. Implement codec selection logic in encoder factory to detect and route to specialized algorithms (src)
4. Add benchmarking tests with real-world geometry samples to validate compression ratio improvements (src)

• CMake — Cross-platform build system supporting 15+ embedded/mobile targets (Android, iOS, Linux variants) with unified source tree and intrinsic detection.
• Emscripten — Compiles C++ encoder/decoder to WASM + JavaScript for browser deployment and GStatic CDN distribution without platform-specific binaries.
• C++11/17 — Core compression algorithms demand low-latency geometry processing with minimal memory overhead; C++ provides direct hardware intrinsics and predictable performance.
• Google Abseil (absl) — Dependency provides container abstractions, memory utilities, and cross-platform compatibility layer reducing reinvention of standard utilities.

• Single C++ codebase compiled to multiple targets (native, WASM, Node.js) rather than separate language implementations

  • Why: Ensures algorithmic consistency and reduces maintenance burden across platform variants.
  • Consequence: Adds Emscripten build complexity and requires careful C++ subset discipline; some platform-specific optimizations must wrap C++ core.

• GStatic versioned CDN URLs for WASM/JS decoders rather than npm-only distribution

  • Why: Enables instant browser deployment, automatic caching, and decoupling from npm release cycles.
  • Consequence: Developers must pin specific versioned URLs to avoid transient propagation failures; adds documentation burden.

• Pluggable compression algorithm selection at build time via CMake options (ENABLE_ATTRIBUTE_COMPRESSION, etc.)

  • Why: Allows embedded deployments to minimize binary size by excluding unused algorithms.
  • Consequence: Feature testing matrix explodes; CI must cover significant option combinations or risk untested codepaths in production.

• Quantization-based geometry compression (lossy) as default algorithm

  • Why: Achieves 50–200x compression ratios acceptable for 3D graphics; exact floating-point preservation rare in visualization pipelines.
  • Consequence: Bit-exact reconstruction impossible; applications requiring precision must use uncompressed fallback or accept quantization error.

• Real-time streaming or progressive mesh transfer (full decompression required before use)
• Lossless geometric compression at floating-point precision
• Platform-agnostic runtime (requires compilation per target; no pure-interpreter builds)
• Video codec integration (handles static 3D geometry only, not temporal sequences)
• Cloud-based encoding/decoding services (library-only, no hosted API)

1. Emscripten build requires EMSCRIPTEN env var and emsdk active (cmake/draco_emscripten.cmake enforces this). 2. WASM decoder versioning: GStatic URLs must match release tags exactly (https://www.gstatic.com/draco/versioned/decoders/VERSION/); using v1/decoders without version causes transient errors per README. 3. CMake is heavyweight with many toolchain files (cmake/toolchains/*.cmake); cross-platform builds often fail on first try due to missing NDK/iOS SDK paths. 4. Python/C#/Node.js bindings require successful C++ build first; they wrap the native library, not pure Python/C#. 5. Test suite uses Google Test (gtest); running tests requires -DRACO_TESTS_ENABLED=ON in CMake.

• Edgebreaker Algorithm — Draco's core mesh compression technique that encodes connectivity via edge traversal labels; understanding it unlocks the encoder/decoder logic in src/draco/compression/
• Entropy Coding (Huffman + Arithmetic) — Used by Draco to achieve final bitrate reduction on quantized geometry; see src/draco/compression/entropy_decoding.h for how decoded symbols are unpacked
• Attribute Quantization — Draco quantizes vertex positions, normals, and UVs to lower bitdepth; configured via draco_compression_options.h and critical for 10-100x compression ratios
• Half-Edge Data Structure — Draco uses half-edge mesh representation for efficient connectivity queries during encoding; see src/draco/core/mesh.h and mesh manipulation utilities
• Emscripten & WebAssembly Compilation — Draco C++ code compiles to WASM via Emscripten (cmake/draco_emscripten.cmake); understanding WASM memory model and JS-WASM interop is essential for browser deployment
• glTF Extension Mechanism — Draco extends glTF as a registered extension (KHR_draco_mesh_compression) and partially supports EXT_mesh_features; see src/draco/transcoder/ for implementation
• Cross-Compilation Toolchains — Draco targets 12+ platforms (ARM, x86, iOS, Android, WASM); cmake/toolchains/ folder contains platform-specific configuration; understanding CMake toolchain files is vital for porting

• KhronosGroup/glTF — Draco is a registered glTF extension codec; understanding glTF spec and KTX2 texture compression helps contextualize mesh compression use cases
• google/meshlab — 3D mesh processing tool that integrates Draco plugins for importing/exporting compressed geometries
• tinyobjloader/tinyobjloader — Lightweight OBJ file parser often paired with Draco for pre-processing mesh geometry before compression
• spatialspark/spatial-media — Uses Draco for compressing 3D assets in spatial computing workflows; shows production integration patterns
• BabylonJS/Babylon.js — WebGL engine with built-in Draco decoder support; major consumer of the JavaScript/WASM bindings from GStatic CDN

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 unit tests for cmake/draco_cpu_detection.cmake

The draco_cpu_detection.cmake file is critical for cross-platform builds across multiple architectures (aarch64, armv7, x86_64, etc.), but there are no visible test cases validating CPU detection logic. This is especially important given the 16+ architecture-specific toolchain files in cmake/toolchains/. A test suite would prevent regressions when CPU detection logic changes and improve confidence in cross-platform builds.

• [ ] Create tests/cmake/cpu_detection_test.cmake to test architecture detection logic
• [ ] Add test cases for each supported architecture (aarch64, armv7, x86_64, arm64-ios, etc.)
• [ ] Integrate tests into cmake/draco_tests.cmake configuration
• [ ] Document expected behavior in BUILDING.md for CPU detection verification

Add JavaScript/WebAssembly encoder/decoder integration tests to CI

The repo has Emscripten encoder/decoder support (mentioned in v1.5.7 release notes with normalized attributes support), but .github/workflows/ci.yml likely doesn't include JavaScript/WebAssembly-specific test coverage. With draco3d.js as the main entry point and npm package support, adding Node.js and browser-based integration tests would catch WebAssembly build/runtime regressions.

• [ ] Expand .github/workflows/ci.yml to add Node.js test job using 'draco_nodejs_example.js'
• [ ] Add test cases in tests/ for WASM encoder/decoder with various mesh compression scenarios
• [ ] Verify npm package installation and basic encode/decode functionality in CI
• [ ] Document expected JavaScript/WASM test results in BUILDING.md

Add security policy enforcement and documentation for Draco format versioning

SECURITY.md exists but the README contains critical warnings about GStatic versioned URLs and edge caching issues. There's no documented version compatibility testing or security advisory process visible in CI workflows. Given that Draco handles 3D graphics data (potential attack surface) and has security fixes in recent releases, adding version compatibility tests and formalizing the security release process would improve maintainability.

• [ ] Expand SECURITY.md with details on Draco format version compatibility guarantees
• [ ] Add .github/workflows/security-tests.yml to validate backward compatibility across recent versions (1.5.5, 1.5.6, 1.5.7)
• [ ] Create tests/version_compatibility/ with test fixtures for validating cross-version encode/decode
• [ ] Document the versioned URL deprecation path and release process in docs/

• Add missing unit tests for src/draco/io/ file I/O modules (PLY, OBJ reader error handling). Search for _test.cc files in that directory and note gaps; this improves robustness for non-drc formats.
• Improve CMake error messages in cmake/draco_options.cmake when required tools (Emscripten, NDK) are missing. Current errors are cryptic; adding FIND_PACKAGE(Emscripten REQUIRED) with friendly error text would save debugging time.
• Add documentation examples to docs/ showing how to use the C# bindings from src/draco/csharp/ (currently only C++ and JavaScript examples are visible). Include a sample .NET Console app that encodes/decodes a mesh.

The Draco project demonstrates a security-conscious approach with explicit hardening statements for decoder components and vulnerability reporting mechanisms. However, the security posture is weakened by incomplete documentation, potential gaps in non-decoder API validation, dependency management concerns, and unclear build security configurations. The project would benefit from completing security documentation, implementing automated dependency scanning, and ensuring consistent security hardening across all build configurations and APIs. The distinction between secure (decoder) and non-secure (encoder) APIs is appropriate but requires better developer-facing guardrails to prevent misuse.

• Medium · Dependency Vulnerability Tracking Gap — package.json. The package.json lacks a comprehensive lock file reference and dependency pinning strategy visible in the analysis. While the project uses CMake for C++ dependencies, the npm package (draco3d) does not specify exact versions for transitive dependencies, increasing the risk of supply chain attacks. Fix: Implement npm package-lock.json or yarn.lock to lock all transitive dependencies. Use automated dependency scanning tools (Snyk, OWASP Dependency-Check) in CI/CD pipeline.
• Medium · Insufficient Input Validation Documentation in Non-Decoder APIs — SECURITY.md. The SECURITY.md explicitly states that encoder API, draco_encoder, and draco_transcoder are 'not hardened against malicious input.' This creates a potential attack surface if these components are accidentally used with untrusted data by developers who may not read security documentation. Fix: Add runtime assertions and input validation checks to non-decoder APIs. Implement compiler warnings or runtime guards to prevent misuse. Consider splitting secure and non-secure APIs into separate namespaces with clear warnings in headers.
• Low · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be truncated at the end ('We use https://g.co/vulnz for our intake and triage. For valid'). The security reporting policy is incomplete, which could confuse security researchers about the proper disclosure process. Fix: Complete the SECURITY.md file with clear SLA for vulnerability responses, supported versions receiving security updates, and complete disclosure guidelines.
• Low · Build Configuration Security Best Practices — cmake/draco_flags.cmake, cmake/toolchains/. Multiple CMake toolchain files for cross-compilation are present, but the analysis shows no evidence of compiler security flags (like stack canaries, ASLR, or PIE) being consistently enforced across all platforms in the cmake/draco_flags.cmake configuration. Fix: Ensure all build configurations enable security flags: -fstack-protector-strong, -D_FORTIFY_SOURCE=2, -fPIE for executables, and -fPIC for libraries. Verify these are applied across all target platforms.
• Low · Automated Dependency Updates Not Visible — .github/dependabot.yml. While dependabot.yml exists indicating some automation, there is no visible evidence of regular dependency update schedules or security patch SLAs in the configuration files provided. Fix: Review and enforce dependabot configuration to automatically update dependencies with proper security scheduling. Ensure critical security patches are prioritized with aggressive update schedules.

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.