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/lukakerr/Pine 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 — Stale — last commit 3y ago

• 6 active contributors
• Other licensed
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 95% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory 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 lukakerr/Pine repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/lukakerr/Pine.

What it runs against: a local clone of lukakerr/Pine — 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 lukakerr/Pine | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 1267 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "lukakerr/Pine(\\.git)?\\b" \\
  && ok "origin remote is lukakerr/Pine" \\
  || miss "origin remote is not lukakerr/Pine (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master 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 1267 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1237d)"
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/lukakerr/Pine"
  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).

Pine is a lightweight, native macOS markdown editor built in Swift that supports GitHub Flavored Markdown, LaTeX math rendering, and custom CSS theming. It functions as a document-based application (following Apple's standards) with split-view editing, live preview, and full-screen support—designed for users who want a minimal, native alternative to Electron-based editors. Single-app Xcode workspace structure: Pine/ directory contains AppDelegate.swift (entry point), Assets.xcassets (UI resources), and presumably feature modules for editing, preview, theming, and markdown processing. Docs/Development/ contains internal reference material (MARKDOWN_REFERENCE.md, RELEASE.md). No visible separation into frameworks or packages—monolithic macOS app architecture.

macOS users and markdown writers who prefer native applications over web-based editors; developers and technical writers who need LaTeX math support and GitHub-flavored markdown without heavyweight dependencies. Contributors are primarily individual developers interested in Swift UI development and markdown tooling.

Early-stage experimental project: the README explicitly states 'It's currently a work in progress' and the codebase is relatively small (~147KB Swift). No visible CI/CD pipeline in the file structure, limited test infrastructure visible, and the project appears actively maintained (evidenced by CHANGELOG.md and CONTRIBUTING.md) but not battle-tested in production. Verdict: actively developed but pre-1.0 / use with caution in production.

Single-maintainer risk (lukakerr); no visible package.json dependencies listed, reducing external risk but suggesting core features are hand-built. The 'work in progress' status and absence of visible CI suggest incomplete test coverage. Breaking changes are likely as the project stabilizes toward v1.0. Consider this experimental for mission-critical workflows.

The repo is actively developed with a CHANGELOG.md and explicit focus on features like themability, math support, and syntax highlighting. The TODO section in README identifies concrete next work: CSS preview editing and sidebar improvements (folder watching, context menu actions). No visible PR data, but the presence of CONTRIBUTING.md signals openness to contributions.

git clone git@github.com:lukakerr/pine.git
cd pine
make

Or open Pine.xcworkspace in Xcode and build directly. Dependencies appear minimal (Swift stdlib focus).

Daily commands: Via Make: make builds the app; make test runs tests. Via Xcode: Open Pine.xcworkspace, select Pine scheme, press ⌘B to build and ⌘R to run. App launches as native macOS window with file browser and editor split-view.

• Pine/AppDelegate.swift: Application entry point and lifecycle management; controls main window, document handling, and menu setup.
• Docs/Development/MARKDOWN_REFERENCE.md: Internal reference for supported markdown syntax and extensions—essential for understanding scope of parser implementation.
• Pine.xcodeproj/xcshareddata/xcschemes/Pine.xcscheme: Build configuration; defines target, scheme, and test setup for reproducible builds.
• CONTRIBUTING.md: Contribution guidelines and code standards (likely references .swiftlint.yml for style enforcement).
• .swiftlint.yml: SwiftLint configuration enforces code style consistency across the codebase.
• Makefile: Build automation; defines make targets for clean builds, tests, and distribution.

For markdown parsing: examine the (likely) Pine/Core or Pine/Parser modules implied by feature set. For UI/editor: Pine/AppDelegate.swift is entry point; Assets.xcassets controls all imagery. For theming: look for CSS loading logic (mentioned in features). For markdown shortcuts: search for Touch Bar and keyboard event handlers. For preview rendering: find WebKit or NSTextView integration. Start by grepping for 'markdown' or 'preview' in *.swift files.

Swift version pinning: .swift-version file indicates specific Swift compiler requirement—ensure Xcode version matches. macOS version target: not explicitly shown in file list; check Pine.xcodeproj/project.pbxproj for MACOSX_DEPLOYMENT_TARGET (likely 10.13+). Minimal dependency transparency: no Cartfile or Package.swift visible, so dependency graph is opaque—check actual Xcode project for linked frameworks. CSS theming system: custom .css loading mechanism is mentioned but implementation files not listed; may require reverse-engineering theme folder structure.

• Document-Based Application (macOS) — Pine explicitly follows Apple's document-based app pattern (mentioned in README), which handles file I/O, undo/redo, and version control automatically—understanding NSDocument is essential for modifying save/load behavior.
• GitHub Flavored Markdown (GFM) Extensions — Pine explicitly supports GFM features (tables, strikethrough, task lists); these are non-standard markdown extensions that require custom parsing logic beyond basic CommonMark.
• LaTeX Math Rendering — Pine advertises 'Math support (LaTeX subset)' as a key feature; this requires either embedding a LaTeX renderer (like MathJax in WebKit) or integrating a native library—non-trivial to implement correctly.
• Touch Bar Integration — README lists 'Touch Bar shortcuts' as a feature; Pine must detect Touch Bar hardware and register NSTouchBar with custom actions for markdown formatting—macOS-specific UI pattern.
• WebKit Preview Rendering — Split-view editing implies markdown source on left, HTML preview on right; likely uses WKWebView to render markdown→HTML, requiring careful HTML sanitization to prevent XSS if user-controlled CSS is loaded.
• CSS Theme Customization & Injection — Pine allows users to create custom .css themes; the app must safely load and inject external CSS into WebKit preview without breaking layout or introducing security vulnerabilities.
• Syntax Highlighting (Source & Preview) — README mentions 'Syntax highlighting for source and preview'; the editor must color-code markdown syntax and code blocks—requires either a custom highlighter or integration of a library like Highlight.js or Prism.

• MacDownApp/macdown — Mature macOS markdown editor written in Objective-C/Swift; direct competitor with similar feature set (split view, preview, syntax highlighting).
• fphilipe/zed — Another native Swift macOS text editor; shares architectural approach and AppKit/document-based app patterns.
• iarna/marked — JavaScript markdown parser (GFM-compliant); Pine likely needs equivalent markdown parsing—reference for expected GFM feature coverage.
• apple/swift — Swift language repo; Pine's toolchain dependency—critical for tracking Swift version requirements and new language features.

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 GitHub Actions workflow for Swift linting and building

The repo has a .swiftlint.yml configuration file but no CI/CD pipeline. A GitHub Actions workflow would automatically validate Swift code style on PRs, ensure the Xcode project builds successfully, and run linting checks before merge. This prevents style inconsistencies and build failures from reaching main.

• [ ] Create .github/workflows/swift-lint-build.yml that runs swiftlint on Pine/ directory
• [ ] Add build step using xcodebuild to compile the Pine.xcodeproj against the .swift-version specified
• [ ] Trigger workflow on pull_request and push to main branch
• [ ] Reference existing .swiftlint.yml configuration in the workflow

Create comprehensive markdown editor feature tests

The repo has a Docs/Development/MARKDOWN_REFERENCE.md documenting supported markdown syntax, but no corresponding test suite. Adding XCTest cases that verify markdown rendering, text transformations (bold, italic), and editor functionality would catch regressions in the core editing experience and validate the documented features actually work.

• [ ] Create Pine/Tests/EditorTests.swift with XCTest cases
• [ ] Add tests for each markdown syntax listed in Docs/Development/MARKDOWN_REFERENCE.md (headers, bold, italic, code blocks, etc.)
• [ ] Test text selection and formatting operations in AppDelegate.swift context
• [ ] Verify markdown parsing against the documented reference behaviors

Document plugin architecture and add example plugin

The repo has Docs/Wiki/Plugins.md describing plugins, but no example plugin or plugin testing infrastructure. Creating a sample plugin (e.g., a simple code snippet insertion or word counter plugin) with clear documentation would help contributors understand how to extend Pine and improve the plugin ecosystem mentioned in the wiki.

• [ ] Create a sample plugin example in Docs/Development/EXAMPLE_PLUGIN.md with Swift code
• [ ] Document the plugin API interface requirements (entry points, required methods)
• [ ] Add a Plugins/ExamplePlugin/ directory with a minimal working plugin implementation
• [ ] Update CONTRIBUTING.md with plugin development instructions and testing guidelines

• Add unit tests for markdown syntax validation: the file structure lacks a visible Tests/ directory despite a make test command. Create XCTest cases for MARKDOWN_REFERENCE.md features (lists, tables, LaTeX blocks) in Pine/Tests/MarkdownParserTests.swift.
• Improve sidebar folder watching: README TODO lists 'Folder watching' as incomplete. Implement FSEvents listener to auto-refresh sidebar when files change on disk—start in a new Pine/Services/FolderWatcher.swift.
• Document CSS theming API: Docs/Development/ lacks a THEMING.md file explaining how users create custom .css themes. Extract theme loading logic from source and write a guide with example theme file.

The Pine markdown editor repository shows a relatively clean macOS application structure with basic configuration management via SwiftLint. However, several security gaps exist: (1) No evidence of code signing/notarization configuration for distribution, (2) Missing App Sandbox entitlements documentation, (3) Lack of explicit dependency management visibility, (4) No security policy or responsible disclosure framework, and (5) Absence of automated security scanning in the build process. These are primarily configuration and process issues rather than code-level vulnerabilities. The application appears to be a single-user document editor with limited external dependencies, reducing some attack surfaces. Recommendations focus on hardening the development and distribution process rather than fixing critical code flaws.

• Low · Missing Code Signing Configuration — Pine.xcodeproj/project.pbxproj. As a macOS application, Pine should implement proper code signing and notarization. No visible evidence of code signing certificates or notarization configuration in the provided file structure. This could impact distribution and user trust. Fix: Implement code signing with Apple Developer certificates and configure notarization for distribution outside the App Store. Add build scripts to automate notarization.
• Low · No Security-Related Configuration Files — Pine.xcodeproj/xcshareddata/. Missing security-hardening configurations such as App Sandbox entitlements, code signing requirements, and security policies. The .plist files shown (IDEWorkspaceChecks.plist) do not indicate proper security entitlements configuration. Fix: Create and maintain Pine.entitlements file with appropriate sandbox restrictions. Document required capabilities and privacy permissions (NSMicrophone, NSCamera, etc.) if used.
• Low · Lack of Security Documentation — Repository root. No visible SECURITY.md or security policy documentation in the repository. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file defining a responsible disclosure policy and security contact information. Include instructions for reporting security issues.
• Low · Incomplete Dependency Visibility — Repository root / Package management. No Package.swift, Podfile, or Cartfile visible in the repository structure. Dependency management status is unclear, making it difficult to assess supply chain security risks. Fix: Ensure all dependencies are explicitly declared and pinned to specific versions. Use Swift Package Manager with version pinning for reproducible builds. Regularly audit dependencies for vulnerabilities.
• Low · No Build Security Validation — .github/workflows or CI/CD configuration. No evidence of automated security scanning in CI/CD pipeline (e.g., no GitHub Actions workflows visible). Missing static analysis, dependency scanning, or security linting automation. Fix: Implement automated security scanning using tools like SwiftLint (already configured), SonarQube, or GitHub Advanced Security. Add dependency vulnerability scanning using Dependabot or similar.

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.