The engine does the work behind every command. It reads the files once, and builds a model. Every check, fix, and page comes from that model, so they always agree.
flowchart LR config[Configuration] --> scan[Scan] scan --> parse[Parse] parse --> model[Model] model --> fix[Fix] model --> site[Site builder] fix --> wrap[Prose unwrap]
Parts
- Configurationmodule
Reads idk-plans.config.json and fills in defaults. It also holds the JSON schema that editors use to check the file.
● 100% (3/3) - Scanmodule
Finds the Markdown files that the configuration includes, and skips the files that it excludes.
● 100% (2/2) - Parsemodule
Reads one Markdown file into facts: frontmatter, tasks, links, diagrams, and generated blocks. It does not look at other files.
● 100% (3/3) - Modelmodule
Joins the parsed files into nodes and trees, calculates every rollup, and finds problems that need more than one file.
● 100% (3/3) - Fixmodule
Writes the parts of each file that the tool owns: generated blocks, link paths, task marks, aliases, and tree tags.
● 100% (4/4) - Prose unwrapmodule
Joins prose that is wrapped by hand into one line for each paragraph, so that viewers which show line breaks do not break sentences.
● 100% (2/2) · 1 deferred - Site buildermodule
Builds a static website from the model, with diagrams that link to pages, a sidebar for each tree, search, and a list of open tasks.
◐ 55% (5/9)
How it works
src/index.js is the public API. loadProject runs configuration, scan, parse, and model, in that order. check adds two checks that need the fix step: stale-generated and hard-wrap. fix writes each file that changes.
The engine is plain ES modules for Node.js, with no build step. It has three dependencies: yaml, picomatch, and marked (only for the site).
Why it works this way
check finds stale generated blocks by running the fix step and comparing the result. So check and fix can not disagree about what is current.
Tasks
- Keep tests for each part, with
node --test