From: Thomas Walker Lynch Date: Fri, 7 Aug 2026 10:37:09 +0000 (+0000) Subject: . X-Git-Url: https://git.reasoningtechnology.com/%27%20%20%20full_path%20%20%20%27?a=commitdiff_plain;h=1318c626cc53a60ecd176a7c291600151693b608;p=TM-2026 . --- diff --git a/document/todo.txt b/document/todo.txt index 5e09e0e..c3f5209 100644 --- a/document/todo.txt +++ b/document/todo.txt @@ -2,3 +2,62 @@ when making a skeleton from Harmony, set skeleton docs and other files not to be edited to read only +2026-08-07 09:55:28 Z + +step counts make should set the default for the step count scope splitability, each step count scope should be able to have its own setting. + +need to be able to make a table of the step count scope names for any counter, not only the section counter + +The RT·name is apparently rendering, though it is a meta property of its immediate parent. It shouldn't do that. However, we are missing support for reading it with the read command apparently. Also, a split step scope has children spread across continuations, apparently the full child list is not currently being iterated through to find the name property. This needs to be fixed. I think we need a virtual node interface, perhaps a class to make a continued node look like a single node to the caller. + +As Claude summarizes the RT·name issue: + + On continuations, the specific shape of it for your todo: RT.Splitter['rt·counter·step'] distributes childNodes between fragments without copying, and counter.js skips name reading when continuation="true". Because paginate_0 runs before the counter phase, the cut has already happened by the time names are read. Worth noting the consequence extends past the name itself — RT·counter·snapshot clones the machine after the name is set on enter, so a snapshot in the head fragment would capture a nameless count even if the name were correctly found in a later one. The gather across continuations has to complete before any fragment's snapshot fires. + + +----- + +--- temp: + +README.md is stale — it advertises , , in hyphen form. RT-constraint doesn't exist in the engine under either spelling. + +-> remind me later we will get back to this. + + is documented but unimplemented. The user manual lists it as a manuscript type alongside article and memo; nothing in the engine references it. For a 4-volume work this is probably the single most consequential gap. + +-> ignore + +User manual omissions: RT·term-em and RT·neologism-em (both live in term.js, and the book uses term-em 5 times), RT·noop, RT·e, RT·label, RT·tuple/RT·tuple-meta, RT·vector/RT·vector-meta, and the splitable attribute. + +-> I am surprised they are not in there, apparently they got dropped, remind me later we will get back to this. + + +term.js violates its own migration note. The design manual's migration notes say to drop dual-spelling selectors in favor of the canonical form; term.js uses the all-lowercase form exclusively ('rt·term, rt·term-em, …'), as does footnote.js. Worth a consistency sweep. + +-> legacy code, remind me later we will circle back to this. + +todo.txt triage. Still open and relevant to the book: paginate's ad-hoc page numbering vs. the counters; unifying footnote/endnote under Note with path keys; the Count/Note capitalization and space-vs-dot key path convention; justified text inserting spaces into inline RT blocks; table types. The theme-name/manifest mismatch item at the top appears already fixed — all three themes' meta.name match their manifest keys and filenames. Close it. + +-> we will examine this again later, some of it will be taken care of with the update. + +footnote.js is a validation stub (processing lives in the paginator). Fine, but the user manual presents it as a peer of endnote. + +-> not ideal, put it on the later list if you think we should address it + +Q + +The title. The file is TM-2026.html, titled "Computational Naturalism", and there's a chapter called "Or, does it go the other way? Computational Naturalism". You described this as volume 1 of Tom's Turing Complete Computer Architecture. Is "Computational Naturalism" the volume-1 title, a working title, or a leftover from a reorganization? + +-> Yep, the first edition was called "volume 1", but now it has a title. Let us come back to this later. + +RT·chapter — implement or convert? Given is also unimplemented and you have three more volumes coming, I'd lean toward building RT·book and RT·chapter properly in the engine rather than flattening chapters into depth-0 sections. That's more work now and much less later. But it's your call, and the section route gets a readable book faster. + +-> Ah yes, convert this now. We want to use the new section approach. + +Lists and blockquotes. 29 raw ones in the book. Add RT elements, or accept raw HTML as legitimate for these? + +-> let us get to this after the sections are fixed. + +Order of operations. Do you want me to start with the engine gaps (so the migration has a target), or with a mechanical first pass on the book (theme-selector, copyright, the comment, the 
 blocks) to get it rendering before we touch structure?
+
+-> mechanical first pass, with sections