My Emacs configuration https://git.cjennings.net/dotemacs/atom?h=load-graph-classify-start 2026-05-24T08:54:09+00:00 2026-05-24T08:54:09+00:00 Craig Jennings c@cjennings.net 2026-05-24T08:54:09+00:00 urn:sha1:6ebd0314c880c4f9fc15936618ad412cef6ea309 The latest design review was a UX and performance pass, and I folded its findings into the spec and the implementation tasks. The important one: human Emacs edits now use the same write path as agent writes. An ai-kb minor mode runs index, full lint, and commit under flock on after-save, so a hand edit can't quietly skip the safety gate. The rest: the generated index.org is now invisible to backlink and orphan logic (excluded from the scan, referenced as plain text rather than id-links), a required :SUMMARY: property feeds the index and query without inference, query gains lexical ranking with recency only as a tie-break, the switch installs a full org-roam profile rather than a two-variable swap, and the browsing surface (dashboard, find, search, show, backlinks, map) is named. I also answered the six build-time decisions: concrete raw and curation limits, performance budgets for the perf fixtures, the lexical scoring weights, org-roam-graph as the first map implementation, the after-save failure UX (the save always lands, the commit is gated, and a failure shows without trapping the buffer), and the after-save recursion guard. The numeric limits and budgets are starting points to calibrate. The rest are firm. Step 1 stays buildable. 2026-05-24T08:30:26+00:00 Craig Jennings c@cjennings.net 2026-05-24T08:30:26+00:00 urn:sha1:51c8c2fe8069740ce79fdb60431da71a23d9a7f9 Review 5 was implementation-hardening, all of it sound, so I folded in all six findings. The important one: the commit gate now runs the full ai-kb lint over the change (index freshness, duplicate IDs, broken links, and a secret scan of nodes and raw/), not just org-lint on the edited node. If the write path is the safety boundary, gating only on single-node syntax would let a stale index or a leaked secret through. The rest, all adopted: an explicit org-lint fatal-check list so a future org-lint change can't silently move the gate, observable push failures surfaced through a state-file log and ai-kb doctor and a startup nudge so the KB can't go quietly local-only, a testable ai-kb query contract with text and --json output, and ID-first durable pointers since filenames change in curation but IDs don't. I also split the build plan into Step 1a (the safe write path) and 1b (query, curate, sync, push timer, workflow), since remember depends on index and lint and the adapter depends on remember. 2026-05-24T08:16:48+00:00 Craig Jennings c@cjennings.net 2026-05-24T08:16:48+00:00 urn:sha1:b96592c2df6ab02c45c500a5e457affe0e2c990f I resolved the four open decisions and baked the answers in: the store lives at ~/.local/share/ai-kb (XDG), the ai-kb CLI is a shell wrapper that calls emacs --batch for the org-lint and sync steps, the push runs off a background systemd --user timer rather than firing on every write (remember only commits locally), and curation is node-count-triggered with the workflow living in the rulesets .ai/workflows/ directory. I also refreshed the provisioning and Step 1 sections to match, since the push timer was a new piece: make ai-kb-init now installs and enables the ai-kb-push timer and service units, and doctor checks for them. Open decisions is empty now and the spec is fully decided. 2026-05-24T08:08:48+00:00 Craig Jennings c@cjennings.net 2026-05-24T08:08:48+00:00 urn:sha1:c87631f0c200556d99b2ccbcd838cdf6877c7014 Reviews 3 (Codex, via Nexus/GraphRAG/Letta research) and 4 pushed on the write loop and the access layer rather than scope. I folded both in. The write path is now a real protocol: fetch and fast-forward before writing, org-lint the node, regenerate the index, commit locally always, and treat the push as best-effort and non-blocking so a failed push never errors or hangs the agent. That's the exact gpg-agent failure we hit earlier today. The index is regenerated from node properties by a script rather than hand-maintained, so it can't drift from the nodes. The access layer became an agent-neutral contract that lives in the repo, fronted by a minimal ai-kb CLI (doctor, query, remember, lint, curate, sync) with destructive operations human-only. That earns its place on Claude-only grounds: it's the clean home for the safe-write protocol and the lint and index steps. Cross-agent use is not a near-term goal, so Codex and Ollama adapters are deferred to vNext. The contract stays neutral in shape, so they're additive later. Added provenance fields, the T1/T2/T3 tier names, and the review dispositions. The spec is now Ready. 2026-05-24T07:32:56+00:00 Craig Jennings c@cjennings.net 2026-05-24T07:32:56+00:00 urn:sha1:1faa6e7538d458a9e65c6e97fbf566363686e6c8 ai-kb is a global, durable, cross-project memory store for Claude Code: org-roam nodes holding lessons, principles, my preferences, and reusable procedures, distinct from the per-project memory files (which shrink to an index pointing into it). The spec covers the two-layer model (a git-versioned file store the agent reads/writes, and an Emacs switch command so I can browse it with backlinks), the sync model, the routing and proactive-write rules, the node format, and the startup retrieval contract. It folds in two reviews. The scope decision: v1 is the memory store, not a full Karpathy LLM Wiki. The heavy machinery (compiled wiki layer, source hashes, formal ingest pipeline, embedding search) is deferred to vNext, each with a reason. Storage is a dedicated private git repo at an XDG path rather than Syncthing or the public emacs-config repo, which would leak personal notes. Two Karpathy ideas earned their way into v1 because they pay off now: capturing the raw source when a node is compiled from external material, and an org-lint validity check on every write so malformed org never reaches the index. Review dispositions and the open decisions are recorded in the spec. 2026-05-17T21:00:57+00:00 Craig Jennings c@cjennings.net 2026-05-17T21:00:57+00:00 urn:sha1:3aa577665329200c90c17db2c949acb45514c29b Two drafts of `docs/design/gptel-git-tools-magit-backend.org` existed at the same path: a 592-line local copy and the 192-line upstream version that just landed in main. I renamed the local draft to `.local.org` so the upstream version can sit at the canonical path. I'll reconcile the two in a follow-up. 2026-05-17T06:16:03+00:00 Craig Jennings c@cjennings.net 2026-05-17T06:16:03+00:00 urn:sha1:2b61aa82afa39a0ff1b165fa9ff09d55d21bfabf Two new design docs in docs/design/ covering the next two GPTel work items, plus matching task scaffolding in todo.org. mcp-el-gptel-integration.org wires mcp.el into the config so GPTel gets access to the nine MCP servers Claude Code already uses (linear, notion, figma, slack-deepsat, drawio, google-calendar, google-docs-personal, google-docs-work, google-keep). The design covers async startup, the write-confirmation policy, a server-enablement defcustom, a doctor with live-auth-check, the audit buffer, and the mcp.el compatibility layer. The spec is at revision 3 after two code-review passes flagged a critical confirmation gap (gptel-confirm-tool-calls nil at ai-config.el:386 silently ignored per-tool :confirm slots) and several incorrect mcp.el API assumptions. Both are addressed. gptel-gh-tool.org wraps the gh CLI as a hybrid surface: 14 typed read wrappers plus one general write tool gated by :confirm t. Host/repo resolution is command-aware: --repo HOST/OWNER/REPO for repo commands, --hostname only for api and auth status. The runner enforces an irreversible-command blocklist, a 64KB in-flight output cap, and a debug-record plus last-error-buffer story. The spec is at revision 2 after a code-review pass corrected gh flag assumptions and reframed the safety story around per-tool confirm. todo.org gains a link to the MCP spec under the parent task plus nine TODO sub-tasks (one per implementation phase), and a new gh-tool TODO with the same spec-link shape. 2026-05-16T15:29:50+00:00 Craig Jennings c@cjennings.net 2026-05-16T15:29:50+00:00 urn:sha1:faf716de7ad4b69486e42de591588d8b750bbdb9 Undercover now instruments gptel-tools/*.el alongside modules/*.el, so the new git_status / git_log / git_diff / web_fetch tools (and their successors) report coverage instead of reading as zero. The matching pre-coverage clean step deletes gptel-tools/*.elc so stale byte-compiled artifacts don't shadow the .el sources. If Emacs loads the .elc first, undercover's source instrumentation never runs. docs/design/coverage.org gains an Elisp-coverage-producer subsection documenting the glob, the :merge-report dependence (SimpleCov merges cross-process reports, LCOV does not), and the missing-artifact failure mode. 2026-05-16T15:10:31+00:00 Craig Jennings c@cjennings.net 2026-05-16T15:10:31+00:00 urn:sha1:c00167c64cbce7f67e2924a51a236c26d7f8d8f4 Adds docs/design/gptel-network-tools.org capturing the brainstorm output for the next gptel-tools batch -- net_diagnose, net_discover, net_services, network_status, dns_lookup -- with argv shapes, target-gating guardrails for nmap, and a ~47-test sketch. Restructures the GPTel Tool Work parent in todo.org with seven themed categories: Git, Org, messaging, file/buffer, filesystem, media / reading, and dev workflow. Each carries a body framing the design choice and stub child themes. Filesystem covers the pandoc / imagemagick / ffmpeg / ripgrep / fd / file+exiftool / jq+yq surface plus an eshell escape hatch. Per-theme spec lands in the task body once written. Implementation tasks join as siblings once the spec is approved. 2026-05-16T10:58:14+00:00 Craig Jennings c@cjennings.net 2026-05-16T10:58:14+00:00 urn:sha1:d76efe15eb5718fb859df87ee12306bcbc56b07c - gptel-git-tools-magit-backend.org -- spec for reimplementing the three current git_* tools on top of magit, plus three new tools (blame, show, branches). - gptel-agentic-tool-ideas.org -- brainstorm seed for additional agentic gptel tools. - agentic-knowledgebase.org -- design sketch for using org-roam as the agent's durable project memory with org-agenda as the execution layer.