Skip to content

Introduction

Technical documentation for the Templar Obsidian plugin.

The current implementation snapshot is 1.2.0-beta.3: 132 built-in styles, leaf-scoped live try-on, note customization, source synchronization, event-driven style rules and usage indexing, bounded pack import/export, settled Reading-mode print preparation, keyboard-first browsing, three density modes, paged/pageless notes, one fixed cross-view baseline lattice, variable-height rhythm correction, ruled-line alignment diagnostics, recovery-backed protected writes, and migration-aware compatibility handling. DEVELOPER_REFERENCE.md is the handoff document for the complete feature map, source map, persistence rules, test/release runbook, and known limitations.

  • DEVELOPER_REFERENCE.md — current-state handoff: every user-facing feature, command and setting, source module, persistence boundary, lifecycle, QA gate, release procedure, and known limitation.
  • ARCHITECTURE.md — design goals, runtime data flow, service responsibilities, and where to add new features.
  • TEMPLATE_SPEC.md — the Templar v1 template schema, field constraints, baseline behavior, and the virtual CSS vocabulary.
  • PAGED_LAYOUT.md — the fixed-canvas invariant, whole-page scaling, page-break fitting, and mobile behavior for paged notes.
  • SECURITY.md — trust boundaries, CSS validation model, privacy, and denial-of-service considerations.
  • MAINTAINER_GUIDE.md — test layout, manual smoke tests, the mobile release gate, schema change recipe, and release steps.
  • REPOSITORY_GOVERNANCE.md — observed GitHub branch, security-update, and release-immutability settings.
  • PERFORMANCE.md — benchmark fixtures and coverage commands for renderer, catalog, vault matching, and pagination work.
  • ASSET_OPTIMIZATION.md — lossless screenshot conversion record and before/after sizes.
  • releases/ — versioned GitHub release notes, including validation status and known beta limitations.
  • releases/1.2.0-beta.2.md — corrective beta for ruled-line alignment across text and rendered elements, with disclosed mobile limitations.
  • releases/1.2.0-beta.3.md — fixed-lattice baseline controller, composite-text diagnostics, and packaged desktop validation.
  • releases/1.2.0-beta.1.md — beta compatibility target with packaged desktop/recovery evidence and disclosed mobile limitations.
  • releases/1.2.0-alpha.5.md — published remediation validation candidate for recovery, migration, automatic-write safety, and CSS trust boundaries.
  • releases/1.2.0-alpha.4.md — immutable validation-tag notes; the workflow did not publish artifacts, so alpha.5 supersedes it as the package under test.
  • releases/1.2.0-alpha.3.md — immutable validation-tag notes; the workflow did not publish artifacts, so alpha.4 supersedes it as the package under test.
  • releases/1.2.0-alpha.2.md — historical renderer-rhythm, paper-pattern, isolation, and security audit release notes.
  • releases/1.2.0-alpha.1.md — UX expansion prerelease notes and historical test evidence.

For a new agent or contributor, read DEVELOPER_REFERENCE.md first for the current snapshot and source map, then: ARCHITECTURE.mdTEMPLATE_SPEC.mdPAGED_LAYOUT.mdSECURITY.mdMAINTAINER_GUIDE.md. The root AGENTS.md contains non-negotiable invariants that apply before editing.

  • The root README.md is the concise user-facing introduction and manual-install guide.
  • TEMPLATE_SPEC.md is authoritative for v1 YAML names, defaults, ranges, migration semantics, and virtual CSS.
  • ARCHITECTURE.md is authoritative for service ownership, renderer data flow, and lifecycle boundaries.
  • PAGED_LAYOUT.md is authoritative for fixed-canvas geometry, scaling, and page fitting.
  • SECURITY.md is authoritative for imported YAML/CSS trust boundaries and dependency/runtime restrictions.
  • MAINTAINER_GUIDE.md is the practical smoke-test and release checklist; the developer reference summarizes it for handoff.
  • releases/<version>.md and CHANGELOG.md are historical. Keep prior release notes immutable and add new entries for new behavior.

When docs and a current test disagree, investigate the implementation and update the relevant contract before handing off. Do not paper over a failing test by changing documentation alone.