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/tw93/Pake 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 today
• 9 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 74% of recent commits

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

What it runs against: a local clone of tw93/Pake — 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 tw93/Pake | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 tw93/Pake. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/tw93/Pake.git
#   cd Pake
#
# 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 tw93/Pake and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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/tw93/Pake"
  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).

Pake is a Rust/Tauri-based CLI tool that packages any webpage into a lightweight native desktop application for macOS, Windows, and Linux with a single command. It solves the bloat problem of Electron by leveraging Tauri's webview-based architecture, producing ~5MB apps instead of 100MB+, while maintaining feature parity with shortcuts, drag-and-drop, immersive windows, and ad removal. Monorepo structure: bin/ contains the TypeScript CLI entry point (cli.ts) with platform-specific builders (BaseBuilder.ts, MacBuilder.ts, WinBuilder.ts, LinuxBuilder.ts), src-tauri/ holds the Rust/Tauri core application, and .github/workflows/ orchestrate releases and testing. The CLI generates Tauri config dynamically (bin/helpers/tauriConfig.ts) and merges user options via bin/helpers/merge.ts.

Web developers and power users who want to distribute web applications as native desktop apps without Electron overhead. CLI users in bin/ call TypeScript builders that invoke Tauri. Contributors work across Rust (src-tauri/), TypeScript CLI (bin/), and GitHub Actions workflows (.github/workflows/).

Production-ready and actively maintained. The project has significant GitHub activity (releases, ~3.11.5 version), comprehensive CI/CD via .github/workflows/, pre-built popular packages (WeRead, Twitter, etc. in releases), and established contribution guidelines (CODE_OF_CONDUCT.md, CONTRIBUTING.md). Commit activity and release cadence indicate healthy ongoing development.

Low risk for core stability, moderate risk for edge cases. Single maintainer (Tw93) creates dependency risk, but the Tauri ecosystem is mature and widely used. The build system depends on Rust toolchain, Node ≥18, and pnpm@10.26.2—version pinning is strict. GitHub Actions workflows (.github/workflows/pake-cli.yaml, release.yml) handle most CI, but cross-platform builds (MacBuilder.ts, WinBuilder.ts, LinuxBuilder.ts) can be fragile with OS-specific quirks.

Active development on CLI robustness and platform support. CI workflows (quality-and-test.yml, pake-cli.yaml, single-app.yaml) validate every commit. The .agents/skills/ directory suggests AI-assisted code review and release processes are being tested. Recent focus appears to be on improving builder reliability across Windows/Mac/Linux and contributor tooling.

git clone https://github.com/tw93/Pake.git
cd Pake
pnpm install
pnpm run cli:build
pnpm run test

For development, use pnpm run dev to start the Tauri dev server or pnpm run cli to watch TypeScript CLI changes with Rollup.

Daily commands:

pnpm run dev              # Start Tauri dev server (hot-reload)
pnpm run cli:build       # Build CLI to dist/cli.js (production mode)
pnpm run build           # Full Tauri release build
pnpm run build:mac       # macOS universal binary
pnpm run build:debug     # Debug build with symbols

After pnpm run cli:build, test with: node dist/cli.js --help

• bin/cli.ts: Main CLI entry point using commander; defines all user-facing commands and argument parsing for the pake CLI tool
• bin/builders/BaseBuilder.ts: Abstract builder class that orchestrates the full app packaging pipeline: icon generation, config merging, Tauri invocation
• bin/builders/MacBuilder.ts: macOS-specific build logic; handles DMG signing and universal binary generation for Apple Silicon + Intel
• bin/builders/WinBuilder.ts: Windows build logic; manages MSI installer generation and x64/ARM64 targeting
• bin/helpers/tauriConfig.ts: Dynamically generates tauri.conf.json from user options and CLI args; critical for app customization (window size, icon, permissions)
• .github/workflows/pake-cli.yaml: Main CI/CD pipeline for npm package publishing; runs linting, building, and automated release to npm registry
• package.json: Defines Node.js minimum version (18.0.0), pnpm lock version, and CLI entry point; enforces strict build environment
• src-tauri/src: Rust implementation of Tauri app core; handles native window management, IPC, and system-level features (not fully detailed but critical)

Adding a CLI feature: edit bin/cli.ts (command parsing) → bin/options/index.ts (option definitions) → bin/helpers/tauriConfig.ts (config generation). Platform-specific build logic: bin/builders/{Mac,Win,Linux}Builder.ts extend BaseBuilder.ts. Tests: tests/index.js (integration tests, run via pnpm run test). GitHub Actions: .github/workflows/pake-cli.yaml handles npm publishing, release.yml creates tagged releases. Rust core changes: src-tauri/src/ (note: not fully listed, but referenced in build scripts).

