Milestones are in order but have no dates. Each one ends with a release to PyPI and an updated
CONFORMANCE.md.
These changes belong in legaldown-validator (the core package) or in the specification, not
here.
| # | Where | Change | Status |
|---|---|---|---|
| U1 | validator | Keep nested list structure in the model (#14) | Done in validator#61; the renderer nests lists from it (v0.2) |
| U2 | validator | Source positions (line numbers) on sections, blocks, and diagnostics (#27) | Done for the validator's diagnostics in 0.3.0 (validator#85); the CLI prints them. 0.4.0 makes a block's and a list item's line public (Document.line_of, Document.layout()). Still open: the line of a directive within a block, which the renderer's own diagnostics are about (#93) |
| U3 | validator | Public API (#26) for what the renderer imports from submodules, and the validator's own placed markers and template decision | Done. Mostly in 0.3.0 (validator#90): placed_markers and is_template on the result. The rest in 0.4.0: quote and drafting-note content, code content, and the answers-file reader (#93, #88). The reader is on legaldown, the rest in the tooling modules legaldown.syntax and legaldown.grammar. The renderer adopted it and dropped validator_bridge.py. The dependency stays pinned to one minor version, since before 1.0 a minor release may change the API |
| U1b | validator | Parser gaps the renderer inherits. Fixed in validator 0.3.0: list markers (#21), tables (#22, #44), comments and HTML blocks (#23, #59), the signature-block cutoff (#24), empty comments (#28), indented code (#9, #41), empty list items (#46), content after a nested list (#64), nested marker changes (#65), headings in quotes and items (#78), raw-html (#40), hard breaks (#25). Still open: link reference definitions (#92) | Mostly done; adopted in v0.2 (validator 0.3.0). Listed in CONFORMANCE.md |
| U4a | validator | Specification 0.2 (templates, §15) | Done in 0.2.0 |
| U4b | validator | Template assembly with an answers set (§15.7, #30) | Done in validator#55; the renderer uses it (v0.2) |
| U5 | specification | A rendering fixtures corpus: source + style settings → expected plain-text output | Not started. The plain-text writer is designed to be its oracle |
- The full pipeline: parse and validate, build, resolve, write
- All four numbering schemes; list enumeration; paragraph numbering; item and paragraph anchors with designations ("2.1(b)")
- Every directive, with every failure marker
- Template view: conditions,
{{choose:}}, drafting notes, alternatives sharing a number - Title block, attachment placeholders, signature blocks
- A table of contents (
contentsstyle setting) and the final check (--final, §15.9) - Style templates: layering,
extends,--set, validation, and three built-in styles; labels in English, Czech, German, French, Polish, and Slovak textandhtmlwriters; thelegaldown-renderCLI- Golden tests, and a conformance run over the specification's examples and fixtures
- Rendering with an answers set, through the core package's assembly (U4b)
--answers answers.yamlon the CLI- Nested lists, with designations such as "2.1(b)(i)" (U1)
- The validator's CommonMark block model: headings in items and quotes, hard line breaks, and diagnostics with line numbers
- Built on
legaldown-validator0.3.0; the first release on PyPI
- Built on
legaldown-validator0.4.0 and only its public API (legaldown,legaldown.syntax,legaldown.grammar);validator_bridge.pyis removed (U3) - A deprecated validator API fails the tests, so a release never calls what the next minor version removes
- Rendered output is unchanged, except that a comment-only quote past the validator's nesting depth no longer renders an empty paragraph
docxwriter behind the[docx]extra- To decide first: static numbers, or Word-native numbering with
REFfields (ADR 0004)
- Choose the engine (ADR 0004). The leading option is WeasyPrint on the HTML writer; its print stylesheet already exists
- Running headers and footers, and page numbers, from the style's
pagesettings
Includes, attachment contents with per-attachment numbering scopes and cross-scope designations (§13.3, §13.8), amendments, and bilingual rendering. These need file access under a configured document root (§2.3), which should come from the core package first.
- Editing or round-tripping from output. The source is the only document of record.
- A JavaScript port. A browser-side renderer for live preview may come later, as a separate package tested against the same fixtures.