Markdown Converter
Agent skill for markdown-converter
Check these tasks after every major change:
Sign in to like and favorite skills
Check these tasks after every major change:
npm run typechecknpm run lintnpm run test:runThe long-term, high-level plan for this project:
'Matrixes' are the top level concept of the app, the elemental building block everything else is based on.
Matrixes represent an ordered outline of heterogeneous elements. Elements can be any kind of unique addressable entity. For instance, elements can be data rows or references to child matrixes. They can potentially be more kinds of entities in the future.
Individual matrixes have two component tables:
All matrices share a third table:
Matrixes can contain other matrixes. Child matrixes are anchored at a specific element position of the parent matrix.
There is always a root matrix that can never be deleted. All other matrixes are children of the root matrix or other matrixes.
Maintains the global ordering of all elements across all matrixes.
Uses Lexorank with
-terminated, variable-length segments (no length headers):0x00
0x01..0xFF (never 0x00).0x00.0x00; a child appends another terminated segment. Parents always sort before descendants.Subtree range query: for a node key
P, the subtree is [P, nextPrefix(P)), where nextPrefix(P) is P with its final 0x00 incremented to 0x01. If no upper bound exists (rare edge), the subtree extends to table end.
Fractional indexing / insert-between: generate a child segment strictly between two sibling segments. If no room at current length, extend the segment by appending bytes (no ancestor changes required).
Reordering semantics: large reordering operations (including reparenting that rewrites descendant keys) are acceptable by design.
Benefits of this encoding:
Some example access patterns for the ordering table:
A metadata table with one row for every ancestor-descendant relationship in the matrix, including the identity relationship between an element and itself.
The closure table is the source of truth for the matrix's outline structure and the depth of each element. However, it must match up with the Lexorank structure in the ordering table, when it comes to ancestor/descendant/sibling relationships. All operations that modify either table should be carefully tested to ensure this invariant, and should use transactions.
Some example access patterns over the closure table:
'Faces' are the views and interaction surfaces for matrixes and their elements.
Faces update optimistically with user input, and propagate their updates to the underlying elements asynchronously. If updates fail, faces will retry, and get user input if intervention is needed.
Faces always interact with matrixes somehow but don't necessarily correspond to any set elements. They can represent: