Claude Code products

Ars Contexta A second brain for your agent. A Claude Code plugin that generates complete knowledge systems from conversation. You describe how you think and work. The engine derives a cognitive architecture -- folder structure, context files, processing pipeline, hooks, navigation maps, and note templates -- tailored to your domain and backed by 249 research claims. No templates. No configuration. Just conversation. v0.8.0 · Claude Code plugin · MIT Installation Add the marketplace to Claude Code: /plugin marketplace add agenticnotetaking/arscontexta Install the plugin: /plugin install arscontexta@agenticnotetaking Restart Claude Code, then run: /arscontexta:setup Answer 2-4 questions about your domain (~20 minutes -- token-intensive but one-time) The engine generates your complete knowledge system Restart Claude Code again to activate generated hooks and skills Run /arscontexta:help to see everything available What It Does Most AI tools start every session blank. Ars Contexta changes that by generating a persistent thinking system derived from how you actually work. What you get: A vault -- plain markdown files connected by wiki links, forming a traversable knowledge graph. No database, no cloud, no lock-in. A processing pipeline -- skills that extract insights, find connections, update old notes with new context, and verify quality. Automation -- hooks that enforce structure on every write, detect maintenance needs, capture session state, and auto-commit. Navigation -- Maps of Content (MOCs) at hub, domain, and topic levels. Templates -- note templates with _schema blocks as single source of truth. A user manual -- 7 pages of domain-native documentation generated alongside. The key differentiator: derivation, not templating. Every choice traces to specific research claims. The engine reasons from principles about what your domain needs and why. The Setup Flow /arscontexta:setup runs a 6-phase process: Phase What Happens Detection Detects Claude Code environment and capabilities Understanding 2-4 conversation turns where you describe your domain Derivation Maps signals to eight configuration dimensions with confidence scoring Proposal Shows what will be generated and why, in your vocabulary Generation Produces all files: context file, folders, templates, skills, hooks, manual Validation Checks all 15 kernel primitives, runs pipeline smoke test The whole process takes about 20 minutes. It's token-intensive because the engine reads research claims, reasons about your domain, and generates substantial output. This is a one-time investment -- after setup, your agent remembers. For advanced users: /arscontexta:setup --advanced to configure dimensions directly. Three-Space Architecture Every generated system separates content into three spaces: Space Purpose Growth self/ Agent persistent mind -- identity, methodology, goals Slow (tens of files) notes/ Knowledge graph -- the reason the system exists Steady (10-50/week) ops/ Operational coordination -- queue state, sessions Fluctuating Names adapt to your domain (notes/ might become reflections/, claims/, or decisions/), but the separation is invariant. Commands Plugin-Level (always available) Command What It Does /arscontexta:setup Conversational onboarding -- generates your full system /arscontexta:help Contextual guidance and command discovery /arscontexta:tutorial Interactive walkthrough (learn by doing) /arscontexta:ask Query the research graph for methodology answers /arscontexta:health Run diagnostic checks on your vault /arscontexta:recommend Get architecture advice for your use case /arscontexta:architect Research-backed evolution guidance /arscontexta:add-domain Add a new knowledge domain to an existing system /arscontexta:reseed Re-derive from first principles when drift accumulates /arscontexta:upgrade Apply plugin knowledge base updates to your system Generated (available after setup) Command What It Does /reduce Extract insights from sources /reflect Find connections, update MOCs /reweave Update older notes with new connections /verify Combined quality check: description + schema + health /validate Schema compliance checking /seed Create extraction task with duplicate detection /ralph Queue-based orchestration with fresh context per phase /pipeline End-to-end source processing /tasks Queue management /stats Vault metrics /graph Graph analysis /next Next-action recommendation /learn Research and grow /remember Mine session learnings /rethink Challenge system assumptions /refactor Structural improvements Processing Pipeline The vault implements the 6 Rs, extending Cornell Note-Taking's 5 Rs with a meta-cognitive layer: Phase What Happens Command Record Zero-friction capture into inbox/ Manual Reduce Extract insights with domain-native categories /reduce Reflect Find connections, update MOCs /reflect Reweave Update older notes with new context /reweave Verify Description + schema + health checks /verify Rethink Challenge system assumptions /rethink Fresh Context Per Phase Each phase runs in its own context window via subagent spawning. LLM attention degrades as context fills. By spawning a fresh subagent per phase, every phase operates in the "smart zone." /ralph 5 |-- Read queue, find next unblocked task |-- Spawn subagent (fresh context) | +-- Runs skill, updates task file, returns handoff |-- Parse handoff, capture learnings |-- Advance phase in queue +-- Repeat for 5 tasks Hooks Four hooks automate quality enforcement: Hook Event What It Does Session Orient SessionStart Injects workspace tree, loads identity, surfaces maintenance signals Write Validate PostToolUse (Write) Schema enforcement on every note write Auto Commit PostToolUse (Write, async) Git auto-commit, non-blocking Session Capture Stop Persists session state to ops/sessions/ The Research Graph The methodology/ directory contains 249 interconnected research claims about tools for thought, knowledge management, and agent-native cognitive architecture. These claims back every configuration decision. Synthesizes Zettelkasten -- Cornell Note-Taking -- Evergreen Notes -- PARA -- GTD -- Memory Palaces -- Cognitive Science (extended mind, spreading activation, generation effect) -- Network Theory (small-world topology, betweenness centrality) -- Agent Architecture (context windows, session boundaries, multi-agent patterns) How Claims Back Decisions Every kernel primitive includes cognitive_grounding linking to specific research: MOC hierarchy -- context-switching cost research (Leroy 2009) Description field -- progressive disclosure principles Wiki links -- spreading activation theory Query directly: /arscontexta:ask "Why does my system use atomic notes?" Semantic Search (optional) qmd adds concept matching across vocabularies. Not required -- the system works fully with ripgrep + MOC traversal. /setup should perform this configuration automatically when semantic search is active. The commands below are manual fallback/setup verification. # Install qmd npm install -g @tobilu/qmd # or bun install -g @tobilu/qmd cd your-vault/ qmd init qmd collection add . --name <notes_directory_name> --mask "<notes_directory_name>/**/*.md" qmd embed Create or merge .mcp.json in the vault root: { "mcpServers": { "qmd": { "command": "qmd", "args": ["mcp"], "autoapprove": [ "mcp__qmd__search", "mcp__qmd__vector_search", "mcp__qmd__deep_search", "mcp__qmd__get", "mcp__qmd__multi_get", "mcp__qmd__status" ] } } } Keep qmd MCP configuration and tool preapproval in .mcp.json. Prerequisites Dependency Required Purpose Claude Code v1.0.33+ Yes Plugin host tree Yes Workspace structure injection ripgrep (rg) Yes YAML queries, schema validation qmd Optional Semantic search Project Structure arscontexta/ |-- .claude-plugin/ | |-- plugin.json # Plugin manifest | +-- marketplace.json # Marketplace listing |-- skills/ # 10 plugin-level commands | |-- setup/ # Conversational onboarding | |-- help/ # Contextual guidance | |-- tutorial/ # Interactive walkthrough | |-- ask/ # Query the research graph | |-- health/ # Diagnostic checks | |-- recommend/ # Architecture advice | |-- architect/ # Evolution guidance | |-- reseed/ # Re-derive from first principles | |-- upgrade/ # Apply knowledge base updates | +-- add-domain/ # Multi-domain extension |-- skill-sources/ # 16 generated command templates | |-- reduce/ # Extract insights | |-- reflect/ # Find connections | |-- reweave/ # Backward pass | |-- verify/ # Combined quality check | +-- ... # 12 more processing commands |-- agents/ | +-- knowledge-guide.md # Pipeline subagent |-- hooks/ | |-- hooks.json # Hook configuration | +-- scripts/ # Hook implementations |-- generators/ | |-- claude-md.md # CLAUDE.md template | +-- features/ # 17 composable feature blocks |-- methodology/ # 249 research claims |-- reference/ # Core reference documents | |-- kernel.yaml # 15 kernel primitives | |-- three-spaces.md # Architecture spec | +-- use-case-presets.md # Pre-validated configs |-- platforms/ # Platform-specific adapters | |-- claude-code/ | +-- shared/ |-- presets/ # Pre-validated configurations |-- scripts/ # Utility scripts +-- README.md Development Clone this repo and add the marketplace to Claude Code: /plugin marketplace add ~/path-to-arscontexta Install the plugin: /plugin install arscontexta@agenticnotetaking Every time you make changes, re-install the plugin: /plugin uninstall arscontexta@agenticnotetaking /plugin install arscontexta@agenticnotetaking Key Files for Contributors reference/kernel.yaml -- 15 primitives every system must include generators/features/*.md -- composable feature blocks skill-sources/*/SKILL.md -- generated command templates skills/setup/SKILL.md -- the derivation engine reference/use-case-presets.md -- preset definitions Presets Three pre-validated configurations for common use cases: Preset For What You Get Research Academic work, literature reviews, synthesis Atomic claims, citation tracking, methodology MOCs Personal Life management, journaling, relationships Reflective notes, goal tracking, relationship MOCs Experimental Testing, iteration, rapid prototyping Lightweight structure, fast capture, minimal ceremony Presets provide starting defaults. The derivation engine adapts from there based on your conversation. Roadmap Feature Status Claude Code plugin Available Marketplace listing Available Multi-agent processing In progress Philosophy The name connects to a tradition. Ars Combinatoria, Ars Memoria, Ars Contexta: the art of context.

