
How TEEI Works: One Platform, Many Programmes
How TEEI works: one platform of shared blocks. A new programme starts on parts that already work, and each is there because research shows what it does.

Showing 21-32 of 99 posts

How TEEI works: one platform of shared blocks. A new programme starts on parts that already work, and each is there because research shows what it does.

We can read from one Astro collection and still disagree on what is published. For a built search index, we filter preview drafts out again.

We traced a crash to old code reading new loader data, then found our tests expecting a failure report from a reload that worked.

We found a 500 before a cache hit, private values in the Worker bundle and missing sitemap routes. Each exposed a boundary we had to migrate.

We moved three apps from Pages to Workers, then changed Cloudflare accounts. We had to rebuild defaults for headers, redirects and deployment targets.

We build two Workers from one React Router app, pass programme identity through typed context, and use stored rows for scheduled work.

We found a session lookup in the language helper, outside our list of guards. We moved resolution into layout middleware and gave the context three states.

A local browser experiment found two ordering bugs in our activity line. We follow the handoffs between Astro, Workers and the visible text.

We omit names, coarsen times and mask country pairs before storage, then derive every public view from that record and remove its id at runtime.

We had recorded the volunteer's answer, but still removed the learner from the lesson. Here is where live signals end and durable outcomes begin.

We could reuse an idempotency key and still change the payload after a deploy. We now store the first attempt’s message fields so a retry can reuse them.

We keep Astro pages static while handling old measurements, failed source reads and island requests that never replace the fallback.