feat: regenerate all demos as 18 segments with docgen

Restructured from 14 to 18 segments:
- 01-06: platform core (refreshed narration + new TTS)
- 07: merge & release pipeline (NEW)
- 08-09: orchestrator + multi-team Helm (renumbered)
- 10: baggage middleware deep-dive (NEW)
- 11: testing ecosystem (renamed/expanded from newman-tests)
- 12-13: test-trace graph + results DB (renumbered)
- 14: customization — hooks, variants, schema (NEW)
- 15-17: regression, GUI tour, GUI extension (REWRITTEN)
- 18: M13 roadmap — what's coming next (NEW)

New Manim scenes: MergeReleaseScene, BaggageMiddlewareScene,
CustomizationScene, ManagementGUITourScene, GUIExtensionPatternScene,
RoadmapScene.

All outputs: H.264 + AAC + faststart (web-native playback).
Concat: full-demo (01-13), full-demo-complete (01-18), platform-core (01-07).
Total runtime: ~45 minutes.

Made-with: Cursor

Author: jmjava

docs/demos/animations/scenes.py

@@ -12,7 +12,7 @@ dirs:
   recordings: recordings
 
 segments:
-  default: ["01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11"]
+  default: ["01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11", "12", "13"]
   all:
     - "01"
     - "02"
@@ -28,26 +28,31 @@ segments:
     - "12"
     - "13"
     - "14"
+    - "15"
+    - "16"
+    - "17"
+    - "18"
 
-# Segment → narration file name stems (matches narration/*.md file names)
 segment_names:
   "01": "01-architecture"
   "02": "02-quickstart"
   "03": "03-bootstrap-dataflow"
   "04": "04-pr-pipeline"
   "05": "05-intercept-routing"
   "06": "06-local-debug"
-  "07": "07-orchestrator"
-  "08": "08-multi-team-helm"
-  "09": "09-results-db"
-  "10": "10-newman-tests"
-  "11": "11-test-trace-graph"
-  "12": "12-regression-suite"
-  "13": "13-management-gui-architecture"
-  "14": "14-gui-tekton-extension"
+  "07": "07-merge-release"
+  "08": "08-orchestrator"
+  "09": "09-multi-team-helm"
+  "10": "10-baggage-middleware"
+  "11": "11-testing-ecosystem"
+  "12": "12-test-trace-graph"
+  "13": "13-results-db"
+  "14": "14-customization"
+  "15": "15-regression-suite"
+  "16": "16-management-gui"
+  "17": "17-extending-gui"
+  "18": "18-roadmap"
 
-# Visual source mapping — matches the VISUAL_MAP from compose.sh
-# type: manim | vhs | mixed | still
 visual_map:
   "01":
     type: manim
@@ -77,56 +82,73 @@ visual_map:
     scene: LocalDebugScene
     source: LocalDebugScene.mp4
   "07":
-    type: vhs
-    tape: 07-orchestrator-api.tape
-    source: 07-orchestrator-api.mp4
+    type: manim
+    scene: MergeReleaseScene
+    source: MergeReleaseScene.mp4
   "08":
+    type: vhs
+    tape: 08-orchestrator-api.tape
+    source: 08-orchestrator-api.mp4
+  "09":
     type: manim
     scene: MultiTeamScene
     source: MultiTeamScene.mp4
-  "09":
-    type: vhs
-    tape: 09-results-db.tape
-    source: 09-results-db.mp4
   "10":
-    type: vhs
-    tape: 10-newman.tape
-    source: 10-newman.mp4
+    type: manim
+    scene: BaggageMiddlewareScene
+    source: BaggageMiddlewareScene.mp4
   "11":
+    type: vhs
+    tape: 11-testing.tape
+    source: 11-testing.mp4
+  "12":
     type: mixed
     scene: BlastRadiusScene
-    tape: 11-graph-tests.tape
+    tape: 12-graph-tests.tape
     sources:
       - BlastRadiusScene.mp4
-      - 11-graph-tests.mp4
-  "12":
-    type: manim
-    scene: RegressionSuiteScene
-    source: RegressionSuiteScene.mp4
+      - 12-graph-tests.mp4
   "13":
-    type: manim
-    scene: ManagementGUIArchitectureScene
-    source: ManagementGUIArchitectureScene.mp4
+    type: vhs
+    tape: 13-results-db.tape
+    source: 13-results-db.mp4
   "14":
     type: manim
