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/fastrepl/anarlog 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 3d ago
• 7 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 69% 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 fastrepl/anarlog repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/fastrepl/anarlog.

What it runs against: a local clone of fastrepl/anarlog — 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 fastrepl/anarlog | 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 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

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

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

# 4. Critical files exist
test -f ".cargo/config.toml" \\
  && ok ".cargo/config.toml" \\
  || miss "missing critical file: .cargo/config.toml"
test -f ".github/workflows/api_ci.yaml" \\
  && ok ".github/workflows/api_ci.yaml" \\
  || miss "missing critical file: .github/workflows/api_ci.yaml"
test -f ".github/workflows/desktop_ci.yaml" \\
  && ok ".github/workflows/desktop_ci.yaml" \\
  || miss "missing critical file: .github/workflows/desktop_ci.yaml"
test -f ".codex/environments/environment.toml" \\
  && ok ".codex/environments/environment.toml" \\
  || miss "missing critical file: .codex/environments/environment.toml"
test -f ".github/AGENTS.md" \\
  && ok ".github/AGENTS.md" \\
  || miss "missing critical file: .github/AGENTS.md"

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

anarlog is an open-source, local-first AI meeting notetaker that records audio, performs on-device speech-to-text transcription, and uses pluggable LLMs (OpenAI, Anthropic, Ollama, etc.) to generate markdown notes. All data stays on your disk as .md files—no cloud backend, no vendor lock-in. It's the open-source successor to Granola, now maintained alongside the proprietary char.com product. Monorepo structure: apps/ contains desktop (Tauri-based), cli, api, and claw; crates/ holds shared libraries (activity-capture, aec, agc, agent-core, api-* modules, analytics); legacy/ and plugins/ contain deprecated or plugin code. Workspace dependencies are heavily aliased as hypr-* (e.g., hypr-api-client, hypr-agent-core) suggesting a historical rebrand from 'Hyprnote'.

Knowledge workers, meeting-heavy professionals, and privacy-conscious teams who want AI-powered meeting notes without cloud storage or account requirements. Also appeals to open-source developers who want a self-hostable, forkable alternative to commercial solutions like Granola or Otter.ai.

Actively maintained but in flux: the team has split focus toward their new proprietary product (char.com), so anarlog receives stability maintenance rather than active feature development. The workspace structure, multi-platform support (desktop via Tauri, CLI, API), and .github/actions CI setup indicate a reasonably mature codebase. However, the README explicitly states most active development happens in char, not here.

Primary risk: team attention fragmentation—most development effort goes to char.com, so anarlog is in 'sustained open-source' mode rather than active feature work. The codebase is large (6.7M Rust, 5.4M TypeScript) with many interdependent workspace crates (apps/, crates/) and excluded packages (plugins/apple-calendar, plugins/cli2, crates/vad-ext), suggesting technical debt or incomplete migration. No publicly visible test metrics or recent commit dates in the provided data.

The .agents/skills/ directory (add-plugin, axum-test-transport, migrate-to-sqlite, sqlite-schema-design, reactive-sqlite-ui) suggests ongoing work on SQLite migration, test infrastructure, and plugin architecture. The presence of Infisical and HuggingFace GitHub Actions hints at infrastructure and model management, but without recent commit data, the exact development velocity is unclear.

git clone https://github.com/fastrepl/anarlog.git
cd anarlog
# Install Rust (via rustup) and bun/node
bun install  # TypeScript dependencies
cargo build  # Build Rust workspace

For desktop dev: cd apps/desktop && cargo tauri dev; for CLI: cargo run --bin claw; for API: cargo run -p api.

Daily commands: Desktop: cd apps/desktop/src-tauri && cargo tauri dev (requires Tauri setup). CLI: cargo run --bin claw -- <args>. API server: cargo run -p api (likely listens on localhost:3000 or via .env). Run tests: cargo test --workspace.

• .cargo/config.toml — Workspace configuration for all Rust members (API, CLI, Desktop, plugins); defines build profiles and dependency resolution strategy.
• .github/workflows/api_ci.yaml — Core CI pipeline for API service; defines build, test, and validation gates for the primary backend component.
• .github/workflows/desktop_ci.yaml — Desktop application CI pipeline; coordinates Tauri builds, E2E tests, and platform-specific compilation steps.
• .codex/environments/environment.toml — Environment and build configuration source-of-truth for development consistency across team.
• .github/AGENTS.md — Agent skill system documentation; defines the AI automation framework and plugin architecture for the codebase.
• .agents/skills/add-plugin/SKILL.md — Skill definition for plugin architecture; reference implementation for extending anarlog with new capabilities.
• Cargo.toml — Root workspace manifest; declares all members, shared dependencies, and workspace-level build configuration.

