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/weolar/miniblink49 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 all four use cases

• Last commit 3w ago
• 5 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Single-maintainer risk — top contributor 87% of recent commits
• ⚠ 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 weolar/miniblink49 repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/weolar/miniblink49.

What it runs against: a local clone of weolar/miniblink49 — 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 weolar/miniblink49 | 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 master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 53 days ago | Catches sudden abandonment since generation |

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

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

# 4. Critical files exist
test -f "build/build_config.h" \\
  && ok "build/build_config.h" \\
  || miss "missing critical file: build/build_config.h"
test -f "base/basictypes.h" \\
  && ok "base/basictypes.h" \\
  || miss "missing critical file: base/basictypes.h"
test -f "base/strings/string_util.h" \\
  && ok "base/strings/string_util.h" \\
  || miss "missing critical file: base/strings/string_util.h"
test -f "base/values.h" \\
  && ok "base/values.h" \\
  || miss "missing critical file: base/values.h"
test -f "base/thread.h" \\
  && ok "base/thread.h" \\
  || miss "missing critical file: base/thread.h"

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

miniblink49 is a lightweight, single-file browser kernel forked from Chromium/Blink that embeds HTML/CSS/JavaScript rendering directly into C++ applications without external dependencies. It provides a minimal (megabyte-scale) alternative to CEF or wke, exporting a pure C API for creating browser windows, loading URLs, intercepting network traffic, and executing JavaScript—with optional Node.js embedding for Electron-like apps. Monolithic C++/C codebase: /base contains platform abstraction (Windows file I/O, JSON parsing, logging); /3rdlib holds binary ffmpeg and curl dependencies; core browser logic spreads across unnamed subdirs. A single DLL/EXE deliverable is built and distributed via GitHub Releases rather than source compilation.

C++ / C# / Delphi desktop application developers who need to render HTML UIs without bundling a full Chromium distribution; particularly those building Windows XP–compatible tools, cross-domain capable applications, or headless web scrapers that demand small binary footprint.

Actively maintained as a v49 (older) kernel with ongoing security updates and features (v108 and v132 versions exist upstream). The project has a live Chinese developer community (forums, WeChat/Telegram groups, Q-groups) and monthly releases at /releases. However, no visible CI/CD pipeline, sparse automated tests, and single-maintainer (weolar) risk mean production use requires careful vetting.

Single maintainer (weolar@miniblink.net), no GitHub Actions CI visible, and the README explicitly warns users not to file compile-error issues—suggesting unstable build chains. The codebase embeds old Chromium (v49, released 2015) which has known security issues; newer versions (v108/v132) are in separate repos. Large C++ surface area (325 MB) with weak test coverage visible in file structure.

The v49 kernel (this repo) is in maintenance mode; active development shifted to v108 (open-sourced in OpenEuler) and unreleased v132. Updates appear to be security patches and bug fixes to v49; the README emphasizes downloading pre-built binaries from Releases rather than building from source.

Clone the repository: git clone https://github.com/weolar/miniblink49.git. However, the README strongly discourages local compilation and recommends downloading pre-built SDK files from https://github.com/weolar/miniblink49/releases (which include demo_src with working examples). See also https://github.com/weolar/mb-demo for standalone demo code.

Daily commands: No traditional 'dev server.' Instead, instantiate a browser window via C API: wkeCreateWebWindow() → wkeLoadURLW() → message loop. See /demo_src (included in Releases) for full Windows GUI examples. Headless usage: create view without window, call JavaScript, extract results.

• build/build_config.h — Core build configuration header that defines platform macros and compilation flags affecting entire codebase
• base/basictypes.h — Foundational type definitions and platform abstractions used throughout the browser kernel
• base/strings/string_util.h — String manipulation utilities that are heavily used across rendering and DOM parsing
• base/values.h — Core data structure for JSON/configuration values used in IPC and settings management
• base/thread.h — Threading abstraction layer critical for browser's multi-threaded architecture
• base/memory/scoped_ptr.h — Smart pointer implementation preventing memory leaks in C++ codebase
• base/win/windows_version.h — Windows version detection essential for Windows XP+ compatibility guarantees

