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/KDE/krita 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 1d ago
• 15 active contributors
• Distributed ownership (top contributor 30% of recent commits)
• GPL-3.0 licensed
• Tests present
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows 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 KDE/krita repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/KDE/krita.

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 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 "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "KoConfig.h.cmake" \\
  && ok "KoConfig.h.cmake" \\
  || miss "missing critical file: KoConfig.h.cmake"
test -f "KoAlwaysInline.h" \\
  && ok "KoAlwaysInline.h" \\
  || miss "missing critical file: KoAlwaysInline.h"
test -f ".clang-format" \\
  && ok ".clang-format" \\
  || miss "missing critical file: .clang-format"
test -f "HACKING" \\
  && ok "HACKING" \\
  || miss "missing critical file: HACKING"

# 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/KDE/krita"
  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).

Krita is a professional digital painting application built on Qt and KDE frameworks, offering a complete end-to-end solution for creating, editing, and compositing digital artwork. It provides layer-based compositing, advanced brush engines, color management, animation support, and VFX capabilities used by comic artists, illustrators, and visual effects professionals. The codebase is 32.2 MB of C++ with Python scripting support for plugins and automation. Monolithic Qt/KDE C++ application with clearly separated concerns: core painting engine and layer system, plugin architecture (3rdparty_plugins/ for extensions like G'MIC), Python bindings for scripting, UI components built with Qt/QML, and vendored dependencies (3rdparty_vendor/ for raqm text shaping). Build system uses CMake with multi-platform targets (Linux AppImage, Windows NSIS, macOS).

Digital artists, comic book illustrators, concept artists, texture painters, and VFX professionals who need professional-grade painting tools with layer compositing, advanced brush customization, and non-destructive editing workflows. Open source contributors interested in graphics applications, KDE ecosystem development, and cross-platform desktop applications.

Production-ready and actively developed. Krita is a mature project with stable branch management (krita/5.2 for stable, master for development), official nightly builds, comprehensive CI/CD via KDE's GitLab, and ongoing feature development despite current feature freeze on master branch. The project has professional adoption in the VFX industry and maintains structured release cycles.

Low risk for a mature project, but notable concerns include: complex dependencies on Qt, KDE frameworks, and graphics libraries (raqm for text shaping, gmic for filters) that may have deployment challenges; master branch is currently feature-frozen suggesting imminent major release so stability work is priority; monolithic C++ codebase means changes can have wide surface area. CI pipelines exist but debug/ASAN builds require manual artifact collection from GitLab jobs.

Master branch is in feature freeze with string freeze active, indicating preparation for a major release. Recent focus appears to be on stabilization and bug fixes rather than new features. Nightly builds are available at cdn.kde.org/ci-builds/graphics/krita/master/, and the project maintains separate stable builds for krita/5.2 branch. CI runs on KDE's infrastructure with specialized builds for debugging (linux-debug-weekly) and memory sanitization (linux-asan-weekly).

Clone from the official KDE repository (GitHub is a mirror only):

git clone https://invent.kde.org/graphics/krita.git
cd krita
mkdir build && cd build
cmake ..
make -j$(nproc)
./bin/krita

Full build instructions are at https://docs.krita.org/en/untranslatable_pages/building_krita.html. Requires Qt 5.x, KDE Frameworks, CMake, and platform-specific graphics libraries.

Daily commands: After building (see howDoIStart), run directly from build directory: ./bin/krita [file.kra]. For development iteration, use CMake's install target: cmake --build . --target install --config Debug then krita. Debug builds with symbols are available from CI artifacts at https://invent.kde.org/graphics/krita/-/jobs (search linux-debug-weekly).

• CMakeLists.txt — Root build configuration for Krita; defines dependencies, compiler flags, and conditional features for Qt/KDE integration across all platforms.
• KoConfig.h.cmake — Core configuration header template; generates platform-specific defines for the entire codebase at build time.
• KoAlwaysInline.h — Critical performance macro used throughout hot paths in rendering and brush engines; affects optimization across the codebase.
• .clang-format — Code style enforcement; all contributors must format changes to pass CI checks and maintain consistency.
• HACKING — Developer onboarding guide; essential reference for build instructions, workflow, and contribution expectations.
• .lgtm.yml — LGTM code analysis configuration; defines static analysis rules and quality gates for pull requests.
• CODE_OF_CONDUCT.md — Community standards and conduct policy; sets expectations for all contributor interactions in the project.

Add a new brush engine or filter plugin

1. Create a new subdirectory in the appropriate plugin location under src/ (CMakeLists.txt (root))
2. Define CMake target with add_library() and link against KIS core libraries ([YourPlugin]/CMakeLists.txt)
3. Implement the plugin interface class inheriting from KisPaintOp or KisFilter ([YourPlugin]/Kis[YourPlugin].cpp)
4. Register plugin factory in KisPaintOpRegistry or KisFilterRegistry ([YourPlugin]/Kis[YourPlugin]Factory.cpp)
5. Add UI settings widget if needed, following existing *.ui patterns ([YourPlugin]/Kis[YourPlugin]OptionsWidget.cpp)
6. Ensure code passes clang-format and clang-tidy checks (.clang-format / .clang-tidy)

Add a new rendering or animation benchmark

1. Create a new header file following KisXyzBenchmark.h pattern (benchmarks/KisYourBenchmark.h)
2. Implement benchmark methods inheriting from QBenchmarkTestCase or custom harness (benchmarks/KisYourBenchmark.cpp)
3. Register benchmark in the CMake test suite (benchmarks/CMakeLists.txt)
4. Add any necessary test data assets to benchmarks/data/ (benchmarks/data/your_test_file.kpp)
5. Document expected performance ranges and failure criteria in benchmark comments (benchmarks/KisYourBenchmark.cpp (comments))

Update or add a platform-specific configuration

1. Modify CMakeLists.txt to add new feature detection or conditional compilation (CMakeLists.txt)
2. Add new configuration macro or template variable to KoConfig.h.cmake (KoConfig.h.cmake)
3. If platform-specific, update .kde-ci.yml or .gitlab-ci.yml for testing (.kde-ci.yml or .gitlab-ci.yml)
4. Document build requirements and platform notes in HACKING or README (HACKING or README.md)

Integrate a new third-party library or plugin

1. If vendored, add to 3rdparty/ or 3rdparty_vendor/ with patches in separate subdirectory (3rdparty_vendor/[LibName]/CMakeLists.txt)
2. Create CMakeLists.txt in library directory with find_package() or custom build rules (3rdparty_vendor/[LibName]/CMakeLists.txt)
3. Update root CMakeLists.txt to include and link new dependency (CMakeLists.txt)
4. Add license file to LICENSES/ directory if new license type (LICENSES/[NewLicense].txt)
5. Update README.md and documentation to describe integration (README.md or README.packagers.md)

• Qt 5/6 + KDE Frameworks — Cross-platform GUI toolkit and rich set of KDE libraries (KFQF) provide UI, file I/O, color management, and integration with Linux desktop; enables single codebase for Windows, macOS, Linux, and Android.
• CMake build system — Industry-standard meta-build system enabling flexible configuration, platform detection, and conditional compilation for diverse targets and architectures.
• C++11/14/17 — Core language for performance-critical rendering and image processing; KoAlwaysInline.h enforces inlining for hot paths.
• Vendored raqm (text shaping library) — Complex script rendering (RTL text, ligatures) requires low-level shaping; vendoring ensures consistent behavior across platforms.
• G'MIC plugin support — Modular architecture allows advanced image processing plugins; plugins build as external CMake targets linked at build time.
• KDE CI + GitLab CI + LGTM — Multi-stage CI/CD ensures code quality: automated builds (.kde-ci.yml), static analysis (LGTM), and clang-tidy checks (.clang-tidy) run on every commit.

• Single codebase for Windows/macOS/Linux/Android via Qt

  • Why: Qt provides excellent cross-platform abstraction, reducing maintenance burden and enabling rapid feature parity.
  • Consequence: Platform-specific quirks require conditional code; native platform optimizations (e.g., macOS Metal, Windows DirectWrite) cannot always be leveraged; larger binary footprint due to Qt dependency.

• Vendored raqm library in 3rdparty_vendor/

  • Why: Ensures consistent text rendering across platforms; direct control over patches and
  • Consequence: undefined

Build complexity: Krita has deep dependencies on Qt, KDE Frameworks, and graphics libraries; missing optional dependencies fail silently rather than explicitly. Color space conversions: Image processing depends on correctly configured ICC color profiles; test images may not render correctly without proper color space setup. Undo system: Layer modifications interact with command stack in non-obvious ways; changes to kis_painter.h or kis_layer.h can break undo/redo without obvious symptoms. Python bindings: Only built if Python development headers are present; missing sip/PyQt5 headers silently disables scripting support. Platform specifics: Windows builds require NSIS installer framework; macOS requires code signing; Linux AppImage requires fuse2/fuse3. Master branch freeze: Currently in feature freeze (see README) — PRs for new features will be rejected until next release cycle.

• Layer Compositing with Blend Modes — Central to Krita's value proposition; understanding Porter-Duff compositing algebra and blend mode math (Multiply, Screen, Overlay) is essential for modifying paint operations in libs/image/
• ICC Color Profiles and Color Space Conversion — Krita's professional use case demands accurate color management; images may render incorrectly without proper sRGB/CMYK/Lab color space handling in kis_painter.h
• Undo/Redo Command Pattern — Every brush stroke, layer operation, and edit is reversible via command stack; understanding command chaining prevents corruption of undo history in kis_transaction.h
• Tile-Based Buffer Management — Krita uses tile-based image representation for memory efficiency on large canvases (8k+); modifying pixel access patterns requires understanding KisTiledDataManager
• Qt Meta-Object Compiler (MOC) Signal/Slot System — All UI interactions and canvas updates route through Qt's signal/slot mechanism; misunderstanding threading model can cause segfaults or frozen UI in src/ui/
• Plugin Architecture via Dynamic Loading — Brush engines, filters, and I/O handlers are loaded dynamically at runtime; adding new paintops requires understanding plugin interfaces in src/plugins/
• Vector Graphics to Raster Rendering (Antialiasing) — Text, shapes, and vector selections require rasterization; Krita uses raqm for complex text shaping and antialiasing to prevent jagged edges

• GNOME/gimp — Direct competitor and predecessor for non-destructive editing workflows; GIMP uses different layer model but shares similar brush engine architecture patterns
• aseprite/aseprite — Specialized pixel art / animation tool with similar layer compositing and undo/redo systems; relevant for animation feature parity discussions
• KDE/krita-blender-addon — Official Blender plugin for Krita integration; shows how Krita integrates into larger VFX pipelines via Python scripting
• KDE/kdevelop — KDE's IDE used by Krita developers; demonstrates best practices for KDE Frameworks integration and plugin architectures
• KDE/kdelibs — Foundational KDE libraries that Krita depends on; changes here can impact Krita's build and behavior

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 3rdparty_vendor/raqm text shaping integration

The raqm library is vendored in the repository with custom patches (0001-Add-arbitrary-run-break-function.patch and 0002-Fix-Unicode-codepoint-conversion-from-UTF-16.patch) but there appear to be no dedicated test files validating the patched functionality. This is critical because text shaping affects rendering across all platforms. New contributors can add unit tests to verify: (1) arbitrary run break function behavior, (2) UTF-16 to Unicode conversion correctness, and (3) integration with Krita's text tool.

• [ ] Create tests/integration/text/raqm_integration_test.cpp to test the patched raqm functions
• [ ] Add test cases for the arbitrary-run-break-function patch with various text inputs
• [ ] Add test cases for UTF-16 codepoint conversion edge cases (surrogate pairs, BMP vs supplementary planes)
• [ ] Update CMakeLists.txt in the test directory to include raqm integration tests
• [ ] Reference the patches in 3rdparty_vendor/raqm/0001-.patch and 0002-.patch in test documentation

Add static analysis configuration for clang-tidy across 3rdparty code

The repository has .clang-tidy configuration at the root level, but the file structure shows extensive 3rdparty and 3rdparty_vendor directories with patched code (raqm with 2 patches, gmic with 1 patch). The .clang-tidy file likely doesn't exclude these properly or lacks vendor-specific rules. A new contributor should audit and enhance the .clang-tidy configuration to properly handle vendored dependencies while maintaining code quality standards for Krita's core code.

• [ ] Review current .clang-tidy configuration and document its current exclusion patterns
• [ ] Add exclusion patterns for 3rdparty/ and 3rdparty_vendor/ directories
• [ ] Create separate .clang-tidy configurations for core Krita code vs. vendored libraries
• [ ] Test clang-tidy runs on both core code and verify 3rdparty code is properly excluded
• [ ] Document the configuration in HACKING or HACKING.gitlab-ci.md

Implement automated license header validation in .kde-ci.yml and .gitlab-ci.yml

The repository has a comprehensive LICENSES/ directory with 17+ license files and uses SPDX identifiers (evidenced by the file structure), but there's no visible automated validation in the CI pipeline files (.kde-ci.yml and .gitlab-ci.yml) to ensure all source files have proper license headers. This is crucial for GPL/LGPL compliance in a KDE project. A contributor can add a CI job that validates all modified files contain proper SPDX headers.

• [ ] Research KDE's reuse/spdx-check tool or similar compliance checking tool
• [ ] Add a new CI job to .kde-ci.yml that runs license header validation on pull requests
• [ ] Add a complementary job to .gitlab-ci.yml for GitLab CI consistency
• [ ] Create a script (e.g., scripts/check-license-headers.sh) that validates SPDX headers against the LICENSES/ directory
• [ ] Document the license header requirements in CODE_OF_CONDUCT.md or CONTRIBUTING.md with examples from major source files

• Add unit tests for kis_painter.h color blending operations in libs/image/tests/ — the core painting engine has minimal test coverage for blend mode combinations, making regressions hard to catch
• Document the layer stack serialization format in HACKING.md — .kra files use custom XML but no schema or parsing guide exists for contributors working on layer I/O
• Create CMake helper for detecting optional G'MIC installation in 3rdparty_plugins/ext_gmic/ — currently build silently skips G'MIC filters if dependencies are missing, confusing new contributors

The Krita codebase shows a reasonable security posture with evidence of static analysis integration (.clang-tidy, .lgtm.yml) and proper licensing documentation. However, there are concerns regarding third-party dependency management, particularly the use of older vendored libraries (raqm 0.10.1) and custom patch files that may diverge from upstream security updates. The main risks are: (1) outdated dependencies without evidence of regular vulnerability scanning, (2) lack of clear documentation for security patches and modifications, (3) absence of a formal security disclosure policy. The C++ nature of the codebase (graphics application) also means common memory safety issues should be actively monitored

• Medium · Third-party Plugin Dependencies without Version Pinning — 3rdparty_plugins/, 3rdparty_vendor/raqm/src/raqm-0.10.1/. The codebase includes third-party plugins (ext_gmic, raqm) in the 3rdparty_plugins and 3rdparty_vendor directories. These external dependencies may have unpatched vulnerabilities. The raqm library at version 0.10.1 is relatively old (released around 2019) and may contain known security issues. There is no evidence of dependency scanning or version management in the visible configuration files. Fix: Implement automated dependency vulnerability scanning using tools like OWASP Dependency-Check or Snyk in CI/CD pipeline. Establish a process for regularly updating third-party dependencies. Document and justify any intentional version constraints. Review the security advisories for raqm 0.10.1 and consider updating to the latest stable version.
• Medium · Patch Files for Vendored Dependencies — 3rdparty_plugins/ext_gmic/0001-force-turn-off-aligned_alloc.patch, 3rdparty_vendor/raqm/0001-Add-arbitrary-run-break-function.patch, 3rdparty_vendor/raqm/0002-Fix-Unicode-codepoint-conversion-from-UTF-16.patch. The codebase includes patch files for vendored dependencies (0001-force-turn-off-aligned_alloc.patch, 0001-Add-arbitrary-run-break-function.patch, 0002-Fix-Unicode-codepoint-conversion-from-UTF-16.patch). While patches may address bugs, they indicate modifications to upstream code that may diverge from security updates. There is no clear documentation of why these patches are necessary or how they are maintained. Fix: Document the rationale for each patch file. Establish a process to track upstream security patches and ensure patches do not interfere with security updates. Consider contributing patches back to upstream projects. Implement a review process for all custom patches.
• Low · Incomplete Security Configuration Visibility — .clang-tidy, .lgtm.yml. While .clang-tidy and .lgtm.yml are present indicating some static analysis configuration, the specific security rules and checks are not visible in the provided file listing. The configuration may not adequately address security concerns like buffer overflows, integer overflows, or unsafe function usage common in C++ code. Fix: Review and enhance static analysis configurations to include security-focused checks. Enable checks for common C++ vulnerabilities (CWE-119, CWE-190, CWE-426). Document the security rules enforced by the analysis tools. Consider adding runtime sanitizers (ASan, UBSan) to the build pipeline.
• Low · No Visible Security Policy or Disclosure Procedure — Repository root. The repository structure does not show evidence of a SECURITY.md file or security policy documentation. This makes it difficult for researchers to responsibly report security vulnerabilities. The CODE_OF_CONDUCT.md exists but doesn't appear to include security reporting procedures. Fix: Create a SECURITY.md file in the repository root following the standard format. Include clear instructions for responsible vulnerability disclosure, expected response times, and contact information for the security team. Reference GitHub's security advisory features if applicable.
• Low · Benchmark Files in Repository — benchmarks/data/. The benchmarks/ directory contains test data files (.kpp files) that are stored in version control. While not inherently a security issue, storing large binary files can obscure changes and complicate security audits. No evidence of signed commits or required code review is visible. Fix: Consider moving large benchmark data files to external storage or using Git LFS. Ensure all commits are signed and require code review for all changes. Document the provenance of benchmark data files.

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.