1. Node version constraint: Requires Node ≥18.0.0 and pnpm@10.26.2 exactly (see .pnpmrc, package.json engines). Mixing npm or old Node will fail silently. 2. Rust toolchain: Build system assumes Rust is installed and in PATH; no auto-detection in build scripts. Cross-compilation requires cargo-cross (referenced in Dockerfile). 3. Platform-specific secrets: GitHub Actions workflows (.github/workflows/release.yml) require signing certificates for macOS (identity) and Windows (signing tools)—local builds will skip signing unless env vars set. 4. Icon generation: icon-gen + sharp dependencies are heavy; first build downloads native bindings and can be very slow on new machines. 5. Tauri version coupling: @tauri-apps/cli and @tauri-apps/api must match minor versions or IPC breaks; see package.json ~2.10.1 pinning. 6. Test env var: PAKE_CREATE_APP=1 required to run tests (bin/cli.ts checks this); without it, test creates real apps.

• Tauri IPC (Inter-Process Communication) — Pake apps need to bridge JavaScript frontend and Rust backend; understanding Tauri's invoke() and listen() patterns is essential for extending core features like drag-drop or window control
• WebView-based packaging — Unlike Electron which bundles Chromium, Tauri uses the OS native webview (WKWebKit on macOS, WebView2 on Windows); this is why Pake apps are 20x smaller, but has platform-specific quirks
• Cross-compilation and platform-specific builds — Pake supports Windows/macOS/Linux from one codebase; BaseBuilder and platform-specific subclasses manage OS-specific toolchains and signing, which is complex and error-prone
• Icon and image generation pipeline — Desktop apps require icons in many formats (.ico, .icns, .png at various resolutions); Pake's icon-gen + sharp integration handles this, but the dependency chain is fragile and platform-dependent
• Configuration-driven app generation — Pake dynamically generates tauri.conf.json from CLI args; understanding how tauriConfig.ts merges defaults, user options, and platform specifics is key to adding new customization features
• GitHub Actions for multi-platform CI/CD — Building signed macOS/Windows/Linux artifacts requires orchestrated CI; Pake's workflow files (.github/workflows/) show patterns for cross-platform matrix builds and secret management
• Rollup module bundling with TypeScript — The CLI is built as an ES module via Rollup (not webpack); understanding the rollup.config.js and bin/ module resolution is necessary to debug CLI packaging or tree-shaking issues

• tauri-apps/tauri — Core dependency and ecosystem foundation; Pake is a specialized wrapper around Tauri for web-to-desktop packaging
• electron/electron — Primary alternative solving the same problem (web → desktop app); Pake exists specifically because Electron is large and slow
• neutralinojs/neutralino — Lighter alternative to Electron using native webview; competes with Tauri/Pake for minimal footprint desktop apps
• napi-rs/napi-rs — Ecosystem companion for Rust ↔ Node.js interop; used by Tauri and relevant to extending Pake with native modules
• vercel/pkg — Adjacent tool for bundling Node.js apps into standalone binaries; complements Pake for CLI tool distribution

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 bin/utils/ validation and transformation functions

The repo lacks unit tests for critical utility functions in bin/utils/ (validate.ts, url.ts, name.ts, icon-source.ts, platform.ts). These utilities are directly used by the CLI and builder providers. Testing them would catch edge cases early, especially for URL parsing, app name normalization, and icon source detection across platforms.

• [ ] Create tests/unit/utils/ directory structure
• [ ] Add test file for bin/utils/validate.ts covering invalid URLs, names, and edge cases
• [ ] Add test file for bin/utils/url.ts covering domain extraction and URL normalization
• [ ] Add test file for bin/utils/name.ts covering special characters and platform-specific naming
• [ ] Add test file for bin/utils/icon-source.ts covering local/remote icon detection
• [ ] Update package.json scripts to include 'test:unit' using Jest or Vitest
• [ ] Add test workflow to .github/workflows/ if missing

Add platform-specific integration tests for builders (MacBuilder, WinBuilder, LinuxBuilder)