Add a new platform-specific file operation

1. Define cross-platform interface in base/files/file.h with File class method (base/files/file.h)
2. Implement abstract method in platform-specific file (e.g., file_win.cc for Windows) (base/files/file_win.cc)
3. Add corresponding path utility in base/files/file_path.h if path handling needed (base/files/file_path.h)
4. Wrap with RAII class in base/files/scoped_file.h for automatic cleanup (base/files/scoped_file.h)

Add new string utilities or encoding support

1. Add utility function declaration in base/strings/string_util.h (base/strings/string_util.h)
2. Implement function in base/strings/string_util.cc (base/strings/string_util.cc)
3. For UTF conversions, extend base/strings/utf_offset_string_conversions.h (base/strings/utf_offset_string_conversions.h)

Extend browser environment simulation and version spoofing

1. Check Windows version detection in base/win/windows_version.h for OS detection (base/win/windows_version.h)
2. Modify browser user-agent string or feature flags in build configuration or command-line parsing (base/command_line.h)
3. Store browser environment settings as Values objects in base/values.h (base/values.h)
4. Serialize/deserialize via JSON in base/json/json_writer.h and json_reader.h (base/json/json_reader.h)

Add threaded background task or worker pool

1. Create new thread using base/thread.h Thread class abstraction (base/thread.h)
2. Implement thread logic; consult base/thread.cc for message loop patterns (base/thread.cc)
3. Use base/lock.h for synchronization between threads (base/lock.h)
4. Serialize task parameters using base/pickle.h for IPC if needed (base/pickle.h)

• Chromium/Blink fork (version 49) — Provides robust, standards-compliant HTML5 rendering with proven stability; version 49 offers minimal binary size while maintaining feature completeness
• C/C++ with optional Nodejs/Electron integration — Enables lightweight embedding in native applications while allowing modern JavaScript/web-based UI development without overhead of full Electron
• Windows-first platform layer (base/win) — Targets Windows XP+ compatibility for broad OS coverage; NPAPI support extends plugin ecosystem compatibility
• RAII memory management (scoped_ptr, scoped_handle) — Prevents memory leaks in long-running embedded browser instances; deterministic cleanup on scope exit
• Multi-threaded message loop (base/thread.h) — Enables responsive UI while performing I/O and rendering; thread pool isolates heavy operations from main thread

• Single-file distribution model

  • Why: Simplifies integration into host applications; no complex installer or DLL dependency chains
  • Consequence: Larger single binary; all code statically linked; harder to patch individual components

• Chromium 49 (older version)

  • Why: Smaller binary footprint and simpler codebase vs. cutting-edge features; stable, proven renderer
  • Consequence: Missing modern CSS features, some ES6+ JavaScript features; security updates from older codebase

• Windows-primary platform layer

  • Why: Maximizes user base and desktop integration; direct Windows APIs for performance
  • Consequence: Limited/no native support for macOS, Linux; platform-specific code maintenance burden

