Changeblog

Wissensnetz / Invisible Creatures Bridge Page Added a new bridge page: “Invisible Creatures.” Defined “heavenly” as non-earthly or unseen, not as morally holy. Kept Scripture primary and preserved silence where the text is silent. Established a strict Layer-2 method: record what appears, what is said, and what is done. No systems assumed. No hierarchies imposed. Introduced “messenger” language as a lexical starting point. Showed overlap between human and non-human messengers without collapsing them into a single class. Built the page as a true Wissensnetz node: Scripture pages remain stable; bridge pages provide orientation; interpretive systems are deferred as labeled overlays. Expanded footnotes beyond simple links. Footnotes now function as micro-bridge nodes with scope notes, short body text, and routing. Added a Lucifer (Isaiah 14:12) footnote. Acknowledged the common association without adopting it. Located the passage in its textual context and routed readers to the Invisible Creatures bridge page. Confirmed that multiple independent footnotes may point to the same bridge page with customized wording per verse. Result: more entry points, less coercion, and clearer separation of text, orientation, and interpretation.

Today we fixed a real drift problem: moving pages broke my Study Index because the links were generated dynamically and depended on old paths. As I moved key pages (such as Zechariah) into /disambiguation, the index began to lose entries. Instead of patching it with more hard-coded link rules, we took the smarter path. We added a simple PAGE_META block to pages (page_type + title), letting each page declare what it is in plain sight, like a label on the file. Then we rewrote /studies.php to scan the file system directly and build the Study Index from pages that opt in. It reads PAGE_META, filters by whitelisted folders, and shows the title with the page_type. No database dependency, no disambiguation chain, and no more whack-a-mole when files move.

We also normalized navigation by copying the Zechariah disambiguation page into /disambiguation/zechariah.php and then mass-correcting all internal PHP links from /bios/zechariah.php to the new canonical location using grep + sed. Finally, the zechariah footnote link_url was updated in the footnotes table so the rendered footnote now points directly to the new disambiguation page.

Today we cleaned up the Zechariah disambiguation page and finally got it under control. The old long scripture dump was not helping readers; it was mostly list noise and “name only” mentions that cannot be reliably disambiguated. Instead of deleting blindly, we triaged each reference, kept only what could be identified by patronymic, role, or clear context, and dropped what was out of scope for this project. We added new, proper disambiguation entries and created real stub pages for newly identified Zechariahs. That included Zechariah son of Meshelemiah (porter / gatekeeper), Zechariah in the days of Uzziah (understanding in the vision of God), Zechariah son of Bebai (Ezra return context), and Zechariah son of Jonathan (Nehemiah procession / trumpets). Each stub follows the canonical bio-page pattern and provides clean scripture anchors with no speculation. We also tightened the Zechariah footnote attachments in the database. Roster-only verses were detached so they stop throwing footnote markers in random name lists. The remaining markers now form a smaller, high-signal set that actually supports the disambiguation work. A new “name variants” note was added (Zachariah/Zacharias/Zacarías/Zecarias), with a clear statement that no alternate-spelling search has been performed yet.

2026-01-24 Progress note: chapter navigation is now live. I added left and right arrow buttons at the bottom of chapter.php. This fixes a real user-flow problem. Before, the reader had to scroll back to the top, open the hamburger menu, and then hunt for the next chapter link. That rhythm was a friction point. Now the reader can move forward or backward without breaking stride. The logic is database-driven (no hard-coded chapter counts). If you reach the end of a book, the next arrow jumps to the first chapter of the next book. If you are at the beginning of a book, the previous arrow jumps to the last chapter of the prior book. When no previous chapter exists, the left arrow is disabled. We also clarified routing: chapter.php without coordinates immediately redirects to the chapter selector, keeping the scripture renderer clean and canonical.

Added a new P0 security task: integrate Project Honey Pot into the contact/message system. Verified my account, generated an http:BL access key, and confirmed the key is working. Stored the key privately in /private/api_keys.php, following the existing API key pattern. First real-world spam submission was used as a test case. Looked up the sender IP in Project Honey Pot and submitted a comment report successfully. This confirms I can contribute real spam data upstream while I continue hardening the message pipeline. Next work will focus on practical anti-spam defenses (honeypot field, IP throttling, and optional automated http:BL lookup).

Added and completed 38_zechariah.php as a full “book profile” page for Zechariah (#38). This is not a commentary and not a bridge page. It is a separate, orthogonal page role: a structured book-level overview that stays close to the text’s own internal markers (dates, named persons, section seams, repeated phrases, and explicit silences). The intent is orientation and reference, not interpretation or camp argumentation. This page now serves as the canonical exemplar for the “text profile” role. It establishes a repeatable template for future book profiles: clear sectioning, plain-reader language, minimal assumptions, and clean reference handling (linking where appropriate without turning the page into a link farm). Going forward, other book-profile pages can follow this model to keep the project consistent, disciplined, and scalable.

Progress note: the new contact/message system is now live and receiving traffic. A real outside user submitted a message through the form, and it was captured directly into the site database. No email system was involved. The admin view shows full message details (sender, subject, timestamp, and IP), proving the end-to-end pipeline works. The first captured message was obvious spam ("Meredith Doe" + Gmail + SEO pitch), which is actually a good sign. It means the system is public-facing and working under real-world conditions. In plain terms: the bait is in the water, and we caught a fish — it just happened to be junk mail. Next step has been promoted to P0: anti-spam hardening for the contact system. Plan is to add a honeypot field (server-side enforced), basic IP throttling, and optionally Project Honey Pot / http:BL integration later. Goal is simple: reduce spam, protect the database, and keep admin time focused on real messages.

Today I formalized a new orthogonal page role: Text Profiles. This keeps book-level structure and metadata out of bios and bridge pages. I created and saved the domain inventory file: /text_profiles/TEXT_PROFILE_DOMAIN_INVENTORY.md This inventory defines the allowed observation domains (attribution, outline, dates, addressees, places, formulae, silences, etc.), without forcing uniform content for every book. I began /text_profiles/38_zechariah.php as the first real Text Profile instance for book #38. This file will be knowledge-dense, but must remain within the Text Profile scope (text-first, non-interpretive). I also adopted an explicit AUTHOR NOTES policy for draft, replaceable scaffolding, so early wording is not mistaken for settled content. Key constraint reinforced: canonical does not mean sterile. Canonical means role-correct, structured, and safe to evolve without scope drift.

Recorded a future enhancement to improve index paper efficiency without affecting index correctness or report pagination. Identified that naive left-to-right wrapping breaks conventional index reading patterns and should not be used. Committed a P2 backlog item to explore an optional CSS-based (tableless) compact index layout that preserves column-major reading order (top-to-bottom, then left-to-right). Explicitly scoped the item as presentation-only, with no impact on index semantics, addressing, or report body pagination. This should save paper.