- High-Level System View
- Pipeline Modules
- Remark Plugin Layer
- Helper & Legacy Processors
- Shared Utilities
The core system orchestrates input sources (CLI, web, API) through the shared three-phase pipeline and remark stack.
graph LR
subgraph Inputs
CLI[CLI]
INTERACTIVE[Interactive CLI]
WEB[Web Interface]
API[Programmatic API]
end
subgraph Core
P1[Phase 1\nContext Builder]
P2[Phase 2\nRemark Processor]
P3[Phase 3\nFormat Generator]
end
subgraph Outputs
MD[Processed Markdown]
HTML[HTML]
PDF[PDF]
META[Metadata Exports]
end
CLI --> P1
INTERACTIVE --> P1
WEB --> P1
API --> P1
P1 --> P2 --> P3
P3 --> MD
P3 --> HTML
P3 --> PDF
P3 --> META
Each entry point builds a ProcessingContext, executes the remark pipeline
once, then hands the cached AST to format generators. This design keeps
behaviour consistent and avoids repeated AST work.
Located in src/core/pipeline/:
context-builder.ts- Phase 1 implementation (buildProcessingContext,mergeMetadata,validateProcessingContext)format-generator.ts- Phase 3 helpers (generateAllFormats,processAndGenerateFormats) plus HTML/PDF/Markdown/metadata orchestrationindex.ts- Re-exports pipeline primitives forsrc/cli, integrations and future API wrappers
The pipeline depends on:
src/core/parsers/*for YAML and force-command parsingsrc/extensions/remark/legal-markdown-processor.tsfor Phase 2 executionsrc/extensions/generators/*for HTML/PDF renderingsrc/utils/*for file operations, logging and archive helpers
Remark functionality resides under src/plugins/remark/ and is documented in
docs/architecture/04_remark_integration.md. Key elements:
- Plugin implementations (
imports.ts,mixins.ts,template-fields.ts,headers.ts,legal-headers-parser.ts,field-tracking.ts,clauses.ts,dates.ts, etc.) operate on the mdast tree plugin-metadata-registry.tsandplugin-order-validator.tsdefine and enforce execution order constraintstypes.tsexposes metadata and validator interfaces used by both the remark processor and tests
Phase 2 (processLegalMarkdownWithRemark) wires these pieces together and emits
LegalMarkdownProcessorResult objects consumed by Phase 3.
The repo still ships helper modules originally designed for Ruby parity:
src/core/helpers/*- Date, number and string helpers accessible from template fieldssrc/core/processors/*- Legacy processors kept for migration compatibility; the three-phase pipeline now supersedes them but selected utilities remain reusable (e.g. clause evaluation logic shared by the remark plugin)src/core/exporters/metadata-exporter.ts- Utility for metadata serialization
A full inventory and retirement plan lives in
plans/2026-03-03-phase2-phase3-span-refactor-plan.md.
Supporting modules include:
src/utils/logger.ts,src/utils/archive-manager.ts,src/utils/index.tsfor logging, archiving and file helperssrc/core/utils/template-variable-replacer.ts- resolves{{ variable.path }}placeholders against metadata objects (simple dot-path traversal)src/constants/index.tsfor resolved paths shared by CLI/web buildssrc/types/index.tsdefiningLegalMarkdownOptions,ProcessingResultand related interfaces consumed across the stacksrc/config/index.ts- cosmiconfig-based project config loader; merges.legalmdrc/legal-markdown.config.*with env-var overridessrc/extensions/tracking/field-span.ts-fieldSpan(name, content, kind)helper that produces compound CSS class spans used by the field-tracking plugin
These utilities are imported by both CLI services and the pipeline to keep behaviour uniform regardless of hosting environment.