Provenance: igem-puzzle-v0.2.html

Plain CSS. Visual design choices, not a programming technique — nothing to cite.

No textbook citation applies here.

Page structure and the puzzle's own content (clue setup text, panel labels). Ordinary HTML — nothing to cite.

No textbook citation applies here.

Plain data — the puzzle's own vocabulary and clue text. Content, not a technique — nothing to cite.

No textbook citation applies here.

Creating elements and appending them in a loop is the basic DOM-building pattern.

📖 The Modern JavaScript Tutorial (javascript.info) — "Document" chapter, specifically "Modifying the document" (createElement / append).

Same DOM-construction pattern, applied to form controls.

📖 The Modern JavaScript Tutorial — "Forms, controls" chapter (building/populating <select> elements).

Nested loops building table rows/cells from arrays of data.

📖 The Modern JavaScript Tutorial — "Document" chapter (DOM construction); the nested-array iteration itself is plain Array#forEach, covered in any JS reference, including MDN's Array docs.

Spreading a NodeList into a real array (`[...document.querySelectorAll(...)]`) so Array methods like .map work on it.

📖 You Don't Know JS Yet — "ES6 & Beyond" chapter, on the spread operator.

Straightforward array iteration and comparison — no particular technique to cite beyond ordinary Array#forEach usage.

No textbook citation applies here.

This is Prolog source, not JavaScript. The permutation + nth1 "generate, then filter" technique is the standard way zebra-style puzzles are solved in Prolog — it's not from any of the three JS textbooks, since it's a Prolog-specific idiom.

📖 Not a JS textbook match — see instead any introductory Prolog resource, e.g. "Learn Prolog Now!" (the classic zebra-puzzle chapter) or SWI-Prolog's own documentation examples.

Splitting a string into lines and searching an array with .findIndex — plain array/string methods.

📖 You Don't Know JS Yet — "Types & Grammar" covers String/Array method usage in this style; no deeper technique involved.

Hand-written mapping of "which clue reveals which grid cell" plus the plain-English reasoning for each clue. Content, not a technique — nothing to cite.

No textbook citation applies here.

A small recursive/iterative walk over a linked, cons-style structure (Prolog's "." list representation) — the same shape as walking any singly-linked list.

📖 SICP JS — the sections on processing lists recursively (Chapter 2, "Building Abstractions with Data"); the general technique of walking a cons-style structure one link at a time is exactly what's taught there.

The consult/query/answer calls follow Tau Prolog's own documented usage pattern. The only genuinely new part is filtering thread.debugger_states for clue-numbered goals and pairing each with its grounded call — ordinary array filtering/mapping over data Tau Prolog already hands back.

📖 No textbook needed for the filtering itself (plain Array#forEach/Array#push); the API usage itself mirrors Tau Prolog's own README, not a textbook.

Rather than incrementally mutating a "known so far" object as the visitor steps forward/back, this recomputes it fresh from step 0 every time. That sidesteps an entire class of bugs where stepping backward would need to carefully undo mutations.

📖 This "derive state fresh rather than mutate it" habit is a general functional-programming idiom rather than one specific textbook passage — SICP (JS or otherwise) touches on the hazards of mutable state, but there isn't a single matching section to point to.

More DOM construction/update — same pattern as renderClues/renderGrid above.

📖 The Modern JavaScript Tutorial — "Document" chapter, again (createElement, textContent, classList).

addEventListener-based event handling, plus a start/stop toggle built on setInterval/clearInterval for the "Play" button.

📖 The Modern JavaScript Tutorial — "Introduction to browser events" chapter for the event handling; "Scheduling: setTimeout and setInterval" for the play/pause timer.