ProjectQ is a mature quantum computing SDK and compiler framework: a Python library with a pybind11/C++ state-vector simulation core. Programmers write high-level quantum programs using an infix DSL (e.g., `H | qubit`, `CNOT | (ctrl, target)`), then a configurable pipeline of compiler engines decomposes, optimizes, and architecture-maps the resulting `Command` stream onto a target backend — a local simulator (classical, unitary, or C++ SIMD-accelerated state-vector), a circuit renderer (TikZ/LaTeX, matplotlib), or a cloud hardware vendor (IBM Quantum, IonQ, AQT, AWS Braket, Azure Quantum, each with its own HTTP/boto3 client). The repository also ships a quantum arithmetic library (ripple-carry adders, modular multiplication, division derived from published papers), a Pauli-operator algebra (`QubitOperator`), and meta-programming context managers (`Control`, `Loop`, `Dagger`, `Compute`/`Uncompute`) that let users express reversible circuits naturally. The architecture is an engine pipeline: `MainEngine` chains `BasicEngine` subclasses — optimizers (`LocalOptimizer`), a rule-based decomposer (`AutoReplacer` + `DecompositionRuleSet`), qubit mappers (`LinearMapper`, `GridMapper`, IBM-specific mappers), tag strippers, and backends — that communicate via `Command` objects. This is a clean, well-tested abstraction: every engine implements `receive`/`send`/`is_available`, and the decomposition system is a genuinely elegant rule engine with recognizer/decomposer pairs. The codebase shows high craftsmanship in several isolated components: hand-tuned AVX2/OpenMP C++ simulation kernels, the dictionary-based `QubitOperator` algebra, sophisticated SWAP-insertion mapper heuristics, and context-manager-based reversible-computation patterns. Test coverage is extensive (nearly every module has a paired `_test.py`) and CI spans multiple Python versions. The repository is hybrid in a narrow sense: it contains tutorial Jupyter notebooks and research-oriented examples (Grover, Shor, VQE for H2, spectral measurement) with academic citations, but these are usage demonstrations of a software framework, not data pipelines or research artifacts — the dominant character is a library/application. Drift is the main liability: cloud backends reference aging vendor APIs (old IBM QX device names, out-of-date IBM Quantum API paths), the Azure Quantum backend has been effectively disabled with a 'temporary workaround' comment, notebook kernelspecs still declare Python 2, release cadence has slowed sharply since v0.8.0 (2022), and the C++ kernel set exists in redundant intrin/nointrin variants that are heavy to maintain. The core compiler and simulator remain current and are the safest parts to build on; the cloud integrations should be treated as reference implementations subject to vendor drift.