Add a New Plugin

1. Create plugin directory under plugins/ following naming convention. (plugins/)
2. Define SKILL.md documenting the plugin's purpose and integration points. (.agents/skills/add-plugin/SKILL.md)
3. Implement plugin trait and register in app plugin system (likely in apps/api or apps/desktop/src-tauri). (apps/api)
4. Add plugin CI workflow following pattern of existing cd/ci workflows. (.github/workflows)

Add a New API Endpoint

1. Create route handler in apps/api following existing Axum patterns. (apps/api)
2. Define request/response types and validation schemas. (apps/api)
3. Register route in main router and document in API test transport. (.agents/skills/axum-test-transport/SKILL.md)
4. Add API integration test in CI pipeline. (.github/workflows/api_ci.yaml)

Support a New Platform (OS/Browser)

1. Add platform-specific activity capture implementation (e.g., crates/activity-capture-linux). (crates/activity-capture-interface)
2. Implement platform-specific capture traits and register in activity-capture factory. (crates/activity-capture)
3. Add cross-compilation configuration and toolchain setup to .cargo/config.toml. (.cargo/config.toml)
4. Create platform-specific CI workflow and add to desktop_ci/desktop_cd pipelines. (.github/workflows/desktop_ci.yaml)

Add a Database Schema Change

1. Review SQLite schema design patterns and constraints in skill docs. (.agents/skills/sqlite-schema-design/SKILL.md)
2. Create migration module (likely in crates or apps/api/migrations). (apps/api)
3. Follow migration pattern documented in migrate-to-sqlite skill. (.agents/skills/migrate-to-sqlite/SKILL.md)
4. Add migration test to db_ci.yaml workflow to validate schema changes. (.github/workflows/db_ci.yaml)

• Rust + Axum — Type-safe, high-performance backend for real-time transcription and meeting synchronization; zero-cost abstractions for latency-critical paths.
• Tauri (Desktop) — Lightweight cross-platform desktop with native OS integration (window capture, focus events); avoids Electron overhead for resource-constrained recording.
• SQLite — Local-first, privacy-first persistence; no external database dependency; embedded in all deployment targets (desktop, CLI, API).
• Activity Capture (Platform-specific) — Modular trait-based design allows macOS (NSWorkspace), Windows (Win32), and future Linux backends without code duplication.
• GitHub Actions + Workflows — Multi-platform CI/CD for desktop (macOS/Windows/Linux notarization), API (Docker), and CLI (standalone binaries); supports coordinated releases.
• AI Skills / Agents — Codified development patterns (plugin system, schema design, migrations) enable AI-assisted code generation and maintenance at scale.

• Monorepo with workspace members vs. separate repositories

  • Why: Enables coordinated releases, shared dependency management, and cross-crate refactoring without version coordination overhead.
  • Consequence: Larger CI/CD matrices; build times scale with workspace; requires discipline in dependency declaration.

• Local-first SQLite + API server instead of cloud-only

  • Why: Supports offline operation, user privacy, and data portability; reduces latency for local queries.
  • Consequence: Sync complexity for multi-device scenarios; must implement conflict resolution and eventual consistency.

• Tauri instead of web-based desktop (Electron/CEF)

  • Why: Reduces binary size and runtime memory footprint for long-running background capture.
  • Consequence: Rust backend must handle all platform-specific windowing/focus logic; less code reuse with web frontend if one existed.

• Plugin system at development time (SKILL.md) rather than runtime hot-reload

  • Why: Simplifies deployment, versioning, and API stability; reduces attack surface for untrusted plugins.
  • Consequence: Requires rebuild to add/update plugins; less flexibility for end-user customization.

• Multi-platform desktop CI with notarization/codesigning

  • Why: Ensures security posture and app store distribution eligibility (especially macOS/Windows SmartScreen).
  • Consequence: Complex GitHub Actions workflows; requires certificate management and long build times; macOS notarization ~5-10min wait.

• Real-time collaboration or multi-user simultaneous editing (meetings are per-device).
• Web-first SaaS platform (core value prop is local-first desktop + CLI).
• Support for proprietary/closed-source meeting platforms via API hooking (uses open audio/transcript capture instead).
• Hot-reload or dynamic plugin system (plugins are compile-time dependencies).
• Linux desktop GUI (CLI is supported; desktop focuses on macOS/Windows where focus/window capture APIs are stable).