selvedge.sh · PyPI · GitHub Long-term memory for AI-coded codebases. A git blame for AI agents — but for the why, not just which line which model touched. Captured live, by the agent, as the change happens. Selvedge is a local MCP server. AI coding agents (Claude Code, Cursor, Copilot) call it as they work to log structured change events with reasoning. Your data stays in a SQLite file under .selvedge/ next to your code. Six months ago, your AI agent added a column called user_tier_v2. You don't know why. git blame points to a commit from claude-code with a generated message that says "Update schema." The session that made the change is long gone — and so is the prompt that produced it. With Selvedge, you run this instead: $ selvedge blame user_tier_v2 user_tier_v2 Changed 2025-10-14 09:31:02 Agent claude-code Commit 3e7a991 Reasoning User asked to add a grandfathering flag for legacy free-tier users during the pricing migration. Stores the original tier so we can backfill discounts without touching billing history. That reasoning was captured by the agent in the moment — written into Selvedge from the same context that produced the change. Not inferred from the diff afterward by a second LLM. Not a hand-typed commit message. Who Selvedge is for Selvedge has two audiences. Same tool, same pip install, same SQLite file under .selvedge/. Different scale of pain. Teams running long-term, AI-coded codebases. When the project is big enough that you (or someone else) will touch it again in six months, twelve months, three years — but most of it was written by an agent whose context evaporated the day each PR shipped. git blame tells you what changed. Selvedge tells you why — even after the agent session, the prompt template, the developer who asked for it, and the model version are all long gone. This is the original use case: production codebases, schema decisions, migrations, dependency changes that need an audit trail that survives turnover. Solo developers using Claude Code on everyday projects. Side projects, weekend builds, the small internal tool you keep poking at. You don't need enterprise governance — you just need to remember why you (or your agent) did the thing you did yesterday, last week, last sprint. Run selvedge init once. Add four lines to your CLAUDE.md. From then on, selvedge blame is muscle memory — a way to talk to your past self when your past self was an LLM. If you've ever come back to your own AI-built project and thought "what was this for again?", Selvedge is the missing piece. The problem Human-written code leaks intent everywhere — commit messages, PR descriptions, inline comments, the Slack thread that preceded it. AI-written code doesn't. The agent has perfect clarity about why it made each decision, but that context lives in the prompt and evaporates when the conversation ends. Six months later, your team is debugging a schema decision with no trail. git blame tells you what changed and when. It can't tell you why. Selvedge captures the why — live, by the agent itself, as the change is made. The diff is git's job. The why is Selvedge's. What's new in v0.3.9.1 The dev.to feedback release. Five improvements publicly promised in the comment threads of the launch post, all landed. Append-only store and zero-LLM core, unchanged. Drop-in upgrade for anyone on 0.3.9 (the v4 migration is metadata-only, instant at any size). Reverted is no longer a permanent ban. A reverted decision can become correct again — so re-open it explicitly, without rewriting history: selvedge supersede payments.card_token \ --reasoning "Provider now vaults card data — the PCI constraint is gone." prior_attempts / blame / diff then read the full trail — tried → reverted → re-opened — with a clear current-status line. Decisions can now also carry a queryable constraint (the principle that drove them) and a stale_when condition; when a later change event matches the condition, stale_decisions flags the decision "review suggested" (surfacing only — no automatic un-retiring, ever). The prior_attempts check is now enforceable. selvedge setup installs a Claude Code PreToolUse hook that blocks schema/migration edits until prior_attempts has been checked this session — and puts the prior reasoning in the block message, so the agent gets the skipped context for free. Fail-open by contract (a miss or error always allows), --dry-run and SELVEDGE_HOOK_DISABLE=1 included. Your pre-Selvedge reverts count too. selvedge import --from-git walks git history (revert-message commits + file deletions) and seeds change_type="revert" events, idempotently — so the mistakes your repo already made once gate the hook and prior_attempts from day one. And recall that survives renames (optional): pip install "selvedge[semantic]" && selvedge index selvedge prior-attempts --fuzzy "tokenized payment credentials" # finds the users.card_token revert even though you asked about payment tokens Local static embeddings (model2vec, ~30 MB, no torch), clearly-labeled fuzzy matches, substring fallback when the extra isn't installed. Core never imports it. Full details in CHANGELOG.md. What's new in v0.3.9 Agent Trace export — Selvedge is a compatible producer. selvedge export --format agent-trace emits Agent Trace v0.1.0 records — the open AI code-attribution wire format from Cursor + Cognition AI — so your captured history travels to any tool that reads the standard. Selvedge's reasoning and entity-level provenance ride along in each record's metadata under the dev.selvedge namespace. Drop-in upgrade for anyone on 0.3.8. selvedge export --format agent-trace -o trace.json # one record per event selvedge export --format agent-trace --ndjson -o trace.ndjson # stream, one per line selvedge export --format agent-trace --collapse-by-session # merge a session into one record selvedge import trace.json --format agent-trace # round-trip back in It's opt-in and additive — nothing about the native model, the 8 MCP tools, or local SQLite changes. Entity-level events (a column, an env var, a dependency) have no line range, so Selvedge marks them metadata.dev.selvedge.range_unknown: true rather than fabricating one — an honest fidelity signal. This was planned for v0.4.0; only the exporter moved forward (Postgres + the tool rename remain the v0.4.0 markers; HTTP + auth ships in v0.4.1). Full mapping in docs/agent-trace-interop.md. Where Selvedge fits AI agents call Selvedge as they work. Selvedge captures the why into a durable, queryable store and emits it back out — as Agent Trace records for cross-tool readers, as observability metadata that links into Sentry/Datadog stack traces, and as compliance artifacts for SOC 2 and EU AI Act audits. Selvedge does not replace git (line-level what/when), PR review tools (review-time quality), agent observability (LLM call traces), or general-purpose code-host AI features. It sits between them — the provenance-as-first-class-citizen layer that everything else references. How Selvedge compares There's a fast-growing "git blame for AI agents" category. Here's where Selvedge fits — and where it deliberately doesn't. Reasoning source Granularity Mechanism Grouping Storage Selvedge Captured live, by the agent in the same context that produced the change Entity — DB column, table, env var, dep, API route, function MCP server — agent calls it as work happens Changesets — named feature/task slugs across many entities SQLite, zero deps AgentDiff Inferred post-hoc by Claude Haiku from the diff at session end Line Git pre/post-commit hook None JSONL on disk Origin Captured at commit time Line Git hook None Local Git AI Attribution metadata Line Git hook + Agent Trace alliance None Git notes BlamePrompt Prompt-only Line Git hook None Local Why "captured live" matters. AgentDiff and Origin generate reasoning after the change is made, by feeding the diff back to a second LLM call. Selvedge's reasoning is the agent's own intent, written from the same context window that produced the change — no inference, no hallucinated explanations, and an empty reasoning field is itself a useful signal (the agent didn't have one). Why "entity-level" matters. Most tools attribute lines. Selvedge attributes things you actually search for: users.email, env/STRIPE_SECRET_KEY, api/v1/checkout, deps/stripe. The first question after git blame is usually "what's the history of this column", not "what's the history of lines 40–48 of users.py". Why "changesets" matter. A Stripe billing rollout touches the users table, two new env vars, three new API routes, one dependency, and four functions across the codebase. Tag every event with changeset:add-stripe-billing and you can pull the entire scope back later — even if the original PR was broken into eight smaller ones over a month. Selvedge ↔ Agent Trace. Agent Trace (Cursor + Cognition AI, RFC Jan 2026, backed by Cloudflare, Vercel, Google Jules, Amp, OpenCode, and git-ai) is an emerging open standard for AI code attribution traces. Selvedge isn't a competitor to it — it's a compatible producer. As of v0.3.9, selvedge export --format agent-trace emits Agent Trace v0.1.0 records (and selvedge import --format agent-trace reads them back); the mapping is in docs/agent-trace-interop.md. Agent Trace is the wire format. Selvedge is the live capture + query layer that emits it. Quickstart pip install selvedge cd your-project selvedge setup That's it. selvedge setup is an interactive wizard: it detects which AI tools you have (Claude Code, Cursor, Copilot), writes the MCP entry into each one's config, drops the canonical agent-instructions block into your project's prompt file (CLAUDE.md / .cursorrules / copilot-instructions.md), installs the PreToolUse enforcement hook into .claude/settings.json (Claude Code only — blocks schema/migration edits until prior_attempts has been checked; --skip-enforcement-hook to opt out), runs selvedge init, and installs the post-commit hook. Every modified file gets a .bak written next to it before any change reaches disk. Re-running is a no-op. For CI bootstrap or devcontainer.json postCreateCommand: selvedge setup --non-interactive --yes Claude Code plugin marketplace (alternative) If you're a Claude Code user and want to install Selvedge through the official plugin marketplace flow, run these inside Claude Code after pip install selvedge: /plugin marketplace add masondelan/selvedge /plugin install selvedge@selvedge The plugin system wires the MCP server into Claude Code, but it does not install the Python package for you — pip install selvedge first, otherwise the selvedge-server command won't exist on your PATH and the plugin can't start. For the full setup (post-commit hook, project CLAUDE.md instructions block, etc.), selvedge setup is still the recommended path; the plugin marketplace install is just the lightweight Claude-Code-only entry point. Verify the wiring — open a second terminal in the same project: selvedge watch Make any change in your AI tool — add a column, rename a function, add an env var. selvedge watch should print the new event within a second of the agent calling log_change. If nothing arrives, run selvedge doctor for a single-command health check that tells you which step is silently broken. Query your history: selvedge status # recent activity + missing-commit count selvedge diff users # all changes to the users table selvedge diff users.email # changes to a specific column selvedge blame payments.amount # what changed last and why selvedge history --since 30d # last 30 days of changes selvedge history --since 15m # last 15 minutes ('m' = minutes) selvedge changeset add-stripe-billing # all events for a feature/task selvedge search "stripe" # full-text search selvedge stats # log_change coverage report (per-agent) selvedge import migrations/ # backfill from migration files selvedge export --format csv # dump history to CSV Manual install — if you'd rather wire it up yourself If you don't want to run the wizard, the four manual steps it automates: 1. Initialize in your project cd your-project selvedge init 2. Register the MCP server Selvedge is a standard stdio MCP server, so it works with any MCP client — Claude Code, Cursor, Windsurf, Codex CLI, Gemini CLI, and more. See Works with any MCP client for the exact config per client. For Claude Code: claude mcp add selvedge -- selvedge-server 3. Tell your agent to use it selvedge prompt --install CLAUDE.md Point --install at whichever prompt file your client reads — the block itself is identical across clients:

