Rishabh ShuklaRishabh Shukla

Rebuilding this site, the mobile menu opened and the page stayed visible behind it. The overlay's background computed as 98% opaque black. Its z-index was above everything. Nothing in the markup or in the computed styles was wrong.

The overlay is rendered inside the header, and the header has a backdrop blur on it. A filter — and backdrop-filter counts — makes an element the containing block for every fixed-position descendant. So position: fixed with inset: 0 was not resolving against the viewport at all. It was resolving against the header: a full-width strip about fifty pixels tall. The background was painted correctly, into a box the size of a navigation bar. The links, which overflowed, still landed roughly where they were expected, which is what made it look like a styling problem rather than a layout one.

Two things worth keeping. The bug was invisible to every tool that reports what an element looks like, because the element looked exactly right — the question nobody thought to ask was how big it was. And it could not reproduce at desktop width, where the overlay never opens at all.

Rendering it into the document body instead puts it back on the viewport's coordinate system, where a full-screen overlay belongs.

A lens is a named curation over the spine — which records, under which heading, in which order. The public pages were written to read from one, which is correct, and it meant that publishing records and then reloading the site produced exactly the page you had before: a name, and nothing under it.

Nothing was broken. publishLens exists in the core library, it is tested, and no screen calls it. The lenses table is empty and there is no way to put anything into it. Both public pages were behaving correctly with respect to a thing that cannot yet be created.

The fix is a fallback: prefer the owner's arrangement wherever there is one, and fall back to everything published of that type where there is not. What makes it worth writing down is the failure it prevents, which is not a blank page. It is a blank page shown to somebody who has just published their whole résumé and now believes the system did not save it.

Assets are entities on the spine, so a file inherits visibility, row-level security, the event log, undo and the publish pipeline, instead of getting a second and weaker access model written beside the real one.

Creating the first storage bucket surfaced something in a schema nobody had read, because the platform had created those tables rather than this repository. Supabase grants the anonymous and authenticated roles full DML on storage.objects and storage.buckets — including TRUNCATE — and then narrows access with policies. TRUNCATE is not subject to row-level security. The policies were never going to see it.

It was the same shape as a hole found earlier in the public schema, present in both projects, and found before there was anything in either bucket to lose. The lesson taken from it was not about storage. It was that a schema the platform creates is still a schema in your database, and "we did not write those tables" is precisely the reason nobody had looked.