1. Workspace crate naming: all internal crates are aliased as hypr-* in dependencies (e.g., hypr-api-client → crates/api-client) due to historical rebrand—use the path not the alias in Cargo.toml imports. 2. Excluded packages: plugins/apple-calendar, plugins/cli2, crates/vad-ext are explicitly excluded from the workspace—they may be incomplete or legacy; don't assume they're integrated. 3. Environment setup: .codex/environments/environment.toml is required for local dev (LLM API keys, feature flags); no .env.example visible in file list, so ask the team for a sample. 4. Tauri app certificate: .github/actions/apple_cert is used in CI—macOS local builds may require provisioning profile setup not documented here. 5. Multi-platform audio: platform-specific activity-capture crates mean changes to audio pipeline require testing on macOS and Windows; Linux support unclear.

• Acoustic Echo Cancellation (AEC) — anarlog includes custom crates/aec to remove speaker audio from the recording during meetings; understanding AEC principles helps when debugging audio quality or filtering artifacts.
• Automatic Gain Control (AGC) — The crates/agc crate normalizes microphone levels across variable speaker distances; essential for reliable transcription quality in uncontrolled meeting environments.
• Voice Activity Detection (VAD) — Detects speech vs. silence to avoid transcribing background noise; the excluded crates/vad-ext suggests a custom or experimental VAD implementation was or is planned.
• Tauri IPC (Inter-Process Communication) — The desktop app uses Tauri's bridge to call Rust functions from TypeScript/React; critical for understanding how the UI triggers transcription, note generation, and file saves.
• Activity Capture & Platform Abstractions — anarlog abstracts audio capture via crates/activity-capture-interface with platform-specific impls (macOS, Windows); this pattern allows cross-platform support without duplicating audio handling logic.
• Agent Pattern (in AI context) — crates/agent-core and crates/api-agent implement the agent orchestration for LLM-powered note generation; understanding agent loops, tool use, and prompt templating is key to extending LLM capabilities.
• Markdown as a Data Format — All meeting notes are stored as .md files on disk (no database lock-in); the entire value prop relies on markdown being both human-readable and machine-parseable for downstream sync, grep, and versioning.

• char/char — The active, closed-source successor product by the same team (fastrepl); where new meeting-note features are being developed. Users of anarlog should know char is the experimental frontier.
• openai/whisper — The likely basis for on-device transcription in anarlog; understanding Whisper's model architecture helps with audio pipeline tuning and fine-tuning for domain-specific transcription.
• tauri-apps/tauri — The Rust/TypeScript desktop framework used in apps/desktop/src-tauri; essential for understanding Tauri-specific issues (IPC, asset bundling, signing).
• lapce/lapce — Another large Rust + Tauri desktop app with similar monorepo structure; useful reference for build patterns, CI/CD, and multi-platform release workflows.
• serde-rs/serde — Ubiquitous in the Rust crates for serialization; critical for understanding how config, API responses, and SQLite data are deserialized across the workspace.

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 CI/CD workflow for Rust workspace builds and tests

The repo has an extensive Rust workspace with multiple crates (activity-capture, aec, afconvert, agc, agent-core, api-*, etc.) but no visible GitHub Actions workflow for running cargo build and cargo test on PRs. With platform-specific crates (macos, windows), this is critical for catching cross-platform regressions early.

• [ ] Create .github/workflows/rust-ci.yml that runs cargo build and cargo test on all workspace members
• [ ] Add matrix strategy for testing on linux-latest, macos-latest, and windows-latest
• [ ] Include cargo clippy for linting and cargo fmt --check for formatting
• [ ] Reference .cargo/config.toml profile settings to ensure dev/release builds use correct optimization levels

Document agent skills system and add SKILL.md templates

The .agents/skills/ directory contains 6 skills (add-plugin, axum-test-transport, migrate-to-sqlite, new-changelog, reactive-sqlite-ui, sqlite-schema-design), each with a SKILL.md file, but there's no top-level documentation explaining how to create new skills or what the SKILL.md spec is. This blocks new contributors from extending the agent system.

• [ ] Create .agents/SKILLS_GUIDE.md documenting the skill architecture and SKILL.md format
• [ ] Review existing SKILL.md files and create a .agents/SKILL_TEMPLATE.md if one doesn't exist
• [ ] Add examples of skill dependencies and how skills interact with the core agent system
• [ ] Link the skills guide from .github/AGENTS.md which already exists

Add unit tests for activity-capture crates across platforms

The workspace includes platform-specific activity-capture crates (activity-capture, activity-capture-interface, activity-capture-macos, activity-capture-windows) which are critical for the AI notetaker's core functionality, but the file structure suggests minimal test coverage. New contributors need a test pattern to follow.

