Maggie Lerman Portfolio

My portfolio began as hands-on design and engineering work. I built and refined custom Nunjucks templates, reusable sections, navigation, and the Eleventy build around the work I wanted to show. I worked on how the site was assembled as well as how it looked: image shortcodes, responsive image formats and sizes, lazy loading, CSS and JavaScript minification, and production-only cleanup. The repository begins in November 2021; its 2022 and 2024 history preserves that work before the documented Cursor collaboration. This was an existing system with my own conventions and tradeoffs when AI entered the workflow.

As I brought AI into the work, I needed it to understand the site I had already built. A July 2025 commit explicitly records Cursor-assisted cleanup; later Codex work extended the templates, components, and review surfaces. I created eleventy-jamstack-expert to make my technical approach reusable: inspect the existing build and data cascade, preserve template conventions, compose layouts and includes clearly, and favor static content with progressive enhancement. The skill is present in my versioned skills library by May 8, 2026. That is a verified repository date, not a claim that it was the first day I wrote it.

I deliberately left the full Context Layer out of this repository. I thought the portfolio was small and expected occasional updates or additions, rather than an ongoing development program. That reasoning is my retrospective account. The resulting policy is visible in the May 8 repository instructions: use lightweight experiment notes, and do not add the full Product OS scaffold unless I explicitly ask for it. Product OS was the wording in that historical instruction. I had a technical skill and some documentation, but had chosen not to install the broader lifecycle, evidence, and project-dashboard system.

The work expanded into redesigns, alternate routes, responsive review tools, color and type studies, prototypes, and cross-project handoffs. I kept encountering what felt like shadow product after shadow product: another surface to inspect, another place to store a decision, another explanation of which version was current. The repository records the practical ambiguity. One handoff said a testing playground still embedded the historical homepage and needed to be adapted before it could test the actual site. Later notes repeatedly distinguish the canonical homepage, the review hub, static captures, and standalone prototypes. Experiments had value; their relationship to the product was becoming work of its own. My experience of repeating work is part of the account, but I have not quantified the time lost.

On October 11, I noticed thousands of uncommitted files under design studies. The audit counted 20,044 untracked files: 19,973 dependency files, 12 generated build files, and 59 source, design, screenshot, and handoff files. The immediate bug was a root-only ignore rule that missed nested dependencies. Fixing it reduced the noise, but did not answer my bigger question: why were we producing duplicate handoff ZIPs and organizing the project this way? I asked whether the standard Context Layer was installed. It was not. That connected the roundabout process I had been experiencing to the exception I had made months earlier.

I asked for the standard Context Layer, a review board, and bug intake. The migration gave the existing work five owning project records: the portfolio redesign, responsive typography and color review, ecommerce prototype, historical studies, and the completed Frill handoff. It added a study register, evidence indexes, a generated dashboard, and explicit next checkpoints. Existing study paths stayed intact. The preservation record covers 690 original documents and study files; their content hashes were checked after migration. The duplicate Frill handoff ZIP was removed with my authorization, and future handoffs were directed to source paths and project records. The open mobile typography issue remained open. This is immediate evidence of organization and preservation, not yet a measured reduction in future rework.

I originally built Context Layer as a workaround for the context problem. By October 2026, I was using a much more capable Codex environment and, in my experience, substantially more native context support. The source session confirms gpt-6-astra with high reasoning. Yet the project still needed a durable answer to which implementation was current, what I had approved, where evidence belonged, and what remained unfinished. My conclusion is that Context Layer is necessary for my ongoing work even when the project starts small. The Eleventy skill carries technical judgment; Context Layer gives the work explicit decisions, ownership, and continuity. This portfolio is a concrete case of why I need both. It does not establish that missing Context Layer was the sole cause of every problem, or benchmark OpenAI's context features. The limit of this evidence is that the migration has just happened: sustained improvement still needs observation.