feat: dynamic section pages, structured data, tests, and catalog improvements

- Add dynamic [section].astro for content-driven section pages
- Add structured JSON-LD generation (jsonld.ts) + markdown export (markdown-export.ts)
- Add comprehensive test coverage (vitest.config.ts, catalog/content/jsonld tests)
- Refactor sections into data layer (src/data/sections.ts)
- Update category/tag/skill/video/post pages for dynamic section support
- Remove hardcoded Wix section pages (cicd-github-actions, curietech, etc.)
- Improve video catalog with better organization and filtering
- Add CONTEXT.md domain documentation and 0001-og-endpoints-stay-per-type.md ADR
- Update deploy workflow with test automation
- Upgrade dependencies (package-lock.json)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: alexandramartinez

.github/workflows/deploy.yml

@@ -29,7 +29,26 @@ concurrency:
   cancel-in-progress: false
 
 jobs:
+  # Gate the whole pipeline on the unit suite (catalog scheduling gate, calendar, .md/JSON-LD
+  # builders). build `needs: test`, so a red suite blocks the build+deploy on EVERY trigger —
+  # push, manual, and the 15-min scheduled rebuild (a failing suite must never auto-ship).
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Set up Node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: npm
+      - name: Install dependencies
+        run: npm ci
+      - name: Run tests
+        run: npm test
+
   build:
+    needs: test
     runs-on: ubuntu-latest
     outputs:
       # Gate for the deploy job. 'true' on every push / manual run; on a SCHEDULED run only

CONTEXT.md

