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/pocoproject/poco 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 — Mixed signals — read the receipts

• Last commit today
• 10 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 57% of recent commits
• ⚠ 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 pocoproject/poco repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/pocoproject/poco.

What it runs against: a local clone of pocoproject/poco — 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 pocoproject/poco | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 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 pocoproject/poco. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/pocoproject/poco.git
#   cd poco
#
# 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 pocoproject/poco and re-run."
  exit 2
fi

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

POCO (Portable Components) is a comprehensive cross-platform C++ library collection (~17.7M lines of C++) for building network-centric, internet-age applications. It provides production-grade abstractions for networking (HTTP/S, TCP/UDP), databases (MySQL, PostgreSQL, ODBC), XML/JSON parsing, threading, cryptography, and IoT scenarios—complementing the C++ Standard Library with practical, pre-built solutions rather than low-level APIs. Modular monorepo architecture: top-level directories like ActiveRecord/, Foundation/, Net/, Data/, Crypto/, and XML/ each represent independent but interdependent libraries. ActiveRecord/Compiler/ contains a code-generation tool (Parser.cpp, CodeGenerator.cpp) for ORM scaffolding. Build system is CMake-first (CMakeLists.txt throughout) with fallback Makefiles. GitHub Actions workflows (.github/workflows/) orchestrate testing, security scanning (CodeQL, fuzzing), and releases.

C++ developers building server applications, embedded systems, IoT devices, or desktop applications who need robust, cross-platform networking and data handling without reinventing HTTP clients, database drivers, or SSL/TLS wrappers. Also used by teams maintaining long-lived systems requiring stability across Windows, Linux, macOS, and embedded platforms.

Highly mature and production-ready. The project has Boost Software License heritage, demonstrates CII Best Practices certification, includes comprehensive CI/CD via GitHub Actions (.github/workflows/ci.yml, cifuzz.yml, codeql.yml), and actively maintains CMake 3.26+ and C++17/20 support. The large codebase (17.7M C++ lines) and structured module layout (ActiveRecord, Foundation, Net, Data, Crypto components) indicate years of battle-tested development.

Low risk for stable use cases; moderate risk for cutting-edge features. Dependency on OpenSSL (1.1.1+) and optional MySQL/PostgreSQL clients introduces external maintenance surface. The monolithic module structure means breaking changes in one library (e.g., Net/HTTP refactor) could affect dependent code across the repo. No indication of single-maintainer risk given the organization (pocoproject), but integration with multiple database drivers (MySQL, PostgreSQL, ODBC) means version compatibility issues are possible.

Active development visible via CI workflows: CodeQL scans run regularly (.github/workflows/codeql.yml), fuzzing is enabled (cifuzz.yml), and there's a semantic-release publish pipeline (.github/workflows/publish_release.yml). The .github/actions/retry-action (TypeScript + GitHub Actions) and upload-test-report suggest recent focus on CI robustness. Maintenance of C++20 support and CMake 3.28+ features indicates ongoing modernization.

git clone https://github.com/pocoproject/poco.git
cd poco
mkdir build && cd build
cmake -DENABLE_CRYPTO=ON -DENABLE_NET_SSL=ON -DENABLE_DATA=ON ..
make -j$(nproc)
make test

Prerequisites: CMake 3.26+, C++17 compiler, OpenSSL 1.1.1+, and optionally libmysqlclient-dev or libpq-dev for database support.

Daily commands: After build (see howDoIStart): ./bin/PocoTest or run individual test suites in build/bin/. For examples, check respective library directories (e.g., Net/samples/ for HTTP examples). No dev server in traditional sense—POCO is a library, not a service.

• CMakeLists.txt: Root CMake configuration controlling all module builds, feature flags (ENABLE_CRYPTO, ENABLE_DATA, etc.), and dependency resolution for OpenSSL, MySQL, PostgreSQL.
• .github/workflows/ci.yml: Primary CI pipeline testing across multiple platforms, compilers, and configurations; reveals expected build artifacts and test suites.
• Foundation/include/Poco/Foundation.h: Core header for Foundation library—threading, exception handling, and utility classes that all other POCO modules depend on.
• Net/include/Poco/Net/HTTPServer.h: Central HTTP server abstraction; key API many users interact with for building web services.
• ActiveRecord/Compiler/src/CodeGenerator.cpp: ORM code generation engine—critical for ActiveRecord functionality and illustrates how POCO generates boilerplate from declarations.
• Data/include/Poco/Data/Session.h: Database abstraction layer header; defines the unified API for MySQL, PostgreSQL, ODBC backends.
• .github/workflows/codeql.yml: Security scanning pipeline showing POCO's commitment to code quality and identifying vulnerability classes (use-after-free, etc.).

New networking feature: modify files in Net/include/Poco/Net/ (headers) and Net/src/ (implementation), add tests to Net/testsuite/. New database adapter: extend Data/src/ and add ORM code generator logic to ActiveRecord/Compiler/src/. Bug fix: locate offending code in library-specific src/ directories (e.g., Foundation/src/ for threading bugs), write a minimal test in library/testsuite/, commit with reference to issue number. All changes require CMakeLists.txt updates if adding new files.

