zara-emacs: structured Emacs, Org-roam daily, and Magit project integration #212

Closed
opened 2026-09-08 02:03:14 +00:00 by nsaspy · 0 comments
Owner

Plugin

zara-emacs

Goal

Give Zara a structured Emacs integration for the operator's real note/coding workflow without embedding editor-specific shell strings in Zara core.

Initial operator phrases/use cases include:

  • open emacs scratch
  • open roam daily
  • open emacs magit <project>
  • open/reveal a file or buffer
  • report current Emacs project/buffer context where explicitly requested

Use emacsclient/server-supported mechanisms or another bounded documented Emacs IPC boundary; do not depend on arbitrary elisp supplied by the model.

Typed operations

At minimum:

  • emacs.open_scratch
  • emacs.open_file(path)
  • emacs.open_buffer(name) where safe/meaningful
  • org_roam.open_daily(date=today)
  • magit.open_project(project_id)
  • emacs.context for bounded current buffer/file/project metadata

Project resolution

magit.open_project(project_id) must consume a configurable known-project/alias mapping rather than hard-code one machine's paths.

Prefer consuming Zara's canonical Prolog-backed project resolver when that contract exists. Until then, keep any plugin-local compatibility mapping explicitly user-owned under XDG config and structured so it can be replaced by the canonical resolver without changing the public tool shape.

Do not commit operator paths or private project names as defaults.

Org-roam + dictation handoff

open roam daily must support the Zara workflow where opening today's note is immediately followed by enabling the existing canonical Zara voice-dictation flow.

This plugin MUST NOT open the microphone, create a second recorder, or implement a second voice runtime. Instead expose a typed completion/event/result that Zara's canonical hook/advice/runtime can use to request dictation after the note open is acknowledged.

A successful editor-open result alone must never falsely claim dictation started.

Safety

  • no model-controlled arbitrary elisp evaluation surface
  • no shell-string interpolation
  • bounded paths/arguments
  • explicit editor-unavailable/server-unavailable results
  • user config and private paths remain outside Git/Nix store
  • operations return acknowledgement/evidence from the Emacs boundary where possible

Integration

  • zara-desktop (#3) may own generic application launch/focus; this plugin owns Emacs-specific semantic operations.
  • zara-context (#4) may consume bounded Emacs project/file context.
  • Zara core issue #260/hook surface should orchestrate post-action behavior such as dictation without this plugin bypassing runtime policy.
  • zara-coding may consume Magit/project operations without duplicating editor IPC.

TDD / acceptance

  • deterministic fake Emacs server tests are RED first
  • scratch/file/daily/Magit operations are structured
  • project aliases/paths are user-configurable and not hard-coded
  • daily-note action emits/verifies a distinct post-open dictation-request seam rather than owning a microphone
  • editor/server unavailable and failed-action paths are explicit
  • arbitrary elisp/shell injection is impossible through the public tool schema
  • tests require no GUI/network and no real Emacs process
  • README documents Emacs server, Org-roam, project alias, and dictation integration
  • registry validation passes
  • plugin tests pass
  • nix flake check passes
## Plugin `zara-emacs` ## Goal Give Zara a structured Emacs integration for the operator's real note/coding workflow without embedding editor-specific shell strings in Zara core. Initial operator phrases/use cases include: - `open emacs scratch` - `open roam daily` - `open emacs magit <project>` - open/reveal a file or buffer - report current Emacs project/buffer context where explicitly requested Use `emacsclient`/server-supported mechanisms or another bounded documented Emacs IPC boundary; do not depend on arbitrary elisp supplied by the model. ## Typed operations At minimum: - `emacs.open_scratch` - `emacs.open_file(path)` - `emacs.open_buffer(name)` where safe/meaningful - `org_roam.open_daily(date=today)` - `magit.open_project(project_id)` - `emacs.context` for bounded current buffer/file/project metadata ## Project resolution `magit.open_project(project_id)` must consume a configurable known-project/alias mapping rather than hard-code one machine's paths. Prefer consuming Zara's canonical Prolog-backed project resolver when that contract exists. Until then, keep any plugin-local compatibility mapping explicitly user-owned under XDG config and structured so it can be replaced by the canonical resolver without changing the public tool shape. Do not commit operator paths or private project names as defaults. ## Org-roam + dictation handoff `open roam daily` must support the Zara workflow where opening today's note is immediately followed by enabling the existing canonical Zara voice-dictation flow. This plugin MUST NOT open the microphone, create a second recorder, or implement a second voice runtime. Instead expose a typed completion/event/result that Zara's canonical hook/advice/runtime can use to request dictation after the note open is acknowledged. A successful editor-open result alone must never falsely claim dictation started. ## Safety - no model-controlled arbitrary elisp evaluation surface - no shell-string interpolation - bounded paths/arguments - explicit editor-unavailable/server-unavailable results - user config and private paths remain outside Git/Nix store - operations return acknowledgement/evidence from the Emacs boundary where possible ## Integration - `zara-desktop` (#3) may own generic application launch/focus; this plugin owns Emacs-specific semantic operations. - `zara-context` (#4) may consume bounded Emacs project/file context. - Zara core issue #260/hook surface should orchestrate post-action behavior such as dictation without this plugin bypassing runtime policy. - `zara-coding` may consume Magit/project operations without duplicating editor IPC. ## TDD / acceptance - [ ] deterministic fake Emacs server tests are RED first - [ ] scratch/file/daily/Magit operations are structured - [ ] project aliases/paths are user-configurable and not hard-coded - [ ] daily-note action emits/verifies a distinct post-open dictation-request seam rather than owning a microphone - [ ] editor/server unavailable and failed-action paths are explicit - [ ] arbitrary elisp/shell injection is impossible through the public tool schema - [ ] tests require no GUI/network and no real Emacs process - [ ] README documents Emacs server, Org-roam, project alias, and dictation integration - [ ] registry validation passes - [ ] plugin tests pass - [ ] `nix flake check` passes
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/zara-plugins#212
No description provided.