Back to buildsBUILD RECORD

The Tesseract Memory / Software notebook / 2026

A portfolio with its own publishing system.

The Tesseract Memory connects project stories with technical notes, with releases tied to the exact revision reviewed and editing tools kept outside the public site.

THE WORK

The project.

The Tesseract Memory gives me one place to explain what I've built, how it works and what changed along the way. Behind the reading experience is a publishing system that lets me keep developing those accounts while controlling exactly which version reaches the public site. Each edit becomes an immutable SQLite revision. Publishing checks its revision and content hash against the reviewed draft before changing the public pointer in a transaction.

The public export includes approved content and the interface needed to read it. Editing APIs and private services stay out, while the separate Working Memory Content Operations tool checks draft handoffs using the same validator. On the homepage, a Three.js figure follows the page sections on larger screens. On smaller screens, the opening figure stays in the normal flow and responds to touch. Its idle movement is one shared breathing cycle.

In this record

ATTEMPTS & CORRECTIONS

What changed along the way.

  1. Fixing raster bands without changing the figure
    At first
    The renderer drew each grain as a hardware point expanding from a rasterized centre. It also calculated the viewport size separately from the drawing buffer it had actually allocated.
    What needed to change
    A recorded check found horizontal and vertical bands across the face, neck and fingers. The investigation traced them to four-bit subpixel raster precision and a one-pixel viewport mismatch. The bands were not in the source artwork.
    My direction
    I required the approved figure and density to remain unchanged. Increasing the grain count, normalizing pose alpha or altering pose scale would not have met that requirement.
    The change
    Each grain now uses an indexed square, and the viewport follows the drawing buffer's actual dimensions. Native cell-edge arithmetic handles the protected head and hand at the Reach endpoint. Grain count, colours, alpha stacking and pose data stay unchanged.
    The result
    The correction changes pixel coverage while preserving all 383,099 grain identities and leaving multisample antialiasing off. Source and development records support that change; source identity alone still does not establish rendered appearance.
  2. Trying a figure-free phone layout
    At first
    Earlier phone layouts reserved bands for the same four-pose figure used on desktop. A later version moved one figure stage between those bands using reversible clipping windows.
    What needed to change
    I flagged scrolling glitches and the large gaps around the figure on mobile. The illustration was getting in the way of reading, so a faster renderer would not have addressed the layout problem.
    My direction
    I initially asked for the mobile figure to be removed, then asked to bring back the first Reach figure with touch interaction and natural scrolling.
    The change
    The 11 September revision removed the figure, caption, motion control and reserved space below 760px. It also skipped renderer startup and disposed existing graphics when entering the compact layout.
    The result
    That revision removed the empty figure space and graphics work from the phone layout. It was a local intermediate design, later superseded by the in-flow Reach figure described in the next update.
  3. Restoring Reach on phones and removing the travelling wave
    At first
    The first Reach figure returned inside the phone page flow, with local touch scatter. A display-scaled drawing buffer still produced visible bands, and the idle field included time-varying flow as well as breathing.
    What needed to change
    I could still see a wavy line effect, and pausing the motion stopped it. That pointed to animated movement as well as pixel sampling; improving the buffer alone could not remove the unwanted motion.
    My direction
    I asked for the figures to breathe visually, with no travelling wave, while keeping the first Reach figure and touch response on smaller screens.
    The change
    The compact buffer now keeps the original 1586 by 992 grid, with rounding tied to the allocated viewport. All independent idle flow and sway were removed. One shared breathing value drives the anatomical field, and the touch lifecycle preserves a quick tap without intercepting scroll or pinch gestures.
    The result
    Local checks cover the native buffer, one-phase motion, primary-contact tracking, pause, reduced motion and offscreen recovery. The source artwork and particle identities are unchanged. Browser-emulated movement was reviewed; a physical-phone check remains a separate kind of evidence.

IMPLEMENTATION

Design choices.

  1. A draft can keep changing while its published version stays available. Restoring older content creates another draft rather than rewriting the historical revision, so the sequence of changes remains available.
  2. The same request can be retried without repeating the mutation: actor-scoped idempotency receipts return the original result for identical arguments and reject a reused key when the arguments change.
  3. The public build contains only the reader's source dependencies. Keeping editing code out of the artifact avoids relying on a hidden route or a disabled button to separate the public site from its authoring tools.
  4. Publication checks the links as well as the text. Notes cannot publish references to unpublished builds, and builds cannot be unpublished while published notes still depend on them.
  5. Desktop poses follow measured page sections, so text wrapping does not shift the figure into the wrong chapter. Compact screens keep one in-flow figure at the source drawing-buffer resolution; touch scatter remains local and scrolling stays native.

HOW IT FITS TOGETHER

Architecture.

  • Next.js reading routes ask article and project repositories for structured records. Local published content and the static snapshot use the same shape, so the reading pages do not need to know where the records came from.
  • Studio and MCP editing tools call one private content service. SQLite stores canonical JSON revisions and SHA-256 hashes, with separate pointers for the latest draft and published version. Database triggers prevent edits to saved revisions and audit entries.
  • Each mutation runs inside BEGIN IMMEDIATE with its audit entry and idempotency receipt. Publishing checks the reviewed revision, content hash and note-to-build relationships. Our release workflow also supplies the optional publication-state guard, so a changed public pointer can stop the release.
  • The exporter validates the published snapshot, copies only the permitted reader dependencies and substitutes static repositories. Studio, API routes, draft seed modules and private services never enter that build.
  • Working Memory Content Operations imports the portfolio's validator for offline draft checks. It returns a handoff report; saving and publishing remain the responsibility of the content service.
  • One Three.js figure uses measured section anchors on desktop and the first Reach pose in the compact page flow. Visibility, pause, reduced motion and context-loss handling control its lifetime without taking over native scrolling.
Explore the architecture map7 components · 6 connections

Editing locally and publishing the reading site

Only approved content and reading components go into the public site. The editing service stays local.

Direct call
Local authoring
Release boundary
Reader

Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.

Choose a component to explore

Select a numbered component on the map or use the component menu. Its details and connections will appear here.

No component selected.

All connections (6)
  1. 01 · Studio + MCP → 02 · Content serviceTyped requests · Direct call
  2. 02 · Content service → 03 · SQLite revisionsVersioned mutations · Direct call
  3. 03 · SQLite revisions → 04 · Published snapshotPublished pointers only · Direct call
  4. 04 · Published snapshot → 05 · Restricted exportValidated payloads · Direct call
  5. 05 · Restricted export → 06 · Static reading routesStatic reader artifact · Direct call
  6. 06 · Static reading routes → 07 · Homepage rendererMeasured section geometry · Direct call

MADE WITH

Next.js · React · TypeScript · Three.js · SQLite · MCP · ChatGPT Sites

ACCESS & INPUT

Security controls.

  • Editing and publishing are separate permissions. A publish request needs a publisher identity, an enabled local publishing gate, explicit confirmation and the exact revision and hash that were reviewed.
  • Public repositories follow the published pointer and cannot select private revisions. Local seed previews require an explicit flag and a direct loopback Host; forwarded headers cannot establish local access.
  • Before saving, validation limits payload size and structure and rejects private paths, credential-shaped strings and unsupported fields. Public media must resolve to a validated local asset.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

  1. Code and development records reviewedReviewed

    The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

    Scope of this check
    Code review, not a fresh run of the app

NEXT

Still to work through.

The publishing checks make the reviewed content reproducible, but they cannot judge the writing or the animation. Those still need a person to read the page and watch it move. Phone-browser emulation covers the interaction rules; it is not a claim about every physical device.