1. OpenSSL version pinning: Requires OpenSSL 1.1.1+; distributions dropping OpenSSL 1.0.x will break builds. 2. CMake 3.26+ hard requirement: Older CMake versions will fail silently or with cryptic errors; check cmake --version before debugging build issues. 3. Optional dependencies are optional but recommended: Building without OpenSSL (ENABLE_CRYPTO=OFF) disables HTTPS, digital signatures, and encryption—many real-world apps require these. 4. Database driver availability varies: MySQL/PostgreSQL support depends on libmysqlclient-dev / libpq-dev being installed; builds may silently skip Data module if headers are missing. 5. ActiveRecord compiler must be built first: If using ORM code generation, the compiler in ActiveRecord/Compiler/ must be compiled before running the code generator on model definitions.

• Thread Pool Pattern — Foundation/src/ThreadPool.cpp implements a work-queue-based thread pool—critical for understanding how POCO's HTTPServer handles concurrent connections without creating a thread per request.
• Active Record Pattern (ORM) — The ActiveRecord/ module (with code generation in ActiveRecord/Compiler/) maps database rows to in-memory objects—you must understand this to use POCO's database layer effectively and generate model classes.
• SSL/TLS Handshake and Certificate Verification — Poco::Net::SecureSocketStream (in Crypto/) wraps OpenSSL for HTTPS; understanding certificate chains and host verification is essential for secure server implementations.
• Connection Pooling — Data/src/ implements connection pooling for databases; reusing connections is critical for performance in web services—POCO abstracts this away but understanding the pattern prevents connection exhaustion bugs.
• Reactor Pattern (Event-Driven I/O) — Net/src/ uses Poco::Net::SocketReactor for multiplexing multiple sockets; understanding readiness-based I/O vs. threading is key to scaling POCO HTTPServer beyond basic use.
• Cross-Platform Abstraction (Platform-Specific Code) — POCO runs on Windows, Linux, macOS, and embedded systems—conditional compilation (Foundation/src/Platform.cpp) hides OS differences; understanding how to add platform-specific code is necessary for contributing system-level features.
• Boost Software License (BSL-1.0) — POCO uses BSL-1.0 (permissive, similar to Apache 2.0) rather than GPL—critical for proprietary software; contributions must respect this license.

• asio/asio — Lightweight alternative for async network I/O; POCO provides higher-level abstractions (HTTPServer, HTTPClient) while ASIO offers lower-level reactor pattern control.
• nlohmann/json — POCO includes JSON parsing (Poco::JSON namespace) but nlohmann/json is a lighter, header-only alternative if you only need JSON without the full POCO stack.
• boostorg/boost — POCO is conceptually similar to Boost (both provide cross-platform C++ abstractions) but more focused on network/web while Boost is broader; both can coexist in projects.
• cpp-netlib/cpp-netlib — Modern C++ HTTP client/server library; competes with POCO's Net module but with C++11+ idioms; useful for projects wanting lighter weight than full POCO.
• pistacheio/pistache — Minimalist C++17 REST framework; addresses the same HTTP server use case as POCO but with micro-framework philosophy vs. POCO's comprehensive library approach.

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 ActiveRecord/Compiler source modules

The ActiveRecord/Compiler directory contains critical code generation components (CodeGenerator.cpp, HeaderGenerator.cpp, ImplGenerator.cpp, Parser.cpp) but there is no visible testsuite directory for the Compiler itself, only for the ORM at ActiveRecord/testsuite/. Code generators are particularly error-prone and need thorough testing to prevent broken generated code. This would significantly improve code quality and prevent regressions.

• [ ] Create ActiveRecord/Compiler/testsuite directory structure mirroring ActiveRecord/testsuite
• [ ] Add unit tests for Parser.cpp covering various ORM.xml schema variations and edge cases
• [ ] Add unit tests for CodeGenerator.cpp, HeaderGenerator.cpp, and ImplGenerator.cpp to validate generated output correctness
• [ ] Integrate Compiler tests into CMakeLists.txt build system
• [ ] Add test execution step to .github/workflows/ci.yml for the Compiler testsuite

Add GitHub Actions workflow for dependency vulnerability scanning (dependabot/Snyk integration)

The repo has .github/workflows/codeql.yml for code security analysis but lacks automated dependency scanning. The npm package.json for retry-action shows multiple production dependencies (@actions/core, milliseconds, tree-kill) that should be monitored for vulnerabilities. Given POCO's role in network and IoT applications where security is critical, automated dependency scanning would catch supply-chain risks early.

