Attached reader

The connected notebook / LaTeX edition

Upcoming website changes

Liam McGrath · Planned work and the change-request database plan

Requests are grouped by the date they were made; finished items move to the change log.

Typesetting equations locally…

Planned work, by the date it was requested. Each date lists the requested changes and how they are planned to be implemented. Finished items move to the Change Log.

1 25 October 2026: open items

1.1 Requested changes

  • Connect a live serverless insert endpoint (Cloudflare Worker + D1 or Supabase) to Workbench/index.html so phone submissions write directly without a GitHub Mobile commit step.

  • Run the next queued Workbench studies: First to Four basketball leverage analysis and Primer-style replicator simulations.

1.2 Planned implementation

  • Point the Workbench forms at the Worker URL once deployed; the browser payload already matches the four SQLite tables in records/workbench/workbench.db.

2 18 October 2026: open items

2.1 Requested changes

  • A redacted tempo-route map, once a copy without the start point exists.

  • The remaining Health destinations: Mentality, Information Consumption, Analytics, and Struggles & Setbacks.

2.2 Planned implementation

  • Redact the Tempo1 screenshot the way the I1 map was redacted, then publish it on the running dashboard.

3 10 October 2026: open items

3.1 Requested changes

  • Confirm where Old Classics and My Hero Academia belong; they are under NanoFtheAbove for now.

  • Dynamic programming, trie and LeetCode Hard solutions, once they are in leetcode_problems.

3.2 Planned implementation

  • Moving a lyric folder is a one-line change to RAP_PAGES in site_content/catalog.py. A folder not yet placed appears under Future Projects, so nothing is dropped.

  • New solutions appear on their pages at the next build: dp or memo tables go to Dynamic Programming, and titles LeetCode rates Hard go to Hard Problems once they are added to HARD_TITLES.

4 Planned next: Series Hub subsections

4.1 Requested changes

  • Updates to each Series Hub destination: Videos, Analytics, History, Records and Creator Petition. Details will come with that prompt.

  • New basketball data for analysis in the style of a JimmyHighRoller video.

4.2 Planned implementation

  • Extend the series data contract before adding new records, so earlier analysis stays reproducible.

5 4 October 2026: open items

5.1 Requested changes

  • Owen’s Creator Hub and Stock Monitoring links, once they are live.

  • Simulations in the style of Primer this month, as internal branches of the Simulations destination.

  • UFC and NBA predictions recorded against outcomes.

  • Swimming set times once a water-safe watch is bought: \(5 \times 50\) m, \(10 \times 50\) m and \(5 \times 100\) m within set windows.

  • Science & Engineering notes from the Gemini chat log; the contribution guide on the Mental Map explains the steps.

  • A database for change requests, once email requests become too many.

5.2 Planned implementation

  • Owen’s rows already exist and only need a URL each in creators.py.

  • The two predictions pages already exist; each needs a log of predictions made before events and the outcomes after.

  • The database plan follows below.

6 Still open from 27 September 2026

6.1 Requested changes

  • Camille’s creator section, once her site URL and written consent are in.

  • HTTPS on the custom domain: GitHub Pages still presents a certificate for the wrong name.

6.2 Planned implementation

  • The HTTPS fix needs the repository owner in GitHub Pages settings: remove and re-add the custom domain, wait for the certificate, then turn on Enforce HTTPS.

7 Database integration plan for change requests

Today, the Request a change form on the Mental Map drafts an email. When requests outgrow email, the same form can post to a small database instead. GitHub Pages only serves static files, so the database needs a separate service. The steps:

  1. Choose a service. Either a hosted Postgres database with row-level security (for example Supabase), or a small serverless endpoint (for example a Cloudflare Worker) in front of a database (for example Cloudflare D1). The endpoint option keeps every secret off the website.

  2. Create the table. Columns: id (generated), name (text, required, up to 120 characters), requested_on (date, required), section, subsection and subsubsection (text, using the site’s paths such as Science-and-Engineering/Physics/Optics), content (text, required, up to 20,000 characters), status (new, accepted, merged or declined, default new), reviewer_note (text) and created_at (timestamp).

  3. Validate on the server. Accept only paths that exist in the site outline (assets/data/atlas-schema.js), require the subsubsection to sit inside the chosen subsection and section, enforce the lengths and strip control characters. Never trust the browser’s checks alone.

  4. Lock down access. The public may insert rows but never read, edit or delete them. With Supabase this is an insert-only policy for the anonymous role; with a Worker, the Worker holds the only key.

  5. Stop spam. Add a bot check (for example Cloudflare Turnstile), a hidden honeypot field and a rate limit per address.

  6. Handle personal data. Names are personal data: add a short privacy note to the form, keep requests only as long as needed and delete one on request.

  7. Switch the form. In request-change.js, send the same fields as JSON to the endpoint, show a confirmation and keep the email draft as the fallback when the service is unavailable.

  8. Review requests. Sort by status, export accepted requests, copy the content into mental_map.tex under the right destination, then mark them merged and list them in the Change Log.

  9. Test. Use a separate staging table, add tests for the validation rules, and try a malformed and an oversized request before going live.

Download original LaTeX source

Back to the top ↑