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 <RT-article>, <RT-title>, <RT-constraint> in hyphen form. RT-constraint doesn't exist in the engine under either spelling.
+
+-> remind me later we will get back to this.
+
+<RT·book> 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 <RT·book> 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 <pre> blocks) to get it rendering before we touch structure?
+
+-> mechanical first pass, with sections
projects / TM-2026 / commitdiff