• [ ] Create .github/workflows/dependency-scan.yml workflow file
• [ ] Configure Dependabot alerts in repository settings or use native GitHub dependency scanning
• [ ] Add steps to scan both native C++ dependencies (CMakeLists.txt files) and npm dependencies (.github/actions/*/package.json)
• [ ] Configure automated PR creation for security patches with appropriate labels
• [ ] Document dependency update process in CONTRIBUTING.md

Add integration test workflow for CMake build across multiple platforms and configurations

While .github/workflows/ci.yml exists, the visibility into its scope is limited in the provided structure. Given POCO's core value proposition is cross-platform compatibility (embedded to server, desktop to IoT), there should be explicit CI workflows testing CMake builds on Windows, Linux, and macOS with various C++ standard versions and build configurations. This ensures the CMakeLists.txt files throughout the repo (ActiveRecord/CMakeLists.txt, ActiveRecord/Compiler/CMakeLists.txt, ActiveRecord/testsuite/CMakeLists.txt) work correctly everywhere.

• [ ] Extend or create .github/workflows/cmake-multiplatform.yml with matrix strategy for [windows-latest, ubuntu-latest, macos-latest]
• [ ] Add matrix for C++ standard versions (C++11, C++14, C++17, C++20) where applicable
• [ ] Include both Debug and Release build configurations
• [ ] Test CMake with and without optional dependencies to validate conditional compilation
• [ ] Add build artifact retention and test report uploads using existing .github/actions/upload-test-report

• Add unit test coverage for Poco::Net::HTTPClientSession timeout handling—check Net/testsuite/ for existing patterns, then add test cases for connection-timeout and read-timeout edge cases with mock servers.
• Document CMake feature flags with examples: create a new docs/CMAKE_OPTIONS.md file listing all ENABLE_* and POCO_* flags (ENABLE_CRYPTO, ENABLE_DATA_MYSQL, ENABLE_SHARED, etc.) with descriptions and how they affect downstream APIs, plus small example CMakeLists.txt snippets.
• Implement missing SHA-512 test vectors in Crypto/testsuite/—NIST test vectors exist; add them as static test cases in the SHA digest test suite to improve cryptographic test coverage and comply with FIPS validation expectations.

The POCO project's GitHub Actions retry utility has moderate security concerns primarily related to outdated dependencies (especially dotenv 8.2.0 with CVE-2021-3749) and loose

• High · Outdated dotenv Dependency with Known Vulnerabilities — .github/actions/retry-action/package.json (devDependencies). The package.json specifies dotenv version 8.2.0, which was released in 2020 and contains known security vulnerabilities (CVE-2021-3749). This version should be updated to the latest stable version (16.x or higher) to patch security issues related to environment variable handling. Fix: Update dotenv to version ^16.0.0 or latest stable version. Run 'npm update dotenv' or manually update the version constraint.
• Medium · Potential Uncontrolled Process Execution via tree-kill — .github/actions/retry-action/package.json (dependencies). The dependency 'tree-kill' (^1.2.2) is used to kill processes. If process IDs or signals are derived from untrusted input without validation, this could lead to unintended process termination or privilege escalation. The wildcard version constraint also allows minor/patch updates that could introduce breaking changes. Fix: Pin the version to a specific release (e.g., 1.2.2 instead of ^1.2.2) after thorough testing. Validate and sanitize any process identifiers before passing them to tree-kill functions.
• Medium · Missing Semantic Versioning Pinning for Critical Dependencies — .github/actions/retry-action/package.json (dependencies). Multiple core dependencies use caret (^) version constraints which allow breaking changes in minor versions. For CI/CD automation and GitHub Actions, this creates non-deterministic builds and potential security drifts. '@actions/core' (^1.10.0), '@types/node' (^20.11.24), and others could receive unexpected updates. Fix: Pin all dependencies to exact versions (remove ^, ~, etc.) or use lock files (package-lock.json) committed to the repository. Consider using 'npm ci' instead of 'npm install' in CI/CD pipelines.
• Medium · Outdated TypeScript and Related Dev Dependencies — .github/actions/retry-action/package.json (devDependencies). TypeScript (^4.7.4) and related build tools are from 2022. While not directly exploitable, older compiler versions may miss security warnings and have unpatched vulnerabilities in the toolchain itself. Fix: Update TypeScript to ^5.0.0 or latest, and update all related dev dependencies (@typescript-eslint/*, ts-jest, ts-node) to their latest stable versions.
• Low · Hardcoded Version in package.json — .github/actions/retry-action/package.json (version field). The package version is set to '0.0.0-managed-by-semantic-release', which indicates semantic versioning is managed externally. While not a direct security issue, this requires strict process controls to prevent accidental releases. Fix: Ensure semantic-release is properly configured with branch protection rules and automated release workflows to prevent accidental or malicious version bumps.
• Low · Permissive ESLint Configuration Not Visible — .github/actions/retry-action/.config/.eslintrc.js (not provided). The lint configuration references './.config/.eslintrc.js' which is not provided in the file structure. Without visibility into ESLint rules, potential security checks (e.g., no-eval, no-implied-eval) may be disabled. Fix: Review ESLint configuration to ensure security-relevant rules are enabled. Use plugins like 'eslint-plugin-security' to catch common security anti-patterns.
• Low · Missing npm Audit and Security Scanning in CI/CD — .github/actions/retry-action/package.json (scripts section). The package.json does not show npm audit or security scanning scripts in the test/lint pipeline. No evidence of automated vulnerability scanning in workflows. Fix: Add 'npm audit' and 'npm audit fix' commands to the CI/CD pipeline. Consider using 'npm audit --audit-level=moderate' to enforce security baselines.

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.