@@ -0,0 +1,46 @@
+# CONTEXT — ProstDev domain glossary
+
+Shared vocabulary for the video catalog and the pages built from it. Use these terms
+as defined here in code, issues, and docs; don't drift to synonyms.
+
+## Glossary
+
+**Video** — one YouTube tutorial in the catalog (`VIDEOS` in `src/data/videos.ts`). Has a
+stable `slug` (→ `/video/<slug>`), a `youtubeId`, and the playlist ids it belongs to. A
+future `publishedAt` hides it in prod (the scheduling gate, `isVideoPublished`).
+
+**Playlist** — a catalog fact: a named YouTube series (`PLAYLISTS` in `src/data/videos.ts`)
+with a `title`, `description`, optional `playlistUrl`, and a prominence `tier`
+(`primary` = focal / homepage-eligible, `more` = findable back-catalog). A Playlist owns the
+canonical title/description; it is NOT a page.
+
+**Section** — a curated landing page (e.g. `/learn-acb`) composed of one or more Playlist
+**blocks** (`SECTIONS` in `src/data/sections.ts`, rendered by `src/pages/[section].astro`). A
+Section is PRESENTATION only: it adds the page `slug`, an optional `seoTitle`, and a per-block
+intro `hook`. It reuses the Playlist's title/description as the heading and meta. One Section
+can compose several Playlists (e.g. `/mulesoft-ai` renders `ai-showdown` + `mulesoft-ai-2025`),
+so a Playlist may be shown on a Section whose slug isn't its own.
+
+**Owning section** — the Section that renders a given Playlist. `sectionHref(playlist)`
+(`sections.ts`) resolves a Playlist to its owning Section's URL, so a Playlist's video
+breadcrumbs and its `/videos` row heading link to the page that actually shows it — even when
+that Playlist appears only as a secondary block.
+
+**Scheduled** — a Video whose `publishedAt` is still in the FUTURE relative to a given instant.
+`isScheduled(v, now)` (`videos.ts`) is the single, environment-free home of that fact. It is the
+one seam two policies build on: the **scheduling gate** `isVideoPublished` (prod HIDES scheduled
+videos; dev shows everything) and the content calendar (`upcomingCalendarItems`, which wants
+exactly the scheduled set, in any environment). Because both read `isScheduled`, the gate and the
+calendar can't drift. A Video with no `publishedAt` is never scheduled (always live). The blog
+twin is the `pubDate` gate in `src/lib/content.ts`.
+
+## Notes
+
+- Section ≠ Playlist: catalog truth lives on the Playlist; a Section only arranges Playlists
+  into a page. Don't duplicate a Playlist's title/description into a Section unless the SEO
+  title genuinely differs (then use `seoTitle`).
+- Adding a section page = add a `Section` to `SECTIONS`. There is no per-page `.astro` file and
+  no slug list to keep in sync (the retired `SECTION_PAGE_SLUGS` Set).
+- Scheduling ≠ prod policy: `isScheduled` is the time FACT; `isVideoPublished` layers the
+  hide-in-prod POLICY on top. Don't re-implement the `publishedAt > now` comparison anywhere —
+  route through `isScheduled` (this is what commit 9d29051's bug + `videos.catalog.test.ts` guard).

docs/adr/0001-og-endpoints-stay-per-type.md

@@ -0,0 +1,61 @@
+# ADR-0001 — OG-image endpoints stay per-type, not a unified dispatcher
+
+- **Status:** Accepted
+- **Date:** 2026-07-16
+- **Deciders:** Alex Martinez
+
+## Context
+
+Social-share (OG) card PNGs are generated at build time by four route files:
+
+- `src/pages/og/default.png.ts` (7 lines)
+- `src/pages/og/post/[slug].png.ts` (15 lines)
+- `src/pages/og/skill/[slug].png.ts` (15 lines)
+- `src/pages/og/video/[slug].png.ts` (23 lines)
+
+The real rendering depth already lives in one deep module, `src/lib/og-image.ts`
+(`card` / `bareImageCard` / `renderCard` / `loadPostHero` / `fetchRemoteImage`). The four
+endpoints are thin adapters over it.
+
+An architecture review (July 2026) listed, as a *Speculative* candidate, unifying the four
+into a single `og/[...type].png.ts` that dispatches by type — noting it as "listed for
+completeness" and marginal. This ADR records why we declined it, so future reviews don't
+re-surface it.
+
+## Decision
+
+Keep one OG endpoint per content type. Do **not** collapse them into a type-dispatching route.
+
+## Rationale
+
+The four endpoints look like duplication but share almost nothing beyond the Astro
+`getStaticPaths` + `GET` shell. What actually differs per type:
+
+- **Data source** — `getPosts()` / `getSkills()` / `publishedVideos()`, and `default` has no
+  `getStaticPaths` at all.
+- **Card function** — post/skill use `card()` (title overlaid on a hero image); video uses
+  `bareImageCard()` (full-bleed YouTube thumbnail, no overlay — the thumbnail already bakes in
+  the title, and overlaying produced text-on-text).
+- **Fetch model** — video is `async` and fetches a remote thumbnail with a maxres→hq fallback;
+  post/skill do a synchronous `loadPostHero(filePath)`.
+
+A unified dispatcher would have to union three `getStaticPaths` (three data sources) and branch
+on type for both the card function and the sync/async fetch. Net change ≈ −5 lines, but it
+**fails the deletion test**: deleting the four files for one router does not concentrate
+complexity — it scatters each content type's OG logic behind a branch and destroys locality.
+Today "how is a video's OG card made?" is answered by one legible 23-line file; behind a
+dispatcher it becomes a case in a multi-type switch. The seam is already in the right place
+(`og-image.ts`); the endpoints are correctly shallow adapters, which is what a route file
+should be.
+
+## Consequences
+
+- Adding a new OG card type = add one small endpoint file (the established pattern), not a new
+  branch in a shared router.
+- The genuine micro-duplication between the post and skill endpoints (both:
+  collection → `getStaticPaths` → `card({ title, eyebrow, bg: loadPostHero(filePath) })`) is
+  accepted as-is; each `GET` body is three lines and the two differ in `eyebrow`/title source,
+  so a shared helper would take nearly as many arguments as it removes lines.
+- Related cleanup done alongside this decision: `og/video/[slug].png.ts` annotated its props
+  with `(typeof VIDEOS)[number]` referencing an unimported `VIDEOS` (a dangling identifier
+  `astro build` tolerated but `astro check` would flag). Switched to the exported `Video` type.