-    scene: GUIExtensionScene
-    source: GUIExtensionScene.mp4
+    scene: CustomizationScene
+    source: CustomizationScene.mp4
+  "15":
+    type: vhs
+    tape: 15-regression.tape
+    source: 15-regression.mp4
+  "16":
+    type: manim
+    scene: ManagementGUITourScene
+    source: ManagementGUITourScene.mp4
+  "17":
+    type: manim
+    scene: GUIExtensionPatternScene
+    source: GUIExtensionPatternScene.mp4
+  "18":
+    type: manim
+    scene: RoadmapScene
+    source: RoadmapScene.mp4
 
-# Manim rendering config
 manim:
   quality: 720p30
   scenes:
     - StackDAGScene
     - HeaderPropagationScene
     - InterceptRoutingScene
     - LocalDebugScene
+    - MergeReleaseScene
     - MultiTeamScene
+    - BaggageMiddlewareScene
     - BlastRadiusScene
-    - RegressionSuiteScene
-    - ManagementGUIArchitectureScene
-    - GUIExtensionScene
+    - CustomizationScene
+    - ManagementGUITourScene
+    - GUIExtensionPatternScene
+    - RoadmapScene
 
-# TTS config
 tts:
   model: gpt-4o-mini-tts
   voice: coral
@@ -135,7 +157,6 @@ tts:
     called tekton-dag. Speak in a calm, professional tone. Pronounce technical
     terms clearly: Tekton, Kubernetes, Helm, Newman, pytest, Neo4j, Manim.
 
-# Concat configs for full demo files
 concat:
   full-demo:
     - "01"
@@ -149,7 +170,9 @@ concat:
     - "09"
     - "10"
     - "11"
-  full-demo-with-m12-2:
+    - "12"
+    - "13"
+  full-demo-complete:
     - "01"
     - "02"
     - "03"
@@ -164,10 +187,22 @@ concat:
     - "12"
     - "13"
     - "14"
+    - "15"
+    - "16"
+    - "17"
+    - "18"
+  platform-core:
+    - "01"
+    - "02"
+    - "03"
+    - "04"
+    - "05"
+    - "06"
+    - "07"
 
-# Validation thresholds
 validation:
   max_drift_sec: 2.75
+  max_freeze_ratio: 0.85
   ocr:
     error_patterns:
       - "command not found"
@@ -188,7 +223,6 @@ validation:
       - "script section"
       - "edit for voice"
 
-# Wizard config
 wizard:
   llm_model: gpt-4o
   system_prompt: >
@@ -206,7 +240,6 @@ wizard:
     - "**/terminal/rendered/**"
     - "**/.venv/**"
 
-# GitHub Pages
 pages:
   title: "tekton-dag Demo Videos"
   description: "CI/CD pipeline platform demo recordings"

docs/demos/animations/timing.json

@@ -0,0 +1,17 @@
+The pull request passed. Tests are green. The developer clicks merge. What happens next?
+
+A GitHub webhook fires and the orchestrator generates a PipelineRun in merge mode. Unlike the pull-request pipeline, which builds only the changed service, the merge pipeline produces a release-quality artifact with proper semantic versioning.
+
+The first interesting step is the version bump task running in release mode. During the pull-request cycle, the version file tracked a release candidate suffix — something like zero dot one dot zero dash rc dot three. The release version bump strips that suffix. The app version becomes zero dot one dot zero — a clean release number.
+
+Next, the pipeline compiles and containerizes the merged code, just like the PR build, but tagged with the merge commit SHA. The compile tasks use the same parameterized build images — Maven, Gradle, npm, pip, or Composer — with the resource profiles configured per team.
+
+Here is where the merge pipeline diverges from the PR pipeline. The tag release images task uses crane — a fast, daemon-less container tool — to copy the built image and re-tag it with the release semver. The image registry now holds the app at v zero dot one dot zero. No rebuild needed — crane copies the layers directly.
+
+After tagging, the pipeline bumps the version file to the next development cycle. Zero dot one dot zero becomes zero dot one dot one dash rc dot zero — ready for the next pull request to start incrementing the release candidate again. This version commit is pushed back to the repository automatically using SSH credentials.
+
+If the team has configured hook tasks, they run at the right points. A post-build hook might trigger an image security scan or generate a software bill of materials. A pre-test hook might seed test data. These are optional Tekton Tasks wired through pipeline parameters — no need to fork the core pipeline definition.
+
+The result is a release-tagged container image sitting in your registry, ready for promotion. How you promote — Argo Rollouts, a Helm upgrade, a manual release script — is up to your deployment strategy. tekton-dag handles everything up to the release artifact.
+
+Pull request tested. Version promoted. Image tagged. Hooks executed. Version file bumped for the next cycle. That is the merge and release pipeline.

docs/demos/docgen.yaml