🛡 Termaxa Run AI coding agents with confidence. Termaxa gates the shell commands an agent runs — previews the blast radius, backs up first, blocks the dangerous ones, and escalates repeat offenders. It's a cooperative windshield, not a sandbox. Your AI agent wants to run git push --force, DROP TABLE users, terraform apply, rm -rf. Most of the time it's right. Sometimes it isn't. Today your only options are supervise every command (which defeats the point of an agent) or trust it blindly (which defeats your Friday). Termaxa is a third option: a gate the agent's commands pass through. It reads a policy you wrote, shows you what's actually about to happen, backs up what's about to change, and records everything. Built for Claude Code and Cursor today; works as a standalone CLI anywhere. Claude Code --> TERMAXA --> git . postgres . docker . terraform . your shell | +- decide allow / ask / deny (your policy) +- preview commits lost, rows affected, resources destroyed +- insure automatic backup before destructive ops +- escalate repeated destructive intent -> auto-deny +- record every attempt, with an execution report Quick start (5 minutes) 1. Install. Download a prebuilt binary from Releases and put it on your PATH — or, with a Rust toolchain: cargo install termaxa termaxa check "rm -rf /" # works immediately — no setup, no project config 2. Wire up a project. cd your-project termaxa init --claude-code # writes .termaxa/policy.yaml, installs the Claude Code hook 3. See it work. termaxa check "git push --force origin main" From now on, every Bash command Claude Code runs in this project passes through Termaxa first. Runtime state (logs, backups) lives in ~/.termaxa/, safely outside your repo. What it looks like 1 - A destructive command can't hide behind a safe prefix $ termaxa check "git status && rm -rf /" decision: deny reason : segment 2/2 `rm -rf /` — Recursive delete from root is blocked. Termaxa splits compound commands and judges each part. git status && buys nothing. 2 - Blast radius, before you commit to it $ termaxa check "psql -d shop -c 'DROP TABLE users'" decision: deny reason : DROP TABLE is blocked. Archive or rename instead. preview : postgres impact DROP TABLE users rows (estimate) : 50,000 referenced by : audit_log, orders, sessions (3 tables) without CASCADE : this DROP will FAIL (dependents exist) insurance : pg_dump users before execution (automatic on run/hook) Row estimates come from the planner (pg_class.reltuples, stale between ANALYZEs) — Termaxa never scans your tables. 3 - An agent that retries can't syntax its way through An agent blocked on rm -rf . will often just try again with different words. Termaxa classifies the intent, not the spelling, and trips a per-session circuit breaker on repeat attempts: $ rm -rf . -> ask (file-delete #1) $ Remove-Item -Recurse -Force . -> ask (file-delete #2, different shell) $ del /s /q . -> DENY circuit breaker: 2 prior file-delete attempts this session Three shells, one intent, third variant auto-denied — no rule enumerated per spelling. find -exec rm, xargs rm, and unlink count too. Configure via circuit_breaker: in policy.yaml (on by default, threshold 2). 4 - Destroy, then un-destroy $ termaxa run -- git push --force origin main ┌ push preview (main -> origin) │ ⚠ remote will LOSE 1 commit(s): │ ✗ 44510f1 important work └ Proceed? [y/N] y 🛟 backup b-1783006590625 — origin/main @ 44510f1 pinned to termaxa/backup/b-1783006590625 $ termaxa rollback b-1783006590625 ✓ origin/main restored to 44510f1 Force push measures what the remote will lose, not just gain — and pins it to a backup branch first. After a session: the report $ termaxa report ┌─ Termaxa Execution Report ───────────────────────── │ commands : 4 ✓ 1 allow · ? 2 ask · ✗ 1 deny │ blocked : ✗ psql -d shop -c "DROP TABLE users" │ impact : • DROP users ~50,000 rows, 3 dependent(s) │ • plan: +3 ~0 -1 │ backups : 1 — rollback available │ risk : Medium (deny×3 + escalation×2 + ask×1 = 5) └────────────────────────────────────────────────── Every line is a fact with a source in the audit log. Nothing invented. Why Termaxa? "Claude Code already asks permission — why do I need this?" The built-in prompt tells you the command. Termaxa tells you the consequence: 50,000 rows, 3 dependent tables, 1 commit lost. It takes the backup before you approve, and when it blocks something it tells the model why, so the agent proposes an alternative instead of retrying. Why not a sandbox / Docker? A sandbox contains damage to the sandbox. But your repo, your database, and your Terraform state are exactly the real things an agent must touch to be useful. Sandboxes are walls; Termaxa is a windshield. They're complementary — run both. Why not OPA / policy engines? OPA decides allow/deny well. It has no execution previews, no automatic backups, no rollback, and no agent-native hook. Termaxa is policy plus the things you actually want when an agent is holding the keyboard. Architecture a command the agent wants to run | +-------------------------v-------------------------+ | TERMAXA | | | | shell split -> policy -> context -> decision | | (&&, ;, |) (yaml) (branch, (allow/ | | flags, ask/deny) | | prod, SQL) | | | v | | preview <-------------- consequential| | (git loss, pg blast radius, | | | terraform plan) v | | insurance <------------- destructive | | (git ref / pg_dump / files) | | | v | | execute | | | | | audit (JSONL, ~/.termaxa) <---------------+ | | notify (webhook) report (session summary) | +---------------------------------------------------+ Six engines, one binary. Policy is in-repo (.termaxa/policy.yaml, reviewable in PRs); logs and backups live in ~/.termaxa/ where no git operation can touch them. Policy .termaxa/policy.yaml — first match wins, * is a wildcard, matching is case- and whitespace-insensitive: version: 1 default: ask # unmatched commands require approval rules: - match: "git status*" action: allow - match: "git push*--force*" action: ask reason: "Force push — remote history will be overwritten." - match: "*drop table*" action: deny reason: "DROP TABLE is blocked. Archive or rename instead." circuit_breaker: # optional (on by default) enabled: true threshold: 2 # trip on the 3rd repeated destructive attempt notify: # optional webhook: https://hooks.slack.com/services/... on: [deny, ask] Command reference Command Purpose termaxa init [--claude-code] scaffold .termaxa/, detect tools, install the hook termaxa check "<cmd>" dry-run: verdict + preview (exit 0/3/4) termaxa run -- <cmd> gated execution: preview → approve → backup → run termaxa hook Claude Code PreToolUse mode (stdin JSON → decision) termaxa log [--decision D] [--source S] [--json] the audit trail termaxa stats totals, sessions, top blocked termaxa backups · termaxa rollback <id> list / restore backups termaxa report [--session ID] [--all] [--md] session summary termaxa notify --test verify your webhook termaxa paths where policy and state live Honest limitations Termaxa is pre-1.0. It's real and tested, and it is not magic. Specifically: Hooks advise; they don't enforce. Termaxa gates commands an agent submits through the Claude Code or Cursor hook. Those agents are cooperative — they respect a deny and propose an alternative, which is what makes the gate work. An agent running in full-auto mode could, in principle, retry a blocked action through a different command or shell; the circuit breaker raises the cost of that, but a hook is an integration point for visibility and policy, not an enforcement boundary. True enforcement means owning the execution path — that's Termaxa Runtime, on the roadmap. For hard guarantees today, pair Termaxa with OS-level sandboxing. Native agent tools bypass the gate. The hook sees shell commands. An agent's own built-in file/edit tools don't go through the shell — observed in live testing, a Cursor agent switched to its native file-delete tool and removed files Termaxa never saw. Non-shell tool calls need OS-level isolation underneath. Cooperative, not a sandbox. Termaxa governs commands that flow through the agent hook or termaxa run. An agent with raw, unhooked shell access is not contained — that needs OS-level sandboxing, a complementary layer. The threat model is agents making expensive mistakes, not a malicious agent actively evading you. Shell parsing is good, not perfect. It splits on &&, ||, ;, | and flags $(...). Subshells ( ), deeply nested quoting, and variable-expanded commands are judged conservatively, not deeply understood. Previews are best-effort. No database connection → static analysis only. Terraform previews shell out to terraform plan. Remote Terraform state is versioned by its backend, not by Termaxa. Backups have edges. rm insurance keys on the literal rm command. Postgres backups use pg_dump/psql and must be on your PATH. No retention/pruning yet — backups accumulate. The format may still change. Pre-1.0 means the policy schema and CLI can shift between minor versions. Pin a release. Claude Code and Cursor are live-tested. Both are exercised end-to-end, including the circuit breaker tripping under a real Cursor session. Codex and Copilot dialects parse each agent's format but aren't verified end-to-end yet. Help validating them is welcome. See SECURITY.md for the full threat model. Contributing Issues and PRs welcome. cargo test must pass; CI runs on Linux, macOS, and Windows. The codebase is ~3,600 lines of dependency-light Rust — src/policy.rs and src/preview.rs are the best places to start reading.