• [ ] Create crates/activity-capture/tests/integration_tests.rs for cross-platform API contract tests
• [ ] Add crates/activity-capture-macos/tests/ with macOS-specific capture tests using conditional compilation
• [ ] Add crates/activity-capture-windows/tests/ with Windows-specific tests
• [ ] Ensure tests document the interface in crates/activity-capture-interface and run in CI on respective platforms

• Add missing unit tests to crates/api-error and crates/api-env—these utility crates likely have high coverage gaps; start by writing tests for error enum variants and env var parsing.
• Document the SQLite schema migration path in a MIGRATION.md file in the root—the .agents/skills/sqlite-schema-design work is ongoing but unclear to new contributors; create a step-by-step guide for running migrations locally.
• Create a plugin template in .agents/skills/add-plugin/SKILL.md—the skill exists but the actual template code or scaffolding command doesn't appear in the file list; add a concrete example plugin (e.g., a stub Slack integration).

• High · Incomplete Dependency Declaration — Cargo.toml - [workspace.dependencies] section. The workspace dependencies list in Cargo.toml is truncated at 'hypr-api-mail' and 'hypr-api-messenger'. This incomplete file makes it impossible to verify all dependencies for known vulnerabilities. The truncation suggests the full dependency tree cannot be audited. Fix: Provide the complete Cargo.toml file and run 'cargo audit' to identify any outdated or vulnerable dependencies. Ensure all transitive dependencies are reviewed.
• High · Multiple GitHub Actions Without Security Hardening — .github/actions/ (multiple action.yaml and action.yml files). The .github/actions directory contains numerous custom actions (infisical_export, hf_download, cn_download, etc.) that interact with external systems, cloud services, and potentially sensitive data. Without examining their implementations, these represent significant supply chain and credential exposure risks. Fix: Audit all custom GitHub Actions for: (1) credential handling and secret masking, (2) input validation, (3) use of pinned action versions, (4) proper error handling. Use GitHub's security guidelines and consider using native GitHub Actions instead of custom ones where possible.
• High · Infisical Integration Without Visibility — .github/actions/infisical_export/action.yaml, .github/actions/infisical_install/action.yaml. Actions for 'infisical_install' and 'infisical_export' are present, indicating secrets management integration. Without seeing the implementation, this represents a potential credential exposure risk if not properly configured. Fix: Ensure Infisical integration uses: (1) short-lived tokens with minimal scope, (2) proper secret masking in logs, (3) audit logging of all secret access, (4) OIDC-based authentication if available instead of static tokens.
• High · Multiple External Download Actions — .github/actions/hf_download/action.yaml, .github/actions/hf_unzip_resource/action.yaml, .github/actions/cn_download/action.yaml. Actions for downloading from Hugging Face (hf_download, hf_unzip_resource) and custom services (cn_download) without visible integrity verification mechanisms suggest potential supply chain attack vectors. Fix: Implement cryptographic verification for all downloaded artifacts: (1) verify checksums/signatures of downloaded files, (2) use pinned versions, (3) host critical dependencies internally, (4) implement Software Bill of Materials (SBOM) tracking.
• Medium · Development Profile Security Configuration — Cargo.toml - [profile.dev] section. The [profile.dev] section disables debug symbols for dependencies (debug = false) but enables them for the main application (debug = true). Combined with incremental compilation and opt-level = 0, this may expose sensitive information in development binaries. Fix: Review debug symbol settings. For sensitive applications, consider: (1) using profile.dev.package.'*' with appropriate debug levels, (2) stripping symbols in production builds, (3) documenting why full debug info is needed in dev.
• Medium · macOS Code Signing Without Verification — .github/actions/apple_cert/action.yaml, .github/actions/macos_notarize_dmg/action.yaml, .github/actions/macos_tcc/action.yaml. The presence of 'apple_cert', 'macos_notarize_dmg', and 'macos_tcc' actions suggests macOS code signing workflows. Without seeing the implementation, certificate management and notarization processes may have security gaps. Fix: Ensure macOS code signing security: (1) store certificates in GitHub Secrets or hardware tokens, never in repo, (2) verify notarization processes use secure APIs, (3) implement certificate rotation policies, (4) audit TCC (Transparency, Consent, and Control) settings.
• Medium · Potential Unencrypted Configuration Files — .codex/environments/environment.toml, .cargo/config.toml, and potential .env files. Files like '.codex/environments/environment.toml', '.cargo/config.toml', and '.env' patterns may contain sensitive configuration. The .gitignore and secrets handling are not visible. Fix: Ensure: (1) all configuration files with secrets are in .gitign

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.