docs: layout comments name all four shipped layout types; #150 changelog pointer and test docstring corrected
CI / verify (push) Successful in 1m39s
Release / release (push) Successful in 37s

Files changed:
- CHANGES.md
- VERSION
- tools/chemenu/commands/new_page.py
- tools/chemenu/tests/test_new_page.py
- tools/chemenu/type_resolver.py
This commit is contained in:
torben committed 2026-09-26 23:05:47 +02:00
1 parent 6c0ebcc4f0
commit dd885db625
5 files changed
+20 -9

No files matched your search

+12 -3
View File
@@ -59,7 +59,7 @@ concern - readable here, never shipped as something to parse.
--- ---
## 7.1.0-beta.30 - 2026-09-26 - new: concept/source record notes name their layout-computed subdirectory; source usage names its required fields (Gitea #150) ## 7.1.0-beta.31 - 2026-09-26 - new_page/type_resolver comments no longer claim only entities declare a layout:
**Author:** Torben Nehmer **Author:** Torben Nehmer
@@ -99,18 +99,27 @@ concern - readable here, never shipped as something to parse.
- gates.md and a run_budget comment name kb pages by title, not by a path that moved - gates.md and a run_budget comment name kb pages by title, not by a path that moved
- cli.py: removed a stale duplicate help-patch line outside the typer._click fallback's try (Gitea #148) - cli.py: removed a stale duplicate help-patch line outside the typer._click fallback's try (Gitea #148)
- new: concept/source record notes name their layout-computed subdirectory; source usage names its required fields (Gitea #150) - new: concept/source record notes name their layout-computed subdirectory; source usage names its required fields (Gitea #150)
- new_page/type_resolver comments no longer claim only entities declare a layout:
<!-- /wikitool:bumps --> <!-- /wikitool:bumps -->
### new_page/type_resolver comments no longer claim only entities declare a layout:
Two code comments - `new_page.py`'s module docstring and `TypeResolver.get_layout`'s - still said
subtype-driven placement applied to "currently just entities", the same stale assumption behind
the `new` record's flat `concept`/`source` paths. They now name the four shipped type-specs that
declare a `layout:`. A test docstring that claimed to run `new source`'s `usage` line verbatim
now says what the test does: it passes the fields that line names. Comments only.
### new: concept/source record notes name their layout-computed subdirectory; source usage names its required fields (Gitea #150) ### new: concept/source record notes name their layout-computed subdirectory; source usage names its required fields (Gitea #150)
The `new`-command's `cli_contract` record promised `kb/concepts/<Name>.md` and `new`'s `cli_contract` record promised `kb/concepts/<Name>.md` and
`kb/sources/Source - <Name>.md` for the `concept` and `source` variants - flat, with no `kb/sources/Source - <Name>.md` for the `concept` and `source` variants - flat, with no
subdirectory. Both type-specs have carried a `layout:` for a while (`concept_type`/`source_type` subdirectory. Both type-specs have carried a `layout:` for a while (`concept_type`/`source_type`
picks the area, same rule an entity or a project already follows), so the actual path is picks the area, same rule an entity or a project already follows), so the actual path is
`kb/concepts/<subdir>/<Name>.md` and `kb/sources/<subdir>/Source - <Name>.md`. Nothing wrote a `kb/concepts/<subdir>/<Name>.md` and `kb/sources/<subdir>/Source - <Name>.md`. Nothing wrote a
page to the wrong place - `new` computes the path itself - but the record is exactly what an page to the wrong place - `new` computes the path itself - but the record is exactly what an
agent reads to find one afterwards, and it was wrong: `instructions/gates.md` named two concept agent reads to find one afterwards, and it was wrong: `instructions/gates.md` named two concept
pages by their old flat path (fixed above) with the record itself as the plausible source of that pages by their old flat path (fixed in the gates.md entry further down) with the record itself as the plausible source of that
assumption. Both notes now name the subdirectory and where it comes from; `comparison`'s note was assumption. Both notes now name the subdirectory and where it comes from; `comparison`'s note was
checked against `types/comparison.md` and left alone; it genuinely has no `layout:`. checked against `types/comparison.md` and left alone; it genuinely has no `layout:`.
+1 -1
View File
@@ -1 +1 @@
7.1.0-beta.30 7.1.0-beta.31
+2 -2
View File
@@ -15,8 +15,8 @@ A schema `default:` is materialized only for a field the schema also lists
in `required:` - an optional field's default is a reader-side assumption in `required:` - an optional field's default is a reader-side assumption
(what a missing field means), and writing it into every scaffolded page (what a missing field means), and writing it into every scaffolded page
would turn that assumption into a stated claim instead (Gitea #109). would turn that assumption into a stated claim instead (Gitea #109).
Directory placement for subtype-driven types (currently just entities) also Directory placement for subtype-driven types (in the shipped specs: entity,
comes from the type-spec, via its `layout:` frontmatter (see concept, source and project) also comes from the type-spec, via its `layout:` frontmatter (see
`TypeResolver.get_layout`) - not a hand-maintained Python dict. `TypeResolver.get_layout`) - not a hand-maintained Python dict.
""" """
from __future__ import annotations from __future__ import annotations
+3 -2
View File
@@ -775,8 +775,9 @@ def test_new_concept_path_matches_its_record_note(monkeypatch, kb_dir):
def test_new_source_path_matches_its_record_note_and_its_usage_is_runnable(monkeypatch, kb_dir): def test_new_source_path_matches_its_record_note_and_its_usage_is_runnable(monkeypatch, kb_dir):
"""Also #150's second finding: the `usage` line itself omitted """Also #150's second finding: the `usage` line itself omitted
`source_type`/`fidelity`/`authority` and could never succeed as written. `source_type`/`fidelity`/`authority` and could never succeed as written.
Running the corrected `usage` verbatim (substituting `<Name>`/`<t>`/etc.) The call below passes exactly the fields the corrected `usage` names,
is the test that it now can.""" with valid values for its placeholders - it does not parse the `usage`
string itself."""
monkeypatch.setenv("WIKI_AUTHOR", "Torben") monkeypatch.setenv("WIKI_AUTHOR", "Torben")
name = "gateway.example.net" name = "gateway.example.net"
_fixture_raw_file(monkeypatch, kb_dir, "raw/notes/gateway.example.net.md") _fixture_raw_file(monkeypatch, kb_dir, "raw/notes/gateway.example.net.md")
+2 -1
View File
@@ -306,7 +306,8 @@ class TypeResolver:
need a hand-maintained `entity_type -> subdirectory` Python dict. need a hand-maintained `entity_type -> subdirectory` Python dict.
Only types with subtype-driven directory placement declare a Only types with subtype-driven directory placement declare a
`layout:` (currently just `types/entity.md`); returns None for types `layout:` (in the shipped specs: `types/entity.md`, `types/concept.md`,
`types/source.md`, `types/project.md`); returns None for types
that don't (e.g. `types/comparison.md`, which has a single flat that don't (e.g. `types/comparison.md`, which has a single flat
directory regardless of subtype). directory regardless of subtype).