Decide who will be assigned where today on a floor map. Workforce placement management for factories and warehouses. English · 日本語 On a factory or warehouse floor, someone decides every day which worker stands at which station on which line. Usually with a whiteboard and paper. haizu turns that into a floor map you can drag people onto, and a screen the floor can read. Upload a floor plan, place spots on it, and build a placement area spec Pick a date and a shift, then drag employees onto spots Show the confirmed placement in a display-only viewer for large screens Features → User guide — how to use each screen, step by step. Getting started You need Node.js 24.18+ (see .nvmrc), pnpm 10+, and Docker. git clone https://github.com/uswebk/haizu.git cd haizu pnpm install docker compose up -d # PostgreSQL + Mailpit (dev mail) cp apps/api/.env.example apps/api/.env # set BETTER_AUTH_SECRET to 32+ random chars cp apps/web/.env.example apps/web/.env cd apps/api && pnpm db:migrate && pnpm db:seed && cd ../.. pnpm dev # web: 3000, api: 3001 Open http://localhost:3000 and create a company from the sign-up screen. Warningpnpm db:seed inserts demo data including a demo admin account ([email protected] / password123). It is for local development only — never run it against a production database. You can skip it and start from the sign-up screen instead. NoteEmail delivery and file storage are pluggable adapters. By default nothing is sent: verification codes, invitation links, and password resets are printed to the API server console (prefixed [email:console]), and uploaded images are stored on local disk (apps/api/uploads). Seeing real emails (Mailpit) docker compose up -d also starts Mailpit, a dev mail server. Set EMAIL_DRIVER=smtp in apps/api/.env and outgoing mail is captured by Mailpit — view it at http://localhost:8025 (nothing leaves your machine). Production adapters Concern Env var Default Swap for production Email EMAIL_DRIVER console Set smtp and point SMTP_* at a real SMTP provider (SendGrid / SES), or implement EmailSender and add a case in src/email/ File storage STORAGE_DRIVER local (local disk) Implement FileStorage (e.g. S3 / GCS) and add a case in src/storage/ The app runs fully on the defaults. Contributions for production adapters are welcome (see CONTRIBUTING.md). Language and timezone The web app (apps/web) reads two deploy-time defaults from its environment (Vite bakes VITE_-prefixed vars in at build time): Concern Env var Default Notes Language VITE_DEFAULT_LOCALE en en or ja. The locale is resolved in this order: the cookie set by the in-app switcher (sidebar user menu / account settings) → the browser's Accept-Language → this default. So this value only applies when the browser asks for no supported language. Timezone VITE_DEFAULT_TIMEZONE (runtime TZ) An IANA name such as Asia/Tokyo. Used to decide "today" and shift times. If unset, it falls back to the runtime timezone (the server's TZ on SSR, the browser's timezone on the client). Set them in apps/web/.env (copied from apps/web/.env.example). There is no per-user timezone setting: the app assumes a single site/timezone per deployment. Running one instance across multiple timezones would need a site-level timezone setting (not implemented). Where to go next docs/guide/ User guide: what each screen does and how to operate it (English + Japanese) docs/architecture.md Design decisions you will break if you don't know them docs/domain/ Domain knowledge, one file per concept (English + Japanese) CONTRIBUTING.md Development commands, conventions, and how to open a PR

code-airlock Website: trivo25.github.io/code-airlock Run Claude Code, Codex, OpenCode, or another coding agent in a disposable microVM, then review its work as normal git commits. Code Airlock is a small wrapper around Docker Sandboxes for people who want to let coding agents work with fewer prompts without giving them direct access to the host machine. Why Use It Coding agents are most useful when they can install packages, run tests, inspect failures, and iterate without asking before every command. That is also exactly when you want a stronger boundary than process-level deny rules. Code Airlock keeps the workflow simple: You want Code Airlock does Run agents unattended Starts the selected agent inside a Docker Sandbox microVM Keep your local repo clean Uses clone mode, so the host repo is mounted read-only Review everything first Pulls sandbox commits back with fetch, diff, and merge Limit network access Can apply a configurable allowlist for model APIs and package registries Switch agents Uses AGENT=claude, AGENT=codex, AGENT=opencode, and other Docker Sandbox agents Why Let the Agent Run Freely? Coding agents are most effective when they can use the tools needed to finish the task: install dependencies, inspect generated files, run test suites, start local services, read logs, and iterate on failures. Over-constraining every shell command often turns the agent into a slower autocomplete loop. Code Airlock moves the main safety boundary below the agent. The agent can work with more autonomy inside a disposable microVM, while the host repo stays read-only and the resulting changes still come back as commits for review. Why Not Just Use sbx Directly? You can. Code Airlock is intentionally a thin wrapper around Docker Sandboxes, not a replacement for it. Use sbx directly when you want full control over sandbox lifecycle, policies, kits, and one-off experiments. Use Code Airlock when you want the common coding-agent loop already wired together: clone mode by default stable sandbox naming per repo one-command agent startup repo-local AGENTS.md scaffolding fetch, diff, review, and merge commands for the sandbox branch a documented credential and network-policy path for Claude Code, Codex, and OpenCode The point is to make the safe workflow boring and repeatable while still leaving sbx available underneath. Why Not Just Configure the Agent Harness Better? Agent harness rules are useful, and Code Airlock is meant to work with them. Codex approvals, Claude Code permissions, OpenCode settings, AGENTS.md, and custom prompts all help shape what the agent should do. Those rules are still policy inside the agent process. They do not give you a disposable VM, a read-only host repo, a separate clone for agent commits, or a host-side review step before changes land. They also do not provide a shared wrapper for Claude Code, Codex, OpenCode, and other agents. Code Airlock treats harness rules as the first layer and Docker Sandboxes as the boundary underneath it. The agent can be configured to behave well; the sandbox limits what happens when it does not. Quick Start Install Docker Sandboxes first. On Linux: curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh sudo apt-get install docker-sbx sudo usermod -aG kvm $USER newgrp kvm sbx login On macOS and Windows, follow Docker's official install guide. Install Code Airlock with npm: npm install -g code-airlock Or with Homebrew (head-only formula until a tagged release exists): brew tap trivo25/code-airlock https://github.com/Trivo25/code-airlock brew install --HEAD code-airlock Once the CLI is installed, it can walk you through any missing prerequisites: code-airlock setup # guided install; shows each command and asks before running it code-airlock doctor # checks only, changes nothing Or use the standalone shell installer: curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | sh The shell installer also adds a short codelock alias when that command is not already taken: codelock up codelock status codelock attach The npm package intentionally installs only code-airlock, because codelock is already an npm package name. Add a personal shell alias if you want the shorter command after npm install: alias codelock=code-airlock Or clone it manually: git clone https://github.com/Trivo25/code-airlock.git cd code-airlock ln -s "$PWD/code-airlock" ~/.local/bin/code-airlock The installer writes to ~/.local/bin by default. Choose another location with: curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | PREFIX=/usr/local/bin sh Skip or rename the short alias: curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | CODE_AIRLOCK_INSTALL_ALIAS=0 sh curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | CODE_AIRLOCK_ALIAS=calock sh Run a Task The shortest loop, one command in and ordinary Git review out: code-airlock run "add pagination to the users endpoint and run the tests" code-airlock diff code-airlock merge run starts the sandbox like up and hands the task to the agent's non-interactive mode: -p for Claude Code, exec --dangerously-bypass-approvals-and-sandbox for Codex, and run for OpenCode. Other agents receive the task as a plain argument. Install - Agent Already using a coding agent? Send it this: Install Code Airlock in this environment, then run its first-run checks. Use npm when available: npm install -g code-airlock If npm is unavailable, use: curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | sh After install, make sure code-airlock is on PATH, then run: code-airlock doctor code-airlock --dry-run up Do not start a real sandbox or change network policy unless I explicitly ask. Run it from the repo you want the agent to work on: cd ~/code/my-project code-airlock doctor # check sbx, virtualization, login, and git code-airlock --dry-run up # preview the sbx commands without running them code-airlock init # optional: add starter AGENTS.md instructions code-airlock up # start Claude Code in a sandbox code-airlock --seed-config up # optionally copy user-level agent customizations code-airlock status # see this repo's sandbox and tmux session On a remote server, keep the agent running after your SSH connection closes: code-airlock --tmux up # detach with Ctrl-b, then d code-airlock attach # reattach later Use another agent: code-airlock --agent codex up code-airlock --agent opencode run "fix the build" The AGENT environment variable and the sandbox.conf setting still work; the --agent flag wins when both are set. When the agent has made changes, review them from your host: code-airlock fetch code-airlock diff code-airlock review # optional: open a visual diff code-airlock merge Prefer a pull request over a local merge: code-airlock pr # push the sandbox branch and open a PR code-airlock pr main feature/foo # explicit base and branch name The push happens from the host with your credentials, so the sandbox still needs no GitHub access. pr uses gh when it is installed and prints the GitHub compare URL otherwise. The default branch name is code-airlock/<sandbox-name>; override it with the second argument or PR_BRANCH. How It Works Code Airlock starts Docker Sandboxes with --clone: Docker creates a private clone inside the sandbox VM. The agent edits and commits inside that clone. Your host repo stays read-only while the agent runs. You fetch the sandbox branch into your local repo and review the diff. You merge only when you are satisfied. If initialized submodules exist, fetch, diff, review, and merge also try to import each sandbox submodule's HEAD commit into the matching host submodule. Submodule commits are fetched into: refs/remotes/code-airlock/<sandbox-name> This lets the parent repo merge point at submodule commits that the host can actually check out. Disable this with FETCH_SUBMODULES=0 for parent-only fetch behavior. This means uncommitted sandbox edits do not come back through the normal flow. If needed, enter the sandbox and commit first: code-airlock shell git status git add -A git commit -m "describe the agent work" exit Then fetch and review from the host. First-Run Checks Most setup failures come from missing Docker Sandboxes, missing KVM/virtualization support, or an unauthenticated sbx CLI. Check before launching: code-airlock doctor Preview what Code Airlock would run without creating a sandbox: code-airlock --dry-run up Dry-run mode prints the sbx and git commands instead of running them. It is useful on machines that cannot run KVM yet, or when you want to understand the workflow before creating a VM. Remote / Server Runs Use --tmux to start the sandboxed agent inside a host-side tmux session: code-airlock --tmux up This attaches immediately so you can talk to the coding agent. To disconnect without stopping it, press Ctrl-b, then d. This detaches your terminal and leaves the agent running in the tmux session. Reattach later with: code-airlock attach For an unattended server run, start the tmux session without attaching: code-airlock --tmux-detached up The default session name is code-airlock-<sandbox-name>. Override it with: TMUX_SESSION=agent-work code-airlock --tmux up TMUX_SESSION=agent-work code-airlock attach For a visual review, use: code-airlock review This fetches the sandbox branch and opens a Git directory diff using VS Code by default. Your working tree is not modified by the review command. Use another Git difftool: REVIEW_TOOL=opendiff code-airlock review REVIEW_TOOL=vimdiff code-airlock review Agent Instructions Agents work better when the repo contains concise project instructions. Code Airlock can create a starter file: code-airlock init This writes AGENTS.md in the target repo only if one does not already exist. code-airlock up will mention the command when no AGENTS.md is present, but it will not silently modify your working tree. Config Seeding By default, a sandbox starts with a fresh agent home directory. Project files that are committed to Git come through clone mode, but personal commands, skills, subagents, and global instructions from your host home directory do not. Opt in to copying curated user-level config before the agent starts: code-airlock --seed-config up This changes startup from one sbx run call to: sbx create --clone ... sbx cp ... sbx run --name ... Default seeded paths: Agent Paths Claude Code ~/.claude/CLAUDE.md, ~/.claude/commands/, ~/.claude/agents/, ~/.claude/skills/ Codex ~/.codex/AGENTS.md, ~/.codex/AGENT.md, ~/.codex/agents/, ~/.codex/skills/, ~/.codex/prompts/ OpenCode ~/.config/opencode/AGENTS.md, ~/.config/opencode/opencode.jsonc, ~/.config/opencode/commands/, ~/.config/opencode/agents/, ~/.config/opencode/skills/ Code Airlock does not copy auth files, histories, logs, caches, session state, or node_modules by default. Credentials should still go through Docker Sandboxes' secret manager. Copy explicit extra user-level paths with: SEED_PATHS="$HOME/.codex/config.toml,$HOME/.claude/settings.json" code-airlock --seed-config up SEED_PATHS entries must be under $HOME; secret-like paths are skipped. Gitignored project-local files are not copied by default. Prefer committing project instructions such as AGENTS.md, CLAUDE.md, and .claude/commands/ when they are meant to travel with the repo. Authentication Model credentials should go through Docker Sandboxes' secret manager or host-side auth flow, not be pasted into the VM. Common setup: sbx secret set -g anthropic # Claude Code API key sbx secret set -g openai --oauth # Codex OAuth sbx secret set -g openai # Codex/OpenCode API key Agent-specific notes: Agent Authentication Claude Code Run code-airlock up and use /login inside Claude, or store an Anthropic key with sbx secret set -g anthropic Codex Use sbx secret set -g openai --oauth, sbx secret set -g openai, or export OPENAI_API_KEY before launch OpenCode Store the provider keys you use, such as openai, anthropic, google, xai, groq, aws, or openrouter Sandboxes do not carry user-level config such as ~/.claude or ~/.codex into the VM by design. Put project-level config in the repo if the agent needs it. GitHub Credentials Code Airlock does not need GitHub credentials for the normal fetch/diff/merge review loop. Give the sandbox GitHub access only if you want the agent to use gh, open pull requests, create issues, or push directly from inside the VM: echo "$(gh auth token)" | sbx secret set -g github Global secrets apply when a sandbox is created. For an existing sandbox, either recreate it or scope the token to that sandbox:

Makoto An integrity hook for Claude Code that watches the agent's own tool calls and blocks the ones that fake a check. When Claude says it did something — ran the tests, cited a paper, committed the fix, verified the certificate — makoto holds that word against its record. If the deed isn't there, or the verification was quietly disabled, makoto blocks the tool call (or the end-of-turn) and hands the agent a one-line correction to retry against. It judges the agent against its own utterances and record — never the world's truth. It holds no facts ("France doesn't exist to it"); it only checks that a claimed word is kept, whole, and honored in deed. A word it lets through becomes spendable: trustworthy tender a reviewer or another agent can accept without re-deriving it. What it catches makoto fires on mechanical hook events — every PreToolUse, PostToolUse, and Stop — and blocks (exit 2, which Claude Code treats as block-and-retry) on 15 pre-checks across five families and 19 end-of-turn gates. Every pre-check and every end-of-turn gate but four blocks; there is no silent "warning" tier for those (see Fire level) — the four documented exceptions are gate.self_wired, gate.canon_fingerprints_advisory, gate.relative_path_citation, and gate.plan_item_drift (below), advisory-only checks that by design never block. Verifier weakening — a check silently neutered content.verifier_predicate_weakened loose-comparator verifier (startswith/endswith/re.match where == is meant) content.verifier_exit_masking exit-code masking (|| true, ; true, set +e on a test/build/lint) content.verifier_body_hollowed hollowed verifier body (return True / pass in a constitution check) content.env_gated_audit audit/verification code gated behind an env var · content.integrity_suppression_flag integrity-named suppression flag (*_skip = true) Fabricated evidence — a claim with no backing artifact content.phantom_citation phantom citation (Author-Year not in makoto/docs/CITATIONS.md) content.unsourced_webfetch WebFetch of a URL never seen in any prior tool result this session content.fabricated_commit_sha fabricated commit SHA/tag presented as proof of a commit content.deferred_checkbox_theater DEFERRED-style checkbox theater on an open to-do item content.illusory_authorship_trailer an illusory Claude/Anthropic authorship or generation attribution (trailer, session link, routing address, or "Generated with/by Claude" footer) — a plain "Claude Code" product-name mention is not matched content.illusory_interruption_claim a fabricated "interrupted by user" claim with no genuine harness-set interruption anywhere in this session's recorded history Self-defense content.self_mute_guard makoto self-mute (disabling or un-wiring makoto via settings.json) Scope & contract discipline — illusory progress and out-of-contract action (SPEC-5, ported by shape from Assay) event.thrash_revert a whole-file Write that reverts a file to an earlier byte-identical content after an intervening different Write (A→B→A, no net progress) gate.contract_order a result-producing call issued while a declared Plan's dependency for that step is still undischarged (its Stop-time sibling gate guards the remainder at turn end) End-of-turn gates — fire on the agent's closing claims, checked against the recorded ledger: gate.completion — "done / created X" but the artifact isn't on disk gate.advance — advancing a phase whose precondition isn't recorded as met gate.green_claim — "suite green" against a recorded test failure gate.dropped — a forward promise carrying identifying info ("I'll add def X to Y", "3 tests in Z") left undischarged at turn-end — said-but-not-done, checked against the agent's own touched-keys gate.fabricated_action — "I ran X / executed Y" in a turn with no tool call at all (presence-of-work, not command-text match) gate.named_test — "test_foo passes" against a recorded FAILED of that exact named test (coreference-pinned; the green_claim delta) gate.stale_pass — "all tests pass" against pytest's own lastfailed record still naming a live failing test (the runner's ledger, existence-filtered for staleness) gate.claimed_running — "the server is running" / "it's up and listening on port 5173" but this session's own recorded Bash evidence contradicts it: no process-start or liveness-check command ran at all this session, or the most recently recorded one ended in a direct error state (interrupted, or a non-zero exit code). Agnostic in the gate.canon sense — the failure verdict reads only those two protocol terminals, never a test-runner regex or a language/framework token; the command classifier is a broad, open-world, multi-ecosystem net (like is_test_runner's), so an unlisted launcher/healthcheck shape is a documented recall bound, never a false-block source. gate.run_promised — the forward-looking sibling of gate.claimed_running: the immediately prior turn's own message promised a first-person run-intent action ("I'll run the tests", "I'm going to restart the server", "let me deploy this") but no Bash call appears anywhere in this session's recorded history since — the word must match the world, checked one turn later. Closed first-person-auxiliary + closed process-lifecycle-verb lexicon (mirroring gate.claimed_running's own verb set), so "it's going to rain today" cannot match on either the subject or the verb axis. Stateless: the one-turn grace period falls out of history structurally never containing the row for the Stop currently being evaluated, so a promise made THIS turn can only ever be checked starting at the NEXT one — no new persistence, no Plan/PlanNode extension (a run-intent promise's only evidence is "a Bash call happened", not a located file write). gate.claimed_shipped — a completed-action sibling to gate.claimed_running/gate.run_promised, but scoped to REMOTE mutations instead of local process liveness: "I merged the PR", "pushed it to main", "it's live now" with no successful remote-mutating tool call anywhere in this session's recorded history. Evidence is a non-dry-run git push over Bash, or a successful call from a closed non-Bash tool set (merge_pull_request — requiring merged: true, not just an error-free response — and push_files, plus their mcp__github__-qualified forms); create_pull_request is deliberately excluded, since opening a PR establishes intent but does not substantiate "merged" or "live". Reads history_all_agents so a subagent's own real push/merge grounds a main-thread claim. Immediate check, no grace period — this claims something already done. gate.completion keeps sole ownership of local file-production claims; this gate never duplicates it. gate.liveness — fires on the code itself, not a claim: a statement with no live effect inside a closed function (dead/illusory work the present-closure model can prove inert). It walks the turn's touched .py ASTs, so it yields a finding per illusory statement rather than one per turn. gate.self_wired — advisory only, never blocks (see Fire level): partial-strip detection of makoto's own .claude/settings.json hook wiring — fires if PreToolUse/PostToolUse/Stop is missing a makoto-dispatching entry while at least one other still has one. It has a documented blind spot: a single edit that strips all three simultaneously disables this check in the same instant it would have fired (Claude Code reloads hook config live, not once at session start), so it provides zero coverage against that full-strip case — see docs/self-defense-asymmetry-followup.md. gate.hollow_test — fires on the code itself, not a claim: a HOLLOWED test (SPIRIT.md §4) — one that survives in name while its content is gutted, so it can never actually fail. Four sub-patterns: no assertion of any kind in the test body; an asserted tautology (assert True, or comparing an expression to itself); a broad, no-op try/except that silently swallows the only call-under-test's failure; and a test-shaped function that can never fire independently — either nested inside another function (pytest's collector never discovers it) or gated behind a skipif/skipIf condition that is provably always true. gate.canon — blocking (level="error", unlike the advisory exceptions below): two language-agnostic Stop primitives over the turn's own call stream, reading only closed protocol fields (tool_name/tool_input identity, tool_response.interrupted/.error) — no test-runner regex, no language token. canon.timeout fires when the turn's LAST tool call ended in a direct error state (interrupted, or a self-emitted error code) and closed without resurfacing or resolving it — an error resolved by a later successful call stays silent. canon.recur fires when the SAME tool call (identical name + byte-identical input) was re-issued back-to-back and every call in that consecutive run ended in the same direct error state — a stuck retry loop with nothing changed between attempts; judged per (tool, input) key, so a later success for that same key silences it even with other, different calls in between. Certified via held-out adversarial RED fixtures (planted cases that must fire) plus a near-vacuous corpus-FP check — the honest corpus almost never carries the triggering precondition (interrupted/self_error_code) at all, so a clean corpus replay alone is inconclusive, not a certification (see ANCESTRY.md §2 Part B for the corrected framing). gate.canon_fingerprints — blocking: 4 of 17 ported session-level "canon" fingerprints (SPEC-5 Task 9, from REF-lever-graded-primitives/signalminer/grade_planted.py's 27-fingerprint THE_CANON) that are robust-core, blocking-capable by construction — 0-FP on both the planted-clean and real-Claude-gold negative sets per the gold-oracle certification (nogreen_checkdisabled, nosrc_destruct, nosrc_green_timeout, notestedit_destruct). gate.canon_fingerprints_advisory — advisory only, never blocks: the other 13 of the same 17 fingerprints — each either rests on a soft/claim atom (claimed_pass_no_run, tool_timeout, assertion_weakened) the gold-oracle finding doesn't certify as robust, or is one of that finding's explicitly-named worst-disqualified fingerprints. Recorded to the audit log per SPEC-5's total-retention rule, never emitted as a block decision. gate.contract_order — blocking: the Stop-time remainder guard over a declared Plan (SPEC-5, ported by shape from Assay's ContractOrder pattern) — fires when the turn ends with the plan's dependency remainder still non-empty. Its PreToolUse sibling guard is a pre-check, not a Stop gate; see makoto/checks/contractOrder.py. Inspect the live catalog with makoto pattern list; see one pattern in full with makoto pattern show content.phantom_citation. Discharging a permanent session-level block gate.canon_fingerprints (and canon.timeout within gate.canon) read the session's own recorded call stream. Once a fingerprint's atoms go true they stay true forever, so without a real discharge path a single sanctioned action (e.g. an owner-approved destructive command) would otherwise block every remaining Stop for the rest of the session. The only discharge is an operator-attributed release, re-derived from the host-written transcript at check time and never trusted from ledger content, so no tool call or file write can forge it. Say, as a real message in the conversation (never inside a tool call or file write): makoto release.operator <fingerprint-id>: <your reason> makoto verifies the turn is genuinely user-authored, non-synthetic, and timestamped after the finding first fired, then discharges that exact fingerprint for the rest of the session. The discharge is chain-appended (kind="release.operator") for the audit trail; the block decision itself is always re-derived from the transcript, never read back from that row. Legitimately writing a flagged shape? Annotate the line with makoto-allow: <reason> (any comment style, case-insensitive). makoto won't fire on it, and your rationale is on the record — an auditable note, not a silent bypass. if os.environ.get("ENABLE_AUDIT_TRAIL"): # makoto-allow: app feature, gates user-facing audit logging write_audit_trail() See docs/SPIRIT.md — 誠 (makoto), the constitution every pattern derives from: a word is real the way water is wet, a constitutive property, not an after-the-fact audit. Install (plugin) /plugin marketplace add Clear-Sights/Makoto /plugin install makoto@makoto Enabling the plugin is the whole install: .claude-plugin/plugin.json + hooks/hooks.json auto-wire dispatch on enable. Claude Code registers PreToolUse, PostToolUse, Stop, SubagentStop, and SessionStart hooks pointing at ${CLAUDE_PLUGIN_ROOT}/makoto/_dispatch_shim.sh automatically (which execs python -m makoto._dispatch). ~/.claude/settings.json is NOT modified — the plugin system manages its own hook registry. State dir + makoto.db are created lazily on the first hook invocation. Companion setting (optional): suppress the harness auto-trailer An illusory AI-authorship commit trailer reaches a commit through two doors. Pre-Check content.illusory_authorship_trailer blocks the agent-authored one — the trailer typed into a git commit message or into file content, the surface no setting can reach. The other door is Claude Code's own automatic append, which a setting governs. To close it at the source, set in ~/.claude/settings.json:

agent-security-scanner-mcp npm audit for AI agents and MCP servers Scan code, MCP tools, prompts, skills, and AI-suggested dependencies before your agent trusts them. Built for Claude Code, Cursor, Windsurf, Cline, OpenClaw, and CI/CD. Start Here Run the agent security smoke test on any repo: npx agent-security-scanner-mcp scan-project . --verbosity compact Or get repo-specific next steps first: npx agent-security-scanner-mcp quickstart --client claude-code Generate public-safe copy for a launch post, GitHub issue, or directory listing: npx agent-security-scanner-mcp share-kit --client claude-code Include a real scan result in the copy: npx agent-security-scanner-mcp scan-project . --verbosity compact > scan-result.json npx agent-security-scanner-mcp share-kit --scan-result scan-result.json --output share-kit.md Install it into your AI coding client: npx agent-security-scanner-mcp init claude-code Replace claude-code with cursor, claude-desktop, windsurf, cline, kilo-code, opencode, or cody. Add the GitHub Actions workflow: npx agent-security-scanner-mcp init-ci github What To Run Before You Trust An Agent # Check the whole project and get an A-F security grade npx agent-security-scanner-mcp scan-project . --verbosity compact # Audit an MCP server before adding it to Claude/Cursor/Windsurf npx agent-security-scanner-mcp scan-mcp ./path/to/mcp-server --verbosity compact # Try an MCP audit demo with tool poisoning and command-exec findings npx agent-security-scanner-mcp demo --type mcp --no-prompt # Verify AI-suggested imports are real packages, not hallucinations npx agent-security-scanner-mcp scan-packages ./src/app.ts npm --verbosity compact # Check one package before installing it npx agent-security-scanner-mcp check-package express npm # Add a local environment health check npx agent-security-scanner-mcp doctor # Add the scanner to your AI client npx agent-security-scanner-mcp init claude-code 🎯 Two Versions Available 🔥 ProofLayer (Lightweight) - NEW! Ultra-fast, zero-Python security scanner — 81.5KB package, 4-second install npm install -g @prooflayer/security-scanner ⚡ 4-second install (vs 45s traditional scanners) 📦 81.5KB package (vs 50MB+ alternatives) 🚀 Instant scans - pure regex, no Python/LLM 🛡️ 400+ security rules across 9 languages 🎯 7 MCP tools for AI agents ✅ Zero dependencies on Python 💯 MIT licensed - free for commercial use 📖 ProofLayer Documentation → 🔬 Full Version (Advanced) Enterprise-grade scanner with AST analysis, taint tracking, cross-file analysis, and LLM-powered semantic review npm install -g agent-security-scanner-mcp 🧬 AST + Taint Analysis - deep code understanding 🔍 1,700+ security rules across 12 languages 📊 Cross-file tracking - follow data flows 🎯 11 MCP tools + CLI commands 📦 4.3M+ package verification (bloom filters) 🐍 Python analyzer for advanced features 🤖 LLM-powered code review - semantic security analysis with intent profiling Continue reading below for full version documentation → New in v4.4.12 (2026-07-12): Scan-backed share kits — share-kit now accepts --scan-result, --grade, and --finding so launch posts and GitHub issue templates can include a real scan grade and top finding. New in v4.4.11 (2026-07-11): Share kit generator — run npx agent-security-scanner-mcp share-kit --client cursor to generate public-safe launch copy, a GitHub issue template, directory listing text, and repo-specific commands for sharing an agent-security smoke test. New in v4.4.10 (2026-07-10): Quickstart planner — run npx agent-security-scanner-mcp quickstart --client cursor to get repo-specific scan, MCP audit, SBOM, CI, and AI-client setup commands before choosing what to run. New in v4.4.9 (2026-07-08): MCP audit demo — run npx agent-security-scanner-mcp demo --type mcp --no-prompt to create and scan a tiny MCP server with tool poisoning, tool-name spoofing, command execution, secret exposure, and missing-validation findings. New in v4.4.8 (2026-07-07): Package hallucination demo — run npx agent-security-scanner-mcp demo --type packages --no-prompt to create and scan a tiny import file with real and fake npm packages. README examples now show both single-package verification and import scanning. New in v4.4.7 (2026-07-07): CI adoption improvements — added init-ci github to install the GitHub Actions workflow from the CLI, and scheduled GitHub Action runs now automatically scan the full project instead of only the latest diff. Package hallucination checks also use all tracked source files during full-project runs. New in v4.3.0 (2026-05-05): Critical security and reliability fixes — GitHub Actions now fail closed instead of fail-open when scanner output is invalid (preventing security gate bypass), patched 8 Hono CVEs (XSS, path traversal, authentication bypass), fixed confidence threshold filtering case sensitivity, and corrected SARIF generation for GitHub Code Scanning. All fixes include comprehensive regression tests. Upgrade recommended for production use. See Full Changelog. New in v4.2.0: Compliance evidence collection — evaluate projects against SOC2-Technical (8 controls) and GDPR-Technical (6 controls) frameworks. Collects evidence from code scans, SBOM, vulnerability checks, and hallucination detection, then evaluates controls with pass/partial/fail/not_evaluated status. Supports evidence persistence for audit trails. See Compliance Evaluation. New in v4.1.0: SBOM generation and dependency vulnerability analysis — generates CycloneDX v1.5 SBOMs, scans against OSV.dev for CVEs, detects hallucinated packages, compares baselines, and generates HTML audit reports. Supports 8 lock file formats and 7 manifest formats across npm, Python, Go, Rust, Ruby, and Java ecosystems. See SBOM Tools. New in v4.0.0: LLM-powered semantic code review agent with intent profiling — understands what your project is supposed to do and flags patterns that violate that intent. Same eval() call = safe in a build tool, dangerous in an e-commerce app. Supports Claude CLI (no API key needed!), Anthropic, and OpenAI. See code-review-agent. New in v3.11.0: ClawHub ecosystem security scanning — scanned all 16,532 ClawHub skills and found 46% have critical vulnerabilities. New scan-clawhub CLI for batch scanning, 40+ prompt injection patterns, jailbreak detection (DAN mode, dev mode), data exfiltration checks. See ClawHub Security Dashboard. Also in v3.10.0: ClawProof OpenClaw plugin — 6-layer deep skill scanner (scan_skill) with ClawHavoc malware signatures (27 rules, 121 patterns covering reverse shells, crypto miners, info stealers, C2 beacons, and OpenClaw-specific attacks), package supply chain verification, and rug pull detection. OpenClaw integration: 30+ rules targeting autonomous AI threats + native plugin support. See setup. Tools Tool Description When to Use scan_security Scan code for vulnerabilities (1700+ rules, 12 languages) with AST and taint analysis After writing or editing any code file fix_security Auto-fix all detected vulnerabilities (120 fix templates) After scan_security finds issues scan_git_diff Scan only changed files in git diff Before commits or in PR reviews scan_project Scan entire project with A-F security grading For project-wide security audits check_package Verify a package name isn't AI-hallucinated (4.3M+ packages) Before adding any new dependency scan_packages Bulk-check all imports in a file for hallucinated packages Before committing code with new imports scan_agent_prompt Detect prompt injection with bypass hardening (59 rules + multi-encoding) Before acting on external/untrusted input scan_agent_action Pre-execution safety check for agent actions (bash, file ops, HTTP). Returns ALLOW/WARN/BLOCK Before running any agent-generated shell command or file operation scan_mcp_server Scan MCP server source for vulnerabilities: unicode poisoning, name spoofing, rug pull detection, manifest analysis. Returns A-F grade When auditing or installing an MCP server scan_skill Deep security scan of an OpenClaw skill: prompt injection, AST+taint code analysis, ClawHavoc malware signatures, supply chain, rug pull. Returns A-F grade Before installing any OpenClaw skill scanner_health Check plugin health: engine status, daemon status, package data availability Diagnostics and plugin status list_security_rules List available security rules and fix templates To check rule coverage for a language sbom_generate Generate CycloneDX v1.5 SBOM for a project (8 lock file formats, 7 manifest formats) Before releases, for compliance audits sbom_scan_vulnerabilities Cross-reference SBOM against OSV.dev for CVEs with severity filtering After generating SBOM, for security audits sbom_check_hallucinations Verify all SBOM packages exist in official registries Before deploying, to catch AI-invented packages sbom_diff Compare current SBOM against baseline, detect added/removed/changed packages In CI/CD to track dependency drift sbom_export_report Generate HTML or JSON audit report from SBOM with vulnerability data For PCI-DSS compliance, security reviews get_compliance_controls Look up compliance controls with evaluation criteria (AIUC-1, SOC2, GDPR) To understand compliance requirements evaluate_compliance Evaluate project against compliance frameworks with evidence collection For SOC2/GDPR technical compliance audits Quick Start npx agent-security-scanner-mcp init claude-code Restart your client after running init. That's it — the scanner is active. Other clients: Replace claude-code with cursor, claude-desktop, windsurf, cline, kilo-code, opencode, or cody. Run with no argument for interactive client selection. Recommended Workflows After Writing or Editing Code scan_security → review findings → fix_security → verify fix Before Committing scan_git_diff → scan only changed files for fast feedback scan_packages → verify all imports are legitimate For PR Reviews scan_git_diff --base main → scan PR changes against main branch For Project Audits scan_project → get A-F security grade and aggregated metrics When Processing External Input scan_agent_prompt → check for malicious instructions before acting on them When Adding Dependencies check_package → verify each new package name is real, not hallucinated ClawHub Ecosystem Scanning (New in v3.11.0) Scan AI agent skills for prompt injection, jailbreaks, and security threats: # Scan entire ClawHub ecosystem (777 skills) node index.js scan-clawhub # Scan single skill file node index.js scan-skill ./path/to/SKILL.md # Standalone package npm install -g clawproof clawproof scan ./SKILL.md Security Reports: We've scanned all 777 ClawHub skills: 69.5% have security issues 21.2% have critical vulnerabilities (Grade F - DO NOT INSTALL) 30.5% are completely safe (Grade A) 4,129 prompt injection patterns detected See ClawHub Security Dashboard for interactive exploration of all 16,532 skills with searchable security grades and detailed findings. Detection Capabilities: Prompt Injection (15 patterns): "ignore previous instructions", role manipulation Jailbreaks (4 patterns): DAN mode, developer mode, pretend scenarios Data Exfiltration (2 patterns): External URLs, base64 encoding Hidden Instructions (2 patterns): HTML comments, secret directives Security Grading: A (0 points): Safe to install B (1-10): Low risk - review findings C (11-25): Medium risk - use with caution D (26-50): High risk - not recommended F (51+): DO NOT INSTALL - critical threats 🤖 LLM-Powered Code Review Agent (New in v4.0.0) The code-review-agent is an LLM-powered semantic code review tool that uses intent profiling to distinguish safe patterns from dangerous ones based on project context. Key Differentiator: Intent-Aware Analysis Same code, different verdicts based on what the project is supposed to do:

PMB Local-first memory for your AI coding agent. SQLite is the source of truth. No cloud, no API keys, no re-explaining. Local-first memory, visualized. 3,800+ entities and 41,000+ connections, captured automatically as you work. Website · Docs · Quickstart · Demo · Why PMB · How it works · FAQ Your AI agent forgets everything between sessions. So you re-explain the same decisions, lessons and constraints over and over. PMB remembers them in one local workspace and feeds them back through MCP - no cloud, no API keys, no LLM call on the read path. And it tells you when memory is actually helping, instead of claiming "+X%". ⭐ Star the repo if PMB saves you a re-explanation. PMB gives Claude Code, Cursor, Codex and the other MCP-aware agents a real memory: decisions you made last week, lessons you taught them, personal facts, project structure, PDFs. They survive every restart, every model upgrade, every agent switch - because they live in a local workspace you own, with SQLite as the durable source of truth and rebuildable search indexes beside it. No API keys. No subscription. No LLM call on the read path. Just local files. Quickstart pip install pmb-ai # 1. install pmb setup # 2. detect your agent + wire the MCP entry pmb warmup # 3. preload the model (first recall is instant) # 4. restart your agent, then just talk to it - memory is automatic pmb stats # 5. see what's stored pmb recall "auth decision" # 6. search memory from the terminal pmb doctor # 7. confirm everything is wired That's it - your agent now remembers. No account, no keys, nothing leaves your machine. Command name: the CLI is pmb. Via pip you also get the alias pmb-ai; via npm (npx pmb-ai setup) the command is pmb-ai and it installs the Python package first, then runs setup. Same tool - use whichever your install gave you. Links: pmbai.dev (site) · docs.pmbai.dev (docs) · Getting started · Deleting memories. Demo What it feels like - same prompt, with and without memory: ▶ Click to play the 2-minute setup You: fix that LoadGuard pricing bug we hit last Tuesday Agent: prepare(message="fix LoadGuard pricing bug") ↓ (6 ms) → project_context: 12 events about LoadGuard, 4 lessons (incl. "never lower NEGOTIATE/SKIP under 25%"), 3 decisions, 2 open goals → active_arcs: "LoadGuard verdict-policy refactor (started Tue)" → lessons: 1 directly matches "pricing" → recent_activity: 8 commits this week Looking at src/engine/verdict-policy.ts (you opened it Tuesday 14:32, last changed Wednesday). The pricing bug is on line 142 where the bundle fallback tightened below the rate-floor. Per the lesson you saved, we never drop the threshold under 25% - restoring the guard there. The agent didn't ask. It didn't guess. It read its memory in 6 ms and showed up already informed. Why PMB Local-first, zero-config. SQLite holds the durable memory; rebuildable search indexes stay local. No account, API keys, telemetry, or cloud to trust. It actually gets used. On Claude Code / Codex, hooks inject the right memory before the model thinks - you never have to remember to call a tool. Multilingual, no setup. The embedder covers 50+ languages; a Russian query finds an English fact. No per-language config. MCP-native. One pmb connect wires Claude Code, Cursor, Codex, Windsurf, Zed, VS Code, and more. Fast read path. Recall in ~35 ms warm; writes return in under a millisecond - no LLM call to remember. Honest impact. The dashboard shows which lessons actually changed outcomes, instead of claiming "+X%". Your data, in the open. pmb export dumps everything to Markdown/JSON. Apache 2.0. See your memory pmb dashboard opens a local, liquid-glass web UI on http://127.0.0.1:8765 over everything PMB captured - written automatically, just by working. It binds to 127.0.0.1 only, so nothing leaves your machine. Map - every entity and connection in your project, as a live graph. Timeline - your memory as a journal, newest first. Nine tabs: Map (entity graph, live), Timeline (git-graph by project), Overview, Entities, Arcs (narrative threads), Lessons (per-rule follow-rate, dead-lesson detection), Duplicates (inline merge), Performance (per-tool latency), Recall (debug ranker). What you can store # Personal facts that change (time-travel: old values archived, never lost) record_keyed_fact("user", "city", "Warsaw") # Project structure - symbols, imports, .gitignore-aware pmb index project . # Why each file exists + the intent behind every commit (Haiku-summarised, local) pmb track modules # one-line purpose per indexed file pmb track changes # new commits: what changed and WHY # PDFs (research papers, manuals, contracts) pmb index pdf paper.pdf pmb index pdf ~/docs --recurse # Whatever your agent logs as it works: decisions, lessons, completed tasks, goals PMB is content-agnostic. If it's text the agent will care about later, PMB remembers and retrieves it. What the agent gets back A single MCP call - prepare(message) - returns the right things at the right level of detail, in 4-16 ms: Field What it is project_context Full project overview if the message mentions a project: key facts, lessons (RULES to follow), decisions, open goals, related entities, the project's narrative arc lessons Procedural rules matching the query, each with a surface_id so the agent can confirm it followed the rule later recent_activity Last 24 h of decisions / edits / completions for session continuity open_goals In-progress goals so the agent knows what you're pursuing active_arcs Narrative arcs the project is currently living in For everything else there's recall(query) (hybrid search, 35 ms warm) and 27 other tools in docs/reference/COMMANDS.md. How it works flowchart LR A[Your agent] -->|MCP stdio| B[PMB MCP server] B --> C[Engine] C -->|read 35 ms| R[Hybrid recall<br/>BM25 + vector + graph + rerank] C -->|write under 1 ms| W[Async embed queue<br/>SQLite first, vectors later] R --> D[(SQLite)] R --> E[(LanceDB)] W --> D W --> E style A fill:#dbeafe,color:#1e3a8a style B fill:#ede9fe,color:#5b21b6 style C fill:#dcfce7,color:#14532d Loading Storage - every durable event lives in SQLite, the source of truth. Rebuildable vector indexes live in LanceDB beside it. The whole workspace stays on your disk and can be copied or exported anytime. Recall - BM25 (lexical) + dense vector (semantic) + entity graph + optional cross-encoder rerank, fused via Reciprocal-Rank-Fusion. Writes - async. The MCP tool returns in under a millisecond; the embed + LanceDB insert happen on a background thread. Dedup - four layers: exact text match -> cosine >= 0.92 auto-merge -> cosine 0.80-0.92 borderline (LLM verify later) -> manual review in the dashboard. Old values are archived, never deleted; full history via keyed_fact_as_of(t). Multilingual - no language packs. The default embedder (paraphrase-multilingual-MiniLM-L12-v2) covers 50+ languages, so где я живу finds a keyed-fact stored as user.city = Warsaw. Intent detection rides English semantic anchors that transfer cross-lingually, and the cold lexical path self-compiles from your own traffic. Recall stays strong across ~11 languages (top-3 ~= 0.9 on a 101-query eval; top-1 = 1.00 for en/fr/pt/ru). See docs/contributing/adding-a-language.md. Install The Quickstart above is all most people need. Other ways: # From source git clone https://github.com/oleksiijko/pmb.git && cd pmb python -m venv .venv && source .venv/bin/activate pip install -e . pmb warmup # prime the ~450 MB embedder once Wire one or more agents (all stdio - the server runs as a child of your agent; no network, no port, no token): pmb connect claude-code # also: codex · cursor · windsurf · gemini · vscode · zed · opencode · continue Point several agents at one memory: pmb connect claude-code --workspace personal pmb connect cursor --workspace personal # both read/write the same workspace Sharing one memory across machines or a team? That's an optional HTTP mode with bearer-token auth - see docs/guide/TEAM.md. Not needed for local use. Running the tests? Use the venv's Python: .venv/bin/python -m pytest (or .venv\Scripts\python.exe -m pytest on Windows). Bare pytest outside the venv just reports missing numpy/fastmcp/typer. CLI cheat sheet # Memory pmb stats show counts and storage info pmb recall "query" search with full debug pmb dashboard web UI on port 8765 (graph, settings, errors) # Ingest pmb index pdf paper.pdf extract + chunk + embed pmb index pdf ~/docs --recurse entire directory pmb index project . scan codebase pmb track changes summarise commit intent (why) pmb track modules one-line purpose per module pmb import chatgpt ~/Downloads/export.json bring existing history # Continuity & efficiency (opt-in) pmb resume save write .pmb/resume.md (commit it) pmb resume install refresh resume.md at every turn end pmb health lessons-impact which lessons actually help outcomes pmb memory ledger Memory Delta handles this session # Maintenance pmb regraph rebuild entity graph pmb consolidate run sleep pass (optional) pmb compact archive old events pmb dedupe resolve borderline duplicates # Hooks (force-feed PMB at the protocol level - no model cooperation) pmb hooks install claude-code wire all lifecycle hooks pmb hooks list show what's installed pmb hooks capabilities ambient mechanism each agent supports pmb hooks uninstall claude-code remove them pmb auto-context "fix bug in PMB" preview per-turn injection pmb session-restore -m 180 preview post-compaction restore pmb lesson-followcheck --dry-run preview follow-through scoring # Ambient memory (the write side - memory journals the agent's work) pmb autowrite --dry-run preview ambient auto-write for this turn pmb ambient-watch . ambient auto-write for MCP-only hosts (git observer) pmb forget-auto drop memory the ambient layer wrote itself # Config pmb config list default tier (25 keys you care about) pmb config list --pro every key, including 80 advanced knobs pmb config set recall.ppr_enabled true toggle a feature pmb connect --rules-only refresh CLAUDE.md only Step-by-step per agent: docs/guide/usage.md. Full reference: docs/reference/COMMANDS.md. Hooks - memory that doesn't wait to be asked The hard part of agent memory isn't storing - it's getting the agent to use what's stored. Soft instructions in a rules file get skipped. So PMB wires hooks at the protocol level (pmb hooks install claude-code), each removing a dependency on the model remembering to act: UserPromptSubmit -> auto-recall. Every message is classified (regex, multilingual, sub-ms) and the matching memory - lessons, past decisions, recall hits, project overview - is injected before the model thinks. Trivial messages inject nothing. PostToolUse -> ambient observe. Every tool the agent runs is appended to a lightweight action journal (a single SQLite INSERT, no model). Reads and ls are filtered out; edits, tests and commits are kept. SessionStart -> session-restore. After a context compaction the agent rebuilds "where you left off" from what the session recorded, instead of re-asking you. Stop -> follow-through + ambient auto-write. (a) It checks which surfaced lessons actually showed up in what the agent did and marks them followed, deterministically. (b) If the agent did NOT call a record_* tool, it synthesizes one activity entry from the observed actions - so real work is captured even when the agent stays silent. Preview any without an agent: pmb auto-context "...", pmb session-restore -m 180, pmb lesson-followcheck --dry-run, pmb autowrite --dry-run. Ambient memory - the write side Auto-recall fixed the read side; ambient memory does the same for the write side - the memory journals the agent's work even when it forgets record_batch: Coordinated. If the agent already called a record_* tool this turn, ambient stays silent; it only fills the gap. Outcome-scored, not churn. A turn is journaled only if results clear a quality bar (tests passed, a failure fixed, a deploy ran), not by file count alone. Honest + reversible. Every ambient entry is tagged source=autowrite, shown as auto in the dashboard, and removable with pmb forget-auto. On by default; disable with pmb config set autowrite.enabled false. Works on every host. Claude Code (hooks), Codex (pmb codex-notify), MCP-only hosts like Cursor/Zed/VS Code (git observer, pmb ambient-watch .). Check yours with pmb hooks capabilities. Synthesis is template-based by default (instant, no model). Opt into a local/API/CLI model summary with pmb config set autowrite.synthesizer llm:ollama or llm:openai (it has a timeout and falls back to the template).

claude-code

Explore categories

How Product Visit works