The builder classes (bin/builders/*.ts) contain platform-specific logic but there are no visible integration tests. Adding tests that verify each builder correctly generates Tauri configs, handles platform-specific options, and validates output would prevent regressions when modifying build logic. Current test file (tests/index.js) appears to be functional but lacks builder-specific assertions.

• [ ] Create tests/builders/ directory with test files for each builder class
• [ ] Add tests/builders/MacBuilder.test.ts testing universal-apple-darwin targets and macOS-specific config
• [ ] Add tests/builders/WinBuilder.test.ts testing Windows-specific icon conversion and MSIX config
• [ ] Add tests/builders/LinuxBuilder.test.ts testing AppImage and deb package generation
• [ ] Add tests/builders/BuilderProvider.test.ts testing platform detection and correct builder selection
• [ ] Add test assertions verifying bin/options/index.ts icon processing is correct per platform
• [ ] Update existing tests/index.js to import and use new builder tests

Add GitHub Actions workflow for dependency security audits and Cargo/npm outdated checks

While the repo has quality-and-test.yml and release.yml workflows, there's no dedicated security or dependency freshness check. Given Pake wraps Tauri (Rust) and has significant npm dependencies, a scheduled workflow checking cargo audit, npm audit, and outdated packages would catch vulnerabilities early and encourage timely updates.

• [ ] Create .github/workflows/security-audit.yml workflow file
• [ ] Add job to run 'cargo audit' in src-tauri/ directory and fail if vulnerabilities found
• [ ] Add job to run 'npm audit' for JavaScript dependencies
• [ ] Add job to run 'npm outdated' and 'cargo outdated' to report stale dependencies (non-blocking)
• [ ] Schedule workflow to run weekly or on dependency file changes (package.json, Cargo.lock)
• [ ] Add step to post results as workflow summary for visibility
• [ ] Reference this workflow in CONTRIBUTING.md to inform contributors about dependency hygiene

• Add unit tests for bin/helpers/merge.ts—this file merges user config with Tauri defaults but has no visible test coverage. A first-time contributor could write Jest tests to validate deep merge behavior for nested window configs and icon paths.
• Document the icon generation pipeline in docs/—the bin/options/icon.ts and icon-gen dependency are non-obvious. A contributor could add a guide explaining how to provide custom icons, what formats work, and why sharp is required.
• Implement missing platform validation in bin/builders/BuilderProvider.ts—currently no explicit check that the current OS matches the requested build target. Add a pre-flight check to warn/error if trying to build a Windows .msi on macOS without proper cross-compilation setup.

• High · Use of Latest Rust in Docker Without Version Pinning — Dockerfile, line 3. The Dockerfile uses 'rust:latest' as the base image and runs 'rustup update stable', which pulls the latest Rust version without pinning. This introduces non-deterministic builds and potential compatibility issues. An attacker could inject malicious code through a compromised Rust toolchain. Fix: Pin the Rust version to a specific release (e.g., 'rust:1.75.0'). Remove 'rustup update stable' or replace with a pinned version. Use digest-based image references for immutability.
• High · Potential Command Injection via Shell Execution — bin/utils/shell.ts, bin/cli.ts, bin/builders/BaseBuilder.ts. The codebase contains multiple shell execution utilities (bin/utils/shell.ts, execa dependency) used in build processes. The CLI accepts user input for URLs and app names that may be passed to shell commands without proper sanitization, risking command injection attacks. Fix: Validate and sanitize all user inputs before passing to shell commands. Use parameterized execution (array-based arguments with execa) instead of string interpolation. Implement strict input validation for URLs, app names, and paths.
• High · Insufficient URL Validation for Webpage Input — bin/utils/url.ts, bin/utils/validate.ts. The application converts arbitrary webpages into desktop apps. While URL validation exists (bin/utils/validate.ts, bin/utils/url.ts), there is no documented protection against:1) Loading malicious/phishing websites, 2) Man-in-the-middle attacks on non-HTTPS URLs, 3) JavaScript execution within wrapped apps without sandboxing Fix: Enforce HTTPS-only URLs by default. Implement certificate pinning for known domains. Document security best practices. Consider adding CSP headers and sandboxing JavaScript execution within the Tauri app. Add warnings for self-signed certificates.
• Medium · Dependency Vulnerability: Sharp and Image Processing — package.json (dependencies: sharp, icon-gen). The project uses 'sharp' (v0.34.5) and 'icon-gen' for image processing. These libraries parse untrusted binary data (user-provided icons). A malicious icon file could trigger buffer overflow or DoS attacks in native image processing code. Fix: Keep sharp and icon-gen updated to latest versions. Validate image file types and dimensions before processing. Implement file size limits. Run image processing in isolated worker processes or containers.
• Medium · Missing Environment Variable Validation — package.json (scripts), bin/builders/BaseBuilder.ts. The project uses environment variables (NODE_ENV, PAKE_CREATE_APP in scripts) but lacks documented validation. Unvalidated environment variables during build could affect security settings. Fix: Implement explicit environment variable validation with allowed values. Document all security-critical environment variables. Use a schema validation library for environment configuration.
• Medium · Incomplete Docker Layer Caching Configuration — Dockerfile, lines 14-18 and 22. The Dockerfile uses '--mount=type=cache' for apt-get but doesn't follow security best practices for caching. The PKG_CONFIG_PATH environment variable is partially defined but incomplete. Fix: Complete the PKG_CONFIG_PATH configuration. Consider using multi-stage builds more carefully to minimize final image size and attack surface. Add HEALTHCHECK and security scanning in CI/CD.
• Medium · Potential File System Access Vulnerabilities — bin/utils/dir.ts, bin/options/icon.ts. The application uses fs-extra for file operations with user-controlled paths (app creation, icon handling). Inadequate path validation could lead to directory traversal attacks. Fix: Validate all file paths to prevent directory traversal (use path.resolve and path.relative checks). Implement strict whitelisting for allowed directories. Use secure temp directory functions from tmp-promise.
• Low · Missing Security Headers Documentation — src-tauri configuration (not fully visible). No documented security headers (CSP, X-Frame-Options, etc.) are configured in generated desktop applications. While Tauri provides some isolation, explicit security configuration is absent. Fix: Document security headers

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.