@@ -0,0 +1,19 @@
+Intercept routing depends on one thing: every service in the call chain must propagate the dev-session header. If any service drops it, the routing breaks. The baggage middleware libraries make this automatic across five frameworks.
+
+Every service has a propagation role defined in the stack YAML. An originator starts the chain — it sets the dev-session header on all outgoing requests. A forwarder reads the incoming header, stores it in request context, and attaches it to every downstream call. A terminal accepts the header for routing and logging but does not forward it further.
+
+Let's walk through each framework.
+
+In Spring Boot, the baggage starter auto-configures everything. A servlet filter called BaggageContextFilter reads the incoming header and stores it using OpenTelemetry Baggage and a thread-local context holder. A RestTemplate interceptor called BaggageRestTemplateInterceptor automatically adds the header to every outbound HTTP call. The entire setup activates with a single property: baggage dot enabled equals true. If the property is false or absent, the filter and interceptor are not registered. Zero overhead in production.
+
+For Node and Vue, the library provides createBaggageFetch — a wrapper around the native fetch API that injects the header — and createAxiosInterceptor for Axios-based projects. The default configuration reads from environment variables like VITE underscore BAGGAGE underscore ENABLED, so the browser build can include or exclude baggage at compile time.
+
+In Flask and Python, the init underscore app function registers a before-request hook that extracts the header and stores it on Flask's g object. For outbound calls, BaggageSession extends the standard requests dot Session class to add the header automatically. Same pattern: enabled by an environment variable, zero-cost when disabled.
+
+The PHP implementation uses PSR-15 middleware for inbound requests and a Guzzle middleware for outbound HTTP. The BaggageMiddleware class reads its configuration from environment variables and can be instantiated with a static fromEnv factory method.
+
+All five implementations follow the W3C Baggage specification alongside the custom x-dev-session header. The W3C baggage header carries key-value pairs in a standardized format, which means third-party observability tools can read the routing context without custom parsing.
+
+The critical safety feature is the enabled flag. In every framework, baggage propagation is off by default. It activates only when the environment variable is explicitly set to true. This means you can deploy the middleware to production and it does nothing until you opt in — no accidental header leakage, no performance impact.
+
+Five frameworks. One header contract. Zero application code changes beyond configuration. That is the baggage middleware.

docs/demos/narration/07-merge-release.md

@@ -0,0 +1,19 @@
+Testing is a first-class concern in tekton-dag. The platform supports four testing frameworks — Newman for API contracts, pytest for Python services, Playwright for end-to-end GUI testing, and Artillery for load testing — all integrated into the pipeline and regression workflows.
+
+Every stack definition includes test specifications attached to each app. The run stack tests task in the pipeline executes these tests with the dev-session header injected. For Postman collections, it uses Newman — the Postman CLI runner — to execute API tests against the live stack. The dev-session header is added to every request so the tests hit the pull-request build through the intercept chain.
+
+For orchestrator HTTP contracts against a live cluster, Newman runs the Postman collection via the run orchestrator tests shell script: port-forward to the cluster, call the REST API, and optionally trigger PipelineRuns. That workflow differs from a full system regression, which is documented in the regression guide.
+
+For fast unit coverage without a cluster, pytest exercises the orchestrator's Flask app, routes, stack resolver, PipelineRun builder, and Kubernetes client wrapper with mocks. Watch the output — dozens of tests across the orchestrator modules, all passing. They verify stack resolution, manifest generation, webhook parsing, and endpoint error handling.
+
+The shared Python package tekton-dag-common has its own test suite as well. Fourteen tests cover the base stack resolver, PipelineRun builder, and Kubernetes constants that are shared between the orchestrator and the management GUI backend.
+
+The management GUI has its own Playwright end-to-end suite — sixty-nine tests covering the web interface. These navigate every view, trigger pipeline actions, verify DAG rendering, and check team switching. The Flask backend has fifty-plus pytest tests covering every API route with mocked Kubernetes responses.
+
+For load testing, Artillery scenarios exercise the stack under concurrent traffic. The artillery variants script runs multiple configurations — baseline load, burst traffic, and sustained throughput — and captures response time distributions. These run during regression or on demand, not on every pull request.
+
+For end-to-end integration, the run e2e with intercepts script triggers a full pull-request pipeline flow and validates that header propagation works through the entire stack. This is the highest-fidelity test — it proves the complete workflow from webhook to cleanup on a live cluster.
+
+Application repos run their Postman, Playwright, and Artillery suites inside stack-pr-test when a pull request opens — those are stack-scoped tests. The orchestrator pytest suite and the full platform regression scripts are system-level: they validate this platform against a cluster and are run on demand, on a schedule, or before releases.
+
+Four frameworks. Stack-scoped and system-level tiers. Full coverage from unit to load. That is the testing ecosystem.