• C interface export alongside C++/C# support

  • Why: Maximum interoperability with diverse languages (Delphi, C#, C++); simplest calling convention
  • Consequence: Higher marshaling overhead; fewer language features in C API; less type safety

• Cross-platform (Linux, macOS) — Windows XP+ only
• Real-time collaborative editing or server-side rendering
• JavaScript sandbox/security isolation beyond Blink's built-in model
• Native support for WebAssembly modules
• Built-in certificate pinning, HSTS, or advanced security policies
• Streaming or progressive rendering for very large documents

Do not attempt to compile from source without explicit guidance from weolar—the README warns that daily updates may break builds. Windows-only: no Linux/Mac support in v49. The 'single file' claim refers to the final DLL/EXE, not the source tree (325 MB of C++). NPAPI plugin support (Windows XP era) adds dead code paths. Pre-built Releases are the only stable distribution; source tags may not align with release versions.

• Blink Rendering Engine — miniblink is a minimal fork of Blink (Chromium's layout/rendering engine); understanding Blink's document tree, style resolution, and compositing is essential to debug rendering bugs or extend CSS support
• V8 JavaScript Engine — miniblink embeds V8 for script execution; knowing V8 context isolation, handle scopes, and the C++ binding API (v8.h) is critical for custom JS-to-C++ interop
• Network Interception & MITM — A core miniblink feature is transparent resource replacement (replace any URL with local file); this requires hooking HTTP/HTTPS at the protocol layer before DNS, implementing certificate bypass for HTTPS spoofing
• Headless Browser Architecture — miniblink supports headless mode (no GUI window, scriptable rendering for crawlers); this means decoupling the render loop from OS windowing (HWND) and enabling background JavaScript execution
• Cross-Domain Resource Sharing (CORS) Bypass — miniblink can disable CORS enforcement at compile/runtime, violating same-origin policy for testing/automation; requires understanding browser security model and where CORS checks live in Blink
• Node.js Embedding — Optional Node.js runtime bundled into miniblink enables Electron-style apps; requires knowledge of libuv event loop integration and Node.js native module system
• Windows NPAPI Plugin Support — miniblink retains NPAPI (Netscape Plugin API) for legacy Flash/Java applet compatibility; this is a Windows-only, pre-2015 standard now obsolete, but required for XP/Vista support

• weolar/miniblink108 — Newer v108 kernel with security patches, being productionized in OpenEuler; recommended over v49 for new projects
• weolar/mb-demo — Standalone demo repository with runnable C++ examples showing how to use miniblink API (forms, navigation, JS binding)
• chromium/chromium — Upstream Blink/V8 engine that miniblink v49 forks from (2015 baseline); necessary to understand rendering architecture and CVE history
• Microsoft/CEF — Chromium Embedded Framework—direct competitor offering similar browser-in-a-box capability with larger footprint but better cross-platform support
• electron/electron — Full-stack Electron runtime; miniblink's mini-electron project aims to replicate Electron UX at 6 MB (vs ~150 MB) using miniblink instead of full Chromium

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 base/strings string utility functions

The base/strings directory contains critical string manipulation utilities (string_util.cc, string_util.h, utf_offset_string_conversions.cc) that lack visible test coverage. These are core functions likely used throughout the browser kernel for URL parsing, encoding/decoding, and text processing. Adding unit tests would catch regressions early and improve confidence in cross-platform string handling.

• [ ] Create base/strings/string_util_test.cc with tests for UTF-8/UTF-16 conversions in string_util.h
• [ ] Create base/strings/utf_offset_string_conversions_test.cc covering edge cases for offset calculations
• [ ] Test platform-specific behavior (Windows wchar_t handling) in test cases
• [ ] Integrate tests into the build system for CI validation

Add unit tests for base/files file handling across Windows platforms

The base/files module (file.cc, file_win.cc, file_path.cc) handles platform-specific file I/O which is error-prone. With no visible tests, regressions in file operations could silently break HTML/resource loading. This is especially critical given the Windows-focused implementation and the presence of scoped file handle management classes.

• [ ] Create base/files/file_test.cc testing file creation, reading, writing, and deletion scenarios
• [ ] Create base/files/file_path_test.cc for path manipulation and normalization (especially Windows path edge cases)
• [ ] Add tests for file permission and platform file descriptor management in scoped_file.h and scoped_platform_file_closer.h
• [ ] Verify tests pass on both 32-bit and 64-bit Windows builds

Add JSON parsing and serialization unit tests for base/json module

The base/json directory (json_parser.cc, json_reader.cc, json_writer.cc) handles critical data serialization used throughout the browser for configuration and IPC. With no visible tests, malformed JSON handling and edge cases (null values, deeply nested objects, Unicode escapes) could cause silent failures or crashes. These tests would protect against regressions in a frequently-used module.

• [ ] Create base/json/json_reader_test.cc testing valid JSON parsing, malformed input handling, and Unicode/escape sequence edge cases
• [ ] Create base/json/json_writer_test.cc for serialization of various data types and ensuring roundtrip consistency
• [ ] Add tests for json_util.cc covering merge, comparison, and transformation functions
• [ ] Include performance benchmarks for large JSON documents given the kernel's performance sensitivity

• Write integration tests for /base/json/json_parser.cc against malformed and edge-case JSON (circular refs, deep nesting) currently untested in visible test dirs.
• Document the network intercept API with commented examples in demo_src—currently no how-to guide for resource replacement, only feature claim in README.
• Add missing error codes and logging in base/platform_file_win.cc when file access fails (currently relies on platform errors)—improve debuggability for users embedding the DLL.

• High · Chromium-based Engine with Inherited Security Risks — Core architecture (entire codebase). miniblink49 is based on Chromium 49, which is extremely outdated (released 2015). This version contains numerous known CVEs and security vulnerabilities that have been patched in modern Chromium versions. The codebase includes old rendering engine code that is no longer maintained. Fix: Migrate to miniblink108 or miniblink132 as mentioned in the README. If continuation with v49 is required, implement strict sandboxing and content isolation mechanisms.
• High · Outdated Third-Party Libraries — 3rdlib/ directory (3rdlib/ffmpeg.dll.lib, 3rdlib/ffmpeg_x64.dll.lib, 3rdlib/libcurl_a.lib). The 3rdlib directory contains compiled libraries (ffmpeg, libcurl) without visible version information or evidence of regular updates. FFmpeg and libcurl are common attack vectors when outdated. No dependency lock files (package.json, requirements.txt, etc.) are visible to track versions. Fix: Maintain a manifest of all third-party library versions with their compilation dates. Regularly audit and update ffmpeg and libcurl to latest versions. Implement automated vulnerability scanning for compiled dependencies.
• Medium · Windows-Specific Implementation with Potential Platform-Specific Vulnerabilities — base/win/, base/process/, base/files/file_win.cc, base/debug/gdi_debug_util_win.cc. The codebase heavily relies on Windows-specific APIs and implementations (base/win/, base/files/file_win.cc, base/process/, etc.). This indicates Windows-only compatibility and may contain platform-specific security issues such as improper handle management, privilege escalation vectors, or Windows-specific buffer overflow patterns. Fix: Conduct security audit focused on Windows API usage, handle management, and privilege escalation vectors. Implement proper HANDLE validation and cleanup. Use AddressSanitizer and other memory analysis tools specific to Windows.
• Medium · Process Injection Capabilities Without Visible Access Controls — base/process/InjectTool.h, base/process/CallAddrsRecord.h. File base/process/InjectTool.h suggests process injection functionality. Process injection capabilities are powerful and dangerous if not properly restricted. No visible documentation or access control mechanisms are evident. Fix: Document the process injection API thoroughly. Implement strict access controls and permission checks before allowing process injection. Add security warnings in documentation about the risks of this functionality.
• Medium · Embedded Node.js Integration — Core architecture (mentioned in README). README mentions 'inner Node.js', suggesting Node.js is embedded within the browser kernel. This introduces significant attack surface as Node.js has full system access and could be exploited to escape the browser sandbox. Fix: If Node.js embedding is necessary, implement strict sandboxing and capability restrictions. Disable filesystem access unless explicitly required. Implement inter-process communication (IPC) security boundaries. Consider using a restricted Node.js environment with minimal permissions.
• Medium · Lack of Security Documentation — Repository root. No visible SECURITY.md, security policy documentation, or security guidelines. No evidence of security disclosure process for vulnerability reporting. README lacks security recommendations for developers integrating miniblink. Fix: Create SECURITY.md with vulnerability disclosure process, security guidelines for integration, and known security limitations. Add security warnings to main README about using outdated Chromium 49.
• Low · No Visible Build Security Configuration — Build system (not visible in provided structure). No evidence of security-focused build configurations (ASLR, DEP/NX, CFG, ASAN, etc.). No Makefile or build configuration files visible that would indicate secure compilation flags. Fix: Enable security compilation flags: /DYNAMICBASE, /NXCOMPAT for DEP, /GUARD:cf for Control Flow Guard, and runtime checks. Document build security settings.
• Low · Memory Management in C++ without Modern RAII Patterns Visible — base. While scoped_ptr.h is present, the codebase origin from Chromium 49 era suggests potential use of manual memory management patterns that could lead to use-after-free or memory leak vulnerabilities. Fix: undefined

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.