From 9a093356c6838fa056c2754a19af4e00563d701f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?M=C3=A5rten=20Angner?= <marten@angner.se>
Date: Thu, 26 Feb 2026 08:19:12 +0100
Subject: [PATCH] Rename learn-wds to learn, update for workshop refactor
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- Rename docs/learn-wds/ to docs/learn/ and update all 17 references
- Module 02: Replace manual clone/mkdir/Mimir with npx installer + direct
  agent activation (Saga, Freya, Idunn — no Mimir)
- Module 08: Replace 9-section scenario template with Q1-Q8 dialog format
  matching the actual workflow (step-05-outline-scenario.md)
- Update scenario naming convention to persona-based (01-name-purpose)
- Update folder structure to NN.step-page-slug format

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---
 .npmignore                                    |   4 +-
 README.md                                     |   2 +-
 docs/docs-guide.md                            |  22 +-
 .../1-project-brief/invitation-snippets.md    |   8 +-
 .../1.1-wds-presentation.md                   |  56 +-
 docs/examples/wds-examples-guide.md           |   2 +-
 ...saga-course-workflow-integration-dialog.md |   6 +-
 .../WDS-BMAD-INTEGRATION-REPORT.md            |   6 +-
 .../WDS-DEEP-ANALYSIS-SUMMARY.md              |   2 +-
 .../wds-v6-conversion-guide.md                |   2 +-
 docs/getting-started/installation.md          |   2 +-
 docs/getting-started/quick-start.md           |   2 +-
 docs/getting-started/where-to-go-next.md      |  16 +-
 docs/learn-wds/00-course-overview.md          | 211 ----
 ...S-Jam-1-Say-Hello-to-AI-Agent-Framework.md |   0
 .../Module 00-transcript.srt                  | 635 ------------
 .../Module 02-transcript.srt                  | 807 ---------------
 .../Module-00-notebook-lm-prompt.md           | 250 -----
 .../Module-00-thumbnail-prompt.md             |  33 -
 .../Module-00-youtube-show-notes.md           |  78 --
 .../Module-01-notebook-lm-prompt.md           | 418 --------
 .../Module-01-thumbnail-prompt.md             |  33 -
 .../Module-01-transcript.srt                  | 731 --------------
 .../Module-02-notebook-lm-prompt.md           | 342 -------
 .../Module-02-thumbnail-prompt.md             |  34 -
 .../Module-03-notebook-lm-prompt.md           | 745 --------------
 .../Module-03-thumbnail-prompt.md             |  33 -
 .../Module-03-transcript.srt                  | 595 -----------
 .../Module-04-notebook-lm-prompt.md           | 163 ---
 .../Module-04-thumbnail-prompt.md             |  36 -
 .../Module-04-youtube-show-notes.md           |  95 --
 .../Module-05-notebook-lm-prompt.md           | 274 -----
 .../Module-05-thumbnail-prompt.md             |  40 -
 .../Module-05-youtube-show-notes.md           |  65 --
 .../module-01-YOUTUBE-SHOW-NOTES.md           |  75 --
 .../module-02-YOUTUBE-SHOW-NOTES.md           |  86 --
 .../module-03-YOUTUBE-SHOW-NOTES.md           |  82 --
 .../course-explainers/trigger-map-example.jpg | Bin 143593 -> 0 bytes
 .../lesson-01-git-setup/01-lesson.md          | 124 ---
 .../lesson-01-git-setup/01-quick-checklist.md |  63 --
 .../checklist.md                              |  87 --
 .../lesson-01-github-and-ide-setup/lesson.md  | 203 ----
 .../lesson-01-setting-up-github/checklist.md  |  70 --
 .../lesson-02-git-configuration/checklist.md  |  40 -
 .../01-quick-checklist.md                     |  48 -
 .../lesson-02-ide-installation/02-lesson.md   |  88 --
 .../02-quick-checklist.md                     |  48 -
 .../lesson-02-install-ide/checklist.md        |  48 -
 .../lesson-02-install-ide/tutorial.md         | 149 ---
 .../01-quick-checklist.md                     |  51 -
 .../lesson-03-git-cloning/03-lesson.md        | 111 --
 .../03-quick-checklist.md                     |  51 -
 .../lesson-03-git-setup/checklist.md          |  41 -
 .../lesson-03-git-setup/tutorial.md           | 159 ---
 .../lesson-04-clone-and-wds/checklist.md      |  93 --
 .../lesson-04-clone-and-wds/tutorial.md       | 217 ----
 .../01-quick-checklist.md                     |  73 --
 .../02-full-lesson.md                         | 206 ----
 .../lesson-04-wds-initialization/04-lesson.md | 206 ----
 .../04-quick-checklist.md                     |  73 --
 .../lesson-05-initiate-mimir/checklist.md     |  79 --
 .../lesson-05-initiate-mimir/tutorial.md      | 244 -----
 .../module-02-overview.md                     |  77 --
 .../tutorial-04.md                            | 460 ---------
 .../lesson-04-workshop-1-business-goals.md    | 274 -----
 .../lesson-05-workshop-2-target-groups.md     | 504 ----------
 .../lesson-07-workshop-4-prioritization.md    | 313 ------
 .../lesson-08-workshop-5-feature-impact.md    | 474 ---------
 .../lesson-09-positive-negative-drivers.md    | 348 -------
 .../tutorial-05b-value-trigger-chain.md       | 395 --------
 .../tutorial-06.md                            | 358 -------
 .../tutorial-08.md                            | 521 ----------
 .../module-09-design-system/tutorial-09.md    | 515 ----------
 .../module-10-design-delivery/tutorial-10.md  | 604 -----------
 .../module-12-conceptual-specs/tutorial-12.md | 734 --------------
 .../00-course-overview/00-course-overview.md  | 240 +++++
 .../00-getting-started-overview.md            |   2 +-
 .../00-course-overview/01-prerequisites.md    |   4 +-
 .../00-course-overview/02-learning-paths.md   |  12 +-
 .../00-course-overview/03-support.md          |   2 +-
 ...4-12-22-WDS-Sessions-1-Say-Hello-to-WDS.md |   4 +-
 .../Webinars/2025-10-22-Webinar-WDS-v4.md     |   2 +-
 ...-15-WDS-Sessions-2-Strategy-in-Practice.md |   4 +-
 .../lesson-01-the-problem.md                  |   6 +-
 ...lesson-02-designer-as-strategic-thinker.md | 483 +++++++++
 .../lesson-03-the-solution.md}                |   8 +-
 .../lesson-04-the-path-forward.md}            |  15 +-
 .../module-01-overview.md                     |  26 +-
 .../lesson-01-git-setup.md}                   |  23 +-
 .../lesson-02-ide-installation.md}            |  15 +-
 .../lesson-03-git-cloning.md}                 |  19 +-
 .../lesson-04-wds-initialization.md           | 135 +++
 .../module-02-overview.md                     |  59 ++
 .../tutorial-02.md                            | 158 +++
 .../lesson-01-understanding-alignment.md      |   8 +-
 .../lesson-02-creating-alignment-document.md  |   6 +-
 .../lesson-03-negotiation-acceptance.md       |   8 +-
 .../lesson-04-external-contracts.md           |  10 +-
 .../lesson-05-internal-signoff.md             |  10 +-
 .../module-03-overview.md                     |   8 +-
 .../tutorial-03.md                            |  14 +-
 .../lesson-01-chaos-problem.md                |   2 +
 .../lesson-02-five-questions.md               |   2 +
 .../lesson-03-document-structure.md           |   4 +-
 .../lesson-04-wds-advantage.md                |   6 +-
 .../lesson-05-using-brief.md                  |   2 +
 .../lesson-06-additional-documents.md         |   4 +-
 .../module-04-overview.md                     |   8 +-
 .../module-04-product-brief/tutorial-04.md    |  18 +-
 .../lesson-01-why-boundaries-matter.md        | 232 +++++
 ...esson-02-defining-platform-requirements.md | 416 ++++++++
 ...odule-05-platform-requirements-overview.md | 186 ++++
 .../tutorial-05.md                            | 377 +++++++
 .../lesson-01-missing-link.md                 |  11 +-
 .../lesson-02-heritage-evolution.md           |  63 +-
 .../lesson-03-five-workshops-overview.md      |  12 +-
 .../lesson-04-workshop-1-business-goals.md    | 319 ++++++
 .../lesson-05-workshop-2-target-groups.md     | 557 ++++++++++
 .../lesson-06-workshop-3-driving-forces.md    | 201 ++--
 .../lesson-07-workshop-4-prioritization.md    | 373 +++++++
 .../lesson-08-workshop-5-feature-impact.md    | 543 ++++++++++
 .../lesson-09-positive-negative-drivers.md    | 507 ++++++++++
 .../lesson-10-visual-trigger-map.md           |  10 +-
 .../lesson-11-feature-impact-scoring.md       |   8 +-
 .../module-06-overview.md}                    |  28 +-
 .../module-06-trigger-mapping/tutorial-06.md} |  26 +-
 .../tutorial-06c-documentation-synthesis.md}  |  20 +-
 .../lesson-01-entering-design.md              | 251 +++++
 .../lesson-02-why-specifications-matter.md    | 836 +++++++++++++++
 .../lesson-03-meet-freya.md                   | 201 ++++
 .../module-07-design-phase-overview.md        | 148 +++
 ...esson-01-design-experiences-not-screens.md | 559 +++++++++++
 ...lesson-02-from-trigger-map-to-scenarios.md | 667 ++++++++++++
 .../lesson-03-mapping-the-journey.md          | 347 +++++++
 .../module-08-outline-scenarios-overview.md   | 298 ++++++
 .../tutorial-08.md                            | 397 ++++++++
 .../lesson-01-visualize-first.md              | 286 ++++++
 .../lesson-02-sketching-techniques.md         | 270 +++++
 .../lesson-03-why-hand-sketching.md           | 250 +++++
 ...esson-04-image-sketching-best-practices.md | 272 +++++
 .../lesson-05-sketch-text-strategy.md         | 509 ++++++++++
 .../lesson-06-ai-wireframe-generation.md      | 211 ++++
 ...module-09-conceptual-sketching-overview.md | 243 +++++
 .../tutorial-09.md                            | 381 +++++++
 .../lesson-01-transformations.md              | 392 ++++++++
 .../lesson-02-storyboard-format.md            | 410 ++++++++
 .../module-10-storyboarding-overview.md       | 290 ++++++
 .../module-10-storyboarding/tutorial-10.md    | 405 ++++++++
 .../lesson-01-design-is-specification.md      | 593 +++++++++++
 ...lesson-02-section-widget-specifications.md | 704 +++++++++++++
 .../lesson-03-element-state-specifications.md | 949 ++++++++++++++++++
 ...e-11-conceptual-specifications-overview.md | 460 +++++++++
 .../storyboards/password-field.md             |  32 +
 .../storyboards/submit-button.md              |  26 +
 .../tutorial-11.md                            | 472 +++++++++
 .../components/button.md                      |  41 +
 .../components/card.md                        |  40 +
 .../components/input.md                       |  42 +
 .../lesson-01-patterns-emerge.md              | 247 +++++
 .../lesson-02-component-anatomy.md            | 332 ++++++
 ...odule-12-functional-components-overview.md | 384 +++++++
 .../tutorial-12.md                            | 405 ++++++++
 .../lesson-01-understanding-modes.md          | 274 +++++
 .../module-13-design-system-overview.md       | 157 +++
 .../module-13-design-system/tutorial-13.md    | 344 +++++++
 .../lesson-01-iterative-building.md           | 182 ++++
 .../lesson-02-documenting-decisions.md        | 188 ++++
 .../lesson-03-when-you-get-stuck.md           | 213 ++++
 .../lesson-04-working-with-code.md            | 304 ++++++
 .../lesson-05-git-discipline.md               | 349 +++++++
 .../module-14-agentic-development-overview.md | 251 +++++
 .../tutorial-14.md                            | 340 +++++++
 .../lesson-01-making-it-visible.md            | 216 ++++
 .../lesson-02-visual-techniques.md            | 334 ++++++
 .../module-15-visual-design-overview.md       | 338 +++++++
 .../module-15-visual-design/tutorial-15.md    | 377 +++++++
 .../lesson-01-validation-packaging.md         | 340 +++++++
 .../module-16-design-delivery-overview.md     | 178 ++++
 .../module-16-design-delivery/tutorial-16.md  | 411 ++++++++
 .../lesson-01-spec-verification.md            | 243 +++++
 .../lesson-02-test-results.md                 | 240 +++++
 .../lesson-03-acting-on-findings.md           | 253 +++++
 .../module-17-usability-testing-overview.md   | 231 +++++
 .../tutorial-17.md                            | 301 ++++++
 .../lesson-01-continuous-improvement.md       | 255 +++++
 .../lesson-02-update-spec-project-code.md     | 229 +++++
 .../module-18-product-evolution-overview.md   | 253 +++++
 .../tutorial-18.md                            | 293 ++++++
 docs/learn/widgets/W01-task-list.md           |  31 +
 docs/learn/widgets/W02-calendar.md            |  31 +
 docs/learn/widgets/W02-product-card.md        |  31 +
 docs/learn/widgets/W03-quick-add.md           |  31 +
 docs/models/models-guide.md                   |   2 +-
 docs/models/smart-goals-model.md              |   4 +-
 package.json                                  |   2 +-
 tools/cli/lib/installer.js                    |   2 +-
 196 files changed, 24578 insertions(+), 14356 deletions(-)
 delete mode 100644 docs/learn-wds/00-course-overview.md
 delete mode 100644 docs/learn-wds/Webinars/2024-12-22-WDS-Jam-1-Say-Hello-to-AI-Agent-Framework.md
 delete mode 100644 docs/learn-wds/course-explainers/Module 00-transcript.srt
 delete mode 100644 docs/learn-wds/course-explainers/Module 02-transcript.srt
 delete mode 100644 docs/learn-wds/course-explainers/Module-00-notebook-lm-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-00-thumbnail-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-00-youtube-show-notes.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-01-notebook-lm-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-01-thumbnail-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-01-transcript.srt
 delete mode 100644 docs/learn-wds/course-explainers/Module-02-notebook-lm-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-02-thumbnail-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-03-notebook-lm-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-03-thumbnail-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-03-transcript.srt
 delete mode 100644 docs/learn-wds/course-explainers/Module-04-notebook-lm-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-04-thumbnail-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-04-youtube-show-notes.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-05-notebook-lm-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-05-thumbnail-prompt.md
 delete mode 100644 docs/learn-wds/course-explainers/Module-05-youtube-show-notes.md
 delete mode 100644 docs/learn-wds/course-explainers/module-01-YOUTUBE-SHOW-NOTES.md
 delete mode 100644 docs/learn-wds/course-explainers/module-02-YOUTUBE-SHOW-NOTES.md
 delete mode 100644 docs/learn-wds/course-explainers/module-03-YOUTUBE-SHOW-NOTES.md
 delete mode 100644 docs/learn-wds/course-explainers/trigger-map-example.jpg
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/01-lesson.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/01-quick-checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-01-github-and-ide-setup/checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-01-github-and-ide-setup/lesson.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-01-setting-up-github/checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-02-git-configuration/checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/01-quick-checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-lesson.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-quick-checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-02-install-ide/checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-02-install-ide/tutorial.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/01-quick-checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/03-lesson.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/03-quick-checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-03-git-setup/checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-03-git-setup/tutorial.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-04-clone-and-wds/checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-04-clone-and-wds/tutorial.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/01-quick-checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/02-full-lesson.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/04-lesson.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/04-quick-checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-05-initiate-mimir/checklist.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/lesson-05-initiate-mimir/tutorial.md
 delete mode 100644 docs/learn-wds/module-02-installation-setup/module-02-overview.md
 delete mode 100644 docs/learn-wds/module-05-map-triggers-outcomes/tutorial-04.md
 delete mode 100644 docs/learn-wds/module-05-trigger-mapping/lesson-04-workshop-1-business-goals.md
 delete mode 100644 docs/learn-wds/module-05-trigger-mapping/lesson-05-workshop-2-target-groups.md
 delete mode 100644 docs/learn-wds/module-05-trigger-mapping/lesson-07-workshop-4-prioritization.md
 delete mode 100644 docs/learn-wds/module-05-trigger-mapping/lesson-08-workshop-5-feature-impact.md
 delete mode 100644 docs/learn-wds/module-05-trigger-mapping/lesson-09-positive-negative-drivers.md
 delete mode 100644 docs/learn-wds/module-05-trigger-mapping/tutorial-05b-value-trigger-chain.md
 delete mode 100644 docs/learn-wds/module-06-platform-architecture/tutorial-06.md
 delete mode 100644 docs/learn-wds/module-08-initialize-scenario/tutorial-08.md
 delete mode 100644 docs/learn-wds/module-09-design-system/tutorial-09.md
 delete mode 100644 docs/learn-wds/module-10-design-delivery/tutorial-10.md
 delete mode 100644 docs/learn-wds/module-12-conceptual-specs/tutorial-12.md
 create mode 100644 docs/learn/00-course-overview/00-course-overview.md
 rename docs/{learn-wds => learn}/00-course-overview/00-getting-started-overview.md (96%)
 rename docs/{learn-wds => learn}/00-course-overview/01-prerequisites.md (93%)
 rename docs/{learn-wds => learn}/00-course-overview/02-learning-paths.md (84%)
 rename docs/{learn-wds => learn}/00-course-overview/03-support.md (98%)
 rename docs/{learn-wds => learn}/Webinars/2024-12-22-WDS-Sessions-1-Say-Hello-to-WDS.md (98%)
 rename docs/{learn-wds => learn}/Webinars/2025-10-22-Webinar-WDS-v4.md (99%)
 rename docs/{learn-wds => learn}/Webinars/2026-01-15-WDS-Sessions-2-Strategy-in-Practice.md (98%)
 rename docs/{learn-wds => learn}/module-01-why-wds-matters/lesson-01-the-problem.md (97%)
 create mode 100644 docs/learn/module-01-why-wds-matters/lesson-02-designer-as-strategic-thinker.md
 rename docs/{learn-wds/module-01-why-wds-matters/lesson-02-the-solution.md => learn/module-01-why-wds-matters/lesson-03-the-solution.md} (94%)
 rename docs/{learn-wds/module-01-why-wds-matters/lesson-03-the-path-forward.md => learn/module-01-why-wds-matters/lesson-04-the-path-forward.md} (90%)
 rename docs/{learn-wds => learn}/module-01-why-wds-matters/module-01-overview.md (77%)
 rename docs/{learn-wds/module-02-installation-setup/lesson-01-git-setup/02-full-lesson.md => learn/module-02-installation-setup/lesson-01-git-setup.md} (77%)
 rename docs/{learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-full-lesson.md => learn/module-02-installation-setup/lesson-02-ide-installation.md} (79%)
 rename docs/{learn-wds/module-02-installation-setup/lesson-03-git-cloning/02-full-lesson.md => learn/module-02-installation-setup/lesson-03-git-cloning.md} (81%)
 create mode 100644 docs/learn/module-02-installation-setup/lesson-04-wds-initialization.md
 create mode 100644 docs/learn/module-02-installation-setup/module-02-overview.md
 create mode 100644 docs/learn/module-02-installation-setup/tutorial-02.md
 rename docs/{learn-wds => learn}/module-03-alignment-signoff/lesson-01-understanding-alignment.md (97%)
 rename docs/{learn-wds => learn}/module-03-alignment-signoff/lesson-02-creating-alignment-document.md (98%)
 rename docs/{learn-wds => learn}/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md (92%)
 rename docs/{learn-wds => learn}/module-03-alignment-signoff/lesson-04-external-contracts.md (95%)
 rename docs/{learn-wds => learn}/module-03-alignment-signoff/lesson-05-internal-signoff.md (95%)
 rename docs/{learn-wds => learn}/module-03-alignment-signoff/module-03-overview.md (94%)
 rename docs/{learn-wds => learn}/module-03-alignment-signoff/tutorial-03.md (97%)
 rename docs/{learn-wds => learn}/module-04-product-brief/lesson-01-chaos-problem.md (99%)
 rename docs/{learn-wds => learn}/module-04-product-brief/lesson-02-five-questions.md (99%)
 rename docs/{learn-wds => learn}/module-04-product-brief/lesson-03-document-structure.md (99%)
 rename docs/{learn-wds => learn}/module-04-product-brief/lesson-04-wds-advantage.md (98%)
 rename docs/{learn-wds => learn}/module-04-product-brief/lesson-05-using-brief.md (99%)
 rename docs/{learn-wds => learn}/module-04-product-brief/lesson-06-additional-documents.md (98%)
 rename docs/{learn-wds => learn}/module-04-product-brief/module-04-overview.md (94%)
 rename docs/{learn-wds => learn}/module-04-product-brief/tutorial-04.md (92%)
 create mode 100644 docs/learn/module-05-platform-requirements/lesson-01-why-boundaries-matter.md
 create mode 100644 docs/learn/module-05-platform-requirements/lesson-02-defining-platform-requirements.md
 create mode 100644 docs/learn/module-05-platform-requirements/module-05-platform-requirements-overview.md
 create mode 100644 docs/learn/module-05-platform-requirements/tutorial-05.md
 rename docs/{learn-wds/module-05-trigger-mapping => learn/module-06-trigger-mapping}/lesson-01-missing-link.md (96%)
 rename docs/{learn-wds/module-05-trigger-mapping => learn/module-06-trigger-mapping}/lesson-02-heritage-evolution.md (87%)
 rename docs/{learn-wds/module-05-trigger-mapping => learn/module-06-trigger-mapping}/lesson-03-five-workshops-overview.md (96%)
 create mode 100644 docs/learn/module-06-trigger-mapping/lesson-04-workshop-1-business-goals.md
 create mode 100644 docs/learn/module-06-trigger-mapping/lesson-05-workshop-2-target-groups.md
 rename docs/{learn-wds/module-05-trigger-mapping => learn/module-06-trigger-mapping}/lesson-06-workshop-3-driving-forces.md (53%)
 create mode 100644 docs/learn/module-06-trigger-mapping/lesson-07-workshop-4-prioritization.md
 create mode 100644 docs/learn/module-06-trigger-mapping/lesson-08-workshop-5-feature-impact.md
 create mode 100644 docs/learn/module-06-trigger-mapping/lesson-09-positive-negative-drivers.md
 rename docs/{learn-wds/module-05-trigger-mapping => learn/module-06-trigger-mapping}/lesson-10-visual-trigger-map.md (96%)
 rename docs/{learn-wds/module-05-trigger-mapping => learn/module-06-trigger-mapping}/lesson-11-feature-impact-scoring.md (97%)
 rename docs/{learn-wds/module-05-trigger-mapping/module-05-overview.md => learn/module-06-trigger-mapping/module-06-overview.md} (89%)
 rename docs/{learn-wds/module-05-trigger-mapping/tutorial-05.md => learn/module-06-trigger-mapping/tutorial-06.md} (95%)
 rename docs/{learn-wds/module-05-trigger-mapping/tutorial-05c-documentation-synthesis.md => learn/module-06-trigger-mapping/tutorial-06c-documentation-synthesis.md} (96%)
 create mode 100644 docs/learn/module-07-design-phase/lesson-01-entering-design.md
 create mode 100644 docs/learn/module-07-design-phase/lesson-02-why-specifications-matter.md
 create mode 100644 docs/learn/module-07-design-phase/lesson-03-meet-freya.md
 create mode 100644 docs/learn/module-07-design-phase/module-07-design-phase-overview.md
 create mode 100644 docs/learn/module-08-outline-scenarios/lesson-01-design-experiences-not-screens.md
 create mode 100644 docs/learn/module-08-outline-scenarios/lesson-02-from-trigger-map-to-scenarios.md
 create mode 100644 docs/learn/module-08-outline-scenarios/lesson-03-mapping-the-journey.md
 create mode 100644 docs/learn/module-08-outline-scenarios/module-08-outline-scenarios-overview.md
 create mode 100644 docs/learn/module-08-outline-scenarios/tutorial-08.md
 create mode 100644 docs/learn/module-09-conceptual-sketching/lesson-01-visualize-first.md
 create mode 100644 docs/learn/module-09-conceptual-sketching/lesson-02-sketching-techniques.md
 create mode 100644 docs/learn/module-09-conceptual-sketching/lesson-03-why-hand-sketching.md
 create mode 100644 docs/learn/module-09-conceptual-sketching/lesson-04-image-sketching-best-practices.md
 create mode 100644 docs/learn/module-09-conceptual-sketching/lesson-05-sketch-text-strategy.md
 create mode 100644 docs/learn/module-09-conceptual-sketching/lesson-06-ai-wireframe-generation.md
 create mode 100644 docs/learn/module-09-conceptual-sketching/module-09-conceptual-sketching-overview.md
 create mode 100644 docs/learn/module-09-conceptual-sketching/tutorial-09.md
 create mode 100644 docs/learn/module-10-storyboarding/lesson-01-transformations.md
 create mode 100644 docs/learn/module-10-storyboarding/lesson-02-storyboard-format.md
 create mode 100644 docs/learn/module-10-storyboarding/module-10-storyboarding-overview.md
 create mode 100644 docs/learn/module-10-storyboarding/tutorial-10.md
 create mode 100644 docs/learn/module-11-conceptual-specifications/lesson-01-design-is-specification.md
 create mode 100644 docs/learn/module-11-conceptual-specifications/lesson-02-section-widget-specifications.md
 create mode 100644 docs/learn/module-11-conceptual-specifications/lesson-03-element-state-specifications.md
 create mode 100644 docs/learn/module-11-conceptual-specifications/module-11-conceptual-specifications-overview.md
 create mode 100644 docs/learn/module-11-conceptual-specifications/storyboards/password-field.md
 create mode 100644 docs/learn/module-11-conceptual-specifications/storyboards/submit-button.md
 create mode 100644 docs/learn/module-11-conceptual-specifications/tutorial-11.md
 create mode 100644 docs/learn/module-12-functional-components/components/button.md
 create mode 100644 docs/learn/module-12-functional-components/components/card.md
 create mode 100644 docs/learn/module-12-functional-components/components/input.md
 create mode 100644 docs/learn/module-12-functional-components/lesson-01-patterns-emerge.md
 create mode 100644 docs/learn/module-12-functional-components/lesson-02-component-anatomy.md
 create mode 100644 docs/learn/module-12-functional-components/module-12-functional-components-overview.md
 create mode 100644 docs/learn/module-12-functional-components/tutorial-12.md
 create mode 100644 docs/learn/module-13-design-system/lesson-01-understanding-modes.md
 create mode 100644 docs/learn/module-13-design-system/module-13-design-system-overview.md
 create mode 100644 docs/learn/module-13-design-system/tutorial-13.md
 create mode 100644 docs/learn/module-14-agentic-development/lesson-01-iterative-building.md
 create mode 100644 docs/learn/module-14-agentic-development/lesson-02-documenting-decisions.md
 create mode 100644 docs/learn/module-14-agentic-development/lesson-03-when-you-get-stuck.md
 create mode 100644 docs/learn/module-14-agentic-development/lesson-04-working-with-code.md
 create mode 100644 docs/learn/module-14-agentic-development/lesson-05-git-discipline.md
 create mode 100644 docs/learn/module-14-agentic-development/module-14-agentic-development-overview.md
 create mode 100644 docs/learn/module-14-agentic-development/tutorial-14.md
 create mode 100644 docs/learn/module-15-visual-design/lesson-01-making-it-visible.md
 create mode 100644 docs/learn/module-15-visual-design/lesson-02-visual-techniques.md
 create mode 100644 docs/learn/module-15-visual-design/module-15-visual-design-overview.md
 create mode 100644 docs/learn/module-15-visual-design/tutorial-15.md
 create mode 100644 docs/learn/module-16-design-delivery/lesson-01-validation-packaging.md
 create mode 100644 docs/learn/module-16-design-delivery/module-16-design-delivery-overview.md
 create mode 100644 docs/learn/module-16-design-delivery/tutorial-16.md
 create mode 100644 docs/learn/module-17-usability-testing/lesson-01-spec-verification.md
 create mode 100644 docs/learn/module-17-usability-testing/lesson-02-test-results.md
 create mode 100644 docs/learn/module-17-usability-testing/lesson-03-acting-on-findings.md
 create mode 100644 docs/learn/module-17-usability-testing/module-17-usability-testing-overview.md
 create mode 100644 docs/learn/module-17-usability-testing/tutorial-17.md
 create mode 100644 docs/learn/module-18-product-evolution/lesson-01-continuous-improvement.md
 create mode 100644 docs/learn/module-18-product-evolution/lesson-02-update-spec-project-code.md
 create mode 100644 docs/learn/module-18-product-evolution/module-18-product-evolution-overview.md
 create mode 100644 docs/learn/module-18-product-evolution/tutorial-18.md
 create mode 100644 docs/learn/widgets/W01-task-list.md
 create mode 100644 docs/learn/widgets/W02-calendar.md
 create mode 100644 docs/learn/widgets/W02-product-card.md
 create mode 100644 docs/learn/widgets/W03-quick-add.md

diff --git a/.npmignore b/.npmignore
index 006025668..64bec51dc 100644
--- a/.npmignore
+++ b/.npmignore
@@ -1,3 +1,3 @@
 # Exclude internal material from npm package
-docs/learn-wds/course-explainers/
-docs/learn-wds/Webinars/
+docs/learn/course-explainers/
+docs/learn/Webinars/
diff --git a/README.md b/README.md
index 4e9ac1cda..a19072232 100644
--- a/README.md
+++ b/README.md
@@ -82,7 +82,7 @@ your-project/
 │   └── module.yaml          # Module definition
 ├── _wds-learn/              # Learning material (optional, safe to delete)
 │   ├── getting-started/
-│   ├── learn-wds/
+│   ├── learn/
 │   ├── method/
 │   ├── models/
 │   └── tools/
diff --git a/docs/docs-guide.md b/docs/docs-guide.md
index e831ef5d7..1c86c5ca5 100644
--- a/docs/docs-guide.md
+++ b/docs/docs-guide.md
@@ -50,14 +50,14 @@ Complete documentation for Whiteport Design Studio - a design-first methodology
 
 **How to use WDS with AI agents:** Step-by-step course using WDS agents + Cursor/Windsurf.
 
-- **[Complete WDS Course](learn-wds/)** - Sequential learning path
-- **[Course Overview](learn-wds/00-course-overview.md)** - What you'll learn
-- **[Module 01: Why WDS Matters](learn-wds/module-01-why-wds-matters/)** - The problem & solution
-- **[Module 02: Installation & Setup](learn-wds/module-02-installation-setup/)** - Get WDS running
-- **[Module 03: Alignment & Signoff](learn-wds/module-03-alignment-signoff/)** - Stakeholder alignment
-- **[Module 04: Product Brief](learn-wds/module-04-product-brief/)** - Create strategic foundation
-- **[Module 05: Trigger Mapping](learn-wds/module-05-map-triggers-outcomes/)** - Map user psychology
-- **[Module 06+](learn-wds/)** - Continue through all phases
+- **[Complete WDS Course](learn/)** - Sequential learning path
+- **[Course Overview](learn/00-course-overview.md)** - What you'll learn
+- **[Module 01: Why WDS Matters](learn/module-01-why-wds-matters/)** - The problem & solution
+- **[Module 02: Installation & Setup](learn/module-02-installation-setup/)** - Get WDS running
+- **[Module 03: Alignment & Signoff](learn/module-03-alignment-signoff/)** - Stakeholder alignment
+- **[Module 04: Product Brief](learn/module-04-product-brief/)** - Create strategic foundation
+- **[Module 05: Trigger Mapping](learn/module-05-map-triggers-outcomes/)** - Map user psychology
+- **[Module 06+](learn/)** - Continue through all phases
 
 **This course is WDS-specific** - teaching you to use Saga, Freya, and Idunn agents.
 
@@ -129,7 +129,7 @@ Complete documentation for Whiteport Design Studio - a design-first methodology
 → Read phase guides as needed
 
 **Learn to use WDS with AI agents**  
-→ Take the [Complete WDS Course](learn-wds/)  
+→ Take the [Complete WDS Course](learn/)  
 → Follow sequential modules
 
 **See what WDS creates**  
@@ -153,7 +153,7 @@ docs/
 ├── getting-started/      # Quick start guides (15 min total)
 ├── models/               # External strategic frameworks
 ├── method/               # Whiteport's methodology guides
-├── learn-wds/            # WDS-specific course (agent-driven)
+├── learn/            # WDS-specific course (agent-driven)
 ├── deliverables/         # Specifications for what you create
 ├── examples/             # Real project examples
 └── README.md             # This navigation hub
@@ -163,7 +163,7 @@ docs/
 
 1. **models/** → "What are the foundational frameworks?" (external, attributed)
 2. **method/** → "How does WDS methodology work?" (Whiteport instruments)
-3. **learn-wds/** → "How do I use WDS agents?" (WDS-specific)
+3. **learn/** → "How do I use WDS agents?" (WDS-specific)
 4. **examples/** → "Show me a real project" (reference implementation)
 
 ---
diff --git a/docs/examples/WDS-Presentation/docs/1-project-brief/invitation-snippets.md b/docs/examples/WDS-Presentation/docs/1-project-brief/invitation-snippets.md
index 07e959bc4..0b1b8f4d4 100644
--- a/docs/examples/WDS-Presentation/docs/1-project-brief/invitation-snippets.md
+++ b/docs/examples/WDS-Presentation/docs/1-project-brief/invitation-snippets.md
@@ -194,7 +194,7 @@ https://www.youtube.com/watch?v=TdujvNYI-3g&list=PL094dWo_kC3t1Z0fs85P99ZK5T3tPv
 There's a course overview that walks through the WDS approach step by step. It covers working in the IDE, creating foundations, design systems, and collaborating with developers.
 
 No pressure, but here it is if you want to explore:
-https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/00-course-overview.md
+https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/00-course-overview.md
 ```
 
 ### Swedish
@@ -202,7 +202,7 @@ https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/mo
 Det finns en kursöversikt som går igenom WDS-tillvägagångssättet steg för steg. Den täcker att jobba i IDE:n, skapa grunder, designsystem och samarbeta med utvecklare.
 
 Ingen press, men här är den om du vill utforska:
-https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/00-course-overview.md
+https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/00-course-overview.md
 ```
 
 ---
@@ -320,7 +320,7 @@ https://github.com/whiteport-collective/whiteport-design-studio
 Found this course about WDS that walks through working in the IDE, creating foundations, design systems, and collaborating with developers using AI agents.
 
 It's free and might be helpful if you're interested in this kind of thing:
-https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/00-course-overview.md
+https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/00-course-overview.md
 ```
 
 ### Swedish
@@ -328,7 +328,7 @@ https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/mo
 Hittade den här kursen om WDS som går igenom att jobba i IDE:n, skapa grunder, designsystem och samarbeta med utvecklare med hjälp av AI-agenter.
 
 Den är gratis och kan vara till hjälp om du är intresserad av den här typen av saker:
-https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/00-course-overview.md
+https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/00-course-overview.md
 ```
 
 ---
diff --git a/docs/examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md b/docs/examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md
index 5c585feb9..453f9ecea 100644
--- a/docs/examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md
+++ b/docs/examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md
@@ -317,10 +317,10 @@ The WDS Presentation page serves as the primary entry point for designers discov
 <h3 style="margin-top: 0;">Module 00: Getting Started with WDS</h3>
 <p>Learn the fundamentals of WDS and get your environment set up. This module covers everything you need to know to start your journey with Whiteport Design Studio - from understanding the core concepts to installing the framework and activating your first AI agent.</p>
 <ul>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/00-course-overview/00-getting-started-overview.md">Module Introduction</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/00-course-overview/01-prerequisites.md">Lesson 01: Prerequisites &amp; Setup Requirements</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/00-course-overview/02-learning-paths.md">Lesson 02: Choose Your Learning Path</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/00-course-overview/03-support.md">Lesson 03: Getting Support &amp; Community</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/00-course-overview/00-getting-started-overview.md">Module Introduction</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/00-course-overview/01-prerequisites.md">Lesson 01: Prerequisites &amp; Setup Requirements</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/00-course-overview/02-learning-paths.md">Lesson 02: Choose Your Learning Path</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/00-course-overview/03-support.md">Lesson 03: Getting Support &amp; Community</a></li>
 </ul>
 </td>
 </tr>
@@ -339,10 +339,10 @@ The WDS Presentation page serves as the primary entry point for designers discov
 <h3 style="margin-top: 0;">Module 01: Why WDS Matters</h3>
 <p>Discover why traditional design-to-development handoffs fail and how WDS transforms the designer's role from task-doer to strategic leader. Learn about the AI revolution in product development and why conceptual specifications are the key to staying relevant.</p>
 <ul>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-01-why-wds-matters/module-01-overview.md">Module Introduction</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-01-why-wds-matters/lesson-01-the-problem.md">Lesson 01: The Problem - Lost Design Intent</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-01-why-wds-matters/lesson-02-the-solution.md">Lesson 02: The Solution - Conceptual Specifications</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-01-why-wds-matters/lesson-03-the-path-forward.md">Lesson 03: The Path Forward - Your Role in the AI Era</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-01-why-wds-matters/module-01-overview.md">Module Introduction</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-01-why-wds-matters/lesson-01-the-problem.md">Lesson 01: The Problem - Lost Design Intent</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-01-why-wds-matters/lesson-02-the-solution.md">Lesson 02: The Solution - Conceptual Specifications</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-01-why-wds-matters/lesson-03-the-path-forward.md">Lesson 03: The Path Forward - Your Role in the AI Era</a></li>
 </ul>
 </td>
 </tr>
@@ -361,7 +361,7 @@ The WDS Presentation page serves as the primary entry point for designers discov
 <h3 style="margin-top: 0;">Module 02: Installation &amp; Setup</h3>
 <p>Get WDS installed and running on your machine. This hands-on module walks you through GitHub setup, IDE configuration, cloning the repository, and activating your first AI agent. By the end, you'll have a fully functional WDS environment ready for your first project.</p>
 <ul>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-02-installation-setup/module-02-overview.md">Module Introduction</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-02-installation-setup/module-02-overview.md">Module Introduction</a></li>
 <li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/getting-started/installation.md">Lesson 01: GitHub &amp; IDE Setup</a></li>
 <li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/getting-started/quick-start.md">Lesson 02: Quick Start Guide</a></li>
 </ul>
@@ -382,10 +382,10 @@ The WDS Presentation page serves as the primary entry point for designers discov
 <h3 style="margin-top: 0;">Module 03: Alignment &amp; Signoff</h3>
 <p>Get stakeholders aligned and secure commitment before starting the project. Learn the discovery discipline, create compelling alignment documents, and generate appropriate signoff documents (external contracts or internal signoff). Master the art of understanding before solving.</p>
 <ul>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-03-alignment-signoff/module-03-overview.md">Module Introduction</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-03-alignment-signoff/lesson-01-understanding-alignment.md">Lesson 01: Understanding Alignment</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-03-alignment-signoff/lesson-02-creating-alignment-document.md">Lesson 02: Creating Your Alignment Document</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md">Lesson 03: Negotiation &amp; Acceptance</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-03-alignment-signoff/module-03-overview.md">Module Introduction</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-03-alignment-signoff/lesson-01-understanding-alignment.md">Lesson 01: Understanding Alignment</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-03-alignment-signoff/lesson-02-creating-alignment-document.md">Lesson 02: Creating Your Alignment Document</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md">Lesson 03: Negotiation &amp; Acceptance</a></li>
 </ul>
 </td>
 </tr>
@@ -404,8 +404,8 @@ The WDS Presentation page serves as the primary entry point for designers discov
 <h3 style="margin-top: 0;">Module 04: Product Brief</h3>
 <p>Create your strategic foundation through AI-guided conversation. Learn how the Product Brief becomes the most powerful prompt you'll ever create - stopping AI hallucinations before they start and making your idea better through 30 structured questions. Everything happens in one environment with zero copy-paste chaos.</p>
 <ul>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-04-product-brief/module-04-overview.md">Module Introduction</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-04-product-brief/tutorial-04.md">Tutorial 04: Creating Your Product Brief with Saga</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-04-product-brief/module-04-overview.md">Module Introduction</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-04-product-brief/tutorial-04.md">Tutorial 04: Creating Your Product Brief with Saga</a></li>
 </ul>
 </td>
 </tr>
@@ -424,19 +424,19 @@ The WDS Presentation page serves as the primary entry point for designers discov
 <h3 style="margin-top: 0;">Module 05: Trigger Mapping</h3>
 <p>Connect business goals to user psychology through 5 structured workshops. Learn the proven Effect Management methodology (20+ years heritage), map both positive and negative psychological drivers, and create a visual one-page strategy map. Includes systematic feature scoring for data-driven prioritization.</p>
 <ul>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/module-05-overview.md">Module Introduction</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-01-missing-link.md">Lesson 01: The Missing Link</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-02-heritage-evolution.md">Lesson 02: The Heritage &amp; Evolution</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-03-five-workshops-overview.md">Lesson 03: The Five Workshops Overview</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-04-workshop-1-business-goals.md">Lesson 04: Workshop 1 - Business Goals</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-05-workshop-2-target-groups.md">Lesson 05: Workshop 2 - Target Groups</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-06-workshop-3-driving-forces.md">Lesson 06: Workshop 3 - Driving Forces</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-07-workshop-4-prioritization.md">Lesson 07: Workshop 4 - Prioritization</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-08-workshop-5-feature-impact.md">Lesson 08: Workshop 5 - Feature Impact</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-09-positive-negative-drivers.md">Lesson 09: Positive &amp; Negative Drivers</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-10-visual-trigger-map.md">Lesson 10: The Visual Trigger Map</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/lesson-11-feature-impact-scoring.md">Lesson 11: Feature Impact Scoring</a></li>
-<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn-wds/module-05-trigger-mapping/tutorial-05.md">Tutorial 05: Creating Your Trigger Map with Saga</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/module-05-overview.md">Module Introduction</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-01-missing-link.md">Lesson 01: The Missing Link</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-02-heritage-evolution.md">Lesson 02: The Heritage &amp; Evolution</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-03-five-workshops-overview.md">Lesson 03: The Five Workshops Overview</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-04-workshop-1-business-goals.md">Lesson 04: Workshop 1 - Business Goals</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-05-workshop-2-target-groups.md">Lesson 05: Workshop 2 - Target Groups</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-06-workshop-3-driving-forces.md">Lesson 06: Workshop 3 - Driving Forces</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-07-workshop-4-prioritization.md">Lesson 07: Workshop 4 - Prioritization</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-08-workshop-5-feature-impact.md">Lesson 08: Workshop 5 - Feature Impact</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-09-positive-negative-drivers.md">Lesson 09: Positive &amp; Negative Drivers</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-10-visual-trigger-map.md">Lesson 10: The Visual Trigger Map</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/lesson-11-feature-impact-scoring.md">Lesson 11: Feature Impact Scoring</a></li>
+<li><a href="https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/docs/learn/module-05-trigger-mapping/tutorial-05.md">Tutorial 05: Creating Your Trigger Map with Saga</a></li>
 </ul>
 </td>
 </tr>
diff --git a/docs/examples/wds-examples-guide.md b/docs/examples/wds-examples-guide.md
index 2b0ed5496..820cfab49 100644
--- a/docs/examples/wds-examples-guide.md
+++ b/docs/examples/wds-examples-guide.md
@@ -83,7 +83,7 @@ While these are real projects (not sanitized templates), you can:
 
 - **[Getting Started](../getting-started/)** - Installation and quick start
 - **[Method Guides](../method/)** - Tool-agnostic methodology references
-- **[Learn WDS Course](../learn-wds/)** - Step-by-step learning path
+- **[Learn WDS Course](../learn/)** - Step-by-step learning path
 - **[Workflows](../src/workflows/)** - Detailed workflow instructions
 
 ---
diff --git a/docs/examples/wds-v6-conversion/F-Agent-Dialogs/2026-01-23-saga-course-workflow-integration/2026-01-23-saga-course-workflow-integration-dialog.md b/docs/examples/wds-v6-conversion/F-Agent-Dialogs/2026-01-23-saga-course-workflow-integration/2026-01-23-saga-course-workflow-integration-dialog.md
index 9700732af..1428853be 100644
--- a/docs/examples/wds-v6-conversion/F-Agent-Dialogs/2026-01-23-saga-course-workflow-integration/2026-01-23-saga-course-workflow-integration-dialog.md
+++ b/docs/examples/wds-v6-conversion/F-Agent-Dialogs/2026-01-23-saga-course-workflow-integration/2026-01-23-saga-course-workflow-integration-dialog.md
@@ -86,7 +86,7 @@ Integrate recently added WDS features into the course materials:
 
 ### Rough Approach
 
-1. Create new learn-wds module: "Working with Agent Dialogs"
+1. Create new learn module: "Working with Agent Dialogs"
 2. Update page specification lessons to include Open Questions
 3. Add Eira to agent personas documentation
 4. Create hands-on exercises for each feature
@@ -111,7 +111,7 @@ These three features represent significant additions to the WDS methodology:
 
 ### Open Questions
 
-- Which learn-wds module should Agent Dialogs go in? (New module or extend existing?)
+- Which learn module should Agent Dialogs go in? (New module or extend existing?)
 - Should Open Questions be part of the page specification lesson or standalone?
 - Is Eira documented enough to add to the course, or needs more definition first?
 - Should we create a dedicated example project showcasing all three features?
@@ -134,7 +134,7 @@ These three features represent significant additions to the WDS methodology:
 ## When I Return
 
 1. Review all three feature locations and documentation
-2. Check existing learn-wds modules for best placement
+2. Check existing learn modules for best placement
 3. Draft course content outline for each feature
 4. Create hands-on exercises
 5. Identify any gaps in feature documentation that need filling first
diff --git a/docs/examples/wds-v6-conversion/F-Agent-Dialogs/WDS-BMAD-INTEGRATION-REPORT.md b/docs/examples/wds-v6-conversion/F-Agent-Dialogs/WDS-BMAD-INTEGRATION-REPORT.md
index 2caa3d19c..455ef3fd6 100644
--- a/docs/examples/wds-v6-conversion/F-Agent-Dialogs/WDS-BMAD-INTEGRATION-REPORT.md
+++ b/docs/examples/wds-v6-conversion/F-Agent-Dialogs/WDS-BMAD-INTEGRATION-REPORT.md
@@ -44,7 +44,7 @@ src/modules/wds/
 │   ├── getting-started/       ✅ Installation, quick start, activation
 │   ├── method/                ✅ 11 methodology guides (tool-agnostic)
 │   ├── models/                ✅ 6 strategic models (external frameworks)
-│   ├── learn-wds/             ✅ 12 modules (agent-driven course)
+│   ├── learn/             ✅ 12 modules (agent-driven course)
 │   ├── deliverables/          ✅ 8 artifact specifications
 │   └── examples/              ✅ 2 real projects (WDS-Presentation, v6-conversion)
 ├── templates/                 ✅ 3 YAML templates
@@ -292,7 +292,7 @@ src/modules/wds/
 
 ---
 
-#### 4. Learn WDS Course (`docs/learn-wds/`)
+#### 4. Learn WDS Course (`docs/learn/`)
 
 **12 Sequential Modules:**
 - Module 00: Course Overview
@@ -561,7 +561,7 @@ src/modules/wds/
 **Issue:** Module numbering inconsistent (skips 7, 11, 13+)  
 **Impact:** Low - course still functional  
 **Recommendation:** Audit and renumber in future release  
-**File:** `learn-wds-audit.md` (created during analysis)
+**File:** `learn-audit.md` (created during analysis)
 
 ---
 
diff --git a/docs/examples/wds-v6-conversion/F-Agent-Dialogs/WDS-DEEP-ANALYSIS-SUMMARY.md b/docs/examples/wds-v6-conversion/F-Agent-Dialogs/WDS-DEEP-ANALYSIS-SUMMARY.md
index f5c39e1c1..3b937166b 100644
--- a/docs/examples/wds-v6-conversion/F-Agent-Dialogs/WDS-DEEP-ANALYSIS-SUMMARY.md
+++ b/docs/examples/wds-v6-conversion/F-Agent-Dialogs/WDS-DEEP-ANALYSIS-SUMMARY.md
@@ -190,7 +190,7 @@ Integration Readiness:   ✅ 95% (testing in BMad needed)
 ### For WDS Team
 
 1. **Monitor Alpha Feedback** - VTC Workshop validation
-2. **Course Audit** - Fix learn-wds module numbering (future release)
+2. **Course Audit** - Fix learn module numbering (future release)
 3. **README Cleanup** - Consider renaming workflow README.md files (future release)
 
 ---
diff --git a/docs/examples/wds-v6-conversion/F-Agent-Dialogs/wds-v6-conversion-guide.md b/docs/examples/wds-v6-conversion/F-Agent-Dialogs/wds-v6-conversion-guide.md
index 6c1186036..ceb1b5ea1 100644
--- a/docs/examples/wds-v6-conversion/F-Agent-Dialogs/wds-v6-conversion-guide.md
+++ b/docs/examples/wds-v6-conversion/F-Agent-Dialogs/wds-v6-conversion-guide.md
@@ -257,7 +257,7 @@ DD-XXX for everything (instead of DD-XXX + SU-XXX) reduced complexity while main
 - **WDS Method Guides:** `../../method/`
 - **WDS Workflows:** `../../src/workflows/`
 - **Other Examples:** `../` (WDS Presentation, etc.)
-- **Course Materials:** `../../learn-wds/`
+- **Course Materials:** `../../learn/`
 
 ---
 
diff --git a/docs/getting-started/installation.md b/docs/getting-started/installation.md
index 0dc319a6a..d1bcfca6f 100644
--- a/docs/getting-started/installation.md
+++ b/docs/getting-started/installation.md
@@ -45,7 +45,7 @@ You should see:
 
 - [About WDS](about-wds.md) - Understand what WDS is and why it exists
 - [Quick Start Guide](quick-start.md) - Your first 5 minutes
-- [Learn WDS Course](../learn-wds/00-course-overview.md) - Learn the concepts deeply
+- [Learn WDS Course](../learn/00-course-overview.md) - Learn the concepts deeply
 
 ---
 
diff --git a/docs/getting-started/quick-start.md b/docs/getting-started/quick-start.md
index 66f30bd5c..d6693ba48 100644
--- a/docs/getting-started/quick-start.md
+++ b/docs/getting-started/quick-start.md
@@ -110,7 +110,7 @@ You created **conceptual specifications** in 5 minutes:
 
 ### Learn the Concepts
 
-[Learn WDS Course](../learn-wds/00-course-overview.md) - Deep dive into WDS methodology
+[Learn WDS Course](../learn/00-course-overview.md) - Deep dive into WDS methodology
 
 ### Start Your Project
 
diff --git a/docs/getting-started/where-to-go-next.md b/docs/getting-started/where-to-go-next.md
index d01411772..0e95afa14 100644
--- a/docs/getting-started/where-to-go-next.md
+++ b/docs/getting-started/where-to-go-next.md
@@ -8,13 +8,13 @@
 
 ### 🎓 Take the Course
 
-**[WDS Course: From Designer to Linchpin](../learn-wds/00-course-overview.md)**
+**[WDS Course: From Designer to Linchpin](../learn/00-course-overview.md)**
 
 Complete training from project brief to AI-ready specifications:
 
 **Module 01: Why WDS Matters**  
 Learn how to be indispensable in the AI era. Understand the paradigm shift where design becomes specification.  
-→ [Start Module 01](../learn-wds/module-01-why-wds-matters/module-01-overview.md)
+→ [Start Module 01](../learn/module-01-why-wds-matters/module-01-overview.md)
 
 **Modules 02-16: Complete WDS Workflow**  
 Master every phase from trigger mapping through design system to development handoff. Each module includes:
@@ -23,7 +23,7 @@ Master every phase from trigger mapping through design system to development han
 - **Tutorials** - Step-by-step hands-on guides
 - **Practice** - Apply to your own project
 
-→ [View All Modules](../learn-wds/00-course-overview.md)
+→ [View All Modules](../learn/00-course-overview.md)
 
 **Best for:** Comprehensive learning with structured curriculum
 
@@ -39,11 +39,11 @@ Step-by-step workflows for:
 
 **Phase 1: Project Brief**  
 Define vision, goals, stakeholders, and constraints that guide all design decisions.  
-→ [Tutorial: Create Project Brief](../learn-wds/module-04-product-brief/tutorial-04.md)
+→ [Tutorial: Create Project Brief](../learn/module-04-product-brief/tutorial-04.md)
 
 **Phase 2: Trigger Mapping**  
 Understand WHO your users are, WHAT triggers their needs, and WHY your business exists. Create a Trigger Map that connects user psychology to business value.  
-→ [Tutorial: Map Triggers & Outcomes](../learn-wds/module-05-map-triggers-outcomes/tutorial-04.md)
+→ [Tutorial: Map Triggers & Outcomes](../learn/module-05-map-triggers-outcomes/tutorial-04.md)
 
 **Phase 3: Platform Requirements**  
 Document technical constraints, integrations, and infrastructure needs.  
@@ -51,7 +51,7 @@ Document technical constraints, integrations, and infrastructure needs.
 
 **Phase 4: UX Design**  
 Transform ideas into conceptual specifications that preserve your design intent. AI agents help you think through solutions, then capture your brilliance in specifications that give your designs eternal life.  
-→ [Tutorial: Initialize Scenario](../learn-wds/module-08-initialize-scenario/tutorial-08.md) | [Tutorial: Conceptual Specs](../learn-wds/module-12-conceptual-specs/tutorial-12.md)
+→ [Tutorial: Initialize Scenario](../learn/module-08-initialize-scenario/tutorial-08.md) | [Tutorial: Conceptual Specs](../learn/module-12-conceptual-specs/tutorial-12.md)
 
 **Phase 5: Design System**  
 Extract design tokens, create reusable components, and generate interactive HTML catalog.  
@@ -123,14 +123,14 @@ Join the WDS community for:
 
 ## Quick Links
 
-- [Course](../learn-wds/00-course-overview.md)
+- [Course](../learn/00-course-overview.md)
 - [Workflows](../wds-workflows-guide.md)
 - [Modular Architecture](../src/workflows/4-ux-design/modular-architecture/00-MODULAR-ARCHITECTURE-GUIDE.md)
 - [Conceptual Specifications](../src/workflows/4-ux-design/CONCEPTUAL-SPECIFICATIONS.md)
 
 ---
 
-**Ready to dive deeper? Start with the [Course](../learn-wds/00-course-overview.md)!**
+**Ready to dive deeper? Start with the [Course](../learn/00-course-overview.md)!**
 
 ---
 
diff --git a/docs/learn-wds/00-course-overview.md b/docs/learn-wds/00-course-overview.md
deleted file mode 100644
index 5b5d7f4b9..000000000
--- a/docs/learn-wds/00-course-overview.md
+++ /dev/null
@@ -1,211 +0,0 @@
-# WDS Course: From Designer to Linchpin
-
-**Master the complete WDS methodology and become indispensable as a designer in the AI era**
-
-[Watch the Course Introduction Video](https://www.youtube.com/watch?v=CQ5Aai_r-uo)
-
----
-
-## Welcome to the WDS Course
-
-This comprehensive course teaches you the complete WDS workflow through **practical modules** that transform how you design products.
-
-**The paradigm shift:**
-
-- The design becomes the specification
-- The specification becomes the product
-- The code is just the printout
-
-**What you'll become:**
-
-- The linchpin designer who makes things happen
-- The gatekeeper between business goals and user needs
-- The irreplaceable designer in the AI era
-
-**Time investment:** ~10 hours total
-**Result:** Complete mastery of WDS methodology from project brief to AI-ready specifications
-
----
-
-## Who Created WDS?
-
-**Mårten Angner** is a UX designer and founder of Whiteport, a design and development agency based in Sweden. After years of working with AI tools, Mårten observed that traditional design handoffs were breaking down. Designers would create beautiful mockups, hand them off to developers, and watch their creative intent get lost in translation.
-
-Mårten developed WDS to solve this problem - a methodology where design thinking is preserved and amplified through AI implementation, not diluted and lost.
-
-**The Mission:** WDS is completely free and open-source. Mårten created it as a **plugin module for BMad Method** - an open-source AI-augmented development framework - to give designers everywhere the tools they need to thrive in the AI era.
-
----
-
-## Before You Start
-
-**[→ Getting Started Guide](00-getting-started/overview.md)**
-
-Review prerequisites, choose your learning path, and get support:
-
-- **Prerequisites** - Skills, tools, time investment
-- **Learning Paths** - Full immersion, quick start, or self-paced
-- **Support** - Testimonials, FAQ, community
-
-**Reading time:** ~15 minutes
-
----
-
-## Course Structure
-
-Each module contains:
-
-- **Lessons** - Theory and concepts (with NotebookLM audio support)
-- **Tutorial** - Step-by-step hands-on guide (for practical modules)
-- **Practice** - Apply to your own project
-
-**Learning format:**
-
-- **Lessons** - Read as documentation or generate audio with NotebookLM
-- **Tutorials** - Follow step-by-step guides with AI support
-- **Practice** - Apply to real projects as you learn
-- **Workshops** - Use for team training
-
----
-
-## Course Modules
-
-### Foundation
-
-- [Module 01: Why WDS Matters](module-01-why-wds-matters/module-01-overview.md)
-- [Module 02: Installation & Setup](module-02-installation-setup/module-02-overview.md) • [Tutorial →](module-02-installation-setup/tutorial-02.md)
-
-### Pre-Phase 1: Alignment & Signoff (Optional)
-
-- [Module 03: Alignment & Signoff](module-03-alignment-signoff/module-03-overview.md) • [Tutorial →](module-03-alignment-signoff/tutorial-03.md)  
-  *Skip if doing it yourself - go straight to Project Brief*
-
-### Phase 1: Project Brief
-
-- [Module 04: Create Project Brief](module-04-project-brief/) • [Tutorial →](module-04-project-brief/tutorial-04.md)
-
-### Phase 2: Trigger Mapping
-
-- [Module 04: Identify Target Groups](module-04-identify-target-groups/)
-- [Module 05: Map Triggers & Outcomes](module-05-map-triggers-outcomes/) • [Tutorial →](module-05-map-triggers-outcomes/tutorial-05.md)
-- [Module 06: Prioritize Features](module-06-prioritize-features/)
-
-### Phase 3: Platform Requirements
-
-- [Module 07: Platform Requirements](module-07-platform-requirements/)
-- [Module 08: Functional Requirements](module-08-functional-requirements/)
-
-### Phase 4: Conceptual Design (UX Design)
-
-- [Module 09: Initialize Scenario](module-09-initialize-scenario/) • [Tutorial →](module-09-initialize-scenario/tutorial-09.md)
-- [Module 10: Sketch Interfaces](module-10-sketch-interfaces/)
-- [Module 11: Analyze with AI](module-11-analyze-with-ai/)
-- [Module 12: Decompose Components](module-12-decompose-components/)
-- [Module 13: Conceptual Specifications](module-13-conceptual-specs/) • [Tutorial →](module-13-conceptual-specs/tutorial-13.md)
-- [Module 14: Validate Specifications](module-14-validate-specifications/)
-
-### Phase 5: Design System
-
-- [Module 15: Extract Design Tokens](module-15-extract-design-tokens/)
-- [Module 16: Component Library](module-16-component-library/)
-
-### Phase 6: Development Integration
-
-- [Module 17: UI Roadmap](module-17-ui-roadmap/)
-
----
-
-## Learning Paths
-
-**Complete Course:** All 17 modules (~12 hours)
-
-**Quick Start:** Modules 1, 2, 5, 9, 13 (~4 hours)
-
-**Phase-Specific:** Jump to any phase as needed
-
----
-
-## NotebookLM Integration
-
-Each module has matching content for NotebookLM:
-
-- Feed module lessons to NotebookLM
-- Generate audio podcasts for learning on the go
-- Generate video presentations for team training
-- Create study guides and summaries
-
-**All modules are optimized for AI-assisted learning.**
-
----
-
-## Module Structure
-
-Every module follows the same pattern:
-
-**1. Inspiration (10 min)**
-
-- Why this step matters
-- The transformation you'll experience
-- Real-world impact
-
-**2. Teaching (20 min)**
-
-- How to do it with confidence
-- AI support at each step
-- Dog Week example walkthrough
-
-**3. Practice (10 min)**
-
-- Apply to your own project
-- Step-by-step instructions
-- Success criteria
-
-**4. Tutorial (optional)**
-
-- Quick step-by-step guide
-- "Just show me how to do it"
-- For practical modules only
-
----
-
-## After the Course
-
-Once you've completed the modules:
-
-1. **[Workflows Guide](../workflows/WDS-WORKFLOWS-GUIDE.md)** - Reference documentation
-2. **[Quick Start](../getting-started/quick-start.md)** - Try WDS with agent
-3. **[Community](https://discord.gg/whiteport)** - Get help and share your work
-
----
-
-## Prerequisites
-
-**What you need:**
-
-- Basic design thinking and UX principles
-- Ability to sketch interfaces (hand-drawn or digital)
-- Understanding of user needs and business goals
-- Willingness to think deeply about WHY
-
-**What you DON'T need:**
-
-- ❌ Coding skills
-- ❌ Advanced technical knowledge
-- ❌ Experience with AI tools
-- ❌ Formal design education
-
-**If you can design interfaces and explain your thinking, you're ready to start.**
-
----
-
-## Ready to Begin?
-
-Ten hours of learning. A lifetime of being indispensable.
-
-**[Start with Module 01: Why WDS Matters →](module-01-why-wds-matters/module-01-overview.md)**
-
----
-
-**This course is free and open-source**
-**Created by Mårten Angner and the Whiteport team**
-**Integrated with BMad Method for seamless design-to-development workflow**
diff --git a/docs/learn-wds/Webinars/2024-12-22-WDS-Jam-1-Say-Hello-to-AI-Agent-Framework.md b/docs/learn-wds/Webinars/2024-12-22-WDS-Jam-1-Say-Hello-to-AI-Agent-Framework.md
deleted file mode 100644
index e69de29bb..000000000
diff --git a/docs/learn-wds/course-explainers/Module 00-transcript.srt b/docs/learn-wds/course-explainers/Module 00-transcript.srt
deleted file mode 100644
index 30c62006f..000000000
--- a/docs/learn-wds/course-explainers/Module 00-transcript.srt	
+++ /dev/null
@@ -1,635 +0,0 @@
-1
-00:00:00,220 --> 00:00:02,723
-All right, let's get right into it. We're
-
-2
-00:00:02,723 --> 00:00:04,600
-talking about something that is sitting
-
-3
-00:00:04,600 --> 00:00:07,103
-at the absolute heart of being a designer
-
-4
-00:00:07,103 --> 00:00:08,980
-today. It's a choice, a really
-
-5
-00:00:08,980 --> 00:00:10,544
-fundamental choice that frankly, every
-
-6
-00:00:10,544 --> 00:00:13,360
-single one of us has to make now that
-
-7
-00:00:13,360 --> 00:00:16,176
-AI is in the picture. And really, it all
-
-8
-00:00:16,176 --> 00:00:18,053
-comes down to this one question.
-
-9
-00:00:18,053 --> 00:00:20,873
-Seriously, in the age of AI. Are you
-
-10
-00:00:20,873 --> 00:00:23,407
-going to be replaceable or are you going
-
-11
-00:00:23,407 --> 00:00:25,624
-to be indispensable? This isn't about the
-
-12
-00:00:25,624 --> 00:00:28,158
-software you use or how fast you can
-
-13
-00:00:28,158 --> 00:00:30,692
-work, it's about who you decide to be.
-
-14
-00:00:30,692 --> 00:00:33,225
-See, to really get this, you have to
-
-15
-00:00:33,225 --> 00:00:35,759
-understand that we are at a major turning
-
-16
-00:00:35,759 --> 00:00:38,293
-point. This isn't just some new trend or
-
-17
-00:00:38,293 --> 00:00:40,827
-another tool to learn now. This is a
-
-18
-00:00:40,827 --> 00:00:43,254
-genuine crossroads. And the path you take
-
-19
-00:00:43,254 --> 00:00:45,709
-from here is going to define your entire
-
-20
-00:00:45,709 --> 00:00:48,164
-career. OK, so look at these two paths.
-
-21
-00:00:48,164 --> 00:00:50,312
-On one side, you've got the factory
-
-22
-00:00:50,312 --> 00:00:51,847
-designer. This is probably pretty
-
-23
-00:00:51,847 --> 00:00:53,995
-familiar, right? You get a ticket, you
-
-24
-00:00:53,995 --> 00:00:56,143
-execute on it. You deliver some mockups.
-
-25
-00:00:56,143 --> 00:00:57,984
-It's predictable work. But here's the
-
-26
-00:00:57,984 --> 00:00:59,826
-catch. That's the work you're now
-
-27
-00:00:59,826 --> 00:01:02,557
-competing with AI to do. But then
-
-28
-00:01:02,557 --> 00:01:04,709
-there's the other path, the linchpin
-
-29
-00:01:04,709 --> 00:01:06,501
-designer. This person doesn't just
-
-30
-00:01:06,501 --> 00:01:09,011
-execute, they create order out of total
-
-31
-00:01:09,011 --> 00:01:11,880
-chaos. They find the human truth in a
-
-32
-00:01:11,880 --> 00:01:14,031
-project and deliver strategy. One is
-
-33
-00:01:14,031 --> 00:01:15,824
-replaceable, the other is indispensable.
-
-34
-00:01:15,824 --> 00:01:18,693
-So you might be asking, why is that
-
-35
-00:01:18,693 --> 00:01:21,203
-factory designer path so dangerous all of
-
-36
-00:01:21,203 --> 00:01:24,065
-a sudden?Well, it boils down to
-
-37
-00:01:24,065 --> 00:01:26,729
-this new threat that is just taking over
-
-38
-00:01:26,729 --> 00:01:28,727
-the Internet. And that threat is
-
-39
-00:01:28,727 --> 00:01:31,058
-something called AI slop. We are all
-
-40
-00:01:31,058 --> 00:01:33,389
-seeing it. The Internet is just getting
-
-41
-00:01:33,389 --> 00:01:35,054
-flooded with these generic soulless
-
-42
-00:01:35,054 --> 00:01:37,718
-interfaces. I mean, they look OK on the
-
-43
-00:01:37,718 --> 00:01:39,716
-surface. They've got all the right
-
-44
-00:01:39,716 --> 00:01:42,047
-buttons, but they feel empty. There's no
-
-45
-00:01:42,047 --> 00:01:43,890
-spark. No soul, nothing that actually
-
-46
-00:01:43,890 --> 00:01:45,864
-connects with a real human being. And
-
-47
-00:01:45,864 --> 00:01:48,119
-here's the part that's kind of tough to
-
-48
-00:01:48,119 --> 00:01:50,657
-hear, but we have to face it. AI is
-
-49
-00:01:50,657 --> 00:01:52,913
-amazing at that factory work. If your job
-
-50
-00:01:52,913 --> 00:01:55,451
-is just to churn out mockups and follow a
-
-51
-00:01:55,451 --> 00:01:56,861
-system, well, you're competing against
-
-52
-00:01:56,861 --> 00:01:58,552
-something that can do it instantly,
-
-53
-00:01:58,552 --> 00:02:00,244
-perfectly, and can try 100 different
-
-54
-00:02:00,244 --> 00:02:02,500
-versions in a minute. And you know what?
-
-55
-00:02:02,670 --> 00:02:05,477
-It never gets tired and it never needs a
-
-56
-00:02:05,477 --> 00:02:07,348
-coffee break. This creates a really
-
-57
-00:02:07,348 --> 00:02:09,842
-brutal new reality in the market. It used
-
-58
-00:02:09,842 --> 00:02:12,025
-to be that a mediocre, soulless product
-
-59
-00:02:12,025 --> 00:02:14,832
-would at least gets a launch and then it
-
-60
-00:02:14,832 --> 00:02:17,015
-would fail. But today, users can spot
-
-61
-00:02:17,015 --> 00:02:19,198
-that generic nobody cared about this vibe
-
-62
-00:02:19,198 --> 00:02:21,381
-a mile away. These products don't even
-
-63
-00:02:21,381 --> 00:02:23,642
-get the chance to fail. Anymore, they're
-
-64
-00:02:23,642 --> 00:02:25,856
-just ignored from the very beginning. OK,
-
-65
-00:02:25,856 --> 00:02:28,069
-so if competing with AI on production
-
-66
-00:02:28,069 --> 00:02:30,915
-work is a dead end, how in the world
-
-67
-00:02:30,915 --> 00:02:32,812
-do you become that indispensable lynchpin
-
-68
-00:02:32,812 --> 00:02:34,709
-designer? Well, it's not about working
-
-69
-00:02:34,709 --> 00:02:36,922
-harder. It's about a complete shift in
-
-70
-00:02:36,922 --> 00:02:39,768
-how you see your job. And that shift is
-
-71
-00:02:39,768 --> 00:02:41,665
-really the core of this methodology
-
-72
-00:02:41,665 --> 00:02:44,071
-called white port design. Audio, or WDS
-
-73
-00:02:44,071 --> 00:02:46,501
-for short, and it totally reframes what
-
-74
-00:02:46,501 --> 00:02:49,278
-you do with WTF. You're not just making
-
-75
-00:02:49,278 --> 00:02:51,708
-pictures of a product, you are literally
-
-76
-00:02:51,708 --> 00:02:53,444
-architecting the product itself. Think
-
-77
-00:02:53,444 --> 00:02:56,221
-about it this way, Your design is the
-
-78
-00:02:56,221 --> 00:02:58,303
-blueprint, it is the specification, the
-
-79
-00:02:58,303 --> 00:03:01,080
-code at the very end. That's just the
-
-80
-00:03:01,080 --> 00:03:03,163
-final print out of your brilliant
-
-81
-00:03:03,163 --> 00:03:05,762
-thinking. Now, this is so important
-
-82
-00:03:05,762 --> 00:03:07,976
-because a lot of people think that
-
-83
-00:03:07,976 --> 00:03:10,191
-working with AI is all about getting
-
-84
-00:03:10,191 --> 00:03:12,089
-better at writing prompts, right? Like
-
-85
-00:03:12,089 --> 00:03:14,304
-you're just a factory worker telling the
-
-86
-00:03:14,304 --> 00:03:16,835
-machine what to do. But with WDS, you
-
-87
-00:03:16,835 --> 00:03:18,416
-flip that entirely. Your strategic
-
-88
-00:03:18,416 --> 00:03:19,998
-thinking, your design decisions, that
-
-89
-00:03:19,998 --> 00:03:21,896
-becomes the input. You're not prompting,
-
-90
-00:03:21,896 --> 00:03:24,111
-you're leading. And this quote just nails
-
-91
-00:03:24,111 --> 00:03:26,551
-the mindset shift. We all think of
-
-92
-00:03:26,551 --> 00:03:28,914
-writing specs as the boring, tedious part
-
-93
-00:03:28,914 --> 00:03:31,616
-of the job, don't we? But in this
-
-94
-00:03:31,616 --> 00:03:33,642
-world, it's the exact opposite. Creating
-
-95
-00:03:33,642 --> 00:03:35,668
-the specification is the most important
-
-96
-00:03:35,668 --> 00:03:38,369
-thing you do. It's the moment you capture
-
-97
-00:03:38,369 --> 00:03:40,733
-your unique creative genius and make it
-
-98
-00:03:40,733 --> 00:03:43,096
-permanent. Make it immortal. So how does
-
-99
-00:03:43,096 --> 00:03:45,460
-this big idea of immortal genius actually?
-
-100
-00:03:45,540 --> 00:03:48,078
-Work in practice. This isn't just some
-
-101
-00:03:48,078 --> 00:03:50,253
-vague philosophy, it's a really concrete
-
-102
-00:03:50,253 --> 00:03:52,428
-process that's built around 4 specific
-
-103
-00:03:52,428 --> 00:03:54,604
-deliverables. These are the things a
-
-104
-00:03:54,604 --> 00:03:56,416
-linchpin designer actually produces. So
-
-105
-00:03:56,416 --> 00:03:59,317
-here they are, the artifacts of a true
-
-106
-00:03:59,317 --> 00:04:01,492
-linchpin. You start with the project
-
-107
-00:04:01,492 --> 00:04:04,030
-brief, getting everyone on the same page
-
-108
-00:04:04,030 --> 00:04:06,546
-about why we're even. Doing this, then
-
-109
-00:04:06,546 --> 00:04:09,201
-you create a trigger map to make sure
-
-110
-00:04:09,201 --> 00:04:10,861
-you're building things that users
-
-111
-00:04:10,861 --> 00:04:12,852
-actually need. After that, your brilliant
-
-112
-00:04:12,852 --> 00:04:14,844
-ideas get captured in crystal clear
-
-113
-00:04:14,844 --> 00:04:16,836
-scenario specs. And finally, the design
-
-114
-00:04:16,836 --> 00:04:19,159
-system makes sure that brilliance can be
-
-115
-00:04:19,159 --> 00:04:21,483
-scaled and repeated. See how each step
-
-116
-00:04:21,483 --> 00:04:24,138
-builds on the last. It's a system for
-
-117
-00:04:24,138 --> 00:04:26,926
-impact. So where does AI fit
-
-118
-00:04:26,926 --> 00:04:29,591
-in all of this? This is the beautiful
-
-119
-00:04:29,591 --> 00:04:32,256
-part. In the WDS world, AI agents are
-
-120
-00:04:32,256 --> 00:04:34,255
-your creative partners. They're like an
-
-121
-00:04:34,255 --> 00:04:35,921
-assistant you can brainstorm with,
-
-122
-00:04:35,921 --> 00:04:37,587
-explore different paths with debate
-
-123
-00:04:37,587 --> 00:04:39,919
-tradeoffs. And then once you've made the
-
-124
-00:04:39,919 --> 00:04:41,918
-smart decision, they become obsessed with
-
-125
-00:04:41,918 --> 00:04:43,251
-perfectly documenting your brilliance,
-
-126
-00:04:43,251 --> 00:04:46,062
-not trying to replace it. OK. O you're
-
-127
-00:04:46,062 --> 00:04:47,819
-probably thinking, this all sounds
-
-128
-00:04:47,819 --> 00:04:49,926
-amazing, but is it actually practical?
-
-129
-00:04:49,926 --> 00:04:52,736
-Can I really do this? Well, let's look
-
-130
-00:04:52,736 --> 00:04:55,546
-at how you can start making this change
-
-131
-00:04:55,546 --> 00:04:57,653
-literally today. To learn this entire
-
-132
-00:04:57,653 --> 00:04:59,760
-methodology from start to finish, it
-
-133
-00:04:59,760 --> 00:05:02,219
-takes about 10 hours. That's it. We're
-
-134
-00:05:02,219 --> 00:05:04,678
-talking about a 10 hour investment of
-
-135
-00:05:04,678 --> 00:05:06,683
-your time. To completely change the
-
-136
-00:05:06,683 --> 00:05:08,457
-direction of your career and getting
-
-137
-00:05:08,457 --> 00:05:10,230
-started couldn't be easier. The entire
-
-138
-00:05:10,230 --> 00:05:12,300
-course is free, it's open source, right
-
-139
-00:05:12,300 --> 00:05:14,370
-on GitHub. There are no subscriptions, no
-
-140
-00:05:14,370 --> 00:05:16,439
-secret fees. The only thing you'd ever
-
-141
-00:05:16,439 --> 00:05:18,804
-pay for are the AI credits you actually
-
-142
-00:05:18,804 --> 00:05:21,465
-use, which ends up being maybe 15 or 20
-
-143
-00:05:21,465 --> 00:05:23,535
-bucks a month, and there's a whole
-
-144
-00:05:23,535 --> 00:05:25,604
-community on Discord ready to help you
-
-145
-00:05:25,604 --> 00:05:28,115
-out. So we're right back where we
-
-146
-00:05:28,115 --> 00:05:30,589
-started. The choice is right in front of
-
-147
-00:05:30,589 --> 00:05:33,372
-you. One path has you competing in a race
-
-148
-00:05:33,372 --> 00:05:35,846
-against AI that you just can't win. The
-
-149
-00:05:35,846 --> 00:05:38,010
-other path leads to you becoming that
-
-150
-00:05:38,010 --> 00:05:39,247
-strategic, indispensable designer whose
-
-151
-00:05:39,247 --> 00:05:41,412
-vision is so valuable it's treated like
-
-152
-00:05:41,412 --> 00:05:43,267
-gold. Ultimately, the tools and the
-
-153
-00:05:43,267 --> 00:05:45,122
-specific techniques don't matter as much
-
-154
-00:05:45,122 --> 00:05:47,329
-as the mindset. The real change happens
-
-155
-00:05:47,329 --> 00:05:49,199
-inside. It's about you deciding who you
-
-156
-00:05:49,199 --> 00:05:51,604
-want to be in this new world of design.
-
-157
-00:05:51,604 --> 00:05:53,742
-O, I'll leave you with that one last
-
-158
-00:05:53,742 --> 00:05:55,613
-question. Which designer do you choose to
-
-159
-00:05:55,613 --> 00:05:55,880
-become?
diff --git a/docs/learn-wds/course-explainers/Module 02-transcript.srt b/docs/learn-wds/course-explainers/Module 02-transcript.srt
deleted file mode 100644
index 0b550ed9c..000000000
--- a/docs/learn-wds/course-explainers/Module 02-transcript.srt	
+++ /dev/null
@@ -1,807 +0,0 @@
-1
-00:00:00,080 --> 00:00:01,915
-All right, let's dive into something
-
-2
-00:00:01,915 --> 00:00:04,363
-that, let's be honest, can feel a little
-
-3
-00:00:04,363 --> 00:00:06,504
-intimidating for a lot of designers. The
-
-4
-00:00:06,504 --> 00:00:08,340
-whole technical setup for the Whiteboard
-
-5
-00:00:08,340 --> 00:00:10,481
-Design Studio course, we're going to go
-
-6
-00:00:10,481 --> 00:00:13,234
-on a little journey here and the goal is
-
-7
-00:00:13,234 --> 00:00:15,681
-to take that feeling of, uh, this is
-
-8
-00:00:15,681 --> 00:00:18,129
-complicated and turn it into, OK, I got
-
-9
-00:00:18,129 --> 00:00:20,647
-this. Does this sound at all familiar?I
-
-10
-00:00:20,647 --> 00:00:22,861
-bet it does. This is probably the number
-
-11
-00:00:22,861 --> 00:00:24,798
-one thing we hear from amazing designers
-
-12
-00:00:24,798 --> 00:00:27,012
-who are totally ready to grow, but they
-
-13
-00:00:27,012 --> 00:00:29,226
-feel like the tools are this giant wall
-
-14
-00:00:29,226 --> 00:00:31,717
-in front of them. If that's you, I just
-
-15
-00:00:31,717 --> 00:00:34,485
-want you to know you are so not alone. In
-
-16
-00:00:34,485 --> 00:00:36,975
-fact, this is the perfect place for us to
-
-17
-00:00:36,975 --> 00:00:38,913
-start. And here's the absolute truth. The
-
-18
-00:00:38,913 --> 00:00:41,559
-thing you have to keep in mind?Every
-
-19
-00:00:41,559 --> 00:00:43,656
-single expert you admire, every designer
-
-20
-00:00:43,656 --> 00:00:46,452
-who seems to have it all figured out.
-
-21
-00:00:46,452 --> 00:00:48,549
-They all started right here, uncertain,
-
-22
-00:00:48,549 --> 00:00:50,995
-maybe a little nervous, wondering if they
-
-23
-00:00:50,995 --> 00:00:53,791
-could really get the hang of it. Well,
-
-24
-00:00:53,791 --> 00:00:56,587
-they did, and you will too. So let's
-
-25
-00:00:56,587 --> 00:00:59,033
-just face that technical hurdle head on.
-
-26
-00:00:59,033 --> 00:01:01,615
-Our first mission is super simple. We're
-
-27
-00:01:01,615 --> 00:01:03,819
-going to demystify all these tools. We're
-
-28
-00:01:03,819 --> 00:01:06,024
-going to take that scary sounding jargon
-
-29
-00:01:06,024 --> 00:01:08,228
-and justice, turn it into ideas that
-
-30
-00:01:08,228 --> 00:01:10,433
-actually make sense. First U Git and
-
-31
-00:01:10,433 --> 00:01:12,952
-GitHub, people get these mixed U all the
-
-32
-00:01:12,952 --> 00:01:15,157
-time. Are they the same thing? Not
-
-33
-00:01:15,157 --> 00:01:17,991
-really. And the best way to get it is
-
-34
-00:01:17,991 --> 00:01:20,510
-with this analogy. Think of Git as the
-
-35
-00:01:20,510 --> 00:01:22,566
-engine. It's the powerful. Thing working
-
-36
-00:01:22,566 --> 00:01:25,071
-behind the scenes, keeping track of every
-
-37
-00:01:25,071 --> 00:01:27,576
-single change you make. And GitHub, well,
-
-38
-00:01:27,576 --> 00:01:30,081
-GitHub is the car. It's the sleek,
-
-39
-00:01:30,081 --> 00:01:31,870
-user-friendly website where you actually
-
-40
-00:01:31,870 --> 00:01:34,733
-store and share your project. O what is
-
-41
-00:01:34,733 --> 00:01:36,880
-GitHub really? Let's just forget the
-
-42
-00:01:36,880 --> 00:01:39,027
-whole intimidating tech reputation for a
-
-43
-00:01:39,027 --> 00:01:41,532
-second. At its heart, it's basically just
-
-44
-00:01:41,532 --> 00:01:43,758
-cloud. Storage, but with a superpower and
-
-45
-00:01:43,758 --> 00:01:45,856
-that superpower is a time machine Every
-
-46
-00:01:45,856 --> 00:01:48,254
-time you save your work, it doesn't just
-
-47
-00:01:48,254 --> 00:01:50,651
-back it U, it creates a specific version
-
-48
-00:01:50,651 --> 00:01:53,349
-you can go back to at anytime It's like
-
-49
-00:01:53,349 --> 00:01:55,447
-the ultimate safety net for your entire
-
-50
-00:01:55,447 --> 00:01:57,844
-design process. OK, so now we know what
-
-51
-00:01:57,844 --> 00:02:00,542
-it is let's take that first big step we
-
-52
-00:02:00,542 --> 00:02:02,340
-are going to create your professional.
-
-53
-00:02:02,420 --> 00:02:04,604
-Home on the Internet your very first
-
-54
-00:02:04,604 --> 00:02:07,100
-GitHub repository and you are going to be
-
-55
-00:02:07,100 --> 00:02:09,284
-amazed at how simple this is. Seriously,
-
-56
-00:02:09,284 --> 00:02:12,092
-you just go to github.com & up. You know,
-
-57
-00:02:12,092 --> 00:02:14,276
-just like you would for any other
-
-58
-00:02:14,276 --> 00:02:17,084
-website. A little pro tip, try to pick a
-
-59
-00:02:17,084 --> 00:02:18,332
-professional sounding username because
-
-60
-00:02:18,332 --> 00:02:20,516
-you might end up sharing this with
-
-61
-00:02:20,516 --> 00:02:22,700
-clients one day. You verify your e-mail.
-
-62
-00:02:22,920 --> 00:02:24,768
-And, well, that's literally it. And
-
-63
-00:02:24,768 --> 00:02:26,924
-justice like that, you've done it. No,
-
-64
-00:02:26,924 --> 00:02:29,388
-really, take a second and let that sink
-
-65
-00:02:29,388 --> 00:02:31,544
-in. That thing that might have seemed
-
-66
-00:02:31,544 --> 00:02:33,700
-kind of complicated a few minutes ago,
-
-67
-00:02:33,700 --> 00:02:36,164
-you just did it. That feeling of progress
-
-68
-00:02:36,164 --> 00:02:38,320
-right there. We're going to keep building
-
-69
-00:02:38,320 --> 00:02:40,784
-on that. Now, when you create your first
-
-70
-00:02:40,784 --> 00:02:42,632
-project folder, they call it a
-
-71
-00:02:42,632 --> 00:02:44,772
-repository. You have a little choice to
-
-72
-00:02:44,772 --> 00:02:47,002
-make. You can have a single repo where
-
-73
-00:02:47,002 --> 00:02:48,953
-all your design specs and maybe some
-
-74
-00:02:48,953 --> 00:02:50,905
-future code live together, which by the
-
-75
-00:02:50,905 --> 00:02:52,856
-way, is perfect for beginners. Or you
-
-76
-00:02:52,856 --> 00:02:54,528
-could have separate repos for everything,
-
-77
-00:02:54,528 --> 00:02:56,758
-which is more of a big corporate thing
-
-78
-00:02:56,758 --> 00:02:58,709
-for this course. Trust me, we're going
-
-79
-00:02:58,709 --> 00:03:00,660
-with the single repo. It keeps everything
-
-80
-00:03:00,660 --> 00:03:02,890
-simple and all in one place. So once
-
-81
-00:03:02,890 --> 00:03:04,563
-you've named your repository and you
-
-82
-00:03:04,563 --> 00:03:06,867
-click that. The right button boom, that's
-
-83
-00:03:06,867 --> 00:03:09,551
-it. You are now officially a GitHub user.
-
-84
-00:03:09,551 --> 00:03:11,900
-You have a professional space to house
-
-85
-00:03:11,900 --> 00:03:14,248
-your work. Feels pretty good, right? OK,
-
-86
-00:03:14,248 --> 00:03:16,597
-now let's build the workshop where you'll
-
-87
-00:03:16,597 --> 00:03:18,945
-actually do the designing All right, we
-
-88
-00:03:18,945 --> 00:03:21,629
-have our cloud storage all set U Now
-
-89
-00:03:21,629 --> 00:03:23,978
-it's time to build your local workshop
-
-90
-00:03:23,978 --> 00:03:26,050
-we're going to install. Something called
-
-91
-00:03:26,050 --> 00:03:29,020
-an IDE, and I promise you it is not
-
-92
-00:03:29,020 --> 00:03:30,1000
-nearly as complicated as that acronym
-
-93
-00:03:30,1000 --> 00:03:33,970
-sounds. O what on earth is an IDE? It's
-
-94
-00:03:33,970 --> 00:03:36,280
-just a fancy acronym for your digital
-
-95
-00:03:36,280 --> 00:03:38,590
-workspace. And here's the best way to
-
-96
-00:03:38,590 --> 00:03:40,900
-think about it. If Microsoft Word is
-
-97
-00:03:40,900 --> 00:03:43,540
-where you write documents and IDE is your
-
-98
-00:03:43,540 --> 00:03:44,860
-workspace for crafting design
-
-99
-00:03:44,860 --> 00:03:46,904
-specifications for WDS. We highly, highly
-
-100
-00:03:46,904 --> 00:03:48,771
-recommend an app called Cursor because
-
-101
-00:03:48,771 --> 00:03:51,261
-it's built for the kind of AI assisted
-
-102
-00:03:51,261 --> 00:03:53,750
-work we'll be doing, and installing it is
-
-103
-00:03:53,750 --> 00:03:55,618
-something you've done 1000 times before.
-
-104
-00:03:55,618 --> 00:03:57,796
-You just download it, click through the
-
-105
-00:03:57,796 --> 00:03:59,352
-installer like any other application,
-
-106
-00:03:59,352 --> 00:04:01,842
-pick a light or dark theme, the important
-
-107
-00:04:01,842 --> 00:04:04,332
-choice, and then you sign in with that
-
-108
-00:04:04,332 --> 00:04:06,199
-brand new GitHub account you just
-
-109
-00:04:06,199 --> 00:04:08,039
-created. And that seamlessly connects
-
-110
-00:04:08,039 --> 00:04:09,912
-your local computer to your cloud
-
-111
-00:04:09,912 --> 00:04:12,097
-storage. OK, so inside your new IDE,
-
-112
-00:04:12,097 --> 00:04:14,282
-you're going to find something called a
-
-113
-00:04:14,282 --> 00:04:16,468
-terminal. And yet, for a lot of
-
-114
-00:04:16,468 --> 00:04:18,653
-designers, that little black box with the
-
-115
-00:04:18,653 --> 00:04:20,526
-blinking cursor looks pretty scary. It
-
-116
-00:04:20,526 --> 00:04:23,336
-feels like you need to be some kind of
-
-117
-00:04:23,336 --> 00:04:25,521
-coding genius just to touch it. But
-
-118
-00:04:25,521 --> 00:04:28,061
-here's the secret you. Do not need to
-
-119
-00:04:28,061 --> 00:04:30,197
-learn some new complex language for this
-
-120
-00:04:30,197 --> 00:04:32,333
-entire course. You are almost always just
-
-121
-00:04:32,333 --> 00:04:34,774
-going to be copying commands that we give
-
-122
-00:04:34,774 --> 00:04:36,910
-you and pasting them into the terminal.
-
-123
-00:04:36,910 --> 00:04:39,351
-That's it. It's just another way to talk
-
-124
-00:04:39,351 --> 00:04:41,182
-to your computer typing instead of
-
-125
-00:04:41,182 --> 00:04:43,318
-clicking. And now for the magic trick.
-
-126
-00:04:43,318 --> 00:04:45,759
-We've got our home in the cloud on
-
-127
-00:04:45,759 --> 00:04:47,971
-GitHub, and we've got our workshop. On
-
-128
-00:04:47,971 --> 00:04:50,219
-our computer, the next step is to connect
-
-129
-00:04:50,219 --> 00:04:52,748
-them. We're going to bring a copy of your
-
-130
-00:04:52,748 --> 00:04:54,996
-roject home. We do this with a process
-
-131
-00:04:54,996 --> 00:04:56,963
-called cloning, and all that really means
-
-132
-00:04:56,963 --> 00:04:59,491
-is making a local copy of your project on
-
-133
-00:04:59,491 --> 00:05:01,177
-your computer that stays perfectly In
-
-134
-00:05:01,177 --> 00:05:03,425
-Sync with what's on GitHub. You can think
-
-135
-00:05:03,425 --> 00:05:05,673
-of it exactly like Dropbox sync, but with
-
-136
-00:05:05,673 --> 00:05:07,359
-that super powerful version history that
-
-137
-00:05:07,359 --> 00:05:09,471
-time. Machine built right in and the
-
-138
-00:05:09,471 --> 00:05:11,819
-process is just so simple. You copy the
-
-139
-00:05:11,819 --> 00:05:14,168
-URL from your GitHub page, you open U
-
-140
-00:05:14,168 --> 00:05:16,516
-that terminal in your IDE and you just
-
-141
-00:05:16,516 --> 00:05:18,864
-type git clone and then paste the link.
-
-142
-00:05:18,864 --> 00:05:21,506
-But now check out Step 4. This is the
-
-143
-00:05:21,506 --> 00:05:23,854
-really cool part. If you don't happen to
-
-144
-00:05:23,854 --> 00:05:26,202
-have git installed yet, your IDE is smart
-
-145
-00:05:26,202 --> 00:05:28,904
-enough to see that it'll. Pop up and ask
-
-146
-00:05:28,904 --> 00:05:31,501
-if you want to install it, you click 1
-
-147
-00:05:31,501 --> 00:05:33,521
-button and it does everything for you.
-
-148
-00:05:33,521 --> 00:05:36,407
-And just like that get us set U OK? With
-
-149
-00:05:36,407 --> 00:05:38,427
-all the tools locked and loaded, we've
-
-150
-00:05:38,427 --> 00:05:40,736
-made it to the final and honestly the
-
-151
-00:05:40,736 --> 00:05:42,756
-most exciting part of this whole setup.
-
-152
-00:05:42,756 --> 00:05:45,064
-It's time to bring in the White Port
-
-153
-00:05:45,064 --> 00:05:46,796
-Design Studio methodology and meet your
-
-154
-00:05:46,796 --> 00:05:49,268
-personal AI guide, Mimir. First, you'll
-
-155
-00:05:49,268 --> 00:05:51,571
-create a special folder called Docs, and
-
-156
-00:05:51,571 --> 00:05:54,533
-what's so cool about this is it lays out
-
-157
-00:05:54,533 --> 00:05:56,836
-the entire WDC process for you. These
-
-158
-00:05:56,836 --> 00:05:58,810
-eight folders aren't just random names,
-
-159
-00:05:58,810 --> 00:06:00,785
-they are the complete battle tested
-
-160
-00:06:00,785 --> 00:06:02,759
-design methodology that's going to guide
-
-161
-00:06:02,759 --> 00:06:05,720
-you all the way from the first idea to
-
-162
-00:06:05,720 --> 00:06:07,695
-the final delivery. This folder becomes
-
-163
-00:06:07,695 --> 00:06:10,110
-the single source of truth. For your
-
-164
-00:06:10,110 --> 00:06:12,558
-entire project and now you meet your
-
-165
-00:06:12,558 --> 00:06:15,007
-guide. Mimir is the AI orchestrator for
-
-166
-00:06:15,007 --> 00:06:17,806
-WDS. And what this means is that from
-
-167
-00:06:17,806 --> 00:06:20,255
-this moment forward, you are never alone.
-
-168
-00:06:20,255 --> 00:06:22,703
-Anytime you feel stuck, anytime you have
-
-169
-00:06:22,703 --> 00:06:25,502
-a question or you just need a little
-
-170
-00:06:25,502 --> 00:06:27,951
-direction, you just type at WD Schmear
-
-171
-00:06:27,951 --> 00:06:30,715
-right there in your IDE. And your guide
-
-172
-00:06:30,715 --> 00:06:33,039
-will be there to help you out. And with
-
-173
-00:06:33,039 --> 00:06:34,846
-that, you're done. The set is complete.
-
-174
-00:06:34,846 --> 00:06:37,170
-You are ready to go. But hey, before we
-
-175
-00:06:37,170 --> 00:06:39,236
-move on, let's just hit pause for a
-
-176
-00:06:39,236 --> 00:06:41,044
-second and look back at everything you
-
-177
-00:06:41,044 --> 00:06:43,110
-just did. No, seriously, take a moment. A
-
-178
-00:06:43,110 --> 00:06:45,175
-lot of designers get stuck at this stage
-
-179
-00:06:45,175 --> 00:06:47,241
-for a long time, but you just pushed
-
-180
-00:06:47,241 --> 00:06:49,307
-right through it. Do you realize what a
-
-181
-00:06:49,307 --> 00:06:52,118
-big deal that is?I mean, look
-
-182
-00:06:52,118 --> 00:06:54,611
-at this list. You created a GitHub
-
-183
-00:06:54,611 --> 00:06:56,392
-account and a professional repository,
-
-184
-00:06:56,392 --> 00:06:58,529
-you installed a professional grade IDE,
-
-185
-00:06:58,529 --> 00:07:01,022
-you actually used the command line to
-
-186
-00:07:01,022 --> 00:07:03,159
-clone your first project, you integrated
-
-187
-00:07:03,159 --> 00:07:05,296
-the entire WDS framework, and you
-
-188
-00:07:05,296 --> 00:07:07,432
-activated your personal AI guide. This
-
-189
-00:07:07,432 --> 00:07:09,925
-wasn't just about clicking a few buttons,
-
-190
-00:07:09,925 --> 00:07:12,712
-this was a transformation. You may have
-
-191
-00:07:12,712 --> 00:07:14,837
-started out feeling like a nervous
-
-192
-00:07:14,837 --> 00:07:17,316
-beginner, but right now you are a
-
-193
-00:07:17,316 --> 00:07:19,795
-designer who is equipped with a fully
-
-194
-00:07:19,795 --> 00:07:21,566
-professional industry standard set. O.
-
-195
-00:07:21,566 --> 00:07:23,691
-Let's end with this thought. After
-
-196
-00:07:23,691 --> 00:07:25,461
-everything you just accomplished, there
-
-197
-00:07:25,461 --> 00:07:28,294
-is no more. I might be able to
-
-198
-00:07:28,294 --> 00:07:31,128
-do this. You just proved to yourself that
-
-199
-00:07:31,128 --> 00:07:33,836
-you are able. The setup is done,
-
-200
-00:07:33,836 --> 00:07:36,174
-your environment is ready, and your guide
-
-201
-00:07:36,174 --> 00:07:38,846
-me mayor is waiting for you. Welcome to
-
-202
-00:07:38,846 --> 00:07:39,180
-WDS.
diff --git a/docs/learn-wds/course-explainers/Module-00-notebook-lm-prompt.md b/docs/learn-wds/course-explainers/Module-00-notebook-lm-prompt.md
deleted file mode 100644
index 84bff0300..000000000
--- a/docs/learn-wds/course-explainers/Module-00-notebook-lm-prompt.md
+++ /dev/null
@@ -1,250 +0,0 @@
-# NotebookLM Prompt: Getting Started with WDS
-
-**Use this prompt to generate audio/video content from the Getting Started sections**
-
----
-
-## Instructions for NotebookLM
-
-**This is a single, self-contained prompt file.**
-
-Simply upload THIS FILE to NotebookLM and use the prompt below to generate engaging audio/video content. No other files needed.
-
----
-
-## Prompt
-
-Create an engaging 15-minute podcast conversation between two hosts discussing the Whiteport Design Studio (WDS) course getting started guide.
-
-**IMPORTANT: WDS stands for Whiteport Design Studio - always refer to it by its full name "Whiteport Design Studio" or "WDS" throughout the conversation.**
-
-**Host 1 (The Skeptic):** A designer who's heard about WDS but is uncertain about investing time in another methodology. Asks practical questions about prerequisites, time commitment, and real-world value.
-
-**Host 2 (The Advocate):** A designer who understands WDS deeply and can explain why it matters, especially in the AI era. Enthusiastic but grounded in practical benefits.
-
-**Conversation structure:**
-
-### 1. Opening (2 min) - Hook the listener
-
-Start with The Skeptic expressing fatigue: "Another design methodology? I've been through Lean UX, Design Thinking, Jobs to be Done... what makes Whiteport Design Studio different?"
-
-The Advocate responds with the core paradigm shift that changes everything: "Here's what's different - in Whiteport Design Studio, the design becomes the specification. The specification becomes the product. The code is just the printout - the projection to the end user." Explain that this isn't just another process overlay, it's a fundamental shift in how designers work with AI.
-
-**Background context:** The Advocate explains that Whiteport Design Studio (WDS) was created by Mårten Angner, a UX designer and founder of Whiteport, a design and development agency from Sweden. Mårten developed Whiteport Design Studio as a plugin module for the BMad Method - an open-source AI-augmented development framework. The goal was to give designers everywhere free and open-source access to AI agents specifically tailored for design work. After years of working with AI tools, Mårten realized that traditional design handoffs were breaking down. Designers needed a methodology where their thinking could be preserved and amplified through AI implementation, not lost in translation. WDS emerged from real-world projects where designers could deliver deeper, more complete work while becoming the strategic thinkers their teams need. By making it open-source and integrating it with BMad Method, Mårten ensures that any designer can access these powerful AI-augmented workflows without cost barriers.
-
-Introduce the context: we're in the AI era where AI can generate mockups in seconds, follow design systems perfectly, and iterate endlessly. The question isn't whether AI will change design - it already has. The question is: which side of the line are you on? Are you doing factory work that AI can replace, or are you a linchpin designer who makes things happen?
-
-Give a quick overview: this conversation will explore the crossroads every designer faces right now - the choice between becoming replaceable or indispensable. We'll talk about the four deliverables that transform your work, why specifications are where your creative brilliance becomes immortal, and yes - briefly - the simple setup. But this isn't about tools. This is about your future as a designer.
-
-### 2. The Designer's Crossroads (4 min) - The choice you're facing right now
-
-The Skeptic gets real: "I'm at a crossroads. I see AI generating mockups in seconds. I see my value being questioned. I don't know if I should double down on craft or learn to work with AI or just... give up and find a new career. What am I supposed to do?"
-
-The Advocate responds with empathy: "You're standing at the most important moment in design history. And here's the truth - you have a choice to make. Not about tools. Not about techniques. About who you are as a designer."
-
-**The Factory Designer Path:** Keep doing what you've been doing. Get briefs, make mockups, hand them off, hope for the best. It's comfortable. It's familiar. But AI is getting better at this every single day. If your value comes from executing predictable outputs, you're competing with something that never sleeps, never has creative block, and costs pennies.
-
-**The Linchpin Designer Path:** Become the person who walks into chaos and creates order. The one who connects business goals to user psychology to technical constraints and finds the human truth at the intersection. The one whose creative thinking is so valuable that it needs to be preserved for eternity - captured in Conceptual Specifications that give your designs immortal life.
-
-The Advocate pauses: "WDS is the path to becoming a linchpin designer. But I need you to understand - this isn't about learning new tools. This is about transforming how you think about your role. You're not a mockup maker anymore. You're a strategic thinker whose creative brilliance deserves to be captured and preserved."
-
-The Skeptic asks: "But practically - what does that actually mean? What changes?"
-
-The Advocate: "Everything changes. You create four deliverables that transform your work. And yes, there's a learning curve - you'll work in an IDE instead of just Figma, you'll use GitHub, you'll invest about 10 hours learning the methodology. But those are just the mechanics. The real transformation is internal - from someone who makes things pretty to someone who creates strategic design systems that preserve your creative genius."
-
-### 3. The Four Deliverables - Where Your Brilliance Becomes Immortal (6 min)
-
-The Skeptic asks: "Okay, you've convinced me I need to transform. But what does that actually look like? What will I create that's so different?"
-
-The Advocate gets passionate: "You'll create four deliverables - but these aren't just documents. These are the artifacts that prove you're a linchpin designer. These are where your creative brilliance becomes immortal. Let me walk you through each one."
-
-**First: Your Project Brief** - This isn't a typical brief. It's your project's strategic foundation with vision and goals clearly defined, stakeholders and constraints documented, and the foundation for every design decision you'll make. This becomes your north star. When stakeholders ask 'why did we build it this way?' you point to the brief. When developers need context, it's all there. When you need to defend a design decision, the reasoning is documented. This is strategic thinking made visible.
-
-**Second: Your Trigger Map** - This is pure strategic gold. You've identified and prioritized target groups, mapped user triggers and outcomes, and prioritized features by impact. This tells you exactly what to build and why. No more guessing what features matter. No more building things nobody uses. The trigger map creates a logical chain of reasoning between the business goals and the users' goals that is traceable to every feature and piece of content in the product. When product managers ask 'what should we build next?' you have the answer, backed by user psychology and business impact.
-
-**Third: Scenario Specifications** - This is where your brilliance comes to life. Here's the magic: AI agents in WDS support you throughout the design process - helping you explore what to draw, discussing design solutions with pros and cons, collaborating as you finalize your design. Then, once you've made all your design decisions, the agents become genuinely interested in capturing every nuance of your thinking in text. They help you document everything your sketch can't convey - why every object is placed exactly where it is, how it connects to the wider picture, what alternatives you considered and rejected. These Conceptual Specifications give your designs eternal life. It's your thinking, your creative integrity, captured and preserved. Not factory work - this is where your design brilliance becomes immortal.
-
-**Fourth: Your Design System Foundation** - Design tokens extracted from your specs, component patterns identified, and reusable architecture defined. This scales your design decisions across the entire product. Every color, every spacing decision, every interaction pattern - documented and reusable. You're not just designing one screen anymore. You're creating a system that scales infinitely. This is how your design thinking compounds over time.
-
-The Advocate pauses for emphasis: "These four deliverables transform you from someone who makes mockups to someone who creates strategic design systems. Each one builds on the last. Each one amplifies your impact. And here's the key - the course walks you through creating all of them, step by step, for your own project."
-
-The Skeptic asks: "But wait - writing specifications sounds like factory work. Isn't that exactly what we're trying to avoid?" The Advocate responds with passion: "That's the beautiful reframe! In WDS, you're not grinding out documentation. The AI agents are your creative partners. They help you think through design solutions, explore alternatives, discuss trade-offs. Then - and this is crucial - they're genuinely fascinated by your thinking. They want to capture every nuance, every decision, every insight. It's like having a brilliant assistant who's obsessed with preserving your creative genius for eternity. The specifications aren't factory work - they're the point where your brilliance comes to life in a form that gives your designs eternal life. Your thinking, your creative integrity, captured perfectly so it can never be lost."
-
-### 4. The AI Era Reality Check (3 min) - Why this matters now
-
-The Skeptic voices the deeper fear: "But I still don't understand - why NOW? Why is this moment so critical? Won't AI just replace designers anyway? Why invest time learning anything when AI is getting better every day?"
-
-The Advocate addresses this head-on with the factory mindset versus linchpin mindset concept from Seth Godin's book "Linchpin: Are You Indispensable?" For over a century, we've been trained to be cogs in a machine - show up, follow instructions, do your part, go home. Replaceable. Interchangeable. Traditional design work follows this exact pattern: get a brief, create mockups, hand off to developers, hope for the best. That's factory work, just with Figma instead of an assembly line.
-
-Here's the uncomfortable truth: AI is really, really good at factory work. If your value as a designer comes from creating predictable outputs based on clear instructions, you're competing with something that's faster, more consistent, and infinitely scalable. AI can generate mockups instantly, follow design systems perfectly, iterate through hundreds of variations without fatigue, and work 24/7 at the same quality level.
-
-But - and this is crucial - AI cannot be a linchpin. It can't walk into chaos and create order. It can't sense when a client is asking for the wrong thing. It can't connect a business goal to a psychological insight to a technical constraint and come up with something nobody expected but everyone loves.
-
-The internet is drowning in what we call "AI slop" - generic interfaces that look fine but feel dead. Products that check all the boxes but have no soul. This is what happens when you let AI do the thinking. But here's the brutal market reality: bad products used to fail after launch. Now bad products never even get to start. Users have infinite options. They can smell soulless design from a mile away. If your product doesn't immediately feel different, feel right, feel like someone actually cared - it's dead on arrival.
-
-This is the opportunity. Linchpin designers do what AI fundamentally cannot do: they give products a soul. They navigate five dimensions of thinking simultaneously - business goals, user psychology, product strategy, technical constraints, and design execution - and find the human truth at the intersection. They make judgment calls that create emotional resonance. They build trust through thoughtful decisions. They care about the outcome in a way that shows in every interaction.
-
-The Advocate explains the transformation: "Designers who master WDS become strategic thinkers who deliver complete value. But here's the crucial difference from traditional AI tools - in WDS, AI agents are your creative partners, not your replacements. They help you explore design solutions, discuss pros and cons, support your thinking process. Then they become fascinated documentarians of your brilliance - capturing every nuance of your creative decisions in Conceptual Specifications that give your designs eternal life."
-
-The key insight: with WDS, your design contribution completely replaces prompting. You make design decisions with AI as your thinking partner. Then AI helps capture your creative integrity in text - not factory work, but preserving your genius. The result is an absolute goldmine for everyone - providing clarity that works like clockwork, replacing hours of pointless back-and-forth prompting. You remain in the loop as the skilled, experienced designer who evaluates AI's work, catches its confident mistakes, and ensures what ships actually makes sense.
-
-### 5. The Simple Path Forward (2 min) - How to begin
-
-The Skeptic asks: "Okay, I'm convinced this is the transformation I need. But how do I actually start?"
-
-The Advocate: "The path is simple. Go to the WDS GitHub repository. Start with Module 01 - Why WDS Matters. Three lessons, 30 minutes. You'll understand the transformation deeply.
-
-Then the course walks you through creating your four deliverables, step by step. Yes, you'll need to install an IDE and learn GitHub - the course shows you how. It's about 10 hours total to learn the methodology. There's a BMad Discord channel where real designers help each other.
-
-But here's what matters - this isn't about the tools. The tools are just the mechanics. This is about choosing to become a linchpin designer whose creative brilliance gets preserved for eternity. That's the real transformation."
-
-The Skeptic: "And the cost?"
-
-The Advocate: "Free and open-source. The only cost is AI credits when you're actually using the system - you pay for what you use, when you use it. Starts around $15-20 per month for typical design work, but you're only paying when the AI is actively helping you. No subscriptions to WDS itself, no course fees, no hidden costs. Mårten created Whiteport Design Studio to help designers thrive in the AI era, not to sell you something. The real cost is choosing to transform. That's the investment that matters."
-
-### 6. Closing (1 min) - The choice is yours
-
-The Advocate brings it home with the paradigm shift: "Remember this - the design becomes the specification. The specification becomes the product. The code is just the printout - the projection to the end user."
-
-The Skeptic, now transformed, says: "I see it now. This isn't about tools or techniques. It's about choosing who I want to be as a designer. Factory worker or linchpin. Replaceable or indispensable."
-
-The Advocate confirms: "Exactly. You're standing at a crossroads. One path leads to competing with AI for factory work. The other path leads to becoming irreplaceable - the designer whose creative brilliance is so valuable it deserves to be preserved for eternity.
-
-WDS gives you the methodology to walk that second path. Four deliverables that prove you're a linchpin designer. AI agents as creative partners who help you think, then capture your genius. Ten hours of learning that transforms your career forever.
-
-The question isn't whether to learn WDS. The question is: which designer do you choose to become?"
-
-The Skeptic ends with: "I choose to be indispensable. I'm in."
-
-The Advocate: "Then go to the WDS GitHub repository. Start with Module 01. The transformation begins now."
-
----
-
-## Resources to Include
-
-At the end of the podcast, The Advocate should mention these resources for listeners who want to explore further:
-
-**Getting Started:**
-
-- Whiteport Design Studio Course: Start with Module 01 - Why WDS Matters
-- GitHub Repository: github.com/bmad-code-org (full course materials, examples, templates)
-- BMad Method Website: bmadmethod.com (case studies, blog posts, methodology deep dives)
-
-**Community & Support:**
-
-- GitHub Discussions: Ask questions, share projects, get feedback
-- NotebookLM Integration: Generate audio/video versions of any module
-- Workshop Materials: Available for team training
-
-**Real-World Examples:**
-
-- Case Studies: See real transformations from traditional to Whiteport Design Studio approach
-- Design System Examples: How Whiteport Design Studio scales across products
-- Specification Templates: Start with proven patterns
-
-**Tools & Templates:**
-
-- Project Brief Template: Start your first WDS project
-- Trigger Map Template: Map user needs to features
-- Scenario Specification Template: Create AI-ready specs
-- Design Token Extraction Guide: Build your design system
-
-The Advocate emphasizes: "Everything is free and open-source. BMad Method built Whiteport Design Studio to help designers thrive in the AI era, not to sell you something. Download it, use it, share it with your team, contribute back if you find it valuable. The only cost is your time - 10 hours to learn, a lifetime of being indispensable."
-
-**Tone:**
-
-- Conversational and engaging, not academic
-- The Skeptic asks real questions designers actually have
-- The Advocate provides concrete answers with examples
-- Both hosts are enthusiastic but realistic about the learning curve
-- Use the testimonials naturally in conversation
-- Reference real case studies showing traditional vs WDS transformation
-
-**Key messages to emphasize:**
-
-- **The designer's crossroads** - factory worker or linchpin, replaceable or indispensable
-- **The existential choice** - this is about who you choose to become, not what tools you learn
-- **Four deliverables** - where your creative brilliance becomes immortal
-- **The paradigm shift** - design IS the specification, specifications preserve your genius
-- **AI as creative partner** - helps you think, then captures your brilliance (not factory work)
-- **Conceptual Specifications** - where your thinking gets eternal life
-- **The transformation** - from mockup maker to strategic thinker
-- **Why NOW matters** - AI slop is drowning the internet, linchpin designers give products soul
-- Tools are secondary - 10 hours learning, IDE + GitHub, BMad Discord support
-- Free and open-source (only pay for AI credits when you use it - ~$15-20/month typical)
-
-**Avoid:**
-
-- Being too salesy or promotional
-- Oversimplifying the learning curve
-- Making unrealistic promises
-- Technical jargon without explanation
-
----
-
-## Expected Output
-
-A natural, engaging conversation that:
-
-- **Focuses on the designer's existential crossroads** - the choice between factory work and linchpin work
-- **Makes the transformation emotional and personal** - this is about who you choose to become
-- **Emphasizes the four deliverables** as proof of linchpin designer status
-- **Reframes specifications** from factory work to where creative brilliance becomes immortal
-- **Positions AI as creative partner** - helps you think, then captures your genius
-- **Explains why NOW matters** - AI slop vs products with soul
-- Mentions practical setup briefly (tools are secondary to transformation)
-- Provides clear next steps (go to GitHub, start Module 01)
-- Takes 15 minutes to listen to
-
----
-
-## Alternative: Video Script
-
-If generating video instead of audio, add these visual elements:
-
-**On-screen text:**
-
-- "The Designer's Crossroads: Factory Worker or Linchpin?"
-- "Replaceable or Indispensable - You Choose"
-- The four deliverables as graphics (Project Brief, Trigger Map, Conceptual Specifications, Design System)
-- "Where Your Creative Brilliance Becomes Immortal"
-- The paradigm shift statement as a title card
-- "AI as Creative Partner - Not Replacement"
-- "Next: Module 01 - The Transformation Begins" as closing card
-
-**B-roll suggestions:**
-
-- Designer at crossroads - two paths diverging
-- Factory assembly line vs creative studio (visual metaphor)
-- The four deliverables as beautiful artifacts
-- Designer collaborating with AI - thinking together
-- Conceptual Specifications capturing design brilliance
-- Before/after: generic AI slop vs product with soul
-- Designer's creative thinking being preserved in text
-- Linchpin designer making strategic decisions
-- Community of transformed designers
-- The transformation journey - mockup maker to strategic thinker
-
----
-
-## Usage Tips
-
-1. **Upload THIS SINGLE FILE** to NotebookLM - no other files needed
-2. **Use the prompt exactly** as written for best results
-3. **Generate multiple versions** and pick the best one
-4. **Share the audio/video** with your team or community
-5. **Iterate** - if the output isn't quite right, refine the prompt
-
----
-
-## Next Steps
-
-After generating the Getting Started content:
-
-- Create NotebookLM prompt for Module 01: Why WDS Matters
-- Build prompts for all 16 modules (complete audio course library)
-- Share in BMad Discord designer channel
-- Use in workshops and team training
-- Iterate based on community feedback
-
-**[← Back to Getting Started Overview](overview.md)**
diff --git a/docs/learn-wds/course-explainers/Module-00-thumbnail-prompt.md b/docs/learn-wds/course-explainers/Module-00-thumbnail-prompt.md
deleted file mode 100644
index da7a9e379..000000000
--- a/docs/learn-wds/course-explainers/Module-00-thumbnail-prompt.md
+++ /dev/null
@@ -1,33 +0,0 @@
-**IMPORTANT: Use the reference image as your exact style guide. Match all visual elements, colors, layout, and character design.**
-
-Create a 1920x1080px YouTube thumbnail matching the reference image style.
-
-**What to Change from Reference:**
-
-**Headlines (Left side):**
-- Line 1: "DESIGNERS DILEMMA" (Rubrik Light, 91pt, white)
-- Line 2: "DELIVER FROM SPECS OR" (Rubrik Bold, 91pt, white)
-- Line 3: "BECOME INDISPENSABLE!" (Rubrik Bold, 91pt, white)
-- Line spacing: 79pt
-
-**Module Badge (Bottom-left):**
-- "00 Getting started" (Rubrik Regular, 108pt, white on red #ff1744)
-
-**Character Activity:**
-- Woman looking at wireframe sketches on the table
-- Skip the tablet
-- Keep the character stylized as it is
-- Expression: Thoughtful, considering options
-
-**Background Pattern:**
-- Add subtle tech/design elements (wireframes, UI shapes)
-- Keep as in reference image
-
-**Workspace Props:**
-- Add: wireframe sketches, design notes
-
-**Keep Everything Else from Reference:**
-- Top-right branding text
-- Character design and style
-- Color scheme and layout
-
diff --git a/docs/learn-wds/course-explainers/Module-00-youtube-show-notes.md b/docs/learn-wds/course-explainers/Module-00-youtube-show-notes.md
deleted file mode 100644
index 5f1fcafab..000000000
--- a/docs/learn-wds/course-explainers/Module-00-youtube-show-notes.md
+++ /dev/null
@@ -1,78 +0,0 @@
-Module 00 - Your Path to Becoming a Linchpin Designer - WDS Course
-<https://www.youtube.com/watch?v=qYPYx01YLUc>
-
-Standing at a crossroads? This 15-minute video explores the most important choice you'll make as a designer in the AI era: Will you be replaceable or indispensable?
-
-*You'll discover:*
-✅ The paradigm shift: Design becomes specification
-✅ Four core deliverables that transform your work
-✅ Why specifications preserve your creative brilliance
-✅ How to get started (10 hours to learn)
-✅ AI as your creative partner, not replacement
-
-*Free & open-source* | Created by Mårten Angner, Whiteport (Sweden)
-
-⏱️ Timestamps
-
-00:00 The Fundamental Choice
-00:30 Two Paths: Factory vs Linchpin Designer
-01:22 The Threat of AI Slop
-02:25 How to Become Indispensable
-02:38 The WDS Paradigm Shift
-03:25 Specifications as Creative Genius
-03:46 The Four Core Deliverables
-04:25 AI as Your Creative Partner
-04:45 Getting Started: 10 Hours to Transform
-05:26 Your Choice, Your Future
-
-🎯 Two Paths
-
-*Factory Designer* - Predictable outputs, competing with AI, replaceable
-*Linchpin Designer* - Strategic thinking, creating order from chaos, indispensable
-
-*Four Core Deliverables:*
-• Product Brief • Trigger Map • Scenario Specifications • Design System Foundation
-
- Course Resources
-
- *WDS Presentation:*
-<https://whiteport.com/whiteport-design-studio/>
-
- Installation Guide:
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/getting-started/installation.md>
-
- Quick Start:
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/getting-started/quick-start.md>
-
- UX-Design channel in the BMad Discord Community:
-<https://discord.gg/Pn63gAuX>
-
- GitHub Discussions:
-<https://github.com/whiteport-collective/whiteport-design-studio/discussions>
-
- Next Module: Module 01 - Why WDS Matters
-<https://www.youtube.com/watch?v=Xhw5JB7mpxw>
-
- *Full Course:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md>
-
- *Next Steps:*
-1. Watch Module 01
-2. Download an IDE (Cursor, VS Code, Windsurf)
-3. Install WDS
-4. Join Discord community
-5. Start creating your four deliverables
-
-*Time Investment:* 10 hours | *Payoff:* A lifetime of being indispensable
-
-🎨 *About WDS*
-AI-augmented design methodology by Mårten Angner (Whiteport, Sweden). Free access to AI agents for designers while preserving creative thinking through specifications. Become 5x more productive with creative control.
-
-#UXDesign #AIDesign #LinchpinDesigner #WDS #BMadMethod #DesignSpecification
-
-💡 *The Choice:* Factory work (replaceable) or Linchpin work (indispensable)?
-
-The design becomes the specification. The specification becomes the product. The code is just the printout.
-
-*Ready to transform? Start Module 01! 🚀*
-<https://www.youtube.com/watch?v=Xhw5JB7mpxw>
\ No newline at end of file
diff --git a/docs/learn-wds/course-explainers/Module-01-notebook-lm-prompt.md b/docs/learn-wds/course-explainers/Module-01-notebook-lm-prompt.md
deleted file mode 100644
index 3beede460..000000000
--- a/docs/learn-wds/course-explainers/Module-01-notebook-lm-prompt.md
+++ /dev/null
@@ -1,418 +0,0 @@
-# NotebookLM Prompt: Module 01 - Why WDS Matters
-
-**Use this prompt to generate audio/video content for Module 01: Why WDS Matters**
-
----
-
-## Instructions for NotebookLM
-
-**This is a single, self-contained prompt file.**
-
-Simply upload THIS FILE to NotebookLM and use the prompt below to generate engaging audio/video content. No other files needed.
-
----
-
-## Prompt
-
-Create an engaging 30-minute podcast conversation between two hosts discussing Module 01 of the Whiteport Design Studio (WDS) course: Why WDS Matters.
-
-**IMPORTANT: WDS stands for Whiteport Design Studio - always refer to it by its full name "Whiteport Design Studio" or "WDS" throughout the conversation.**
-
-**Host 1 (The Skeptic):** A designer who's uncertain about their future in the AI era. Feels threatened by AI tools and wonders if design skills still matter. Asks challenging questions about value and relevance.
-
-**Host 2 (The Advocate):** A designer who has embraced the linchpin mindset and understands how WDS makes designers indispensable. Enthusiastic about the transformation but realistic about the work required.
-
-**Conversation structure:**
-
-### 1. Opening (3 min) - The Linchpin Question
-
-Start with The Skeptic asking the core question: "I've heard about AI changing design. I've heard about the threat. But what I really want to understand is - what makes me valuable? What's my unique contribution that matters?"
-
-The Advocate responds: "That's exactly the right question. And the answer comes from Seth Godin's 2010 bestselling book 'Linchpin: Are You Indispensable?' Godin identifies two types of workers: factory workers who follow instructions and can be replaced, and linchpins who walk into chaos and create order. The question isn't whether AI will change design - it already has. The question is: are you a factory worker or a linchpin?"
-
-The Advocate continues: "This is where Whiteport Design Studio comes in. We're banding together to carve out a space for linchpin designers - designers who understand their irreplaceable value and serve clients and developers in an honest and sustainable way. You don't have to figure this out alone."
-
-Introduce the module's promise: "In the next 30 minutes, you'll understand exactly what makes you irreplaceable as a designer. Not your tools. Not your aesthetic taste. But your uniquely human gift - what Godin calls 'emotional labor' and what we call 'user-centric creativity.' And remember - it's hard to be a beginner, but the BMad community is here to help."
-
----
-
-### 2. The Problem - Factory Work vs Linchpin Work (8 min)
-
-The Skeptic asks: "Okay, but what does that actually mean? What's the difference between factory work and linchpin work in design?"
-
-**Seth Godin's Insight: Emotional Labor**
-
-The Advocate starts with Godin's framework: "In his 2010 book 'Linchpin: Are You Indispensable?', bestselling author and marketing visionary Seth Godin talks about two types of work. There's factory work - following instructions, creating predictable outputs, being replaceable. And there's linchpin work - which requires what Godin calls 'emotional labor.' This is the work of genuinely caring about the outcome, connecting with people's real needs, and creating meaning that matters."
-
-The Skeptic: "Emotional labor? That sounds... soft. What does that have to do with design?"
-
-**The Designer's Reality: User-Centric Creativity**
-
-The Advocate: "Everything. For designers, emotional labor translates into something very specific: user-centric creativity. This is your irreplaceable gift. Let me break down what this actually means:"
-
-What user-centric creativity looks like:
-
-- **Understanding WHY** - Not just making things look better, but understanding why users feel frustrated
-- **Connecting goals** - Bridging business goals and human needs in ways that serve both
-- **Creating experiences that feel right** - Not just function correctly, but feel like someone cared
-- **Making judgment calls** - Serving people even when it's harder than following a formula
-- **Providing meaning** - Creating products that have soul, not just features
-
-The Advocate continues: "This is hard work. It requires you to genuinely care. To empathize. To think deeply about people's needs. To make judgment calls when there's no clear answer. AI can generate interfaces. But it cannot provide emotional labor. It cannot genuinely care about the outcome."
-
-The Skeptic: "So my value is in the caring? In the human connection?"
-
-The Advocate: "Exactly. While AI can execute instructions perfectly, you provide the thinking that matters. You're the one who walks into chaos and creates order. You're the one who gives products a soul."
-
----
-
-### 3. The Solution - Becoming a Linchpin Designer (10 min)
-
-The Skeptic asks: "Okay, I'm listening. But what makes a designer a linchpin instead of a cog? What's the actual difference?"
-
-**What Makes a Linchpin Designer:**
-
-The Advocate explains Seth Godin's definition: "A linchpin is someone who can walk into chaos and create order. Someone who invents, connects, creates, and makes things happen. That's exactly what product design is at its core."
-
-Godin describes linchpins as people who:
-
-- **Invent** - Create solutions that didn't exist before
-- **Connect** - Bridge disparate ideas and people
-- **Create** - Make things that matter
-- **Make things happen** - Deliver results when there's no clear roadmap
-
-The Advocate continues: "This is you. When you walk into a project with unclear requirements, conflicting stakeholder needs, and complex user problems - you create order. You transform complexity into clarity. You invent solutions nobody expected. You bridge business, psychology, and technology. That's linchpin work."
-
-**The Designer's Three Irreplaceable Gifts:**
-
-The Advocate gets specific: "Godin talks about emotional labor. For designers, this translates into three concrete gifts that AI fundamentally cannot provide:"
-
-**1. Emotional Labor (Genuine Caring)**
-
-- You genuinely care about the outcome
-- You empathize with user frustration
-- You feel the weight of your decisions
-- You provide meaning, not just features
-
-**2. User-Centric Creativity (Connecting Needs)**
-
-- You understand WHY users feel frustrated
-- You connect business goals to human needs
-- You create experiences that feel right
-- You make judgment calls that serve people
-
-**3. The Gatekeeper Role (Protecting Quality)**
-
-- You catch mistakes before they ship
-- You evaluate if solutions make logical sense
-- You ensure goals don't contradict needs
-- You protect users from bad decisions
-- You create the impactful meeting between business and user
-
-The Skeptic: "So I'm not just making things look good. I'm the person who makes sure things make sense?"
-
-The Advocate: "Exactly. You're the linchpin. The person who walks into chaos and creates order. The person who makes things happen."
-
-**The Paradigm Shift:**
-
-The Advocate brings it home: "Here's the transformation that Whiteport Design Studio enables. Your design thinking - your user-centric creativity - becomes the specification. You capture WHY, not just WHAT. You document your judgment calls. You make your emotional labor visible and actionable."
-
-The paradigm shift: "Design becomes specification. Specification becomes product. Your creative thinking is preserved and amplified, not diluted and lost."
-
-Your transformation:
-
-- **From:** Creating mockups hoping developers understand your intent
-- **To:** Capturing your design thinking in specifications that preserve your creative decisions
-- **Result:** From hoping it works to knowing it will - because your thinking is captured
-
----
-
-### 4. The 5 Dimensions - What Makes You Irreplaceable (7 min)
-
-The Skeptic asks: "This sounds great in theory. But what's the actual skill that makes me irreplaceable? What am I doing that AI can't?"
-
-**5-Dimensional Thinking:**
-
-The Advocate explains: "Godin says linchpins 'connect disparate ideas.' For product designers, this means navigating five different dimensions of thinking at the same time. Most people can handle one or two dimensions. Irreplaceable designers navigate all five simultaneously."
-
-The 5 dimensions:
-
-1. **Business Existence (WHY)** - Understanding purpose and value creation
-2. **Business Goals (SUCCESS)** - Connecting to metrics and impact
-3. **Product Strategy (HOW)** - Making hard choices about features
-4. **Target Groups (WHO)** - Empathy and understanding needs
-5. **Technical Viability (FEASIBLE)** - Bridging design and implementation
-
-**Real Example - Family Coordination App:**
-
-The Advocate uses a concrete example: "Think about designing an app that helps families coordinate tasks. You need to understand:
-
-- **WHY** - Why does this business exist? (Solving family conflict and stress)
-- **SUCCESS** - What does success look like? (Kids complete tasks without nagging)
-- **HOW** - What features serve that goal? (Visual task board, not text lists)
-- **WHO** - Who are the users? (Busy parents and reluctant kids)
-- **FEASIBLE** - What's technically possible? (Mobile app with family sharing)"
-
-The Skeptic: "So I'm connecting all these dots simultaneously?"
-
-The Advocate: "Exactly. Each dimension informs the others. Miss one, and your design falls apart. You need to hold all five in your head at once, making judgment calls that balance competing needs. AI can help you think through each dimension individually. But it cannot navigate all five simultaneously while providing the emotional labor of genuinely caring about the outcome. That's uniquely human. That's what makes designers irreplaceable."
-
----
-
-### 5. The Transformation - How WDS Guides You (7 min)
-
-The Skeptic reflects: "I'm starting to see WHY I'm valuable. But HOW do I actually make this transformation? What's the practical path?"
-
-**The Three-Part Transformation:**
-
-The Advocate gets practical: "Whiteport Design Studio guides you through a three-part transformation. This isn't theory - it's a concrete process that builds your linchpin capabilities step by step."
-
-**Part 1: Understanding Business and User Goals**
-
-The Advocate explains: "First, you learn to deeply understand both sides of the equation. Not just surface-level - but the real WHY behind business existence and user needs. You learn to ask the right questions, dig deeper, and connect the dots between what the business needs to survive and what users need to thrive."
-
-What you learn:
-
-- How to uncover the real business purpose (not just features)
-- How to understand user goals at a deep level (not just tasks)
-- How to find the intersection where both are served
-- How to document this understanding in a Project Brief and Trigger Map
-
-The Skeptic: "So I become the person who truly understands the problem?"
-
-The Advocate: "Exactly. You become the expert on WHY this product exists and WHO it serves."
-
-**Part 2: Working in the IDE - Design as Specification**
-
-The Advocate continues: "Second, you learn to work directly in the IDE - your development environment. This sounds technical, but it's actually liberating. You learn to capture your design thinking in text specifications that preserve your creative intent."
-
-What you learn:
-
-- How to write specifications that capture WHY, not just WHAT
-- How to document your judgment calls and reasoning
-- How to work with AI as your creative partner
-- How to deliver in the form developers need (not just mockups)
-
-The Skeptic: "So I'm learning to communicate my thinking clearly?"
-
-The Advocate: "Yes. You're making your emotional labor visible and actionable. Your user-centric creativity becomes the specification that guides development."
-
-**Part 3: Assuming Leadership - Serving Client and Developers**
-
-The Advocate brings it home: "Third, you learn to assume leadership for the design process. Not leadership as in 'boss' - but leadership as in 'the person who makes things happen.' You become the linchpin who serves both the client and the developers with exactly what they need, in the form they need it."
-
-What you learn:
-
-- How to lead the design process (courage and curiosity, not confidence)
-- How to serve the client with clarity on business value
-- How to serve developers with specifications they can implement
-- How to be the gatekeeper who ensures quality and logic
-
-The Skeptic: "But I don't feel confident enough to lead."
-
-The Advocate: "That's the point - you don't need confidence to start. You need courage and curiosity. Confidence comes later, after a couple of projects, when you know what you can deliver. You start with courage to try, curiosity to learn, and the willingness to look foolish. Confidence is earned through practice."
-
-The Skeptic: "So I become indispensable by serving others?"
-
-The Advocate: "Exactly. Godin says linchpins make themselves indispensable by being generous - by giving their unique gifts to serve others. You're not hoarding knowledge or creating dependencies. You're providing clarity that makes everyone more effective."
-
-**WDS Guides You Through This:**
-
-The Advocate emphasizes: "This course is your guide through this transformation. Module by module, you'll build these capabilities. You'll learn the frameworks, practice the skills, and through practice, develop the confidence that comes from knowing what you can deliver."
-
-Your transformation:
-
-- **Understanding** - Business and user goals at a deep level
-- **Capability** - Working in the IDE, design as specification
-- **Leadership** - Serving client and developers with what they need
-- **Confidence** - Earned through practice, not required to start
-- **Result:** The linchpin designer who makes things happen
-
----
-
-### 6. Closing - Your Choice (3 min)
-
-The Advocate brings it home: "You've just learned why you're irreplaceable as a designer. Not because of your tools. Not because of your aesthetic taste. Because of your ability to provide emotional labor - to genuinely care about the outcome. To walk into chaos and create order. To navigate five dimensions of thinking simultaneously. To provide user-centric creativity that gives products a soul."
-
-The Skeptic, now transformed: "I see it now. I'm not competing with AI. I'm the gatekeeper. I'm the one who makes things happen. AI is my tool, not my replacement. But I have to be honest - I still feel like a beginner. I'm worried I'll look foolish."
-
-The Advocate responds with warmth: "That's the most important thing you just said. It's hard to be a beginner. Everyone feels that way. But here's what I want you to understand - we're banding together as linchpin designers. This isn't about being the best or knowing everything. It's about serving clients and developers in an honest and sustainable way."
-
-The Advocate continues: "Take the risk to look like a fool. Ask the 'stupid' questions. Share your struggles. Don't be afraid to reach out. The BMad community is here to help. We're all figuring this out together. That's what makes us strong."
-
-The Skeptic: "So I'm not alone in this?"
-
-The Advocate: "You're not alone. The question isn't whether AI will change design - it already has. The question is: are you a factory worker or a linchpin designer? Replaceable or indispensable? And will you join us in carving out this space together?"
-
-The Skeptic: "I choose to be indispensable. And I choose community over isolation. What do I do right now?"
-
-The Advocate gets fired up: "Right now? Right now you stop hiding. This is not the time to go into hibernation and hope it all just goes away. The AI era is here. The choice is made. You need to stand up with a mindset of:"
-
-**I Can. I Do. I Will.**  
-**No matter what. No matter when. No matter how.**
-
-The Advocate continues with passion: "Listen - designers half as smart as you have already made this transition. Now it's your turn. Let yourself be known! Stop waiting for the perfect moment. Stop waiting to feel ready. Stop waiting for permission."
-
-**The Action:**
-
-The Advocate: "Download an IDE. Install BMad. Select WDS in the installation. Build something. It doesn't matter what. Get moving and you will figure it out. That's how this works. You learn by doing. You build confidence through practice. You become a linchpin by acting like one."
-
-The Skeptic: "Just... start? Even if I don't know what I'm doing?"
-
-The Advocate: "Especially if you don't know what you're doing. That's courage. That's curiosity. That's the beginning of confidence. Module 02: Project Brief will guide you. The BMad Discord will support you. But you have to take the first step. Download. Install. Build. Move."
-
-The Advocate brings it home: "The transformation continues, together. But it starts with you choosing to act. Right now. Today. Let yourself be known."
-
----
-
-## Resources to Include
-
-At the end of the podcast, The Advocate should mention these resources:
-
-**Key Concepts:**
-
-- Seth Godin's book: "Linchpin: Are You Indispensable?" (2010)
-- Bestselling author and marketing visionary Seth Godin
-- Factory mindset vs linchpin mindset
-- Emotional labor - what linchpins provide
-- User-centric creativity - emotional labor for designers
-- The paradigm shift: design becomes specification
-- 5-dimensional thinking
-
-**Next Steps:**
-
-- Complete Module 02: Project Brief
-- Apply 5-dimensional thinking to your current project
-- Start capturing WHY in your design decisions
-- Practice being the gatekeeper between business and user needs
-
-**Community:**
-
-- BMad Discord: Share your transformation journey
-- GitHub Discussions: Ask questions about becoming a linchpin designer
-
----
-
-## NotebookLM Audio Generation Guidelines
-
-**Tone:**
-
-- Deeply empathetic about the shame and fear designers feel
-- Honest and direct about the AI threat for factory workers
-- Empowering and inspiring about the opportunity for linchpin designers
-- Warm and welcoming about community support
-- Use Seth Godin's concepts and language throughout
-- Make the transformation feel urgent but achievable
-- Balance fear (replaceable) with hope (indispensable) and community (not alone)
-
-**Key messages to emphasize:**
-
-- **The linchpin question** - are you a factory worker or a linchpin designer?
-- **Emotional labor** - what linchpins provide (Seth Godin's concept from his 2010 book)
-- **User-centric creativity** - the designer's irreplaceable gift (emotional labor in action)
-- **Three irreplaceable gifts** - emotional labor, user-centric creativity, gatekeeper role
-- **Walking into chaos and creating order** - what linchpins do
-- **Designer as gatekeeper** - protecting quality, catching mistakes, ensuring logic
-- **5-dimensional thinking** - navigating complexity that AI cannot handle
-- **The paradigm shift** - design thinking becomes specification, preserving creative intent
-- **The three-part transformation** - understanding, capability, leadership
-- **Part 1: Understanding** - business and user goals at a deep level
-- **Part 2: Capability** - working in the IDE, design as specification
-- **Part 3: Leadership** - serving client and developers with what they need
-- **WDS guides you** - concrete process, module by module
-- **Community support** - we're banding together as linchpin designers
-- **It's hard to be a beginner** - take the risk, the BMad community is here to help
-- **No more hiding** - this is not the time to go into hibernation
-- **I Can. I Do. I Will. No matter what, no matter when, no matter how.** - the mindset you need right now
-- **Designers half as smart have already done this** - now it's your turn
-- **Let yourself be known** - download, install, build, move
-- **Action beats perfection** - get moving and you will figure it out
-
-**Avoid:**
-
-- Being too theoretical or academic
-- Repeating doom/gloom from Getting Started module
-- Focusing too much on AI threat instead of human value
-- Making unrealistic promises or comparisons
-- Making it sound like you have to be perfect or know everything
-- Mentioning specific project examples or timelines
-
----
-
-## Expected Output
-
-A natural, engaging conversation that:
-
-- **Focuses on human value** - what makes designers irreplaceable
-- **Explains the linchpin concept** clearly using Seth Godin's framework
-- **Emphasizes emotional labor** as the core of linchpin work
-- **Details user-centric creativity** as the designer's irreplaceable gift
-- **Explains the three irreplaceable gifts** - emotional labor, user-centric creativity, gatekeeper role
-- **Teaches 5-dimensional thinking** as the practical skill that makes designers indispensable
-- **Shows the practical HOW** - the three-part transformation WDS guides you through
-- **Part 1:** Understanding business and user goals
-- **Part 2:** Working in the IDE, design as specification
-- **Part 3:** Assuming leadership, serving client and developers
-- **Emphasizes WDS as your guide** - concrete process, step by step
-- **Builds community** - you're not alone in this journey
-- **Ends with powerful call to action** - no more hiding, time to act NOW
-- **I Can. I Do. I Will.** - the mindset shift
-- **Download. Install. Build. Move.** - concrete first steps
-- Takes 30 minutes to listen to
-
----
-
-## Alternative: Video Script
-
-If generating video instead of audio, add these visual elements:
-
-**On-screen text:**
-
-- "Factory Worker or Linchpin Designer?"
-- Seth Godin quote: "Linchpins walk into chaos and create order"
-- "Emotional Labor: The Work of Genuinely Caring"
-- "User-Centric Creativity: The Designer's Gift"
-- "Three Irreplaceable Gifts"
-- "The 5 Dimensions of Design Thinking"
-- "The Paradigm Shift: Design Becomes Specification"
-- "I Can. I Do. I Will."
-- "No Matter What. No Matter When. No Matter How."
-- "Let Yourself Be Known"
-- "Download. Install. Build. Move."
-- "Next: Module 02 - Project Brief"
-
-**B-roll suggestions:**
-
-- Designer walking into chaos, creating order
-- Linchpin connecting disparate ideas
-- Designer providing emotional labor - caring, empathizing
-- User-centric creativity in action
-- Designer as gatekeeper - evaluating, protecting quality
-- 5 dimensions visualized as interconnected circles
-- Designer navigating complexity simultaneously
-- Transformation journey: uncertain → confident
-- Community of linchpin designers
-
----
-
-## Usage Tips
-
-1. **Upload THIS SINGLE FILE** to NotebookLM - no other files needed
-2. **Use the prompt exactly** as written for best results
-3. **Generate multiple versions** and pick the best one
-4. **Share the audio/video** with your team or community
-5. **Iterate** - if the output isn't quite right, refine the prompt
-
----
-
-## Next Steps
-
-After generating Module 01 content:
-
-- Create NotebookLM prompt for Module 02: Project Brief
-- Build prompts for all remaining modules
-- Share in BMad Discord designer channel
-
----
-
-**This module transforms how designers think about their role in the AI era - from threatened to indispensable!** 🎯✨
diff --git a/docs/learn-wds/course-explainers/Module-01-thumbnail-prompt.md b/docs/learn-wds/course-explainers/Module-01-thumbnail-prompt.md
deleted file mode 100644
index 5f9b85e03..000000000
--- a/docs/learn-wds/course-explainers/Module-01-thumbnail-prompt.md
+++ /dev/null
@@ -1,33 +0,0 @@
-**IMPORTANT: Use the reference image as your exact style guide. Match all visual elements, colors, layout, and character design.**
-
-Create a 1920x1080px YouTube thumbnail matching the reference image style.
-
-**What to Change from Reference:**
-
-**Headlines (Left side):**
-- Line 1: "LET'S GET TO WORK:" (Rubrik Light, 91pt, white)
-- Line 2: "HOW TO ACTUALLY BECOME" (Rubrik Bold, 91pt, white)
-- Line 3: "IRREPLACEABLE AS A DESIGNER!" (Rubrik Bold, 91pt, white)
-- Line spacing: 79pt
-
-**Module Badge (Bottom-left):**
-- "01 Foundation" (Rubrik Regular, 108pt, white on red #ff1744)
-
-**Character Activity:**
-- Woman piecing folders, files and puzzle pieces together in an intricate pattern on the table
-- skip the tablet
-- keep the carracter stylized as it is
-
-
-**Background Pattern:**
-- Add subtle architectural elements (pillars, building blocks)
-- Keep as in reference image
-
-**Workspace Props:**
-- Add: building blocks, structural diagrams
-
-**Keep Everything Else from Reference:**
-- Top-right branding text
-- Character design and style
-- Color scheme and layout
-
diff --git a/docs/learn-wds/course-explainers/Module-01-transcript.srt b/docs/learn-wds/course-explainers/Module-01-transcript.srt
deleted file mode 100644
index 1a5487ca5..000000000
--- a/docs/learn-wds/course-explainers/Module-01-transcript.srt
+++ /dev/null
@@ -1,731 +0,0 @@
-1
-00:00:00,240 --> 00:00:01,903
-If you're a designer, you've probably
-
-2
-00:00:01,903 --> 00:00:03,843
-felt that little knot in your stomach
-
-3
-00:00:03,843 --> 00:00:06,614
-every time you see a new AI tool that can
-
-4
-00:00:06,614 --> 00:00:08,277
-do something you thought was uniquely
-
-5
-00:00:08,277 --> 00:00:10,216
-yours. But what if that anxiety is
-
-6
-00:00:10,216 --> 00:00:11,879
-actually a signal not that you're
-
-7
-00:00:11,879 --> 00:00:13,819
-becoming obsolete, but that your role is
-
-8
-00:00:13,819 --> 00:00:15,759
-about to become more important than ever
-
-9
-00:00:15,759 --> 00:00:17,699
-before? In this explainer, we're going to
-
-10
-00:00:17,699 --> 00:00:19,916
-break down how to make that shift from
-
-11
-00:00:19,916 --> 00:00:21,314
-feeling threatened. To becoming
-
-12
-00:00:21,314 --> 00:00:23,073
-absolutely indispensable. This is the
-
-13
-00:00:23,073 --> 00:00:25,185
-question, right? It's on every designer's
-
-14
-00:00:25,185 --> 00:00:27,1000
-mind, and it's a totally valid fear. I
-
-15
-00:00:27,1000 --> 00:00:30,111
-mean, we see AI generating entire
-
-16
-00:00:30,111 --> 00:00:31,871
-interfaces, creating stunning images from
-
-17
-00:00:31,871 --> 00:00:34,686
-a text prompt, and it's so easy to
-
-18
-00:00:34,686 --> 00:00:37,501
-just wonder, OK, so where do I fit
-
-19
-00:00:37,501 --> 00:00:40,316
-in now? But what if we're asking the
-
-20
-00:00:40,316 --> 00:00:42,237
-wrong question?Entirely. The marketing
-
-21
-00:00:42,237 --> 00:00:44,492
-genius Seth Godin dropped this incredible
-
-22
-00:00:44,492 --> 00:00:47,123
-idea in his book Linchpin. He said
-
-23
-00:00:47,123 --> 00:00:49,753
-that the real value isn't just in
-
-24
-00:00:49,753 --> 00:00:52,384
-doing tasks, it's in walking into total
-
-25
-00:00:52,384 --> 00:00:55,014
-chaos and creating order. And man, that
-
-26
-00:00:55,014 --> 00:00:57,269
-one idea just flips the whole
-
-27
-00:00:57,269 --> 00:00:59,899
-conversation about AI on its head. So
-
-28
-00:00:59,899 --> 00:01:02,530
-this brings us to a fundamental choice.
-
-29
-00:01:02,750 --> 00:01:05,129
-AI is already here, it's already changing
-
-30
-00:01:05,129 --> 00:01:07,508
-the game. The real question isn't if
-
-31
-00:01:07,508 --> 00:01:09,886
-things will change, it's how are you
-
-32
-00:01:09,886 --> 00:01:12,605
-going to change with them? What kind of
-
-33
-00:01:12,605 --> 00:01:15,324
-designer are you going to choose to be?
-
-34
-00:01:15,324 --> 00:01:17,363
-Golden lays out 2 completely different
-
-35
-00:01:17,363 --> 00:01:19,742
-paths. On one side you've got the
-
-36
-00:01:19,742 --> 00:01:21,781
-replaceable worker. This is someone who
-
-37
-00:01:21,781 --> 00:01:23,225
-follows instructions creates. Predictable
-
-38
-00:01:23,225 --> 00:01:25,982
-stuff, and let's be real, AI is getting
-
-39
-00:01:25,982 --> 00:01:28,739
-scary good at that. But then there's the
-
-40
-00:01:28,739 --> 00:01:30,462
-other path, the indispensable linchpin.
-
-41
-00:01:30,462 --> 00:01:32,875
-This is the person who doesn't just
-
-42
-00:01:32,875 --> 00:01:35,632
-follow the map. They draw the map, they
-
-43
-00:01:35,632 --> 00:01:37,700
-invent solutions, they thrive in chaos,
-
-44
-00:01:37,700 --> 00:01:39,423
-and maybe most importantly, they
-
-45
-00:01:39,423 --> 00:01:41,836
-genuinely care. OK, so this whole factory
-
-46
-00:01:41,836 --> 00:01:44,275
-versus lynchpin idea. Sounds great in a
-
-47
-00:01:44,275 --> 00:01:46,866
-book, but what does it actually mean in
-
-48
-00:01:46,866 --> 00:01:49,456
-the real world of design? What does this
-
-49
-00:01:49,456 --> 00:01:51,399
-look like in your day-to-day projects?
-
-50
-00:01:51,399 --> 00:01:53,990
-Let's dig in. The heart of lynchpin work,
-
-51
-00:01:53,990 --> 00:01:56,256
-according to Godin, is something he calls
-
-52
-00:01:56,256 --> 00:01:58,199
-emotional labor. Now, this isn't about
-
-53
-00:01:58,199 --> 00:02:00,790
-being weepy at your desk. It's the hard,
-
-54
-00:02:00,790 --> 00:02:02,732
-often invisible work of empathy. It's
-
-55
-00:02:02,732 --> 00:02:04,903
-about, really. Connecting with people and
-
-56
-00:02:04,903 --> 00:02:07,083
-truly, deeply caring about the final
-
-57
-00:02:07,083 --> 00:02:09,989
-outcome. So what is emotional labor for a
-
-58
-00:02:09,989 --> 00:02:11,805
-designer? It's user centric creativity.
-
-59
-00:02:11,805 --> 00:02:14,348
-That's it. It's taking that genuine care
-
-60
-00:02:14,348 --> 00:02:16,891
-and putting it into action. It's that
-
-61
-00:02:16,891 --> 00:02:19,434
-uniquely human spark that lets you bridge
-
-62
-00:02:19,434 --> 00:02:22,340
-what a business needs with what our real
-
-63
-00:02:22,340 --> 00:02:24,326
-person actually wants. Creating an
-
-64
-00:02:24,326 --> 00:02:26,263
-experience that just feels right. You
-
-65
-00:02:26,263 --> 00:02:28,845
-know an AI can generate 1000 layouts but
-
-66
-00:02:28,845 --> 00:02:31,105
-it cannot genuinely care. Not for real.
-
-67
-00:02:31,105 --> 00:02:34,010
-And this, this is where we get to the
-
-68
-00:02:34,010 --> 00:02:36,270
-good stuff. Your true value isn't your
-
-69
-00:02:36,270 --> 00:02:38,852
-mastery of figma or your ability to push
-
-70
-00:02:38,852 --> 00:02:41,435
-pixels around a screen. It's in the gifts
-
-71
-00:02:41,435 --> 00:02:44,017
-you bring to the table that are uniquely
-
-72
-00:02:44,017 --> 00:02:46,858
-human. The things that I, by its
-
-73
-00:02:46,858 --> 00:02:49,076
-very design, just can't copy. Let's
-
-74
-00:02:49,076 --> 00:02:51,293
-breakdown exactly what those are. It
-
-75
-00:02:51,293 --> 00:02:54,250
-really boils down to three key gifts that
-
-76
-00:02:54,250 --> 00:02:56,099
-make you irreplaceable. First, that
-
-77
-00:02:56,099 --> 00:02:58,686
-emotional labor we just talked about that
-
-78
-00:02:58,686 --> 00:03:00,904
-genuine sense of caring. Second, user
-
-79
-00:03:00,904 --> 00:03:03,121
-centric creativity. Your ability to be
-
-80
-00:03:03,121 --> 00:03:04,988
-the ultimate connector between. Business
-
-81
-00:03:04,988 --> 00:03:07,533
-goals and human needs. And 3rd, and this
-
-82
-00:03:07,533 --> 00:03:10,078
-is a big one, you have the gatekeeper
-
-83
-00:03:10,078 --> 00:03:12,304
-role. You're the one who protects the
-
-84
-00:03:12,304 --> 00:03:14,213
-user. You're the quality control. You're
-
-85
-00:03:14,213 --> 00:03:16,758
-the one who asks, does this actually make
-
-86
-00:03:16,758 --> 00:03:19,302
-sense? This chart does a fantastic job of
-
-87
-00:03:19,302 --> 00:03:20,893
-showing the incredible complexity. You're
-
-88
-00:03:20,893 --> 00:03:22,801
-managing all the time. You're constantly
-
-89
-00:03:22,801 --> 00:03:25,172
-thinking in five dimensions at once. Why
-
-90
-00:03:25,172 --> 00:03:27,215
-does this company even exist? What does
-
-91
-00:03:27,215 --> 00:03:29,258
-success look like? How is this product
-
-92
-00:03:29,258 --> 00:03:31,885
-going to get us there? Who are we even
-
-93
-00:03:31,885 --> 00:03:33,928
-building this for? And is it even
-
-94
-00:03:33,928 --> 00:03:35,680
-technically possible? An AI can analyze
-
-95
-00:03:35,680 --> 00:03:38,307
-these pieces 1 by 1, sure, but it can't
-
-96
-00:03:38,307 --> 00:03:40,350
-hold them all in this delicate balance
-
-97
-00:03:40,350 --> 00:03:42,393
-while also bringing that human element of
-
-98
-00:03:42,393 --> 00:03:44,728
-caring to the table. That right there is
-
-99
-00:03:44,728 --> 00:03:46,674
-your. Superpower OK, this slide gets
-
-100
-00:03:46,674 --> 00:03:49,526
-right to the heart of the shift you have
-
-101
-00:03:49,526 --> 00:03:51,743
-to make. We're moving away from just
-
-102
-00:03:51,743 --> 00:03:53,644
-making pretty pictures and hoping the
-
-103
-00:03:53,644 --> 00:03:55,545
-developers can read our minds. For
-
-104
-00:03:55,545 --> 00:03:57,763
-instance, instead of just handing over a
-
-105
-00:03:57,763 --> 00:03:59,347
-static mockup, you deliver a
-
-106
-00:03:59,347 --> 00:04:00,614
-specification that actually preserves
-
-107
-00:04:00,614 --> 00:04:02,832
-your intent. You say this password field
-
-108
-00:04:02,832 --> 00:04:05,050
-must have real time strength feedback to.
-
-109
-00:04:05,130 --> 00:04:06,722
-Encourage strong passwords because our
-
-110
-00:04:06,722 --> 00:04:08,951
-research showed security as a top user
-
-111
-00:04:08,951 --> 00:04:11,180
-concern. You see the difference? You go
-
-112
-00:04:11,180 --> 00:04:13,727
-from just hoping it works to knowing it
-
-113
-00:04:13,727 --> 00:04:16,274
-will work. Alright, so we've talked a lot
-
-114
-00:04:16,274 --> 00:04:19,140
-about the what and the why, but I'm sure
-
-115
-00:04:19,140 --> 00:04:21,687
-you're thinking OK great, but how? How do
-
-116
-00:04:21,687 --> 00:04:23,916
-I actually do this? That's where the
-
-117
-00:04:23,916 --> 00:04:26,041
-Whiteboard Design Studio or. D Framework
-
-118
-00:04:26,041 --> 00:04:28,806
-comes in. Think of it as your concrete
-
-119
-00:04:28,806 --> 00:04:31,571
-path, your how to guide for making this
-
-120
-00:04:31,571 --> 00:04:33,299
-transformation happen. It's really a
-
-121
-00:04:33,299 --> 00:04:35,372
-three-part journey. First you go deeper,
-
-122
-00:04:35,372 --> 00:04:37,791
-you truly understand the core purpose of
-
-123
-00:04:37,791 --> 00:04:40,211
-the business and the user's goals. Then
-
-124
-00:04:40,211 --> 00:04:42,630
-you build the practical skills to capture
-
-125
-00:04:42,630 --> 00:04:44,703
-your thinking as a clear specification,
-
-126
-00:04:44,703 --> 00:04:46,672
-maybe even working. Right inside the
-
-127
-00:04:46,672 --> 00:04:48,108
-development environment. And finally, you
-
-128
-00:04:48,108 --> 00:04:50,119
-step into a leadership role. And that's
-
-129
-00:04:50,119 --> 00:04:52,417
-not about being a boss. It's about being
-
-130
-00:04:52,417 --> 00:04:54,427
-a guide. A servant leader who gives
-
-131
-00:04:54,427 --> 00:04:56,438
-everyone the clarity they need to do
-
-132
-00:04:56,438 --> 00:04:58,736
-their best work. And hey, if that word
-
-133
-00:04:58,736 --> 00:05:00,172
-leadership sounds a little intimidating,
-
-134
-00:05:00,172 --> 00:05:01,609
-just remember this confidence isn't
-
-135
-00:05:01,609 --> 00:05:03,619
-something you need to start. It's what
-
-136
-00:05:03,619 --> 00:05:06,354
-you get as a result of starting. All
-
-137
-00:05:06,354 --> 00:05:09,265
-you need on day one is the courage to
-
-138
-00:05:09,265 --> 00:05:11,530
-try something new and the curiosity to
-
-139
-00:05:11,530 --> 00:05:13,472
-see what happens. The confidence will
-
-140
-00:05:13,472 --> 00:05:16,060
-come, I promise. O here we are. The
-
-141
-00:05:16,060 --> 00:05:18,648
-theory is clear, the path is laid out.
-
-142
-00:05:18,648 --> 00:05:21,237
-Now it really all comes down to one
-
-143
-00:05:21,237 --> 00:05:23,502
-thing, a choice, your choice. You know
-
-144
-00:05:23,502 --> 00:05:26,090
-the temptation to just wait and see it's.
-
-145
-00:05:26,160 --> 00:05:28,940
-Wrong to kind of hope this whole AI
-
-146
-00:05:28,940 --> 00:05:31,719
-thing just blows over. But the AI era
-
-147
-00:05:31,719 --> 00:05:34,499
-is here. That ship has sailed. Hiding is
-
-148
-00:05:34,499 --> 00:05:37,279
-not a strategy. The only winning move is
-
-149
-00:05:37,279 --> 00:05:40,058
-to engage. This is the kind of mindset
-
-150
-00:05:40,058 --> 00:05:42,838
-that's going to carry you through. It's a
-
-151
-00:05:42,838 --> 00:05:44,923
-personal commitment to action. It's a
-
-152
-00:05:44,923 --> 00:05:47,513
-belief in your own power. Define your
-
-153
-00:05:47,513 --> 00:05:50,182
-value in this brand new world. It's
-
-154
-00:05:50,182 --> 00:05:52,470
-about consciously deciding right now to
-
-155
-00:05:52,470 --> 00:05:54,758
-become indispensable. When you boil it
-
-156
-00:05:54,758 --> 00:05:57,428
-all down, it comes to this so
-
-157
-00:05:57,428 --> 00:05:59,716
-simple. You can't wait for permission.
-
-158
-00:05:59,716 --> 00:06:02,385
-You can't wait for the perfect moment.
-
-159
-00:06:02,385 --> 00:06:05,055
-The only way forward is to start
-
-160
-00:06:05,055 --> 00:06:07,087
-building. Building your skills. Building
-
-161
-00:06:07,087 --> 00:06:09,107
-your projects, Building your future O
-
-162
-00:06:09,107 --> 00:06:11,465
-What does that actually look like today?
-
-163
-00:06:11,465 --> 00:06:14,159
-Here are a few simple first steps. Get
-
-164
-00:06:14,159 --> 00:06:16,180
-comfortable. In a developer's world, that
-
-165
-00:06:16,180 --> 00:06:18,201
-can mean downloading an IDE, an
-
-166
-00:06:18,201 --> 00:06:19,548
-integrated development environment. It's
-
-167
-00:06:19,548 --> 00:06:21,232
-basically just the workshop where
-
-168
-00:06:21,232 --> 00:06:22,915
-programmers build software. Then maybe
-
-169
-00:06:22,915 --> 00:06:25,273
-explore tools like Blind that help you
-
-170
-00:06:25,273 --> 00:06:27,466
-turn your design thinking. Directly into
-
-171
-00:06:27,466 --> 00:06:29,583
-code. But honestly, the most important
-
-172
-00:06:29,583 --> 00:06:32,406
-thing is just to start. Get moving, Build
-
-173
-00:06:32,406 --> 00:06:34,170
-something, anything, you'll learn by
-
-174
-00:06:34,170 --> 00:06:36,993
-doing. That is the whole key. The big
-
-175
-00:06:36,993 --> 00:06:39,110
-take away here is that your
-
-176
-00:06:39,110 --> 00:06:40,521
-transformation from threatened to
-
-177
-00:06:40,521 --> 00:06:42,639
-indispensable. It doesn't start when you
-
-178
-00:06:42,639 --> 00:06:45,109
-feel ready, it starts the exact moment
-
-179
-00:06:45,109 --> 00:06:47,694
-you decide to act. The tools, the
-
-180
-00:06:47,694 --> 00:06:49,542
-resources, they're all out there just
-
-181
-00:06:49,542 --> 00:06:51,698
-waiting for you. So the only question
-
-182
-00:06:51,698 --> 00:06:54,162
-left is, will you take that first step?
-
-183
-00:06:54,162 --> 00:06:56,010
-Will you let yourself be known?
diff --git a/docs/learn-wds/course-explainers/Module-02-notebook-lm-prompt.md b/docs/learn-wds/course-explainers/Module-02-notebook-lm-prompt.md
deleted file mode 100644
index 1e08f8f85..000000000
--- a/docs/learn-wds/course-explainers/Module-02-notebook-lm-prompt.md
+++ /dev/null
@@ -1,342 +0,0 @@
-# NotebookLM Prompt: Module 02 - Installation & Setup
-
-**Use this prompt to generate audio/video content for Module 02: Installation & Setup**
-
----
-
-## Instructions for NotebookLM
-
-**This is a single, self-contained prompt file.**
-
-Simply upload THIS FILE to NotebookLM and use the prompt below to generate engaging audio/video content. No other files needed.
-
----
-
-## Prompt
-
-Create an engaging 30-minute podcast conversation between two hosts about Module 02 of the Whiteport Design Studio (WDS) course: Installation & Setup.
-
-**IMPORTANT: WDS stands for Whiteport Design Studio - always refer to it by its full name "Whiteport Design Studio" or "WDS" throughout the conversation.**
-
-**Host 1 (The Nervous Beginner):** A designer who's never used GitHub, Git, or IDE tools. Worried about technical setup, afraid of making mistakes, needs reassurance and clear guidance.
-
-**Host 2 (The Patient Guide - Mimir's Voice):** An experienced designer who remembers being a beginner. Warm, encouraging, patient. Explains complex concepts simply and celebrates small wins.
-
-**Conversation structure:**
-
-### 1. Opening (3 min) - You Can Do This
-
-The Nervous Beginner: "I'm excited about WDS, but honestly... I've never used GitHub. I've never installed an IDE. I'm worried I'll mess something up and not be able to fix it. Is this course even for someone like me?"
-
-The Guide: "That's exactly who this course is FOR! Let me tell you something important: every single experienced designer you admire was once exactly where you are now. Uncertain. Nervous. Wondering if they could do it. And you know what? They all figured it out. And so will you. Because we're going to walk through this together, step by step, celebrating every small win."
-
-The Guide continues: "Here's the beautiful truth: modern tools have gotten so good that most of what used to be 'technical' is now just... clicking buttons. GitHub? It's basically cloud storage with a time machine. An IDE? It's like Microsoft Word, but for design files. Git? Your IDE installs it for you automatically. You're not learning to code. You're just... getting set up."
-
-Introduce the module: "In the next 30 minutes, you'll go from 'I don't know what any of this means' to 'Oh! That's actually pretty simple.' We'll cover GitHub, IDEs, cloning repositories, and meeting Mimir - your WDS guide. And I promise: if you can use a computer and follow instructions, you can do this."
-
----
-
-### 2. Lesson 01 - Git Setup (8 min)
-
-The Nervous Beginner: "Okay, let's start. What even IS Git? And GitHub? Are they the same thing?"
-
-**Understanding Git and GitHub (2 min)**
-
-The Guide: "Great question! They're related but different. Git is the sync engine - the behind-the-scenes tool that tracks changes. GitHub is the website - your professional cloud storage. Think of Git as the engine, GitHub as the car."
-
-The Guide continues: "Here's what GitHub does for you: Every time you save your work, it's backed up. You can go back to any previous version. You can work with other designers. You can share with clients or developers. It's like Google Drive, but specifically built for project files with a complete history."
-
-**Creating Your GitHub Account (3 min)**
-
-The Nervous Beginner: "That actually makes sense! So how do I get started?"
-
-The Guide walks through:
-- Go to github.com and sign up
-- Choose a professional username (you might share this with clients!)
-- Verify your email
-- "See? You already did something technical! That was easy, right?"
-
-**Repository Structure Decision (3 min)**
-
-The Nervous Beginner: "Now what? I need to create a... repository?"
-
-The Guide: "Yes! A repository is just a folder that GitHub tracks. But here's the important part: how you NAME it determines your structure. This is a strategic decision."
-
-Explain the two options:
-- **Single repo** (`my-project`): Specs and code together - for small teams, building yourself
-- **Separate specs repo** (`my-project-specs`): Specs only - for corporate, many developers
-
-The Guide: "Most beginners should use single repo. It's simpler. You can always split later if needed."
-
-Walk through:
-- Name your repository based on your choice
-- Add a description
-- Public (portfolio) or Private (client work)
-- Check 'Initialize with README'
-- Create!
-
-The Guide celebrates: "Look at that! You just created your first GitHub repository. You're officially a GitHub user. How does that feel?"
-
----
-
-### 3. Lesson 02 - IDE Installation (6 min)
-
-The Nervous Beginner: "Okay, that wasn't scary at all! What's next?"
-
-**What is an IDE? (2 min)**
-
-The Guide: "Now we install your workspace. An IDE - Integrated Development Environment - sounds technical, but it's just... your workspace. Like Microsoft Word is your workspace for documents, Cursor is your workspace for design specifications."
-
-The Guide continues: "For WDS, I recommend Cursor. It's built for AI-augmented work. But VS Code works great too if you prefer. Both are free."
-
-**Installation Process (2 min)**
-
-Walk through:
-- Download from cursor.sh
-- Install (just click through like any app)
-- First launch: Choose theme (Light or Dark - totally personal preference!)
-- Sign in with GitHub (makes everything easier)
-- Install recommended extensions
-
-The Nervous Beginner: "Wait, that's it? I just... downloaded and installed it like any other app?"
-
-The Guide: "Exactly! See? Not scary. You've been installing apps your whole life. This is the same thing."
-
-**Terminal Verification (2 min)**
-
-The Guide: "One more thing. Press Ctrl+` (or Cmd+` on Mac). See that panel that appears at the bottom? That's called a terminal. It's how you'll talk to Git."
-
-The Nervous Beginner: "A terminal sounds scary..."
-
-The Guide: "I know! But here's the secret: you'll mostly just copy and paste commands. Think of it like a command line where you type instructions instead of clicking buttons. And we'll give you every command. You'll see - it's actually pretty satisfying!"
-
----
-
-### 4. Lesson 03 - Git Repository Cloning (5 min)
-
-The Nervous Beginner: "Alright, I have GitHub, I have an IDE. Now what?"
-
-**Understanding Cloning (2 min)**
-
-The Guide: "Now we 'clone' your repository. Clone just means 'make a copy on your computer.' Your project lives in GitHub (the cloud). Now we bring it down to your computer so you can work on it."
-
-The Guide explains: "When you clone, you're creating a local copy that stays in sync with GitHub. Work on your computer, save to GitHub. It's like Dropbox sync, but with full version history."
-
-**The Cloning Process (3 min)**
-
-Walk through:
-- Create a Projects folder (nice organized home for everything)
-- Get your repository URL from GitHub (click Code → copy)
-- Open terminal in Cursor
-- Type: `git clone [paste URL]`
-- Watch it download!
-
-The Guide: "And here's the magic moment - Cursor will say 'Install Git?' if you don't have it. You click Install. It installs automatically. And that's it! Git is set up."
-
-The Nervous Beginner: "Wait, so I DON'T have to manually install Git?"
-
-The Guide: "Nope! The IDE handles it. See? Modern tools take care of you. Now open your project folder in Cursor - File → Open Folder. And there's your project!"
-
----
-
-### 5. Lesson 04 - WDS Project Initialization (6 min)
-
-The Nervous Beginner: "I can see my project! This is actually exciting!"
-
-**Adding WDS to Your Workspace (2 min)**
-
-The Guide: "Now the fun part - we add the WDS methodology to your workspace. WDS lives separately from your project, so you can use it across multiple projects."
-
-Walk through:
-- Clone WDS repository (same as you just did!)
-- Add it to workspace (File → Add Folder to Workspace)
-- Now you see both: your-project AND whiteport-design-studio
-
-The Nervous Beginner: "So WDS is like... a reference library that lives next to my project?"
-
-The Guide: "Perfect analogy! It contains all the agents, workflows, and training. You reference it, but your actual work stays in your project."
-
-**Creating the Docs Structure (2 min)**
-
-The Guide: "Now we create the magic folder: `docs/`. This is where ALL your WDS specifications will live. Your design source of truth."
-
-Walk through creating 8 phase folders:
-- 1-project-brief
-- 2-trigger-mapping
-- 3-prd-platform
-- 4-ux-design
-- 5-design-system
-- 6-design-deliveries
-- 7-testing
-- 8-ongoing-development
-
-The Guide: "These 8 folders represent the complete WDS methodology. You'll learn what goes in each one as you progress through the course."
-
-**Meeting Mimir (2 min)**
-
-The Nervous Beginner: "Okay, folders created. Now what?"
-
-The Guide: "Now you meet Mimir! He's your WDS guide and orchestrator. Find the file `MIMIR-WDS-ORCHESTRATOR.md` in the WDS folder. Drag it to your AI chat. Say hello!"
-
-Describe what happens:
-- Mimir introduces himself warmly
-- He asks about your skill level (be honest!)
-- He checks your setup
-- He guides your next steps
-- He connects you with specialists when ready
-
-The Guide: "And here's the beautiful part: from now on, whenever you're stuck, confused, or need guidance - just type `@wds-mimir [your question]`. He's always there. You're never alone in this."
-
----
-
-### 6. Celebration and Next Steps (2 min)
-
-The Guide: "Do you realize what you just accomplished?"
-
-List the achievements:
-- Created a GitHub account
-- Set up a repository
-- Installed a professional IDE
-- Cloned your first repository
-- Integrated WDS
-- Created proper folder structure
-- Activated your personal guide
-
-The Guide: "That's HUGE! Many designers never get past this step. They get overwhelmed, give up. But you? You did it. You should genuinely be proud."
-
-The Nervous Beginner: "You're right... I was really nervous, but I actually DID it. It wasn't as scary as I thought."
-
-The Guide: "That's the pattern you'll see throughout WDS. Things that sound intimidating become manageable when broken down into steps. And now? Now you're ready to start the actual methodology. Module 03 awaits: Creating your Project Brief."
-
----
-
-### 7. Closing - The Power of Belief (1 min)
-
-The Guide: "Before we wrap up, I want to share something Mimir would say: 'You can do this. I believe in you.' Those aren't empty words. They're based on a simple truth - you just proved you can learn new technical things. You just set up a complete professional development environment from scratch. If you can do that, you can master WDS."
-
-The Nervous Beginner: "Thank you. I actually feel... capable. Like I might actually be able to do this."
-
-The Guide: "You don't 'might be able.' You ARE able. You just did. Welcome to WDS. Mimir is waiting for you."
-
----
-
-## Content to Include
-
-**Module 02 covers:**
-
-**Lesson 01: Git Setup**
-- Creating GitHub account with professional username
-- Understanding repositories as tracked folders
-- Single repo vs separate specs repo decision
-- Repository naming determines structure
-- Creating new repository or joining existing
-- Strategic guidance on when to use each approach
-
-**Lesson 02: IDE Installation**
-- What an IDE is (workspace for specifications)
-- Cursor vs VS Code comparison
-- Installation process (platform-specific)
-- First launch setup and GitHub sign-in
-- Terminal verification
-
-**Lesson 03: Git Repository Cloning**
-- Creating organized Projects folder
-- Understanding cloning (cloud to local)
-- Getting repository URL from GitHub
-- Cloning with git clone command
-- Git auto-installation by IDE
-- Opening project in IDE
-
-**Lesson 04: WDS Project Initialization**
-- Cloning WDS repository separately
-- Adding WDS to workspace (dual folder setup)
-- Creating 8-phase docs structure
-- Understanding what each phase represents
-- Finding and activating Mimir
-- First conversation with Mimir
-- The @wds-mimir command for ongoing help
-
----
-
-## Key Messages to Emphasize
-
-1. **"You Can Do This"**
-   - Modern tools handle complexity automatically
-   - Setup is mostly clicking buttons
-   - Following instructions, not learning to code
-   - Every expert was once a nervous beginner
-
-2. **"It's Not As Scary As It Sounds"**
-   - GitHub = cloud storage with history
-   - IDE = workspace app like Word
-   - Cloning = copying files
-   - Terminal = typing commands instead of clicking
-
-3. **"Strategic Decisions Matter"**
-   - Repository naming determines structure
-   - Single vs separate affects workflow
-   - Think about your team situation
-   - Can always adjust later
-
-4. **"You're Never Alone"**
-   - Mimir is always available
-   - @wds-mimir [any question]
-   - Community support
-   - No question too small
-
-5. **"Small Wins Build Confidence"**
-   - Celebrate creating GitHub account
-   - Celebrate installing IDE
-   - Celebrate first clone
-   - Celebrate meeting Mimir
-
----
-
-## Tone and Approach
-
-**For The Nervous Beginner:**
-- Genuine vulnerability about technical topics
-- Asks clarifying questions
-- Expresses relief when things are simpler than expected
-- Grows in confidence through the conversation
-- Represents the listener's internal dialogue
-
-**For The Guide:**
-- Warm, patient, never condescending
-- Uses simple analogies (cloud storage, Word, Dropbox)
-- Celebrates every small accomplishment
-- Normalizes being a beginner
-- Provides encouragement genuinely
-- Speaks with Mimir's wisdom and warmth
-
-**Overall tone:**
-- Supportive and encouraging
-- Practical with concrete examples
-- Honest about difficulty (it can feel overwhelming)
-- Celebrating progress ("Look what you just did!")
-- Building genuine confidence through achievement
-
----
-
-## Target Audience
-
-**Designers who:**
-- Have never used GitHub or Git
-- Are nervous about "technical" setup
-- Worry they'll break something
-- Need step-by-step guidance
-- Want reassurance they can do this
-- May have imposter syndrome about technical topics
-
-**This module proves:** If you can follow instructions and click buttons, you can set up a professional development environment. Technical confidence comes from doing, not from prior knowledge.
-
----
-
-## Call to Action
-
-End with: "You've completed Module 02. Your environment is ready. Mimir is waiting in your AI chat. And Module 03 - Creating Your Project Brief - is where the real magic begins. You're not a beginner anymore. You're a designer with a professional setup. Welcome to WDS."
-
----
-
-**Upload this file to NotebookLM to generate installation training content**
-
diff --git a/docs/learn-wds/course-explainers/Module-02-thumbnail-prompt.md b/docs/learn-wds/course-explainers/Module-02-thumbnail-prompt.md
deleted file mode 100644
index 8c92e9be7..000000000
--- a/docs/learn-wds/course-explainers/Module-02-thumbnail-prompt.md
+++ /dev/null
@@ -1,34 +0,0 @@
-**IMPORTANT: Use the reference image as your exact style guide. Match all visual elements, colors, layout, and character design.**
-
-Create a 1920x1080px YouTube thumbnail matching the reference image style.
-
-**What to Change from Reference:**
-
-**Headlines (Left side):**
-- Line 1: "INSTALL WDS:" (Rubrik Light, 91pt, white)
-- Line 2: "MASTER YOUR NEW" (Rubrik Bold, 91pt, white)
-- Line 3: "DESIGN WORKSPACE!" (Rubrik Bold, 91pt, white)
-- Line spacing: 79pt
-
-**Module Badge (Bottom-left):**
-- "02 Installation" (Rubrik Regular, 108pt, white on red #ff1744)
-
-**Character Activity:**
-- Woman assembling a some strange machine with cogs and pins laying flat upside down on the table
-- She has paused, holding a cog in her hand, thinking about where to place it
-- Skip the tablet
-- Keep the character stylized as it is
-
-**Background Pattern:**
-- Replace the objects in the background but keep the same style and add a giant circuit board layout that covers the whole background
-- Keep the same color scheme and lighting
-
-**Workspace Props:**
-- Add: open manual on the desk beside her, mechanical parts (cogs, pins)
-
-**Keep Everything Else from Reference:**
-- do not put light objects behind her face since we need to keep her silhouette clear
-- Top-right branding text
-- Character design and style
-- Color scheme and layout
-
diff --git a/docs/learn-wds/course-explainers/Module-03-notebook-lm-prompt.md b/docs/learn-wds/course-explainers/Module-03-notebook-lm-prompt.md
deleted file mode 100644
index 42f25d8e6..000000000
--- a/docs/learn-wds/course-explainers/Module-03-notebook-lm-prompt.md
+++ /dev/null
@@ -1,745 +0,0 @@
-# NotebookLM Prompt: Module 03 - Alignment & Signoff
-
-**Use this prompt to generate audio/video content for Module 03: Alignment & Signoff**
-
----
-
-## Instructions for NotebookLM
-
-**This is a single, self-contained prompt file.**
-
-Simply upload THIS FILE to NotebookLM and use the prompt below to generate engaging audio/video content. No other files needed.
-
----
-
-## Prompt
-
-Create an engaging 35-40 minute podcast conversation between two hosts discussing Module 03 of the Whiteport Design Studio (WDS) course: Alignment & Signoff.
-
-**IMPORTANT: WDS stands for Whiteport Design Studio - always refer to it by its full name "Whiteport Design Studio" or "WDS" throughout the conversation.**
-
-**Host 1 (The Hesitant Designer):** A designer who struggles with the business side of projects. Uncomfortable talking about money, afraid of contracts, and unsure how to position themselves professionally. Often undersells their value and gets stuck in scope creep situations.
-
-**Host 2 (The Strategic Professional):** A designer who has learned to navigate the business side with confidence. Understands that protecting the project with clear agreements is serving the client, not being defensive. Has learned from painful lessons.
-
-**Conversation structure:**
-
-### 1. Opening (3 min) - Why This Feels Uncomfortable
-
-Start with The Hesitant Designer expressing their discomfort: "I just want to design. The business stuff - pitches, contracts, negotiations - it makes me uncomfortable. I feel like I'm being pushy or greedy when I talk about money. Can't I just skip this part and start designing?"
-
-The Strategic Professional responds with empathy: "I get it. I used to feel exactly the same way. But here's what I learned the hard way: skipping alignment and signoff doesn't make you generous - it makes you unprofessional. And ultimately, it hurts the client even more than it hurts you."
-
-The Strategic Professional continues: "This is Module 03 of the Whiteport Design Studio method - WDS for short. And here's why this module exists: we realized through over 10 years of design and IT projects that the foundation you build BEFORE design work often has more impact on the project's success than the design itself. A brilliant design built on misaligned expectations fails. A good design built on solid alignment succeeds."
-
-The Hesitant Designer: "Wait, the foundation is more impactful than the design?"
-
-The Strategic Professional: "Often, yes. If you and your client aren't aligned on what success looks like, if the contract doesn't protect both of you, if expectations are fuzzy - no amount of brilliant design will save that project. That's why WDS includes this module with templates and agent instructions based on years of painful lessons."
-
-The Strategic Professional continues: "In the next 40 minutes, you'll discover something that changes everything: when you genuinely understand what success looks like for your client - when you can clearly specify their desired outcomes - pitching stops feeling like selling and starts feeling like helping. You'll learn when you actually need this (hint: not always), how to ask the questions that reveal what they truly need, and how to create alignment documents and contracts that protect both you and your client. This is about building sustainable, healthy working relationships where everyone wins."
-
-The Hesitant Designer: "Okay, but what's the actual process? What are the steps?"
-
-**The Clear Workflow:**
-
-The Strategic Professional: "Here's the entire WDS workflow for this phase - from first conversation to project start:
-
-1. **Listen** - Discovery meeting with client to understand their goals and what's important for success
-2. **Create** - Build a pitch (alignment document) based on what they told you they need
-3. **Present** - Share your proposal in a second meeting showing you understood them
-4. **Negotiate** - Adjust and refine together until you find the perfect match
-5. **Accept** - They say yes to the pitch
-6. **Contract** - Generate a short, clear contract based on the accepted pitch
-7. **Sign** - Both parties sign
-8. **Brief** - Use the pitch and contract as the backbone of your project brief
-
-The pitch and contract aren't throwaway documents - they become the foundation that guides everything that follows. This is the WDS way: every step builds on the previous one, creating a connected workflow instead of isolated documents."
-
-The Hesitant Designer: "So WDS gives me templates and instructions for each of these steps?"
-
-The Strategic Professional: "Exactly. WDS includes Saga the Analyst - an AI agent with instructions based on over 10 years of design and IT project experience. She guides you through discovery questions, helps you create the pitch, and generates contracts that actually work. You're not figuring this out alone - you have a thinking partner trained on real-world lessons."
-
----
-
-### 2. Understanding Alignment (8 min) - When You Need It (And When You Don't)
-
-The Hesitant Designer asks: "Okay, but do I really need this? Can't I just have a conversation and then start working?"
-
-**WDS Context: The Four Phases**
-
-The Strategic Professional: "Let me give you context. Whiteport Design Studio - WDS - is built on four phases:
-
-1. **Phase 1: Win Client Buy-In** (That's this module - Alignment & Signoff)
-2. **Phase 2: Map Business Goals & User Needs** (Understanding what drives behavior)
-3. **Phase 3: Design Solutions** (The actual design work)
-4. **Phase 4: Deliver to Development** (Specifications and handoff)
-
-We start with Phase 1 because the foundation matters more than most designers realize. Get alignment right, and everything else flows. Skip it, and even brilliant design fails."
-
-**When to Skip This Module:**
-
-The Strategic Professional is direct: "First, let's talk about when you DON'T need this module. If you're doing a project yourself - you have full autonomy, no stakeholders to convince, no one to approve your work - skip this entirely. Go straight to Module 04: Project Brief and start designing. Seriously. Don't waste time on alignment documents when you don't need them."
-
-When to skip:
-- You're building something yourself (side project, portfolio piece)
-- You have full autonomy and budget control
-- No stakeholders need to approve or fund the work
-- You're the sole decision-maker
-
-The Hesitant Designer: "That's a relief. But what about when I do need it?"
-
-**When You NEED Alignment:**
-
-The Strategic Professional explains: "You need this module when there's a gap between you and the decision-maker. Three common scenarios:"
-
-**Scenario 1: Consultant → Client**
-- You're proposing a project to a client
-- They need to be convinced it's worth the investment
-- You need formal commitment before you start work
-
-**Scenario 2: Business Owner → Suppliers**
-- You run a business and need to hire designers/developers
-- You need to align on what you're buying
-- You need a contract to protect your business
-
-**Scenario 3: Manager/Employee → Stakeholders**
-- You have a project idea but need approval
-- You need budget allocation
-- You need stakeholder buy-in to proceed
-
-The Strategic Professional emphasizes: "In all three scenarios, you're bridging a gap. Someone needs to say 'yes' and commit resources before work can begin. That's when you need alignment."
-
----
-
-### 3. Understanding Their Outcomes First (6 min) - The Foundation of Every Pitch
-
-The Hesitant Designer asks: "Okay, so I need to pitch. But where do I start?"
-
-**The Mindset Shift: Understanding Before Pitching**
-
-The Strategic Professional: "Here's the secret that makes pitching easier: start by understanding THEIR outcomes, not your solution. When you can clearly specify what success looks like for THEM, pitching stops feeling like selling and starts feeling like helping."
-
-The Hesitant Designer: "But don't I need to have a solution first?"
-
-The Strategic Professional: "No. That's backwards. If you start with your solution, you're guessing what they need. Then you're trying to convince them your solution is right. That's exhausting and it feels like selling. But when you start by genuinely understanding what they're trying to achieve, what success looks like in their eyes, what problems keep them up at night - then your pitch becomes a clear articulation of how you'll help them get there."
-
-**The Discipline: Don't Solve in the Same Meeting**
-
-The Strategic Professional emphasizes: "And here's the discipline that separates professionals from amateurs: even if you're the best designer in the world and you immediately see the solution - DON'T present it in the same meeting. Resist the urge to flood them with solutions."
-
-The Hesitant Designer: "Wait, but won't they want to hear my ideas?"
-
-The Strategic Professional: "Remember: the carpenter measures twice before cutting once. The doctor diagnoses before writing a prescription. You're not there to impress them with how fast you can solve their problem. You're there to understand the problem deeply first."
-
-**Discovery Questions That Reveal Outcomes:**
-
-The Strategic Professional shares: "Saga the Analyst helps you ask the right discovery questions. Keep asking until you find the real pain point:"
-
-- **What does success look like for you?** (Their desired outcome)
-- **What's not working right now?** (The pain they're experiencing)
-- **Tell me more about that - what specifically happens?** (Digging deeper into the pain)
-- **How does that impact your business/team/users?** (Understanding consequences)
-- **What happens if we don't solve this?** (The cost of inaction)
-- **What have you tried before?** (What didn't work and why)
-- **How will this impact your business/team/users?** (The value they expect)
-- **What would make this a home run?** (Their definition of exceptional)
-
-The Strategic Professional: "Notice - you're not asking about features or budget yet. You're understanding THEIR world. Their problems. Their definition of success. And you keep asking questions until you find the pain point, then you enquire deeper about that pain point, and you confirm it actually exists."
-
-**Discovery Questions That Reveal Risks:**
-
-The Strategic Professional adds: "But here's what most designers miss - you also need to understand what's important to them for the project to succeed. Ask constructive questions about planning and confidence:"
-
-- **Is there something specific you're concerned about?** (Their worries, gently)
-- **What would help you feel confident about moving forward?** (What they need to feel secure)
-- **What lessons have you learned from past projects?** (Learning from history)
-- **What would make you feel this is going well as we proceed?** (Positive indicators)
-- **What dependencies or external factors should we plan for?** (External factors)
-- **What would be important to include in our agreement?** (Their priorities)
-- **How would you like us to handle changes or unexpected situations?** (Proactive planning)
-
-The Hesitant Designer: "That feels much better - I'm helping them plan, not dwelling on what could go wrong."
-
-The Strategic Professional: "Exactly. And here's the key - what they tell you becomes the basis for mutually beneficial contract provisions. Not generic boilerplate, but thoughtful protections that give them confidence."
-
-The Strategic Professional gives an example: "Say they mention 'In our last project, communication dropped off and we felt out of the loop.' Now you know to include regular check-ins and status updates in the contract. They say 'We want to make sure we can adjust if priorities change'? You include a clear change order process that respects both parties' time. What's important to them guides you to contract clauses that build confidence."
-
-**Take Notes, Confirm Understanding, Then Stop**
-
-The Strategic Professional shares: "Here's what you do in that first meeting: listen, take notes, ask clarifying questions, and summarize back what you heard. 'So if I understand correctly, you're looking to achieve X, which will deliver Y, and you'd like us to plan for Z. Is that right?' When they say yes, you say: 'Thank you for sharing this - your goals and what's important to you for this to succeed. Let me think about how I can help you achieve what you need while addressing what you've mentioned, and I'll come back to you with a thoughtful proposal.'"
-
-The Hesitant Designer: "So I don't share any ideas in that first meeting?"
-
-The Strategic Professional: "Not full solutions. You can acknowledge the problem: 'Yes, I see why this is critical.' You can validate their concerns: 'That makes complete sense.' But you don't solve it on the spot. Why? Because the carpenter measures twice. The doctor runs tests before diagnosing. You need time to think through the right solution, not the first solution that comes to mind."
-
-**From Understanding to Helping:**
-
-The Hesitant Designer: "So when I understand what they actually need..."
-
-The Strategic Professional: "Then you go away, create a thoughtful proposal using Saga, and come back with a clear articulation: 'Here's what you said you need. Here's how I'll help you get there. Here's what success looks like. Here's the investment required.' When they see their own words reflected back with a clear path forward, they say yes. But that happens in a SECOND meeting, after you've had time to think."
-
-The Hesitant Designer: "So I'm genuinely focused on helping them, not impressing them with how fast I can solve things?"
-
-The Strategic Professional: "Exactly. And here's the beautiful part - when you take the time to genuinely understand before proposing solutions, they FEEL that. They feel heard. They feel understood. The energy shifts from 'This person is trying to sell me something' to 'This person actually gets what I'm trying to do.' That's worth more than any clever solution you could have blurted out in the first meeting."
-
-**Making Every Interaction More Valuable:**
-
-The Strategic Professional adds: "This approach makes every conversation more valuable. Whether it's a discovery call, a pitch meeting, or a negotiation - when you're focused on understanding and clarifying their outcomes, you're serving them. You're helping them think more clearly about what they actually need. Even if they don't hire you, you've added value. And you've shown them you're someone who diagnoses before prescribing."
-
----
-
-### 4. The 6 Elements of Alignment (8 min)
-
-The Hesitant Designer asks: "Okay, so I need to convince someone. But how do I structure that conversation? What do they need to hear?"
-
-**The Framework - 6 Core Elements:**
-
-The Strategic Professional explains: "Every alignment document - whether it's a pitch, proposal, or internal signoff - needs to answer six core questions. Miss one, and your pitch falls apart."
-
-**1. The Idea - What are we building?**
-- Clear statement of the solution
-- Not features - the actual thing you're creating
-- One sentence that anyone can understand
-
-**2. The Why - Why does this matter?**
-- Business value and ROI
-- User pain points being solved
-- Strategic importance
-- What happens if we DON'T do this?
-
-**3. The What - What exactly is included?**
-- Scope of work (what's in, what's out)
-- Deliverables (tangible outputs)
-- Features and functionality
-- What you'll hand over when you're done
-
-**4. The How - How will we execute?**
-- Your approach and methodology
-- Timeline and milestones
-- Team and resources needed
-- Risk mitigation
-
-**5. The Budget - What's the investment?**
-- Cost breakdown
-- Payment structure
-- What they're getting for their money
-- ROI justification
-
-**6. The Commitment - What do we need to proceed?**
-- Decision timeline
-- Resources required
-- Stakeholder involvement
-- Next steps after approval
-
-The Strategic Professional shares a story: "I once pitched a project focusing only on features (The What). I thought if I made it sound cool enough, they'd say yes. They didn't. Why? Because I never answered The Why. I never showed them the business value. I never demonstrated ROI. I was asking for $50K without proving why it was worth it."
-
-The Hesitant Designer: "So it's not about making it sound impressive. It's about answering their actual questions?"
-
-The Strategic Professional: "Exactly. Decision-makers don't care how cool your design is. They care if it's worth the investment. Answer these six questions clearly, and you make it easy for them to say yes."
-
-**The Critical Link: Their Outcomes Drive Everything**
-
-The Strategic Professional adds: "But here's what makes these elements powerful - each one should connect back to THEIR desired outcomes. When you write The Why, you're articulating the outcome they told you they want. When you write The What, you're showing how it delivers that outcome. When you write The Budget, you're showing why that outcome is worth the investment."
-
-The Hesitant Designer: "So I'm not making up the value. I'm reflecting back what they already said they need?"
-
-The Strategic Professional: "Exactly. That's why the discovery conversation is so important. When you genuinely understand what they're trying to achieve, writing the pitch is just documenting that understanding."
-
----
-
-### 5. Creating Your Alignment Document (7 min)
-
-The Hesitant Designer asks: "This makes sense. But how do I actually create this document? What's the structure?"
-
-**The 10-Section Alignment Document:**
-
-The Strategic Professional explains: "Saga the Analyst - that's the WDS agent for Phase 1 - guides you through creating an alignment document with 10 sections. But here's the key - you don't have to fill them in order. Start with what you know, explore what you're unsure about, and iterate until it's complete. And Saga helps you discover what you don't know yet by asking those outcome-focused questions."
-
-The Hesitant Designer: "Wait, Saga is an AI agent?"
-
-The Strategic Professional: "Yes. WDS includes AI agents trained on over 10 years of design and IT project experience. Saga the Analyst specializes in Phase 1 - helping you understand the business side, ask the right questions, and create documents that actually work. She's your thinking partner, not just a template generator."
-
-The 10 sections:
-
-1. **Project Overview** - The Idea in clear language
-2. **Background & Context** - Why now? What led to this?
-3. **Problem Statement** - What pain are we solving?
-4. **Objectives & Goals** - What does success look like?
-5. **Proposed Solution** - The What and How
-6. **Scope & Deliverables** - What's included (and what's not)
-7. **Timeline & Milestones** - When will things happen?
-8. **Budget & Investment** - What's the cost?
-9. **Risks & Mitigation** - What could go wrong?
-10. **Next Steps** - What happens after approval?
-
-**The Flexible Process:**
-
-The Strategic Professional emphasizes: "Saga doesn't force you through these in order. Instead, Saga asks: 'What do you know? What are you uncertain about? Let's explore together.' You might start with the problem, jump to budget, circle back to objectives. That's fine. The goal is clarity, not rigid structure. This flexibility is built into WDS because we learned that every project and every designer thinks differently."
-
-**Extracting from Existing Materials:**
-
-The Strategic Professional adds: "Often, you already have this information scattered across emails, conversations, meeting notes. Saga can help you extract and synthesize it. Upload your notes, share conversation summaries, and Saga structures it into a compelling pitch. But more importantly, Saga helps you identify what's MISSING - what questions you haven't asked yet about their outcomes."
-
-The Hesitant Designer: "So I don't have to start from scratch?"
-
-The Strategic Professional: "Not at all. But here's the key - if you realize you don't actually know what success looks like for them, Saga will help you craft discovery questions to find out. Don't guess. Ask. Understanding their outcomes makes writing the pitch 10x easier."
-
----
-
-### 6. Negotiation & Iteration (5 min)
-
-The Hesitant Designer asks nervously: "Okay, I've created the document. Now I have to share it? What if they reject it?"
-
-**The Negotiation Mindset:**
-
-The Strategic Professional responds: "First, let's reframe 'rejection.' They're not rejecting you. They're providing feedback on the proposal. Big difference. This is negotiation, not judgment."
-
-The process:
-
-1. **Share the alignment document** - Give them time to read
-2. **Gather feedback** - What works? What concerns them?
-3. **Iterate** - Adjust based on their feedback
-4. **Repeat until alignment** - Keep refining until everyone agrees
-
-The Strategic Professional shares: "I once pitched a project for $75K. Client said, 'This sounds great, but we only have $50K budgeted.' Instead of walking away, I asked, 'What if we reduced scope to fit $50K?' We cut two phases, kept the core value, and moved forward. That's negotiation."
-
-**Acceptance - When Everyone Is Aligned:**
-
-The Strategic Professional: "You know you've achieved alignment when the stakeholder says, 'Yes, this is exactly what we need. Let's proceed.' That's your signal to move to the next step: formalize it with a signoff document."
-
-The Hesitant Designer: "So negotiation isn't about being defensive. It's about finding the version that works for everyone?"
-
-The Strategic Professional: "Exactly. You're serving them by helping them make a good decision."
-
-**Discovery Never Stops:**
-
-The Strategic Professional adds: "And here's something important - negotiation is also discovery. Their feedback tells you more about what they actually need. 'We only have $50K' tells you about their constraints. 'We're concerned about timeline' tells you their priorities. Use their feedback to understand them better, then refine the proposal to serve them better."
-
----
-
-### 7. Signoff Documents - External Contracts (8 min)
-
-The Hesitant Designer asks: "Okay, they've said yes. Now what? Do I need a contract?"
-
-**When You Need External Contracts:**
-
-The Strategic Professional explains: "If money is changing hands between different legal entities, you need a contract. Two main scenarios:"
-
-**Scenario 1: Project Contract (Consultant → Client)**
-- You're a consultant/agency working for a client
-- Client is paying you for specific deliverables
-- You need legal protection for both parties
-
-**Scenario 2: Service Agreement (Business → Suppliers)**
-- Your business is hiring designers/developers
-- You're buying services from another business
-- You need to protect your investment
-
-**What's in the Contract:**
-
-The Strategic Professional details: "Saga helps you create a contract based on the pitch they already accepted. Here's the key principle WDS teaches: short and concise. Long contracts are hard to understand, and it's easier to hide strange provisions in dense text. Keep it clear and brief. This comes from years of experience - we've seen designers get trapped by their own overly complex contracts."
-
-Key sections:
-- **Scope of Work** - What's included (and explicitly what's NOT) - reference the accepted pitch
-- **Deliverables** - Tangible outputs from the pitch
-- **Timeline** - Milestones from the pitch
-- **Payment Terms** - Cost and payment schedule from the pitch
-- **Change Management** - How scope changes are handled (change order process)
-- **Acceptance Criteria** - When work is considered complete (from their definition of success)
-- **Intellectual Property** - Who owns the code, designs, content
-- **Termination Clause** - How either party can exit
-- **Warranties & Limitations** - What you guarantee (and don't)
-
-The Strategic Professional emphasizes: "The contract comes FROM the accepted pitch. You're not writing it from scratch - you're formalizing what they already agreed to. This makes it much shorter and clearer. Everything references back to the pitch they said yes to."
-
-**Business Models:**
-
-The Strategic Professional explains different payment structures:
-
-- **Fixed-Price** - Total project cost, paid in milestones
-- **Hourly/Daily Rate** - Time-based billing
-- **Retainer** - Monthly fee for ongoing availability
-- **Value-Based** - Price based on impact/value delivered
-
-The Strategic Professional warns: "Here's the mistake I see designers make: they create vague contracts to seem flexible. 'We'll design a website.' That's it. No scope boundaries. No change process. Then the client adds 10 pages, 5 features, and expects the same price. You're stuck."
-
-**Protecting Scope:**
-
-The Strategic Professional emphasizes: "The most important section is 'What's NOT Included.' Be explicit. 'This does not include e-commerce functionality. This does not include third-party integrations. This does not include backend development.' Why? Because when scope creeps, you point to the contract and say, 'That's a change order. Here's the additional cost.'"
-
-The Hesitant Designer: "So the contract isn't about being defensive. It's about protecting the project?"
-
-The Strategic Professional: "Exactly. It protects you AND the client. It ensures everyone knows what to expect. That's serving them with clarity. And because it's based on the pitch they already accepted, it's short, clear, and references what they already agreed to. No surprises. No dense legal text hiding strange provisions."
-
-The Hesitant Designer: "Wait - the contract is based on the accepted pitch?"
-
-The Strategic Professional: "Yes! That's the key. The pitch becomes the foundation. The contract formalizes it with legal protections. Then both documents - pitch and contract - become the backbone of your project brief. Everything connects. Listen, create, present, negotiate, accept, contract, sign, brief. It's a flow, not separate documents."
-
----
-
-### 8. Signoff Documents - Internal Signoff (5 min)
-
-The Hesitant Designer asks: "What if I'm not a consultant? What if I work for a company and need approval for an internal project?"
-
-**When You Need Internal Signoff:**
-
-The Strategic Professional explains: "If you're a manager or employee proposing a project that needs approval and budget allocation, you need an internal signoff document. This is different from an external contract - it's simpler, but still critical."
-
-**Internal Signoff Structure:**
-
-The Strategic Professional details:
-
-- **Project Summary** - The Idea, Why, What
-- **Business Case** - ROI and strategic value
-- **Budget Request** - Cost breakdown and approval
-- **Timeline** - Milestones and deadlines
-- **Stakeholder Approval** - Who needs to sign off
-- **Next Steps** - What happens after approval
-
-**Company-Specific Formats:**
-
-The Strategic Professional adds: "Many companies have their own formats - project intake forms, budget request templates, approval workflows. Saga can adapt to your company's format. You provide the template, Saga helps you fill it in based on your alignment document."
-
-The Hesitant Designer: "So I'm just translating the alignment document into whatever format my company uses?"
-
-The Strategic Professional: "Exactly. The thinking is the same - The Idea, Why, What, How, Budget, Commitment. You're just adapting the presentation."
-
----
-
-### 9. Real Examples - What Good Looks Like (4 min)
-
-The Hesitant Designer asks: "This all sounds great in theory. But what does a good alignment document actually look like?"
-
-**Example 1: SaaS Dashboard Redesign**
-
-The Strategic Professional shares: "A designer pitched a dashboard redesign for a SaaS company. Here's how they structured it - but notice how they started by understanding the outcome the company wanted:"
-
-- **The Idea:** Redesign the analytics dashboard to make data actionable
-- **The Why:** Current dashboard overwhelms users - 80% don't use it. Lost opportunity for data-driven decisions. **(Client's stated problem: "Our users aren't getting value from our analytics")**
-- **The What:** New dashboard with 5 key metrics, drill-down capability, mobile responsive
-- **The How:** 8-week timeline, user research → prototypes → implementation
-- **The Budget:** $45K (ROI: 30% increase in feature adoption = $200K annual value)
-- **The Commitment:** Approval by March 1st, access to 10 users for research
-
-The Strategic Professional: "Notice the ROI calculation? They didn't just say 'better dashboard.' They quantified the impact: 30% increase in adoption equals $200K value. But that number came from understanding the CLIENT'S definition of success. The client said 'We need users to adopt this feature' - so the designer built the entire pitch around that outcome."
-
-**Example 2: Internal Tool for Support Team**
-
-The Strategic Professional shares another: "An employee pitched an internal tool to their manager. But first, they had a discovery conversation with their manager about what 'good support' looks like:"
-
-- **The Idea:** Build a knowledge base search tool for support team
-- **The Why:** Support reps spend 15 minutes per ticket searching for answers. 100 tickets/day = 25 wasted hours. **(Manager's stated outcome: "I need my team spending time on customers, not searching for documentation")**
-- **The What:** AI-powered search, integration with existing knowledge base, Slack bot
-- **The How:** 6-week build, beta test with 5 reps, full rollout after validation
-- **The Budget:** $8K (ROI: 25 hours/day saved = $150K/year in productivity)
-- **The Commitment:** Approval this week, 5 reps for beta testing
-
-The Strategic Professional: "Again, notice the quantification. They didn't say 'support reps are frustrated.' They said '25 wasted hours per day = $150K annually.' That's the language decision-makers understand. But the key is - they learned this from ASKING the manager what success looked like. The manager told them 'I need efficiency' - so they built the entire pitch around efficiency gains."
-
----
-
-### 10. Common Mistakes & How to Avoid Them (5 min)
-
-The Hesitant Designer asks: "What are the biggest mistakes designers make with alignment and contracts?"
-
-**Mistake 0: Not Understanding Their Outcomes First**
-
-The Strategic Professional: "Actually, the BIGGEST mistake happens before you even write anything - it's pitching before you understand what they actually need. Designers get excited about a solution and start writing without genuinely understanding what success looks like for the client. Then they wonder why the pitch doesn't land."
-
-The Hesitant Designer: "So understanding comes first?"
-
-The Strategic Professional: "Always. If you can't clearly articulate what they're trying to achieve in their words, you're not ready to pitch yet. Ask more questions. Understand their world. Then the pitch writes itself."
-
-**Mistake 0.5: Presenting Solutions in the Discovery Meeting**
-
-The Strategic Professional adds: "And here's the related mistake - flooding them with solutions in the first meeting. You ask a few questions, and suddenly you're excited and start presenting ideas. Stop. The carpenter measures twice before cutting once. The doctor diagnoses before prescribing. Take notes, confirm understanding, and say 'Let me think about this and come back with a thoughtful proposal.' That discipline separates professionals from amateurs."
-
-**Mistake 1: Vague Scope**
-
-The Strategic Professional: "The biggest mistake is being vague about scope to seem flexible. 'We'll design a great website' - that's meaningless. Great in whose opinion? How many pages? What functionality? Be specific. Define boundaries."
-
-**Mistake 2: No 'What's NOT Included' Section**
-
-The Strategic Professional: "Designers skip this because it feels negative. But this is your scope protection. 'This does not include SEO. This does not include content writing. This does not include hosting setup.' When the client asks for it later, you have a clear answer: 'That's a change order.'"
-
-**Mistake 3: Not Quantifying Value**
-
-The Strategic Professional: "Saying 'This will improve the user experience' isn't enough. Improve by how much? What's the business impact? 'This will reduce cart abandonment by 15% = $50K additional revenue.' That's how you justify your price."
-
-**Mistake 4: Avoiding Money Conversations**
-
-The Strategic Professional addresses The Hesitant Designer directly: "I know you feel uncomfortable talking about money. But here's the truth - if you don't talk about money upfront, you'll talk about it later when the client refuses to pay or disputes the bill. Being clear about cost at the beginning is serving them."
-
-**Mistake 5: Not Using Change Orders**
-
-The Strategic Professional: "When scope changes mid-project, designers often just absorb it to avoid conflict. That's how you end up working for free. Instead: 'That's outside our current scope. I can provide a change order with the additional cost and timeline impact.' That's professional."
-
-The Hesitant Designer: "So being clear isn't being greedy. It's being professional?"
-
-The Strategic Professional: "Exactly. Clarity serves everyone."
-
----
-
-### 11. Closing - Your Professional Foundation (4 min)
-
-The Strategic Professional brings it home: "You've just learned Module 03 of Whiteport Design Studio - WDS Phase 1: Win Client Buy-In. This is about creating alignment and protecting your projects with clear agreements. This isn't about being pushy or defensive. It's about serving your clients and stakeholders with clarity."
-
-The Hesitant Designer reflects: "I see it now. Alignment isn't about selling. It's about understanding first - genuinely understanding what they're trying to achieve - and THEN articulating how I can help them get there. And I need to resist the urge to impress them with quick solutions. The carpenter measures twice. The doctor diagnoses first. I understand, take notes, come back with something thoughtful. When I know what success looks like for them, everything gets easier. And contracts aren't about mistrust - they're about protecting the project so it can succeed."
-
-The Strategic Professional: "Exactly. And this is why WDS starts here, in Phase 1, before any design work begins. Because we learned through over 10 years of projects that the foundation you build - the alignment, the understanding, the clear agreements - has more impact on project success than the design itself. Get this right, and everything that follows in Phase 2 through 4 works. Skip it, and even brilliant design fails."
-
-The Strategic Professional: "Exactly. Here's what you now know:"
-
-**What You've Learned:**
-
-- **WDS Phase 1: Win Client Buy-In** - why foundation matters more than most designers realize
-- **The WDS workflow** - Listen → Create → Present → Negotiate → Accept → Contract → Sign → Brief
-- **When you need alignment** (and when to skip it)
-- **The discipline to understand before solving** - carpenter measures twice, doctor diagnoses first
-- **Separate discovery from solution** - don't present in the same meeting
-- **Understanding their outcomes first** - the foundation that makes pitching easier
-- **Discovery questions** that reveal what success looks like for them
-- **Keep asking until you find the real pain point** - then confirm it exists
-- **Take notes, confirm, then stop** - come back with a thoughtful proposal
-- **The 6 elements** every alignment document needs
-- **How to create** a compelling pitch that makes it easy to say yes
-- **Negotiation as iteration** - refining until everyone agrees
-- **External contracts** - protecting consultant/client relationships
-- **Internal signoff** - navigating company approval processes
-- **What good looks like** - real examples with quantified ROI
-- **Common mistakes** - and how to avoid them (especially solving too quickly)
-
-**Your Action:**
-
-The Strategic Professional: "Now, here's what you do. Before you write anything, understand what they need. Have that discovery conversation. Ask those outcome-focused questions. Keep asking until you find the real pain point. Take notes. Confirm understanding. Then STOP. Say 'Let me think about this and come back with a thoughtful proposal.' Don't flood them with solutions in that first meeting."
-
-The Strategic Professional continues: "Then - and only then - work with Saga the Analyst to create your alignment document. Saga is part of the WDS method - an AI agent trained on over 10 years of project experience. Take the time to think it through. The carpenter measures twice before cutting once. The doctor diagnoses before prescribing. You understand before solving."
-
-The Strategic Professional: "When you come back with that thoughtful proposal, share it. Negotiate. Refine it based on their feedback. Get approval. Formalize it with a contract or signoff document. That's the WDS process for Phase 1."
-
-The Strategic Professional continues: "But if you're building something yourself - if you have full autonomy and don't need approval - skip this entirely. Go straight to WDS Phase 2: Map Business Goals & User Needs, or even Phase 3 and start designing. Don't waste time on alignment when you don't need it. WDS is flexible - use what serves your situation."
-
-**Building Your Professional Foundation:**
-
-The Strategic Professional emphasizes: "This module is about building your professional foundation. You're learning to operate as a strategic professional, not just a designer who executes orders. You're learning to bridge the gap between idea and execution, between vision and commitment. And it all starts with the discipline to understand deeply before you solve quickly."
-
-The Strategic Professional adds: "This is why Whiteport Design Studio exists - to give you the templates, the agent instructions, and the process that comes from over 10 years of real-world experience. You're not figuring this out alone. You have a method that works."
-
-The Hesitant Designer: "Understand first. Resist the urge to impress with quick solutions. Take time to think. Help second. I'm ready. What's next?"
-
-The Strategic Professional: "Next is WDS Phase 2: Map Business Goals & User Needs - where you understand what drives user behavior. Then Phase 3: Design Solutions - where you transform that alignment into detailed design. Then Phase 4: Deliver to Development - specifications and handoff. But before you move forward, make sure you have commitment. Don't start detailed work until stakeholders have said yes."
-
-The Hesitant Designer: "Discovery meeting first. Understanding deeply. Then proposal. Then alignment. Then design. The WDS way."
-
-The Strategic Professional: "Exactly. Measure twice, cut once. Diagnose, then prescribe. Now let yourself be known. Have that uncomfortable conversation about money. Define clear scope. Create a contract that protects everyone. But most importantly - take the time to genuinely understand what they need before you propose how to help. That's how professional designers operate. That's the WDS method. That's Phase 1 complete."
-
----
-
-## Resources to Include
-
-At the end of the podcast, The Strategic Professional should mention these resources:
-
-**Key Concepts:**
-
-- **WDS (Whiteport Design Studio)** - the method containing templates and agent instructions based on 10+ years of experience
-- **WDS Four Phases** - Phase 1: Win Client Buy-In, Phase 2: Map Goals & Needs, Phase 3: Design Solutions, Phase 4: Deliver to Dev
-- **Foundation matters more than design** - why WDS starts with alignment before design work
-- **Saga the Analyst** - WDS AI agent for Phase 1, trained on real-world project experience
-- **Understand before you solve** - the carpenter measures twice, the doctor diagnoses first
-- **Separate discovery from solution** - don't present in the same meeting
-- **Understanding their outcomes first** - the foundation that makes everything easier
-- **Discovery questions** that reveal what success looks like
-- The 6 elements of alignment (Idea, Why, What, How, Budget, Commitment)
-- When to skip this module (doing it yourself)
-- Alignment document structure (10 sections)
-- External contracts (Project Contract and Service Agreement)
-- Internal signoff documents
-- Business models (fixed-price, hourly, retainer, value-based)
-- Change order process
-- Scope protection strategies
-
-**Next Steps:**
-
-- Complete WDS Phase 2: Map Business Goals & User Needs
-- Practice pitching with quantified ROI
-- Review your current contracts for scope clarity
-- Set up change order templates
-
-**Community:**
-
-- BMad Discord: Share your alignment document
-- GitHub Discussions: Ask questions about contracts and pricing
-
----
-
-## NotebookLM Audio Generation Guidelines
-
-**Tone:**
-
-- **Emphasize WDS branding** - mention Whiteport Design Studio, the four phases, Saga the Analyst agent
-- **Foundation before design** - stress that alignment matters more than most designers realize
-- **10+ years of experience** - mention the method is based on real-world project lessons
-- Empathetic about discomfort with business/money conversations
-- Transformative about the mindset shift from selling to helping
-- Emphasize the discipline and patience to understand before solving
-- Use the carpenter and doctor analogies with respect and gravity
-- Emphasize that understanding their outcomes makes everything easier
-- Direct about the importance of professional boundaries
-- Practical with real examples and specific numbers
-- Empowering about serving clients through clarity
-- Normalize the discomfort - everyone feels this way
-- Balance business protection with serving the client
-- Show genuine curiosity and interest in understanding their needs
-- Celebrate the restraint to not present solutions in the discovery meeting
-
-**Key messages to emphasize:**
-
-- **WDS (Whiteport Design Studio)** - mention the method name frequently
-- **Four WDS Phases** - Phase 1: Win Buy-In, Phase 2: Map Goals, Phase 3: Design, Phase 4: Deliver
-- **Foundation more impactful than design** - alignment determines project success
-- **Saga the Analyst** - WDS agent trained on 10+ years of project experience
-- **Templates and instructions from real experience** - not theory, but proven practice
-- **The clear workflow** - Listen → Create → Present → Negotiate → Accept → Contract → Sign → Brief
-- **Pitch and contract become project brief backbone** - not throwaway documents
-- **Contract based on accepted pitch** - formalizing what they already agreed to
-- **Short and concise contracts** - long text is hard to understand and can hide strange provisions
-- **Understanding before pitching** - know what they need first, pitch second
-- **Separate discovery from solution** - don't present solutions in the same meeting
-- **The carpenter measures twice** - take time to understand before solving
-- **The doctor diagnoses first** - understand the problem before prescribing the solution
-- **Ask until you find the pain point** - keep digging deeper to understand the real issue
-- **Ask what's important for success** - understand what gives them confidence
-- **Planning together builds trust** - asking about dependencies and preferences shows you care
-- **What's important to them informs the agreement** - provisions that give them confidence
-- **Take notes, confirm, then stop** - resist the urge to flood them with solutions
-- **Clearly specify their outcomes** - makes pitching feel like helping, not selling
-- **Discovery questions** - ask what success looks like in their words
-- **When to skip** - if you're doing it yourself, skip this module
-- **When you need it** - consultant/client, business/suppliers, manager/stakeholders
-- **The 6 elements** - Idea, Why, What, How, Budget, Commitment
-- **Clarity serves everyone** - not being pushy, being professional
-- **Quantify value** - ROI calculations make it easy to say yes
-- **Scope protection** - "What's NOT Included" is critical
-- **Change orders** - how to handle scope changes professionally
-- **Negotiation as iteration** - refining until everyone agrees
-- **Contracts protect everyone** - not defensive, protective
-- **Talk about money upfront** - avoiding it doesn't make you generous
-- **Professional foundation** - operating as a strategic professional
-- **Understanding makes pitching easier** - when you genuinely know what they need, writing is effortless
-
-**Avoid:**
-
-- Making it sound like you need this for every project
-- Being overly legal or formal in tone
-- Making contracts sound scary or adversarial
-- Focusing too much on worst-case scenarios
-- Assuming everyone is a consultant (some are employees)
-- Being too vague about pricing and scope
-- **Skipping the discovery/understanding phase** - don't jump to solutions without understanding outcomes first
-- **Presenting solutions in the discovery meeting** - resist the urge to impress with quick solutions
-
----
-
-## Expected Output
-
-A natural, engaging conversation that:
-
-- **Emphasizes understanding their outcomes first** as the foundation that makes everything easier
-- **Shows the discipline of separating discovery from solution** - don't present in the same meeting
-- **Uses the carpenter and doctor analogies** to illustrate professional patience
-- **Shows how to ask discovery questions** that reveal what success looks like
-- **Demonstrates keeping asking until you find the real pain point**
-- **Shows the discipline: take notes, confirm understanding, then stop** - come back with a thoughtful proposal
-- **Demonstrates the mindset shift** from selling to helping through genuine understanding
-- **Clarifies when this module is needed** (and when to skip it)
-- **Explains the 6 elements of alignment** clearly and practically
-- **Shows how to structure an alignment document** (10 sections)
-- **Demonstrates negotiation as iteration** - not rejection
-- **Details external contracts** with clear sections and business models
-- **Explains internal signoff** for employees and managers
-- **Provides real examples** with quantified ROI that came from understanding client outcomes
-- **Highlights common mistakes** and how to avoid them (especially solving too quickly)
-- **Empowers designers** to operate as strategic professionals
-- **Normalizes discomfort** about money and contracts
-- **Emphasizes serving through clarity** - not being defensive
-- **Shows how understanding makes pitching easier** - when you know what they need, writing feels effortless
-- **Ends with clear action** - understand first, create alignment, get signoff, move to Project Brief
-- Takes 35-40 minutes to listen to
-
----
-
-## Alternative: Video Script
-
-If generating video instead of audio, add these visual elements:
-
-**On-screen text:**
-
-- "The Carpenter Measures Twice"
-- "The Doctor Diagnoses First"
-- "Understand Before You Solve"
-- "Don't Present in the Discovery Meeting"
-- "Take Notes, Confirm, Then Stop"
-- "Ask Until You Find the Pain Point"
-- "What Does Success Look Like for Them?"
-- "Discovery Questions That Reveal Outcomes"
-- "When to Skip This Module"
-- "The 6 Elements of Alignment"
-- "Idea, Why, What, How, Budget, Commitment"
-- "Negotiation as Iteration"
-- "What's NOT Included - Your Scope Protection"
-- "Change Order Process"
-- "Clarity Serves Everyone"
-- "Quantify Your Value"
-- "ROI = Easy Yes"
-- "Understanding Makes Pitching Easier"
-- "Helping, Not Selling"
-- "Professional Foundation"
-- "Next: Module 04 - Project Brief"
-
-**B-roll suggestions:**
-
-- Discovery conversation - asking questions, listening intently
-- Designer taking detailed notes during client meeting
-- Designer resisting the urge to jump to solutions
-- Carpenter measuring twice with a ruler
-- Doctor examining patient before diagnosis
-- Understanding what success means to them
-- Designer saying "Let me think about this and come back"
-- Designer working alone, thinking through the proposal
-- Designer presenting thoughtful proposal in SECOND meeting
-- Negotiation and iteration process
-- Contract signing
-- Budget calculations and ROI
-- Scope boundaries being drawn
-- Change order being created
-- Professional designer-client relationship
-- Internal approval workflow
-- Transformation: hesitant → confident
-- Light bulb moment: "Oh, they need THIS"
-- Genuine helping vs. pushy selling
-- The patience to understand before solving
-
----
-
-## Usage Tips
-
-1. **Upload THIS SINGLE FILE** to NotebookLM - no other files needed
-2. **Use the prompt exactly** as written for best results
-3. **Generate multiple versions** and pick the best one
-4. **Share the audio/video** with your team or community
-5. **Iterate** - if the output isn't quite right, refine the prompt
-
----
-
-## Next Steps
-
-After generating Module 03 content:
-
-- Create NotebookLM prompt for Module 04: Project Brief
-- Build prompts for all remaining modules
-- Share in BMad Discord designer channel
-
----
-
-**This module transforms how designers navigate the business side - from uncomfortable to professionally confident!** 🎯✨
-
diff --git a/docs/learn-wds/course-explainers/Module-03-thumbnail-prompt.md b/docs/learn-wds/course-explainers/Module-03-thumbnail-prompt.md
deleted file mode 100644
index 7b65dd738..000000000
--- a/docs/learn-wds/course-explainers/Module-03-thumbnail-prompt.md
+++ /dev/null
@@ -1,33 +0,0 @@
-**IMPORTANT: Use the reference image as your exact style guide. Match all visual elements, colors, layout, and character design.**
-
-Create a 1920x1080px YouTube thumbnail matching the reference image style.
-
-**What to Change from Reference:**
-
-**Headlines (Left side):**
-- Line 1: "IDEA TO PROJECT PITCH:" (Rubrik Light, 91pt, white)
-- Line 2: "MAKE STAKE HOLDER" (Rubrik Bold, 91pt, white)
-- Line 3: "PRESENTATIONS" (Rubrik Bold, 91pt, white)
-- Line spacing: 79pt
-
-**Module Badge (Bottom-left):**
-- "03 Alignment" (Rubrik Regular, 108pt, white on red #ff1744)
-
-**Character Activity:**
-- Keep the womans angle and position similar as in the first reference image. Keep the character neutral and stylized as it is
-- On the desk there is a large computer screen showing an ongoing online meeting. The woman is in front of the screen, and she has documents and postit notes in front of her allover her keyboard. She is holding up her hands with palms up in an inviting gesture while holding a pencil.
-- Skip the tablet
-
-**Background Pattern:**
-- CLear the background from precious objects exept the globe
-- Add oversized an toned down business elements (checkmarks, approval stamps, handshake icons ect)
-- Keep as in reference image
-
-**Workspace Props:**
-- Add: stylized contract documents, project pitch printout, calculator, coffee cup stylised. To textshould be visible or  be presented with just scribble or gray markers
-
-**Keep Everything Else from Reference:**
-- Top-right branding text
-- Character design and style
-- Color scheme and layout
-
diff --git a/docs/learn-wds/course-explainers/Module-03-transcript.srt b/docs/learn-wds/course-explainers/Module-03-transcript.srt
deleted file mode 100644
index 84d87711d..000000000
--- a/docs/learn-wds/course-explainers/Module-03-transcript.srt
+++ /dev/null
@@ -1,595 +0,0 @@
-1
-00:00:00,280 --> 00:00:02,151
-Welcome to The Explainer. Today we're
-
-2
-00:00:02,151 --> 00:00:04,333
-going to tackle something that makes a
-
-3
-00:00:04,333 --> 00:00:05,892
-lot of creative people really
-
-4
-00:00:05,892 --> 00:00:08,074
-uncomfortable, and we're going to turn it
-
-5
-00:00:08,074 --> 00:00:09,633
-into your single greatest professional
-
-6
-00:00:09,633 --> 00:00:11,504
-strength, mastering the business side of
-
-7
-00:00:11,504 --> 00:00:13,686
-design. I'm willing to bet this sounds
-
-8
-00:00:13,686 --> 00:00:15,869
-familiar, right? You know that pit in
-
-9
-00:00:15,869 --> 00:00:18,363
-your stomach when it's time to talk money
-
-10
-00:00:18,363 --> 00:00:21,009
-or contracts or negotiations?All you want
-
-11
-00:00:21,009 --> 00:00:23,914
-to do is just get to the fun part,
-
-12
-00:00:23,914 --> 00:00:26,174
-the creative work. But here's a thought.
-
-13
-00:00:26,174 --> 00:00:28,434
-What if all that business stuff isn't
-
-14
-00:00:28,434 --> 00:00:30,694
-just a necessary evil? What if it's
-
-15
-00:00:30,694 --> 00:00:32,631
-actually the secret ingredient to doing
-
-16
-00:00:32,631 --> 00:00:34,246
-better, more successful design work?
-
-17
-00:00:34,246 --> 00:00:36,829
-Let's dive in and reframe this using the
-
-18
-00:00:36,829 --> 00:00:38,766
-Whiteboard Design Studio method as our
-
-19
-00:00:38,766 --> 00:00:41,553
-guide. OK, First things first. We have to
-
-20
-00:00:41,553 --> 00:00:43,479
-talk about the core problem, the
-
-21
-00:00:43,479 --> 00:00:45,725
-fundamental dilemma that trips us so many
-
-22
-00:00:45,725 --> 00:00:47,972
-projects before a single idea is even
-
-23
-00:00:47,972 --> 00:00:50,219
-sketched out. And here's the deal. You
-
-24
-00:00:50,219 --> 00:00:51,824
-could create the most jaw-dropping,
-
-25
-00:00:51,824 --> 00:00:54,071
-brilliant design in the world, but if
-
-26
-00:00:54,071 --> 00:00:56,317
-it's built on a shaky foundation of
-
-27
-00:00:56,317 --> 00:00:58,243
-mismatched expectations, it is going to
-
-28
-00:00:58,243 --> 00:01:00,490
-fail. The groundwork you lay before you.
-
-29
-00:01:00,600 --> 00:01:03,216
-Ever open a design A often matters more
-
-30
-00:01:03,216 --> 00:01:06,160
-than the design itself. O how do we fix
-
-31
-00:01:06,160 --> 00:01:08,122
-this? Well, what's really fascinating is
-
-32
-00:01:08,122 --> 00:01:10,084
-that the solution isn't some complex
-
-33
-00:01:10,084 --> 00:01:12,047
-business secret. It's a simple, powerful
-
-34
-00:01:12,047 --> 00:01:14,663
-shift in your mindset. I mean, just think
-
-35
-00:01:14,663 --> 00:01:16,625
-about any other respected profession. A
-
-36
-00:01:16,625 --> 00:01:18,588
-good Carpenter always measures twice, so
-
-37
-00:01:18,588 --> 00:01:21,422
-they only have to cut once. It's all
-
-38
-00:01:21,422 --> 00:01:23,168
-about that upfront discipline to make
-
-39
-00:01:23,168 --> 00:01:25,787
-sure the work is right. Or think about a
-
-40
-00:01:25,787 --> 00:01:27,825
-doctor. They're not just going to guess
-
-41
-00:01:27,825 --> 00:01:29,571
-what's wrong and start handing out
-
-42
-00:01:29,571 --> 00:01:31,608
-prescriptions, right? No way. They ask a
-
-43
-00:01:31,608 --> 00:01:33,645
-ton of questions, they run tests, they
-
-44
-00:01:33,645 --> 00:01:35,391
-diagnose the root problem before they
-
-45
-00:01:35,391 --> 00:01:37,429
-ever propose a solution, and our process
-
-46
-00:01:37,429 --> 00:01:39,466
-should be exactly the same. So this
-
-47
-00:01:39,466 --> 00:01:42,181
-brings us to the. Absolute core of this
-
-48
-00:01:42,181 --> 00:01:43,858
-whole approach. Understand before you
-
-49
-00:01:43,858 --> 00:01:45,870
-solve. It's about having the discipline
-
-50
-00:01:45,870 --> 00:01:48,553
-to resist that urge we all have to
-
-51
-00:01:48,553 --> 00:01:51,235
-jump in and show off our ideas. Instead,
-
-52
-00:01:51,235 --> 00:01:53,918
-your only job in that first meeting is
-
-53
-00:01:53,918 --> 00:01:55,930
-to listen to deeply understand their
-
-54
-00:01:55,930 --> 00:01:57,607
-goals, their frustrations, and what
-
-55
-00:01:57,607 --> 00:01:59,954
-success actually looks like to them. And
-
-56
-00:01:59,954 --> 00:02:02,274
-this charge is. Lays it out perfectly,
-
-57
-00:02:02,274 --> 00:02:04,451
-doesn't it? The amateur rushes in, trying
-
-58
-00:02:04,451 --> 00:02:06,940
-to sell a solution to impress with speed.
-
-59
-00:02:06,940 --> 00:02:08,806
-The professional, on the other hand,
-
-60
-00:02:08,806 --> 00:02:10,983
-slows down. They help the client get
-
-61
-00:02:10,983 --> 00:02:12,850
-crystal clear on the problem. First,
-
-62
-00:02:12,850 --> 00:02:14,716
-they're not selling, they're helping. And
-
-63
-00:02:14,716 --> 00:02:16,582
-listen, this isn't just for freelancers.
-
-64
-00:02:16,582 --> 00:02:18,760
-It doesn't matter if you're a consultant
-
-65
-00:02:18,760 --> 00:02:20,937
-pitching a new client, a business owner
-
-66
-00:02:20,937 --> 00:02:23,311
-hiring a vendor. Or an employee trying to
-
-67
-00:02:23,311 --> 00:02:25,272
-get buy in from your boss. Anytime
-
-68
-00:02:25,272 --> 00:02:27,513
-there's a gap between you and a decision
-
-69
-00:02:27,513 --> 00:02:29,474
-maker who needs to commit resources, this
-
-70
-00:02:29,474 --> 00:02:31,995
-is the mindset you need. OK, so we've got
-
-71
-00:02:31,995 --> 00:02:33,956
-the mindset down. Now for the practical
-
-72
-00:02:33,956 --> 00:02:35,917
-part. Let's look at the actual toolkit
-
-73
-00:02:35,917 --> 00:02:38,438
-that helps you build a pitch so clear and
-
-74
-00:02:38,438 --> 00:02:40,679
-so aligned that it makes it really easy
-
-75
-00:02:40,679 --> 00:02:43,427
-for them to say yes. These six questions
-
-76
-00:02:43,427 --> 00:02:44,990
-are everything. Every single successful
-
-77
-00:02:44,990 --> 00:02:47,177
-proposal, whether it's for a client or
-
-78
-00:02:47,177 --> 00:02:49,677
-your boss, has to answer all of them.
-
-79
-00:02:49,677 --> 00:02:52,177
-What are we building? Why? What's in the
-
-80
-00:02:52,177 --> 00:02:54,677
-box? How will we do it? What's the
-
-81
-00:02:54,677 --> 00:02:56,865
-investment and what's the next step? Miss
-
-82
-00:02:56,865 --> 00:02:59,052
-even 1 and you're creating doubt, and
-
-83
-00:02:59,052 --> 00:03:01,552
-doubt is a deal killer. This is so
-
-84
-00:03:01,552 --> 00:03:03,876
-important to remember. You have to speak
-
-85
-00:03:03,876 --> 00:03:05,396
-their language. Decision makers don't
-
-86
-00:03:05,396 --> 00:03:07,220
-really care about how beautiful your
-
-87
-00:03:07,220 --> 00:03:09,348
-design is, they care about the outcome.
-
-88
-00:03:09,348 --> 00:03:12,084
-Is it worth the time and money you have
-
-89
-00:03:12,084 --> 00:03:13,908
-to connect every single thing you're
-
-90
-00:03:13,908 --> 00:03:16,036
-proposing back to the business value they
-
-91
-00:03:16,036 --> 00:03:18,772
-told you they needed. O don't just say a
-
-92
-00:03:18,772 --> 00:03:21,204
-new tool will save time. Quantify it. Put
-
-93
-00:03:21,204 --> 00:03:23,850
-a number on it. Saying this project
-
-94
-00:03:23,850 --> 00:03:25,800
-will create $150,000 in annual
-
-95
-00:03:25,800 --> 00:03:28,140
-productivity gains. Now that is a
-
-96
-00:03:28,140 --> 00:03:30,090
-language every single decision maker
-
-97
-00:03:30,090 --> 00:03:32,040
-understands. And here's the beautiful
-
-98
-00:03:32,040 --> 00:03:34,770
-part. Once you get that solid alignment
-
-99
-00:03:34,770 --> 00:03:37,500
-on the value and the plan, everything
-
-100
-00:03:37,500 --> 00:03:40,230
-that comes next just flows. It becomes
-
-101
-00:03:40,230 --> 00:03:42,180
-this totally natural, simple progression
-
-102
-00:03:42,180 --> 00:03:44,399
-from understanding. To agreement. You can
-
-103
-00:03:44,399 --> 00:03:47,096
-see it here. It's like a logical chain
-
-104
-00:03:47,096 --> 00:03:49,456
-reaction. You listen, you build a itch
-
-105
-00:03:49,456 --> 00:03:52,153
-based on what you heard, they accept it.
-
-106
-00:03:52,153 --> 00:03:54,514
-And then that very same document becomes
-
-107
-00:03:54,514 --> 00:03:56,874
-the foundation for the contract and the
-
-108
-00:03:56,874 --> 00:03:58,560
-project brief. No surprises, no
-
-109
-00:03:58,560 --> 00:04:00,583
-confusion. Each step builds directly on
-
-110
-00:04:00,583 --> 00:04:02,943
-the last. And let's talk about that
-
-111
-00:04:02,943 --> 00:04:04,718
-contract. Because it makes people
-
-112
-00:04:04,718 --> 00:04:06,710
-nervous. A contract isn't about mistrust.
-
-113
-00:04:06,710 --> 00:04:09,033
-It's an act of professional service. It's
-
-114
-00:04:09,033 --> 00:04:10,693
-just about clarity. You're simply
-
-115
-00:04:10,693 --> 00:04:12,685
-formalizing what you both already happily
-
-116
-00:04:12,685 --> 00:04:15,341
-agreed to. And you know what the most
-
-117
-00:04:15,341 --> 00:04:17,001
-important section is often defining
-
-118
-00:04:17,001 --> 00:04:19,324
-what's out of scope. That's your best
-
-119
-00:04:19,324 --> 00:04:21,316
-friend in preventing scope creep. So
-
-120
-00:04:21,316 --> 00:04:23,640
-you've put in all this upfront work.
-
-121
-00:04:23,780 --> 00:04:25,446
-You've listened, you've diagnosed, you've
-
-122
-00:04:25,446 --> 00:04:27,444
-aligned. What's the ultimate payoff? Why
-
-123
-00:04:27,444 --> 00:04:29,776
-go through all the trouble? Well, the
-
-124
-00:04:29,776 --> 00:04:31,775
-impact is huge. It completely transforms
-
-125
-00:04:31,775 --> 00:04:33,107
-the entire relationship. Client
-
-126
-00:04:33,107 --> 00:04:35,439
-confidence in you goes through the roof.
-
-127
-00:04:35,439 --> 00:04:37,438
-The chances of the project actually
-
-128
-00:04:37,438 --> 00:04:39,436
-succeeding skyrocket. And for you, it
-
-129
-00:04:39,436 --> 00:04:41,435
-leads to a healthier, more profitable
-
-130
-00:04:41,435 --> 00:04:44,100
-business. It really is a win, win, win.
-
-131
-00:04:44,650 --> 00:04:47,192
-And this might be the biggest shift of
-
-132
-00:04:47,192 --> 00:04:48,781
-all. You've fundamentally change your
-
-133
-00:04:48,781 --> 00:04:51,005
-role. You're no longer just an order
-
-134
-00:04:51,005 --> 00:04:53,229
-taker, someone who just executes a list
-
-135
-00:04:53,229 --> 00:04:55,453
-of tasks. You become a strategic partner,
-
-136
-00:04:55,453 --> 00:04:58,313
-someone they rely on to guide them to a
-
-137
-00:04:58,313 --> 00:05:00,219
-successful outcome. The whole thing, from
-
-138
-00:05:00,219 --> 00:05:02,126
-that first conversation to the final
-
-139
-00:05:02,126 --> 00:05:04,032
-signed contract, is really an active
-
-140
-00:05:04,032 --> 00:05:06,606
-service. You were giving your client and
-
-141
-00:05:06,606 --> 00:05:08,702
-yourself the gift of clarity. It makes
-
-142
-00:05:08,702 --> 00:05:11,097
-everyone feel safe and secure so you can
-
-143
-00:05:11,097 --> 00:05:13,193
-all focus on what really matters, doing
-
-144
-00:05:13,193 --> 00:05:14,989
-incredible work together. And that leaves
-
-145
-00:05:14,989 --> 00:05:17,384
-us with one final thought to take into
-
-146
-00:05:17,384 --> 00:05:19,480
-your next meeting. Ask yourself this, are
-
-147
-00:05:19,480 --> 00:05:21,875
-you there just to sell them something or
-
-148
-00:05:21,875 --> 00:05:23,971
-are you there to genuinely help them
-
-149
-00:05:23,971 --> 00:05:24,270
-succeed?
diff --git a/docs/learn-wds/course-explainers/Module-04-notebook-lm-prompt.md b/docs/learn-wds/course-explainers/Module-04-notebook-lm-prompt.md
deleted file mode 100644
index 063828331..000000000
--- a/docs/learn-wds/course-explainers/Module-04-notebook-lm-prompt.md
+++ /dev/null
@@ -1,163 +0,0 @@
-# NotebookLM Prompt: Module 04 - Product Brief
-
-**Use this prompt to generate audio/video content for Module 04: Product Brief**
-
----
-
-## Instructions for NotebookLM
-
-**This is a single, self-contained prompt file.**
-
-Simply upload THIS FILE to NotebookLM and use the prompt below to generate engaging audio/video content. No other files needed.
-
----
-
-## Prompt
-
-Create an engaging 25-30 minute podcast conversation between two hosts discussing Module 04 of the Whiteport Design Studio (WDS) course: Product Brief.
-
-**IMPORTANT: WDS stands for Whiteport Design Studio - always refer to it by its full name "Whiteport Design Studio" or "WDS" throughout the conversation.**
-
-**Host 1 (The Curious Designer):** A designer ready to start a project and wants to understand the practical process.
-
-**Host 2 (The Practical Guide):** A designer who uses the Product Brief as a living reference throughout every project phase.
-
-**Conversation structure:**
-
-### 1. Opening (3 min) - The Real Question
-
-The Curious Designer: "I already know what app I want to build. Why should I waste time on a document?"
-
-The Practical Guide: "That's exactly what everyone thinks. But here's what you're actually missing: You're about to spend weeks or months prompting AI, fighting hallucinations, correcting assumptions, copy-pasting between tools. The Product Brief isn't a document - it's the most powerful prompt you'll ever create. And it makes your idea better."
-
-The Curious Designer: "Wait, a prompt? I thought it was planning documentation."
-
-The Practical Guide: "That's the paradigm shift. In WDS, the Product Brief IS your prompt - but it's a prompt that every agent reads automatically. You write it once through a guided conversation, and it stops AI hallucinations before they start. No more endless back-and-forth. No more 'but I already told you that.' The AI just knows your project."
-
----
-
-### 2. One Environment, Zero Copy-Paste (4 min)
-
-The Curious Designer: "OK, but where does this actually happen? Am I jumping between ChatGPT and my code editor?"
-
-The Practical Guide: "No! That's the breakthrough. Everything happens in your IDE - your code editor. You create the Product Brief there. You refine it there. Every agent reads it there. Your code lives there. Your documentation lives there. Everything in one place.
-
-No cutting and pasting between GPTs. No losing context. No 'wait, where did I save that?' It's all right there, version controlled, accessible to your entire team, ready for every phase of development."
-
-The Curious Designer: "So I'm not switching tools constantly?"
-
-The Practical Guide: "Never. You activate Saga in your IDE. She asks questions. You answer. The document builds right there in your editor. Then when you move to design, Sketch reads that same document - same place, same context. When you write content, Lyra reads it. When you code, developers read it. One environment, one source of truth, zero friction."
-
----
-
-### 3. Questions That Make Your Idea Better (6 min)
-
-The Curious Designer: "You said this makes my idea better. How?"
-
-The Practical Guide: "The process is around 30 questions where your answer leads to the next in a fun and engaging way. This challenges you to really think deeply about your product. Not surface-level stuff - deep strategic thinking. And I guarantee - you will feel MORE excited about your idea when you're done, not less.
-
-Saga asks things like: 'What problem are you actually solving?' You think you know, but when you have to articulate it clearly, you realize there's a deeper insight.
-
-Then she digs deeper: 'Who is experiencing this problem?' Not just 'parents' but 'working parents juggling multiple kids' schedules while managing their own careers.' The specificity makes your solution sharper.
-
-She asks: 'How will you measure success?' You can't say 'make it better' - you have to think: 'Reduce missed commitments by 50% in month one.' That clarity changes how you design.
-
-She explores constraints: 'What's your budget? Timeline? Team size? Technical limitations?' Naming them isn't limiting - it's liberating. Now you know what you're working with.
-
-And she keeps going - about your competitive landscape, your differentiation, your stakeholders, your risks. Around 30 questions total that cover everything you need to think through before you start building."
-
-The Curious Designer: "So it's not just documentation, it's thinking?"
-
-The Practical Guide: "Exactly! You're refining your thinking in real-time. And here's the beautiful part - you're watching the document build as you talk. Every insight captured. Every refinement documented. And when your thinking evolves later - which it will - the document is right there at your fingertips. You update it immediately, and every agent sees the improved thinking instantly."
-
----
-
-### 4. Man and Machine Collaboration (5 min)
-
-The Curious Designer: "Wait, so Saga is writing the document while I talk. Can I see what she's doing?"
-
-The Practical Guide: "Yes! And this is crucial. You review every single change the AI makes. You're not blindly accepting AI output. You're collaborating.
-
-Saga suggests a way to phrase your vision. You see it appear in the document. You think: 'Hmm, not quite right.' You say: 'Actually, let me refine that...' She updates it immediately.
-
-This is powerful man-and-machine collaboration. You bring the strategic thinking. She brings the structure and ensures nothing gets missed. But you're always in control. You see every change. You approve every word. You refine together."
-
-The Curious Designer: "So I'm not just prompting and hoping?"
-
-The Practical Guide: "Never. You're working together in real-time. And because it's all in your IDE with version control, you can see the entire history. You can revert changes. You can branch and experiment. It's not black-box AI - it's transparent collaboration where you're always the decision maker."
-
----
-
-### 5. Beyond the Brief - The Complete Foundation (4 min)
-
-The Curious Designer: "Is the Product Brief the only document I create?"
-
-The Practical Guide: "No! And this is where it gets even better. Saga will also set up additional documents in the same folder - right alongside your Product Brief.
-
-Need to define your main features? She creates a Core Features document.
-
-Need to specify supported languages? She creates a Language Selection document.
-
-Need to define your brand voice? She creates a Tone of Voice document.
-
-Need to capture your visual identity? She creates a Visual Design Brief.
-
-Whatever is crucial for YOUR project, she sets it up in the same place. Not scattered across tools. Not lost in chat history. Right there in `/docs/A-Product-Brief/` - organized, accessible, version controlled."
-
-The Curious Designer: "So it's not just one document, it's a complete strategic foundation?"
-
-The Practical Guide: "Exactly. And every document feeds into the next phase of your project. Your Product Brief leads to Trigger Mapping. Your Core Features lead to Scenarios. Your Tone of Voice leads to Content. Everything connects. Nothing is wasted."
-
----
-
-### 6. Stopping Hallucinations Before They Start (4 min)
-
-The Curious Designer: "You mentioned this stops AI hallucinations. How?"
-
-The Practical Guide: "Because every document in WDS leads to the next. The Product Brief becomes the foundation for Trigger Mapping. Trigger Mapping becomes the foundation for Scenarios. Scenarios become the foundation for Design.
-
-Each agent reads the previous work before starting. They don't make assumptions. They don't hallucinate features you never asked for. They don't invent user needs that don't exist.
-
-Without this foundation, you're constantly fighting: 'No, I didn't say that.' 'Why did you add this feature?' 'That's not my target user.' You're prompting forever just to get back to what you actually wanted.
-
-With the Product Brief, the AI knows your project from the start. Every agent is aligned. Every decision is grounded in your documented strategy. The hallucinations just... stop."
-
-The Curious Designer: "So I'm not constantly correcting the AI?"
-
-The Practical Guide: "No. You're collaborating from a shared understanding. The AI isn't guessing - it's reading your Product Brief. It knows your constraints, your users, your goals. You spend your time refining and improving, not correcting and explaining."
-
----
-
-### 7. The Bottom Line (3 min)
-
-The Curious Designer: "OK, I'm convinced. What's the actual time investment?"
-
-The Practical Guide: "Maybe 2-3 hours for a thorough Product Brief. But here's what you're getting:
-
-You're creating the most powerful prompt possible - one that every agent reads automatically.
-
-You're stopping weeks of hallucination hell and endless prompting.
-
-You're setting up one environment where everything lives - no tool switching, no copy-paste.
-
-You're establishing transparent collaboration where you review every AI change.
-
-You're refining your thinking through questions that make your idea genuinely better.
-
-You're creating a living document that's always at your fingertips when your thinking evolves.
-
-You're building a complete strategic foundation with all supporting documents in one place.
-
-And you're supercharging your entire process - making the final product better than your original idea.
-
-That's not time wasted. That's time invested that pays back 10x, 50x, 100x throughout your project."
-
-The Curious Designer: "When you put it that way... why would I NOT do this?"
-
-The Practical Guide: "Exactly. Open your IDE. Activate Saga. Start the conversation. Your future self - the one who isn't fighting hallucinations at 2am - will thank you."
-
----
-
-## End of Prompt
-
-Generate the podcast conversation following this structure, maintaining natural dialogue flow while covering all key concepts. Make it engaging, practical, and action-oriented.
diff --git a/docs/learn-wds/course-explainers/Module-04-thumbnail-prompt.md b/docs/learn-wds/course-explainers/Module-04-thumbnail-prompt.md
deleted file mode 100644
index eb4230bb6..000000000
--- a/docs/learn-wds/course-explainers/Module-04-thumbnail-prompt.md
+++ /dev/null
@@ -1,36 +0,0 @@
-**IMPORTANT: Use the reference image as your exact style guide. Match all visual elements, colors, layout, and character design.**
-
-Create a 1920x1080px YouTube thumbnail matching the reference image style.
-
-**What to Change from Reference:**
-
-**Headlines (Left side):**
-- Line 1: "INSTANT CLARITY" (Rubrik Light, 91pt, white)
-- Line 2: "A PRODUCT BRIEF" (Rubrik Bold, 91pt, white)
-- Line 3: "IN 30 QUESTIONS!" (Rubrik Bold, 91pt, white)
-- Line spacing: 79pt
-
-**Module Badge (Bottom-left):**
-- "04 Product Brief" (Rubrik Regular, 108pt, white on red #ff1744)
-
-**Character Activity:**
-- Keep the woman's angle and position similar as in the first reference image. Keep the character neutral and stylized as it is
-- Woman is working at her desk with a large product brief document/blueprint spread out in front of her
-- She's holding a pen/marker and has just finished writing, looking satisfied at the completed document
-- On the desk: sticky notes, coffee cup, the product brief with visible sections/structure
-- Skip the tablet
-
-**Background Pattern:**
-- Clear the background from previous objects except the globe
-- Add oversized and toned down strategic elements (checkmarks, document icons, organizational charts, flowchart nodes)
-- Keep as in reference image
-
-**Workspace Props:**
-- Add: stylized product brief document (visible structure/sections), sticky notes, pen/marker, coffee cup, notebook. No text should be visible or be presented with just scribble or gray markers
-
-**Keep Everything Else from Reference:**
-- do not put light objects behind her face since we need to keep her silhouette clear
-- Top-right branding text
-- Character design and style
-- Color scheme and layout
-
diff --git a/docs/learn-wds/course-explainers/Module-04-youtube-show-notes.md b/docs/learn-wds/course-explainers/Module-04-youtube-show-notes.md
deleted file mode 100644
index 120b4fed9..000000000
--- a/docs/learn-wds/course-explainers/Module-04-youtube-show-notes.md
+++ /dev/null
@@ -1,95 +0,0 @@
-Module 04 - Product Brief - Your Strategic Foundation Through Guided Conversation
-
-<https://youtu.be/yhKxkuLq1kQ>
-
-Teams waste weeks building the wrong thing beautifully. The Product Brief prevents this - a 2-3 page strategic document that answers the 5 questions every project needs before design starts. Create it through AI-guided conversation with Saga, your thinking partner.
-
-*You'll learn:*
-✅ Why projects fail without strategic foundation (and how to prevent it)
-✅ The 5 strategic questions every Product Brief must answer
-✅ What the document looks like and how teams use it
-✅ How WDS ensures excellence through thinking partnership
-✅ Additional strategic documents you can create as needed
-
-*Free & open-source* | 46-58 minutes | Foundation module
-
-⏱️ Timestamps
-
-00:00 The AI Prompting Trap
-01:00 The Paradigm Shift - Brief as Ultimate Prompt
-02:00 The 30 Questions Process
-03:00 One Environment Workflow
-04:00 Ending AI Hallucinations
-05:00 The Value Proposition
-
-🎯 The 5 Strategic Questions
-
-*What & Why* - Vision and positioning (what you're building, why it matters)
-*Who* - Target users and stakeholders (who uses it, who decides)
-*How We'll Know* - Success criteria (measurable outcomes)
-*Context* - Competitive landscape (alternatives, differentiation)
-*Boundaries* - Constraints (technical, business, design limitations)
-
-📋 What You'll Create
-
-*Core Document:*
-Product Brief (2-3 pages) - Single source of truth for entire team
-
-*Optional Documents (as needed):*
-Core Features - Feature prioritization (must/should/could/won't have)
-Tone of Voice - Brand personality and communication guidelines
-Visual Design Brief - Visual direction and inspiration
-Technical Brief - Architecture and integration requirements
-Content Strategy - Content types, goals, publishing
-Localization Strategy - Multi-language/region planning
-Accessibility Requirements - Compliance and user needs
-Data & Privacy - Collection, storage, compliance
-
-📚 Course Resources
-
-🌊 *WDS Presentation:*
-<https://whiteport.com/whiteport-design-studio/>
-
-📖 *Tutorial 04:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/module-04-product-brief/tutorial-04.md>
-
-📖 *Project Brief Template:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/src/modules/wds/workflows/1-project-brief/project-brief/complete/project-brief.template.md>
-
-💬 *UX-Design channel in the BMad Discord Community:*
-<https://discord.gg/Pn63gAuX>
-
-📖 *GitHub Discussions:*
-<https://github.com/whiteport-collective/whiteport-design-studio/discussions>
-
-◀️ *Previous Module:* Module 03 - Alignment & Signoff
-<https://www.youtube.com/watch?v=TKjOLlU8UCE>
-
-▶️ *Next Module:* Module 05 - Trigger Mapping
-<https://youtu.be/xs_cRk-NoJk>
-
-📚 *Full Course:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md>
-
-⚡ *The WDS Advantage*
-
-*Thinking Partnership:* Human-in-the-loop collaboration from BMad methodology
-*AI-Guided:* No blank page, no missed elements
-*Conversational:* Talk it out, Saga writes it down
-*Professional:* Built-in best practices (SMART goals, constraint checklists)
-*Flexible:* Two levels (simplified or complete based on needs)
-*Living:* Easy to update as you learn
-
-✅ *Next Steps:*
-1. Watch this module to understand the Product Brief approach
-2. Complete Tutorial 04 to create your Product Brief with Saga
-3. Add optional documents as your project needs them
-4. Share with team for alignment
-5. Start Module 05: Trigger Mapping
-
-🎨 *About WDS*
-AI-augmented design methodology by Mårten Angner (Whiteport, Sweden). The Product Brief is your project's constitution - everything else is legislation.
-
-#ProductBrief #DesignStrategy #ProjectPlanning #WDS #StrategicFoundation #AIGuided
-
-*This one document is the difference between confident execution and constant confusion. 🎯*
diff --git a/docs/learn-wds/course-explainers/Module-05-notebook-lm-prompt.md b/docs/learn-wds/course-explainers/Module-05-notebook-lm-prompt.md
deleted file mode 100644
index 4891f5960..000000000
--- a/docs/learn-wds/course-explainers/Module-05-notebook-lm-prompt.md
+++ /dev/null
@@ -1,274 +0,0 @@
-# Module 05: Trigger Mapping - NotebookLM Prompt
-
-## Instructions for NotebookLM
-
-Use this prompt to generate an engaging 6-7 minute audio conversation about Trigger Mapping in WDS. The conversation should feel natural, insightful, and practical - like two colleagues discussing a powerful methodology over coffee.
-
----
-
-## The Prompt
-
-Create a 6-7 minute conversational audio deep dive about Trigger Mapping in Whiteport Design Studio.
-
-**Opening Hook (0:00-0:30)**
-
-"We've all felt that excitement, right? You have a great idea. You're pumped. In your mind, you can already see how wonderful this is going to be. Next step? Let's jump into an AI dialog and make it happen. We can't wait!
-
-But what if we told you there's a way to elevate that idea? To focus your imagination even more? A way to refine and map out exactly how valuable your product is going to be - for yourself, for your organization, and for the end user.
-
-What we're talking about is a single slide that has the power to change how you work with digital products forever. We're talking about the Trigger Map. It's as powerful as it is for a hunter to aim properly before a shot. For a carpenter to measure twice before making a cut. Or for a doctor to diagnose before prescribing.
-
-With Whiteport Design Studio agents, making a Trigger map only this takes a few minutes, and it becomes the backbone of a solid digital strategy. But still, it is so compact that the end result can be easily fit it on a single presentation slide."
-
-**The Big Idea (0:30-1:00)**
-
-"Here's the missing link between strategy and design. Trigger Mapping connects three strategic layers in one visual map:
-
-First layer: Your business goals - what YOU need to achieve. Your vision, your measurable objectives.
-
-Second layer: Your target groups - WHO out there in the world will make sure, with their use of the product, that you achieve YOUR goals. Not just any users - the specific people whose behavior drives your success.
-
-Third layer: Their usage goals - what THEY are trying to achieve. Their psychological drivers - both what they want to accomplish and what they fear or want to avoid. This is THEIR why, not yours.
-
-The magic is in the connection: Your business goals are achieved THROUGH their usage. They use your product to achieve THEIR goals, and in doing so, they help you achieve YOURS. That's the strategic chain. That's why it's called a Trigger Map - you're mapping what triggers them to act in ways that serve your business.
-
-It's not just user research. It's strategic psychology mapped visually so everyone on your team understands this chain from business goal to user motivation to design decision. And it's based on 20+ years of proven methodology, not some new trend."
-
-**The Heritage (1:00-1:30)**
-
-Quick credibility moment: Trigger Mapping is based on Effect Management methodology from inUse in Sweden - created by Mijo Balic and Ingrid Domingues. This approach has been guiding strategic design for over 20 years.
-
-WDS modernized it in three key ways. First, simplified the map by removing features so it stays relevant as your product evolves. Second, added negative driving forces - because research shows people work harder to avoid pain than pursue gain. Third, integrated systematic feature scoring so you can prioritize based on real strategic impact, not opinions.
-
-**The Five Workshops (1:30-4:30)**
-
-This is the heart of the conversation. Walk through each workshop with energy and practical insight:
-
-**Workshop 1: Business Goals (30 seconds)**
-
-"First, you define what winning looks like on TWO levels. Vision - the visionary statement, the aspirational 'why' that motivates your team. Like 'Make remote work sustainable and healthy.' Then you ask the bridging question: 'When this vision is being realized, what will we observe in the world?' That leads to strategic objectives - measurable goals expressed using the SMART method. 'Achieve 5,000 active teams by Q4. Reach 70% retention rate.' Saga guides you through this in 15-20 minutes, connecting aspiration to accountability. This two-level clarity becomes your north star for everything that follows."
-
-**Workshop 2: Target Groups (45 seconds)**
-
-"Now the critical question: WHO out there in the world will make sure, with their use of the product, that you achieve your goals? This isn't about abstract segments - it's about real people whose lives your product will touch. Not demographics like 'parents aged 30-45' but behavioral profiles like 'busy working parents juggling multiple kids' schedules, desperately avoiding family conflict over forgotten responsibilities.' You identify 3-5 groups, create detailed personas, then prioritize ruthlessly. Which group's product usage has the highest impact on your business goals? Which is most feasible to reach? This ranking becomes critical because it determines where you focus your design efforts."
-
-**Workshop 3: Driving Forces (60 seconds)**
-
-"Here's where it gets psychological. For each persona, you map BOTH sides of motivation. Positive drivers - what do they want to achieve? What pulls them forward? And here's the WDS enhancement - negative drivers. What do they want to avoid? What fears push them to act? 
-
-Think about it: A busy parent isn't just seeking 'better organization.' They're desperately avoiding the shame of missing their kid's soccer game. That negative driver - that fear - is often more powerful than any positive benefit. This is loss aversion in action. People work roughly twice as hard to avoid pain as they do to pursue equivalent gain. 
-
-But here's the validation step: Once you've mapped these drivers, you ask the control questions. If this target group feels this way, would our offering be the best option for them? What alternatives do they have? Why should they care in the first place? These questions validate that your drivers actually connect to your product's value proposition. It's a reality check that prevents you from building for the wrong psychology."
-
-**Workshop 4: Prioritization (45 seconds)**
-
-"You can't design for everyone at once. So you prioritize ruthlessly. Which target groups matter most? Which psychological drivers are strongest? This isn't guessing - you're making strategic choices based on business impact and emotional intensity. The output is a ranked list. Your top group's top drivers become your design focus. Everything else is secondary."
-
-**Workshop 5: Feature Impact (60 seconds)**
-
-"Now comes the magic. You take your feature ideas and score them systematically against your prioritized drivers. Each feature gets rated on a 0-3 scale: How well does it address the top psychological drivers? You do this for each feature against each top driver, then sum the scores. 
-
-The math is simple but the insight is profound. You end up with a scored feature list where every number traces back through psychological drivers, to target groups, to business goals. No more random feature requests. No more stakeholder opinion battles. Every design decision is backed by strategic data."
-
-**The Visual Map (4:30-5:00)**
-
-"The Trigger Map itself is beautifully simple. Business goals at the center. Target groups radiating out, ranked by priority. Their positive and negative drivers connected to each group. It's a one-page strategy document that everyone can understand - stakeholders, developers, designers. 
-
-When someone asks 'why are we building this?' you point to the map. The answer is right there. This feature addresses this psychological driver, for this target group, which supports this business goal. Traceable reasoning. Strategic clarity."
-
-**The Workflow Integration (5:00-5:30)**
-
-"And here's what makes WDS different from traditional user research: you have flexibility in how you work. You can do this solo with Saga in your IDE through structured conversation - perfect for individual designers or remote teams. Or you can run it as a physical team workshop with a whiteboard, then upload a photo of your sketch to Saga who will digitize and structure it for you.
-
-Either way, it all happens in your IDE, right alongside your code and design files. Your answers become living documents that feed directly into the next phase. No separate research tools. No lost context. No copying and pasting between systems. Everything builds on everything. Your Product Brief informs your Trigger Map. Your Trigger Map guides your scenarios. Your scenarios drive your design. It's one continuous strategic thread."
-
-**The Value Proposition (5:30-6:30)**
-
-Bring it home with the core benefits:
-
-"So what do you get for 60-90 minutes of strategic work? First, you stop guessing. Every design decision is backed by mapped psychology and business strategy. Second, you get team alignment. Everyone sees the same strategic picture. No more endless debates about priorities.
-
-Third, you get systematic feature prioritization. That scored feature list becomes your roadmap, and it's defensible. When stakeholders ask why you're not building their pet feature, you can show them: here's our Trigger Map, here are our top drivers, here's how features score against them. Your feature scores lower. It's not personal - it's strategic.
-
-Fourth, you get traceable reasoning. Every feature connects to a psychological driver, every driver connects to a target group, every group connects to a business goal. No orphaned features. No random requests. Strategic clarity from top to bottom.
-
-And finally, you get a long-term reference document. The Trigger Map doesn't become outdated when features change. It stays relevant because it focuses on strategy, not implementation. Update it when your business goals shift or you learn new user psychology. But it's not something you're constantly maintaining."
-
-**Three Approaches for Different Situations (6:30-7:00)**
-
-"Now, WDS recognizes that you're not always starting from scratch. You might be in different situations, so we offer three approaches to Trigger Mapping.
-
-First, the full process we just covered - starting from scratch. Sixty to ninety minutes, five workshops, comprehensive strategic foundation. Perfect when you have no existing documentation and need to build everything from the ground up.
-
-Second, what if you already have documentation? Vision docs, user research, interview transcripts, project plans - maybe hundreds of pages gathering dust that nobody actually reads? That's where Documentation Synthesis comes in. Thirty to forty-five minutes. Saga analyzes your documentation, validates what's there, fills gaps through conversation, and transforms it all into a single-slide Trigger Map you can actually use. No more pasting 200 pages into AI chats. No more research reports nobody reads. One actionable strategic artifact.
-
-Third, what if you're in a real hurry? What if you need strategic guidance but don't have even 30 minutes? That's the Slim Trigger Map. Fifteen to twenty minutes. You pick ONE strategic objective, identify ONE target group, map ONE key driver - typically negative, because that's often most powerful. One clear chain from business goal to user psychology to design decision. Quick strategic validation when time is tight.
-
-Think of it like this: Full Trigger Mapping is your comprehensive foundation for major products. The from-existing-docs route transforms existing research into actionable strategy. The Slim Trigger Map is your quick strategic check for focused features. All three are based on the same proven methodology. All three give you traceable reasoning. You just choose the approach that fits your situation."
-
-**The Closing (7:00-7:10)**
-
-"So whether you have 90 minutes to build from scratch, 30 minutes to synthesize existing documentation, or 15 minutes for quick validation, you have the tools to stop guessing and start knowing. This is 20 years of proven methodology, modernized and AI-guided for how we work today.
-
-Stop guessing. Start mapping."
-
----
-
-## Key Messaging Themes
-
-**Heritage & Credibility:**
-- 20+ years of Effect Management methodology
-- Created by pioneers at inUse, Sweden
-- Battle-tested, not experimental
-- WDS modernization makes it better
-
-**The Psychology Angle:**
-- Both positive AND negative drivers
-- Loss aversion principle (pain > gain)
-- Emotional intensity matters
-- Real human psychology, not surface wants
-
-**The Strategic Value:**
-- Three-layer strategic chain (your goals → their usage → their psychology)
-- Visual one-page reference showing all connections
-- Systematic feature scoring
-- Traceable reasoning for every decision
-
-**The WDS Advantage:**
-- AI-guided through Saga
-- Solo conversation or team whiteboard workshop
-- Happens in your IDE
-- Integrated workflow
-- Living strategic document
-
-**The Practical Payoff:**
-- 90 minutes saves months
-- Stop guessing, start knowing
-- Team alignment
-- Defensible priorities
-
----
-
-## Visual Example: Simplified Trigger Map
-
-Here's a simplified Trigger Map structure to help explain the visual layout:
-
-```mermaid
-graph LR
-    BG1["<b>BUSINESS GOAL 1</b><br/><br/>Visionary Statement 1<br/><br/><b>Strategic Objectives:</b><br/>• Strategic Objective 1<br/>• Strategic Objective 2<br/>• Strategic Objective 3"]
-    
-    BG2["<b>BUSINESS GOAL 2</b><br/><br/>Visionary Statement 2<br/><br/><b>Strategic Objectives:</b><br/>• Strategic Objective 1<br/>• Strategic Objective 2<br/>• Strategic Objective 3"]
-    
-    PRODUCT["<b>Product/Solution Name</b>"]
-    
-    TG1["👥 <b>Primary Target Group</b>"]
-    
-    TG2["👤 <b>Secondary Target Group</b>"]
-    
-    POS1["<b>✅ POSITIVE DRIVERS:</b><br/>• Positive Usage Goal 1<br/>• Positive Usage Goal 2"]
-    
-    NEG1["<b>❌ NEGATIVE DRIVERS:</b><br/>• Negative Usage Goal 1<br/>• Negative Usage Goal 2"]
-    
-    POS2["<b>✅ POSITIVE DRIVERS:</b><br/>• Positive Usage Goal 1<br/>• Positive Usage Goal 2"]
-    
-    NEG2["<b>❌ NEGATIVE DRIVERS:</b><br/>• Negative Usage Goal 1<br/>• Negative Usage Goal 2"]
-    
-    BG1 --> PRODUCT
-    BG2 --> PRODUCT
-    PRODUCT --> TG1
-    PRODUCT --> TG2
-    TG1 --> POS1
-    TG1 --> NEG1
-    TG2 --> POS2
-    TG2 --> NEG2
-    
-    style BG1 fill:#e3f2fd,stroke:#1976d2,stroke-width:3px
-    style BG2 fill:#e3f2fd,stroke:#1976d2,stroke-width:3px
-    style PRODUCT fill:#fff9c4,stroke:#f57f17,stroke-width:3px
-    style TG1 fill:#fff3e0,stroke:#f57c00,stroke-width:2px
-    style TG2 fill:#fff3e0,stroke:#f57c00,stroke-width:2px
-    style POS1 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
-    style NEG1 fill:#ffebee,stroke:#c62828,stroke-width:2px
-    style POS2 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
-    style NEG2 fill:#ffebee,stroke:#c62828,stroke-width:2px
-```
-
-**Key Visual Elements:**
-- **Left (Blue):** Business Goals with vision statements and measurable SMART objectives
-- **Center (Yellow):** The Product/Solution being built
-- **Middle (Orange):** Target Groups radiating from the product, with priority indicators (👥 primary, 👤 secondary)
-- **Right (Green/Red):** Usage Goals separated into positive drivers (✅ green - what they want) and negative drivers (❌ red - what they fear)
-- **Arrows:** Show the strategic chain - business goals → product → target groups → their psychological drivers (both positive and negative)
-
-This one-page map makes the entire strategy visible and accessible to everyone on the team.
-
----
-
-## How Teams Use the Trigger Map
-
-**The Trigger Map isn't just created once - it's referenced throughout the entire product lifecycle:**
-
-### During Strategic Work
-- **Workshop clarifies thinking** - Forces teams to articulate assumptions about users
-- **Builds deep empathy** - Goes beyond demographics to understand psychological drivers
-- **Creates shared understanding** - Everyone aligned on who matters and why
-- **Establishes user starting point** - Where users are when they begin their journey
-
-### For Product Decisions
-- **Feature prioritization** - Systematic scoring against top drivers (not opinions)
-- **Scope negotiations** - Defend what's in/out with strategic rationale
-- **Roadmap planning** - Sequence features by impact on priority drivers
-- **MVP definition** - Build what addresses the most important drivers first
-
-### In Design & UX
-- **Scenario creation** - Design realistic user journeys based on actual drivers
-- **Content writing** - Messaging that speaks to positive desires and negative fears
-- **Page-level features** - What functionality serves which drivers
-- **Navigation design** - Paths that help users achieve their goals
-
-### For Marketing & Sales
-- **Value proposition** - Messaging that addresses top psychological drivers
-- **Landing page structure** - Sections targeting specific personas and their drivers
-- **Ad copy** - Speak directly to what users want and what they fear
-- **Sales enablement** - Equip teams with driver-based talking points
-
-### Ongoing Management
-- **Bug prioritization** - Fix what hurts priority drivers most
-- **Stakeholder communication** - One-page visual shows strategic rationale
-- **Team alignment** - Resolve debates by referencing the map
-- **Validation testing** - Test if your assumptions about drivers are accurate
-
-**The key insight:** This isn't a document you create and file away. It's a living strategic reference that guides every decision from features to marketing to support documentation.
-
----
-
-## Tone & Style
-
-- **Conversational but authoritative** - You know this works
-- **Practical, not academic** - Focus on real benefits
-- **Energetic about the psychology** - This is fascinating stuff
-- **Confident about the value** - This prevents expensive mistakes
-- **Respectful of the heritage** - Standing on giants' shoulders
-
----
-
-## What to Emphasize
-
-✅ The three-layer connection (YOUR goals → WHO achieves them → THEIR goals)  
-✅ The gap between Product Brief and design (the missing link)  
-✅ Both positive and negative drivers (the WDS enhancement)  
-✅ Systematic scoring (data over opinions)  
-✅ Visual one-page map (accessible to everyone)  
-✅ 20+ year heritage (proven, not trendy)  
-✅ 90 minutes prevents months of waste
-
----
-
-## What to Avoid
-
-❌ Getting too technical about the methodology  
-❌ Spending too long on any one workshop  
-❌ Making it sound complicated or academic  
-❌ Forgetting to mention the heritage  
-❌ Skipping the negative drivers emphasis  
-❌ Not connecting to real business value
diff --git a/docs/learn-wds/course-explainers/Module-05-thumbnail-prompt.md b/docs/learn-wds/course-explainers/Module-05-thumbnail-prompt.md
deleted file mode 100644
index 90d24a688..000000000
--- a/docs/learn-wds/course-explainers/Module-05-thumbnail-prompt.md
+++ /dev/null
@@ -1,40 +0,0 @@
-**IMPORTANT: Use the reference image as your exact style guide. Match all visual elements, colors, layout, and character design.**
-
-Create a 1920x1080px YouTube thumbnail matching the reference image style.
-
-**What to Change from Reference:**
-
-**Headlines (Left side):**
-- Line 1: "TRIGGER MAPPING" (Rubrik Light, 91pt, white)
-- Line 2: "YOUR ONE SLIDE STRATEGY" (Rubrik Bold, 91pt, white)
-- Line 3: "FOR ANY DIGITAL PROJECT!" (Rubrik Bold, 91pt, white)
-- Line spacing: 79pt
-
-**Module Badge (Bottom-left):**
-- "05 Trigger Mapping" (Rubrik Regular, 108pt, white on red #ff1744)
-
-**Character Activity:**
-- Keep the woman's angle and position similar as in the first reference image. Keep the character neutral and stylized as it is
-- Woman is working with a large visual trigger map spread out in front of her
-- She's connecting elements on the map with lines/arrows, showing strategic connections
-- On the desk: sticky notes with "Business Goals", "Target Groups", "Drivers" visible as labels
-- Expression: focused and strategic, making connections
-- Skip the tablet
-
-**Background Pattern:**
-- Clear the background from previous objects except the globe
-- Add oversized and toned down strategic mapping elements (connected nodes, mind-map branches, arrows showing flow, target/bullseye icons)
-- Keep as in reference image
-
-**Workspace Props:**
-- Add: large trigger map diagram (visible strategic layers), sticky notes with labels, markers/pens, coffee cup, notebook
-- The map should show visual hierarchy: center node with radiating connections
-- No text should be visible or be presented with just scribble or gray markers
-
-**Keep Everything Else from Reference:**
-- do not put light objects behind her face since we need to keep her silhouette clear
-- Top-right branding text
-- Character design and style
-- Color scheme and layout
-
-.
diff --git a/docs/learn-wds/course-explainers/Module-05-youtube-show-notes.md b/docs/learn-wds/course-explainers/Module-05-youtube-show-notes.md
deleted file mode 100644
index 34fd1f426..000000000
--- a/docs/learn-wds/course-explainers/Module-05-youtube-show-notes.md
+++ /dev/null
@@ -1,65 +0,0 @@
-Module 05 - Trigger Mapping - Connect Business Goals to User Psychology
-<https://youtu.be/xs_cRk-NoJk>
-
-Ever built something beautiful that nobody wanted? Trigger Mapping bridges business strategy to user psychology through 5 structured workshops, creating a visual one-page map that guides every design decision. Based on 20+ years of proven methodology.
-
-*Free & open-source* | 6 minutes | Core methodology module
-
-⏱️ Timestamps
-
-00:00 The Problem - Why Brilliant Ideas Fail
-00:41 The Solution - What is a Trigger Map?
-01:30 The Three Layers - Business Goals, Target Groups, Usage Goals
-02:48 The Psychology - Positive vs Negative Drivers (Loss Aversion)
-04:01 Building the Map - The Process & Visual
-05:09 The Benefits - Stop Guessing, Start Mapping
-
-🎯 What You'll Create
-
-Visual one-page Trigger Map connecting:
-• Business Goals → Target Groups → Usage Goals (positive + negative drivers)
-• Data-driven feature prioritization
-• Clear strategic rationale for every design decision
-
-📚 Course Resources
-
-🌊 *WDS Presentation:*
-<https://whiteport.com/whiteport-design-studio/>
-
-📖 *Module 05 Overview:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/module-05-trigger-mapping/module-05-overview.md>
-
-📖 *Tutorial 05:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/module-05-trigger-mapping/tutorial-05.md>
-
-📖 *Trigger Mapping Guide:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/method/phase-2-trigger-mapping-guide.md>
-
-💬 *UX-Design channel in the BMad Discord Community:*
-<https://discord.gg/Pn63gAuX>
-
-📖 *GitHub Discussions:*
-<https://github.com/whiteport-collective/whiteport-design-studio/discussions>
-
-◀️ *Previous Module:* Module 04 - Product Brief
-<https://youtu.be/yhKxkuLq1kQ>
-
-▶️ *Next Module:* Module 06 - Scenarios (Coming Soon)
-
-📚 *Full Course:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md>
-
-⚡ Key Insight
-
-Negative drivers (fears/pains) are often more powerful than positive ones. Loss aversion: people work twice as hard to avoid pain as to pursue equivalent gain.
-
-📖 Heritage
-
-Based on Effect Management (Mijo Balic & Ingrid Domingues, inUse Sweden) and Impact Mapping (Gojko Adzic)
-<https://www.impactmapping.org>
-
-🎨 About WDS
-
-AI-augmented design methodology by Mårten Angner (Whiteport, Sweden). 90 minutes of strategic work saves months of building the wrong things. 🎯
-
-#TriggerMapping #UserPsychology #FeaturePrioritization #WDS #StrategicDesign
diff --git a/docs/learn-wds/course-explainers/module-01-YOUTUBE-SHOW-NOTES.md b/docs/learn-wds/course-explainers/module-01-YOUTUBE-SHOW-NOTES.md
deleted file mode 100644
index 3651c7222..000000000
--- a/docs/learn-wds/course-explainers/module-01-YOUTUBE-SHOW-NOTES.md
+++ /dev/null
@@ -1,75 +0,0 @@
-Module 01 - Why WDS Matters - Are You a Factory Worker or a Linchpin Designer?
-<https://www.youtube.com/watch?v=Xhw5JB7mpxw>
-
-The AI era is here. The question is: are you a factory worker or a linchpin designer? Replaceable or indispensable?
-
-This 30-minute deep dive explores why designers are irreplaceable in the AI era - not because of tools, but because of emotional labor, user-centric creativity, and the ability to walk into chaos and create order.
-
-*You'll learn:*
-✅ Seth Godin's Linchpin concept and why it matters RIGHT NOW
-✅ Three irreplaceable gifts only human designers provide
-✅ 5-dimensional thinking - the skill that makes you indispensable
-✅ The three-part transformation WDS guides you through
-✅ How to act: I Can. I Do. I Will.
-
-*Free & open-source* | 30 minutes (3 lessons × 10 min)
-
-⏱️ Timestamps
-
-00:00 The Fundamental Choice
-00:59 Two Paths: Factory vs Linchpin
-02:25 Three Irreplaceable Gifts
-04:14 The WDS Framework
-05:42 The Mindset & First Steps
-
-🎯 Key Concepts
-
-*Linchpin Designer* - Walks into chaos and creates order (Seth Godin)
-*Emotional Labor* - Genuinely caring about the outcome
-*User-Centric Creativity* - Connecting business goals to user psychology
-*5-Dimensional Thinking* - Business existence, goals, product strategy, target groups, technical viability
-
-📚 Course Resources
-
-🌊 *WDS Presentation:*
-<https://whiteport.com/whiteport-design-studio/>
-
-🛠️ *Installation Guide:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/getting-started/installation.md>
-
-📚 *Linchpin Book by Seth Godin:*
-<https://www.amazon.com/Linchpin-Are-You-Indispensable-ebook/dp/B00354Y9ZU>
-
-💬 *UX-Design channel in the BMad Discord Community:*
-<https://discord.gg/Pn63gAuX>
-
-📖 *GitHub Discussions:*
-<https://github.com/whiteport-collective/whiteport-design-studio/discussions>
-
-◀️ *Previous Module:* Module 00 - Getting Started
-<https://youtu.be/qYPYx01YLUc>
-
-▶️ *Next Module:* Module 02 - Installation & Setup
-<https://www.youtube.com/watch?v=tYifpxFVVks>
-
-📚 *Full Course:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md>
-
-✅ *Next Steps:*
-1. Complete the three written lessons (30 min)
-2. Download an IDE (Cursor, VS Code, Windsurf)
-3. Start Module 02: Installation & Setup
-4. Join Discord community
-5. Let yourself be known
-
-💪 *The Mindset:* I Can. I Do. I Will. No matter what. No matter when. No matter how.
-
-🎨 *About WDS*
-AI-augmented design methodology by Mårten Angner (Whiteport, Sweden). Free access to AI agents for designers. The transformation: From task-doer to strategic leader. From replaceable to indispensable.
-
-#UXDesign #AIDesign #LinchpinDesigner #WDS #BMadMethod #SethGodin #Linchpin
-
-🔥 This is not the time to hide. The AI era is here. Stand up. Act. Download. Install. Build. Move.
-
-*Ready to become indispensable? Watch the full module and move to Module 02! 🚀*
-<https://www.youtube.com/watch?v=tYifpxFVVks>
diff --git a/docs/learn-wds/course-explainers/module-02-YOUTUBE-SHOW-NOTES.md b/docs/learn-wds/course-explainers/module-02-YOUTUBE-SHOW-NOTES.md
deleted file mode 100644
index 09926e504..000000000
--- a/docs/learn-wds/course-explainers/module-02-YOUTUBE-SHOW-NOTES.md
+++ /dev/null
@@ -1,86 +0,0 @@
-Module 02 - WDS Installation & Setup - From Zero to Hero in one Hour!
-<https://www.youtube.com/watch?v=tYifpxFVVks>
-
-"I've never used GitHub. I've never installed an IDE. I'm worried I'll mess something up."
-
-Sound familiar? This 6-minute guided walkthrough takes you from complete beginner to fully set up with WDS - even if you've never touched GitHub, Git, or an IDE before.
-
-*You'll learn:*
-✅ Create a GitHub account and repository
-✅ Install your IDE workspace (Cursor or VS Code)
-✅ Clone your project to your computer
-✅ Add WDS to your workspace
-✅ Meet Mimir - your personal WDS guide
-
-*Free & open-source* | 45-60 minutes setup | No technical experience required
-
-⏱️ Timestamps
-
-00:00 The Technical Setup Challenge
-00:59 Creating Your GitHub Account
-03:13 Installing Your IDE Workspace
-04:43 Cloning Your Project
-05:42 WDS Integration & Meeting Mimir
-
-🎯 Key Concepts
-
-*GitHub* - Professional cloud storage with version control
-*Repository* - A tracked folder where your project lives
-*IDE* - Your workspace for creating specifications
-*Cloning* - Making a local copy of your GitHub repository
-*Mimir* - Your WDS orchestrator (@wds-mimir anytime!)
-
-📚 4 Lessons
-
-1. *Git Setup* (15-20 min) - GitHub account, repository creation
-2. *IDE Installation* (10 min) - Download Cursor or VS Code
-3. *Repository Cloning* (10 min) - Clone project to your computer
-4. *WDS Initialization* (15-20 min) - Add WDS, create 8-phase docs, activate Mimir
-
-📁 *8-Phase Docs Structure:*
-1-project-brief • 2-trigger-mapping • 3-prd-platform • 4-ux-design • 5-design-system • 6-design-deliveries • 7-testing • 8-ongoing-development  
-
-📚 Course Resources
-
-🌊 *WDS Presentation:* [WDS Presentation](https://whiteport.com/whiteport-design-studio/)
-
-💻 *Download Cursor:* <https://cursor.sh>
-
-📥 *Download VS Code:* <https://code.visualstudio.com>
-
-📥 *GitHub:* <https://github.com>
-
-💬 *UX-Design channel in the BMad Discord Community:*
-<https://discord.gg/Pn63gAuX>
-
-📖 *GitHub Discussions:*
-<https://github.com/whiteport-collective/whiteport-design-studio/discussions>
-
-◀️ *Previous Module:* Module 01 - Why WDS Matters
-<https://www.youtube.com/watch?v=Xhw5JB7mpxw>
-
-▶️ *Next Module:* Module 03 - Alignment & Signoff
-<https://www.youtube.com/watch?v=TKjOLlU8UCE>
-
-📚 *Full Course:*
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md>
-
-✅ *Next Steps:*
-1. Complete the 4-lesson setup (follow along!)
-2. Activate Mimir and have your first conversation
-3. Start Module 03: Alignment & Signoff
-4. Join the WDS community
-
-💪 *"You can do this. I believe in you."* - Mimir
-
-🎨 *About WDS*
-AI-augmented design methodology by Mårten Angner (Whiteport, Sweden). Transforms designers into indispensable linchpins who connect business goals, user psychology, and technical constraints.
-
-👤 *About Mimir*
-Your WDS orchestrator - a wise advisor who assesses your skill level, guides setup, and provides support. Invoke anytime: @wds-mimir [your question]
-
-#GitHub #IDESetup #Cursor #VSCode #WDS #Mimir #DesignCourse #BeginnerFriendly
-
-*Ready to start? Follow along and you'll be WDS-ready in under an hour! 🚀*
-<https://www.youtube.com/watch?v=TKjOLlU8UCE>
-
diff --git a/docs/learn-wds/course-explainers/module-03-YOUTUBE-SHOW-NOTES.md b/docs/learn-wds/course-explainers/module-03-YOUTUBE-SHOW-NOTES.md
deleted file mode 100644
index 5583fa01c..000000000
--- a/docs/learn-wds/course-explainers/module-03-YOUTUBE-SHOW-NOTES.md
+++ /dev/null
@@ -1,82 +0,0 @@
-Module 03 - Alignment & Signoff - Get Stakeholder Buy-In for Your Design Projects
-<https://www.youtube.com/watch?v=TKjOLlU8UCE>
-
-Struggling with the business side of design? Feel uncomfortable talking about money or negotiating contracts? This module teaches you how to get stakeholder buy-in and protect your projects with clear agreements.
-
-*You'll learn:*
-✅ The discovery discipline: Understanding before solving
-✅ When you need stakeholder alignment (and when to skip it)
-✅ Create compelling alignment documents with quantified ROI
-✅ The 6 elements of alignment (Idea, Why, What, How, Budget, Commitment)
-✅ Formalize commitment with professional contracts
-✅ Protect scope and handle change orders professionally
-
-*Free & open-source* | 55-75 minutes | Optional module
-
-⏱️ Timestamps
-
-00:00 The Business Side Challenge
-00:39 The Discovery Discipline
-02:30 The 6-Element Toolkit
-03:39 From Alignment to Contract
-04:44 Becoming a Strategic Partner
-
-🎯 Key Concepts
-
-*Discovery Discipline* - Understand before you solve (measure twice, diagnose first)
-*6 Elements of Alignment* - Idea, Why, What, How, Budget, Commitment
-*Alignment Document* - Makes the case for why the project matters
-*Signoff Documents* - External contracts or internal approval
-*Scope Protection* - Clear boundaries, change order process
-
-📚 Course Resources
-
-🌊 *WDS Presentation:*
-<https://whiteport.com/whiteport-design-studio/>
-
-Project Pitch Guide:
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/deliverables/project-pitch.md>
-
-Service Agreement Templates:
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/deliverables/service-agreement.md>
-
-UX-Design channel in the BMad Discord Community:
-<https://discord.gg/Pn63gAuX>
-
-GitHub Discussions:
-<https://github.com/whiteport-collective/whiteport-design-studio/discussions>
-
-Previous Module: Module 02 - Installation & Setup
-<https://www.youtube.com/watch?v=tYifpxFVVks>
-
-Next Module: Module 04 - Product Brief
-<https://youtu.be/yhKxkuLq1kQ>
-
-Full Course:
-<https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md>
-
-✅ *When to Use This Module:*
-✅ Consultant pitching to client
-✅ Employee seeking stakeholder approval
-✅ You struggle with business conversations
-✅ You've been stuck in scope creep
-
-❌ *Skip if:* Building yourself with full autonomy
-
-� *Discovery Discipline Flow:*
-1. Discovery meeting → 2. Reflect → 3. Create pitch → 4. Present → 5. Iterate → 6. Get acceptance → 7. Generate contract → 8. Sign → 9. Proceed to Project Brief
-
-✅ *Next Steps:*
-1. Complete the 5 lessons
-2. Follow Tutorial 03 to create alignment document
-3. Practice with real or hypothetical project
-4. Start Module 04 (or skip if you don't need alignment)
-
-🎨 *About WDS*
-AI-augmented design methodology by Mårten Angner (Whiteport, Sweden). Transforms designers into strategic leaders who confidently navigate business conversations and protect projects.
-
-#DesignBusiness #ClientContracts #ScopeCreep #WDS #DesignROI #ProjectPitch
-
-💼 *Remember:* Alignment isn't about being pushy. Contracts aren't about being defensive. They're about serving clients with clarity.
-
-*Ready to master the business side of design? Watch the full module! 💼*
diff --git a/docs/learn-wds/course-explainers/trigger-map-example.jpg b/docs/learn-wds/course-explainers/trigger-map-example.jpg
deleted file mode 100644
index 8b541238f73a8e9590f0d571361a3f1c653f77f6..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 143593
zcmeFZ2UL?^w<jC~L=hVTilC?j=^#iI5E~^#Kw5y%RB8wT=~AO8DqRwahNdKdlu#1_
z2?3QRARwVhARt{@klx|T|K9hz_nrCHoq6x9S@X@zdLI^f7Mz^(>}Q|0_iz8sKKOa?
z3vkLn7o-bdJH!Tf%lZKv>;ri3>)gI)Zftzt>{5WDqTDsW!64uzfRmH+2<H(VE-oIP
zqeqYO9Oq$O$Nv)-8|RTD++5s$HE^7V`#)9nU!QW&z?KaFuyL~e%LVw`#de6DgYz)g
zk)zzl*Z}PRTE_bP*V4Z$JOwz!#?F3-gPoI;gM-yf7^@7xahj9&vcm1dXG|V(UGe5q
ze4hC6i0GZNFZ`xme}LB?`$Qb&7C3uO@VwYnaS2H&C1n*=HT4^J@9F63>4OZ+%q<|6
zR@P8QCubK|H<-JxpMOB$)1crNFC$;QeiIdqLMJ7sq`rHP$;RSxa`Qgr7nD~Jh?S(O
zYVz0mhQ_AmZ!N8~?w;Ph{+|Q%(XsJ~$*JkzGqX#}E30ek8=G6(r&%H&;^1KC;QC8s
zwnKreU-r`+oR<|2^WHY$dgOiPisJJle0LH*mVG%YdfoI7|6`vnZULausMyk9QvZw4
z|Cr1X|3gCmo6P?v^1)}o=_7~CIG(Vxv7|rE#(tXZfDYhcXJh@rej1<+*pYk24UhnQ
zIP}lkKUMI5$S7cM$sD)qT?@O@*J--LBcOQaQ<hVNN7NOba98f3Q^6^7Ke<OeebTXl
z%eejlW4|Cz3s+O`ms{r0^2r!RP^xyhCinnwyK^@WdH`55-*QKGcJ3zgx7qB69{?s2
zPtGUs9sqv$9snf!>UJ%JiQ3cC`vxykNV|InfR-yF0~f^(03W9J&G5+00`-5b%q8o!
zwQ~SK-TSZF_USnQWMyqhoq&$4Y#ac9Z;(z;Q}<tFZ5a^{0Arsf^A7;p+RNs`#JcIl
zebA}>Z%gufT-wVS@B=`jNt@YzICA2XIvm+KvWvRBmpJCIeF8aoqyGR9jZMkh-DQdM
zz^9M(gt{%@-5t?}x>ex=K&yYr0f1jm)_7}+CD4aSJnIq2W&PLddQr&V>IZ<NIfs3z
zcxcwj$^k&^_CH_xpFRDb7~Zc9$$bPyaKBMq&&?6e@7KRs&X?YPaek@wP%}EKM(c=@
zPRI2JNyV5j-oYQ2r4kFz8HKjw?(<cyY8g?C_5W|!W>#d`_wSPX_X1cGxQoA0WXycc
zA#tjHlNjc>bph|`7YX14JYc)U`48RL8W{(GZ@qcQe&Wb7f5I*`0T++lLZ1BdZMAh?
z>(u`t%kh89cwqldIJtFV&S8ztTD9(3@*$(ldc*b7PLB1iB}@bmt7$B49k$074$e3W
z_ymF}kDsINjC;=mgi`aF3YqS<N&c>4p*ot1rUmrcKFjL|fKkbcRrE4z39DF7RMRH>
z*_%87Jj0}%Pr4C}KB_IJc;t&<$4QR(Cn4)o#fqjsnIEI_q77+Y3?dU>I}-E}67Uc7
zjIiCvZX7glFU0NuaM|hr(Drj%fBFEB`sV<^lW@PdzU%)6i%GNX)&bxxlQoR(@W@pi
zZ@tZAEz60Z(tTM6t9?DVO~z%`AP(Ay9p@dk()}*VBgf{_(c78W((K;qzHS4rUfD`A
z-%AosGDF*TI)~diBqj^Q_I+P=7mPk)bo7F=)}6+^h58HzpO3e-R4B<`DS9_FajcnR
zM%`GDY5Jl99-QERK8#7MZE^2N_=>{OY-`-E+?_<+0&!oLJ8UdIw7u<Dn9H1?mDe_x
zr5IfI&pGl*r&T4IQocc;sLRLB3C*N{HN7<T%qvgwJ$w(mgZ7L&lq@#nY<`#nb?x>P
zF_KEu$nDL`9+}TF6Dshph8hq29&TA_ww#DR9(MqEwYq1zqaU%MOUnVf$&S{z@;1t#
zaK6UpHBp+kP2TX>q)2^<dT`b$eJ_K%+@Yp~4-@<~OC}v1(2W7X==+8p(MCAYKyEW1
zJMo*&ZJxVjlm#rg!qs?8<mk`M6Vh4^_h27ucAN={Wf<$5^a_;$0SgzY#%g4uIXmib
zz}r!2NFE57--CYfT0b|dhMXtlHXKE8+S^u^0<9SF?PX`#<koS8Sz2HNs4Ht!K_yvF
zJBNmp6$Z2|NH~R@e)i=4D@uP`gw2!BG6vz0Cq>-pa(1PnCz(~<_6wGhP-6=dDtaN$
zkQ{ot8t*WyQ#HqFD9(wEOU{wlK+M&p^%6X0GKIT$O^V^`7@ULKb59RvixD7Ftupbh
zXH*yYI*+UH>NmdplA$|x79MvT)SFm?B~SHy?HtV<CO(BfyM;5`^!;VWkE7J88~|p{
zhZp+tS8P@6FI<+MjH`9&A4Inmp4q)eOG<z8=TjE-2Cq-pR`uBGfc*`a=T3As71WL7
zegX@kD~=#z95%VMMt>WnjV_2cl*Ri|2Ks)*=hDVT$I{g1O3O=Ex8nRlm0{vIcUqie
z0EL1Z{EfXiSS{ODP(2wHvH8)W=XFSv!gTaP`-Kr_xJDYCcHF(W;pSy+B^R#l`Odv-
zmD*H)tv>6vQ^=pik|BgE!)xx{pAG<D3v~JV(UV4oLAkKQIo7vBm1YcsJNzcqL&wq|
zV`lt)4gmG?M{R805!DIE`Ihkrl~;2M3%=_KDvCfPP~D0o$si_;hacwd4;>Lrw<Hgx
z+p3lutxwIlplX@@KSzx-?kr|lgE2$o0qenbmEB6YT@Y=7h_}33Mm1I$4v9%lR8?eN
zG)?!^g$O_IdR`0#84$B}w?FN}?7}54$Qkhg$Fb`K%a&^KO%<Qu8j(K<%_W=RtsoJj
z7(?*8u|&FYh5j@wN-*kSah;l}v13n}daF^6p!)30m_(C&VQjin_hM^ra%Dfh{Zf*9
zw>M-O3pKTq=NrQ;_=jwSgTx$0dsG(i*2R$s|6DxveVB=-U6SoqqQoox(I6)mv#U<l
zd{U9pUne{lgKsRl!#*|1Ti*%oC!{QeW-vDF>^4WffWXjV+O)&52nc!sI9Of|2?z+-
zc+`DK<$T~SF!5xTUcV>Z_Jkp>BhmK6jbEpRKPwcw%idAbU5&ecBS)?c<2!+7EvoBw
z6Mnr$xFz$xa*HtB*^Q6qRQU%n()PRg0XMYlbgR9_L{2^V(F~KzaADkz=a+pl8_XZn
z!FJ)!`LCd_(Ow`6{LwmzJGe(D!E{sDTG<nK3&$h7N;AgOH<E@jGlU<H3#}ty1sDD_
ze}#0tQU0qpx3WobziM_uY{NdZowh_?y7`kNDnOsTv-lZ+_kSz`go`mL2AXLD?)0hs
zITJg^p3%LnYO~O;k+jiXrM}GIJvuYU_2nbdTUZw?r5{3{=#L%ogq@d$A;ywpThnp|
zRDPD0oWFPUQiKf_ZakjXh7;wKDhp{<f$J3Z&aWD@&$vpgJ`QZ~bsw5Mj|hvRKo`MU
z!=&Is&&1#1qFrd+zTCc0J%rX|QtD}~N-SsntFi~Jyn?dzfGfxA)p)Lj+kV>=UKJ6I
zy?MSE>uzk-!CZ=^SWClyQ+vHFjBpNDOV?p)9%DTS$!3bz@G^14X2-v*2fA*iIuM_3
za=f<l`hw6O)vfBiz7C3tZ>$TdOIbT64UA~RFNOt`APB_o#aYs?I^;2Xi+S>?avOd7
zy2MMYZI3;MasWsyG&%s3!0RTYMYcjjKrE+Yd0%8SaVGg^@L!t-AKR~P!{WIc%#V(a
zpR|esN|Mb|?23X<jB|aMi9dXeGc4Be)yG#@D3M=Pxp06XA}RS;`mq!($KuQF-(+iy
z_MiBth5HfH`&(Xrio(kxSk9JL<M|yP*FBE#M+bl-)6sRm<&cXh2LSGye=FrGZ9@Lg
zn-clEn%KE>^4o`ZAB6m~-aqy7zx{Y|x_Ob@=XU_$ZN$y0mOPDPZ`HfkqDNQg85f+c
z^So|+nn&xta2cPZ6au6Z$Z%M!DqShzF?WM}nyR*09{9OFyLEl$>;E<g-algWbBT;)
z9G<g64TB+3p$SUYlHdCPmzM|y+J>*yo1sy9@2!^0s;nO;nV+{M4eucaZZ`4Np6$D8
z0Robo-#lVVG35(BIkdD7IPnZ(bbLUyvN>6Xa$5OZ2M!udF!L$5w_jXazTt4(ZR5Ot
z>cUk;r=MIY-|LUn<vSTs$bew~!k0mw!S7^bN~7HoH(e_0z#HIdxWk`?x;H3>9Q2+*
zs)=1*iuoC!P35bhgd~mlUn*teJkoBppr(Rh$(%tOhh=8)#)hjgZoGAeJ~K0&_x@u(
ztZ$o2NU?k)7U3`P+eh(a)fbM7w>eJTx)i~AFB@01i&=&-v{~C-gt^nNEo|NIUd$?7
z*Bk0kZ>Mco{c6^Fv84TDJ0URjup9o{=zWug2i&ooj4C-c_9q-3x!pcH2&IXAX|3Mf
z?L=A2t6kJBNQ_}!N!{&@krN)u(#>RYRb7f;&Ka%5YOgZF3yw1<hJKwoBJ}4PU_3h7
zYrq<BYm;QtpIpi4Z>KKSl5`A=VEE!B2e~*Lsv<nfy=awOaYOccedV^r!W8zHzH<-e
zYO+<nj>2V~<<B~oP6Z9MciulCVVuH^8Zhu(sbP$?87i%Lm~P<mh}d%j2)Dw^^sCRk
zKFEHxQHqsgI+Kyt@*B{OPwWb+ZYLyN_^wfw@4h;&H{T>2LrwFtPwidZVh`>1zsT%g
z$Of-U%!HpTqY+;HIMpJHi&0d?m{*?>kZ;YF=Zx<r#h$>qWEc-O>O!r77>3VmCaG5|
z#LfenW+7%BYMOf8P8p=^H3_pWoK3sH+8^Rjzq9_tUrv<SO%U}-=3USZ+TfF<##_gK
z7XU6?knG)CsUh?ox5*PVlD3&)<}iv$JuLmGjQ6J@7l-#Kl+f6AuFp{)Z1psQQ}8}-
zB`ru*6keMJ`UCb;QM#vuKX7nfa?F+58ln27r7X-Y`Z2Qt5j(0wDak0P7~IB?92|7E
z#^l!=l3%$7Z5#*_Lu)jO;R^YlRdE}w2qk_V_v~)z@U<3elk*Q*uG-B!0E7>}iiX7G
z(qL6>7JaIuX{32{<pJR2YMb4Sx%+q3_q#akY-=)|dvHtDIsT6lI}W#FfeUTCwtJfe
z0h6&#xFkPIQ`5Tk9OTz8f@*DaFKM;8E~Va-LGexL;l}1aVOd#@fkN%ao8F(V7fvic
zoO0^peO1BOqQrEkXMBac-yUGP+R5m`oLL8qwljmF;q|mGa)h|(?13Vxb<GH*JJ2DJ
zt}VP+F2#c}lKWJ*4O~{;&DSDJT}8J@B;~7Dol7(?xO6Om@>ZYORF)K!|Mdm^)PtBg
zr$M6~->b|FeD;q4PywpAR?;}5IJF!?a!D!JTRT!C>g<&*a^jv7_%8b`EB=)yTf;k*
z9xLa{9tR*=cB;mT3)kD#VXnt)cH-3VUU}q_-Z}i*m9%xks@W0c#l4B{9d!9T%8n=F
z*k{QPoqS#HP{Pt+z6B|BUaOW7dFb6s1C<Zzw~lbP;`|!bZ~7}s-}LMDvMgS>xgX4I
zSO>veGBF;DUV8oC{E#PBe-b|V`GrJ+t>YTbvi-2Fmwek&4Lto)7*)0WO}Za=h)cZv
zC|=Car_di#VM=A@^m@z_evsr`O<JxNP+I(`$(UJ8W&8$o&ZUc=<u$}yFr8t_G5wD|
zdfx{^9B&aokt6FhrC#h5JSqBcO63`V@Ai%g1`JZy-CkB1q7JSj=o`ZwzYQz#AvZ0~
zieX_uBD@f6W5b$~lrW&pa9gN&wfBuHVHp$c1RH=*c8uH4_Jnk%`t);<hWLd=IXD&C
z^*c*{E+nu_etrOmJu4)8hC&?)s5H+0(TDpBjq(meE-S-E))oSHBOMO_@{Tj2S^Ez4
zyNX(hl#}=V1(?%xsLxtfc0T}Eu+Z<wFniIxw&N?i3GYAdZ@t+kXJ*(Ro&V2)TT?Ly
z0MQ=pwW*P9j%23xmO$Hnt$c@geBHz&k?r*Zz||1h(6ZH!{~%WOkE3e;qu*qkf^zM?
z_Al99V8QR%($U%t`LlJR?XQ>Ix0{zWphGkN0PJ(As`^zs59!3)ChmykYdW0oq$0lG
zYE$6GYL)?fbcBfflmKv{SGJwQ+rTiiSBqG{2ntH-I`iYNK4L*(TxSDWI)h{!0POpb
z-yqt{>o-v>%zkoLyI!<gx^(r<Uwb@z<1XueqL7j`hrJ_~y<^%#r6bzkwlE@#?-J(n
zXL^5Se*1?J$iH-T(XDP->n`h&2$rc0vL9y|_#Sn0W4mKd=k|3^vn+kDW!LilHW7pW
z1hV-*+6VvrdXBR<FL(Pz@UG7u5nk0xyqo2Gf6;NC@5f=^&D!pSD?)Q|3?9hY$dh{n
zH;8u2Z}tXF#L^3kKTWlzU)cBFd^w{`>;Vf$zR&W-UY1h?SPbb8<xR}JJ<&Y6U$RFH
z%AdVyHW-$(;LwU*%wy_*`4#LW%oB0qF#Nw94O%xzH~#926)(O}z1Q_O+B4s*FDg)%
z+YE}&w()*@Y?x1s&GSLk`#f~yjJjkYw%{^@mvu%iDkD*Y!?mfNbhw#q5|y>e3uKy9
z1aDLX*n`b8I!FyHPwEJjrEze=9^YEK&8E+)>c?Fuay(%wL8SZQ$bDkBzui@u%_B#r
z?pYr^p)#?Pmwsll0wfF$1fmgc8KJ*kDn<6F*pLa-3<H`&eMR&O+M1YBK2)O~Jv@~v
zMR1VA<9y8$2(gl+on|$<&GHwOS$nWwFDh;jA&wBTqr<nUG1j2)l=9{RfqT)MD0SJ%
zYc+qc2Fu^jg&b~-hJYQ16MV(yt`b!SewI|zYw2jHu4yiHbAW+cd}^?$<AQc?fTmk`
zy*ly0PzxFdf+~_L%g9sF&=Ec6T#El3!}v}Qkb?R?RPVB=^@47D7s%1j2{bFTKWYaw
zY~lNM8FB!CM)pq>72rO8r*2m3_{s{byAOT^4Gd5UJ(xJMr1%2%!lOmy3+9<9gX^Xw
znKAN!(g@`#p=oC0d@LsS{c+rq%^(PS)UY}lCdy{tbB%ogmdaMyD9v>1fAUB&G`_kJ
z(vZK?di}N2{G_#phPBGr5GF2*Tx}^&{f1u)J|Wd!EiYXFD_rxogv10=M^q~BzqTUN
z9IR`ir32tvcMexepxI?f=%Xoyc<)QrAD>P801_s79}n&Nn!yKXQ#4*Ygm*!Jo^XRo
zH_Ayzdv<xYTa#+W+accZ73)ev@|5t^q>KHur5KRv)so!k{lf96BKqh8O<lIJK|r8b
z6k{ef^vNmZ&ZXhyyN6EInwtm$6YV&n!{<P?R&5{y-^#e<ZX6~ZGdnac(P%FT%#ru6
zOv&Qy)lGMmHKpWBe9}?Hg$?MMB0zNaE`(2;O+999ZEvVD(7U1`QKpP>OlXh;SlJhu
zT{8qusJ$TeuvK3w#|Q=-8*Vp{bk9<RQF5@hcxxunXzsBXHX54CT93%xb^-37nF=Gt
zu0ll$^4nP5I+xd;G}L_m{Kyz~3nGU+F2BU;I~wd9INu&-I(O!0^OQpG2ar%JYP=;9
zkGO{xdTK59?$T^x>BAGO_HgH35Ty(Zbu~BBTITWU#4wZ*NL)OdI$)ZhY;9v5a$dNM
zY-Bj&9G<U2+kuo<xU5aTnS4d-9i^6Iz!g^q9uca^D-lj(!>#l&(7Q`47+ah!_*i;H
zd=UUfx!YE{cTsE>;UEGkRz$a(N;71RsU+Ew?PPlpeyf4K9dr5v8osK3DAO~;3e>*K
zrLQ<&(V1J!ag_Dr<d3@LVh&D+^{+A%giz{0y{Nmdhrju31!25tH(QlG7OwWBJGNrV
zLyIkaEg@jW#^PzZ@C;+Q*SvpVSP_FZS_mndoa`PB8L*zdJw7<~N+<{-UpZuFe@E;U
zjX8Guc-l)CgwB-`1V-_($++Pvu8*qJG<82n@-vDql&hRV$3Dh8p@Uac%c&(24f%SB
zJ;wIX=yZP*>aW~E>RNn$qckapW|}y#>0nLih4@jUu<)QmxF-5km)z;pCw>vXgUXUR
zQ)Zz$LzLv!(nCen=9P#RHHIpaPNUI58o0jrS!RC_Rjie0TNX$xVst0CbX$^x^QCdj
z*kf?DP;lWalAajz&2ReEF*xW>jr2PK%hXo%X#$N93DFb0CuH$8rD!xq9szIfDZH3!
zk~@~<7-I8&ht_LHXSSRN(Y>>?WXvzCto4~q^+71^M}2Y%jNcEwpW#o9N_<G_RuXcA
z$)u75?r78~+6X;ysY1N%7}L2GaF@?Fd*WG9;s-9U`f|wdT=uM_`-qsjF3M;<w4G2q
zSiX_L=u&xLmXuQ94S`rDTkYKIo6&7=nITVt>}Q8EB`6g(ZQudf%j7Z?L#H`eLr2Os
zqH8N4O0;8T7k`cf`uXjbViniJIAC^PTu-t}?bV@2f_XyF-B$0qWid%rF(K8qR>oRF
zg~b_iT<Z0g)oEngV%fa)#dCC7hA*`FjY}T^acB7VNtLGMFPdMxv_2&Qt11)E4celW
z?z2hVy?*$!-{T?$ymHWJfvo(SN%xsKE;78v`NG9~2JhYo{9=}6zE}<^4<Z{7kaPjl
zm79#dzwVpv-B%V^na0|Gv)%<~`j1*ozqaoat<D7JS(I*N0pxz?_#|dO6OFQtZ`gXr
zo*E=vQJF|8FQ0*CQ+n%sQp$s`?(y33f^YY1e%PT=Q`$DrQ2*Z~#D>SJd&FOR)EJY+
zYH;tao1-soaX0VVH`DaAck5nnIt4oiTzvB{mcrAz*V+^Az59g+fREhUHF`TKLepC!
z*YEDFoZj=-x>0jx;BTgnrsMc=(%|7_uXQ9TD0L^ieQN7sfTK2L#YdCMP@QnZ`zp8F
zA4^T!uwaxRk}fRn4f@*P@jZ;2(CeW?bu~Ho5(<V`vt9=t`8d5YZTzQ$iZkS^yl&GD
zm-^Wvo|*EaO-X~pY!RuXa?~;Mi)aK$*>Wn9Kirk)ZfqLFn>ys^H3_<D*}I|vZD%OA
z*-@;GV$(gCIc-NJ!7Y{Z{r6Cm3X?UF^RbMlfg-D?S@x$+zus<>{PtQjYh`-ut+&^`
zKT;p=F`=6v@@lOsYz!PU84`C(ITz1gUoN-4*G~B3c}R(UQXF<}%W}dt_S*h<q<9V_
zM~G_SG7e;HgYuYoX7Q@g9{<RVq&`Bw^yEM{C@;?s)4PuRPE+t#7kdrr8)kf0EQwM?
z$@9cbHNU!`&V`8vRXxOVxy*sY$r~S)3ucME9(}R2LIaDTWZKuR0Q$Oj$m-fmb$@Z0
z%Ez&=E400P(75Q4W*;oG@}ZgVQgGvqxH*Q=gyu*5!=6bf&Z6YD_{CDpr)um}a(B#*
ziFe>o6YOjHL&gCh<g6f~{j4Bx&ySD_5~np^_%r?$LT}4yoJyG1S&tgr0WZwIb7Mry
z51j6eKgZE=Eqv))`#JwMqhzp8i&<>;VmM6FS_2_uy@;LMU&<9*F~=WU5jQpQCRUq4
z3)hCX;fppOt9`M}qYS@Udmt&(KXcE%+v3$|YlGmISM;Z<Y{K9T!OFL{>F?PuKk65a
zyo$G2(Mx;Un}mk0BRnYhu$}?sEG1{9MME9c3mHn8_`v?+y>QiseXCACh}Hf`UYkyT
zxa@=vboPm@_V)Qj2f3q&dO(@vmi5<CsVCI|pUuw#u}5JR9gxgfERq}9mS<So`9&zc
zWbw+7azrlrRfh^B3CkcA?|VVIX2Z36nMzuRmbbr+Jsp1#tNzo;FScr~l}qM&lb)t&
zVTkV0<rO0ZpTT6+lALvFw;==m=!b!6zd2S?t}{gr+-oOq9z@-Lp0|0$P!;luhA;@4
zigM|J?%zWyJ}xNg${2G-`>OB*z5?b0otUT`d!@@4^*ij_wV0FNF-akxis8SjD~Tv|
z=IoDT7^SMw+`X?H5_~gyJ&qU<JYw1xGa4f=(*9}o#!O1khq}x@jx*r%biEUYg4|<2
zsCTT(oKyHRh#HuFc?N4lr01K;d4@gS!kF0cMiPwe{9W%&j6=*(8<$&?f(>R=Rr^Pl
z!;}Juh0x8)vF0yD-9ujFkSM=F_<P&qTgh1KOkK6TA)EASwY{G*zGx$_!S4E|fENwA
zH@mZAJ$pvN9EDWtl+d$pb#FG|UHOLG42+}$=qBFLi;G%y$w~x>kYho!_KUT!%dX%`
z+T|*eHP+uhWeBTW^ZaeHsEgyT^mE_l%-*2$@9;w_reBKfOISpZnK>7&9Trr6nj};d
zjfM$}DIWm5y3we$*e&!tW>pLR6}ik=%CdGfy!LpLfA{apuvky>?dj(G98SBp40Q-0
zue;?q6Qc!lQf}qo6q?V}etRS8r~$~mKgoxxQ;}{j3Ad?xT`+fbk}r8%x1H2GAe*M~
zd!R#sR5Qt!HXt5C@rQ$DNpp^Ozc?(ju@=ClK^6xgCs?^IN*?m0-gRG+6}a@d;r_Yj
zZ^V=p9hU1eE3&=fwRgy1Lu5C``2gT>cKS@S!}7I+y$~c?E2Y+I`@#Ruv<#jFuw_Np
z4^W8Glf!Bc=GoQvXT^sDR?T^uOF!_K6wTg9J@1^RCphCBe*aj4Iq5;aY}1JW$Y9AZ
z$LU*KyP{_HD~0x*{+Xqp4KwO~y(MMV_c~W6>;H;%y(DxaAkGmdX(RL$@gi(dO8L(4
zy!oMqOwePHCdv>1dvKVuIg&u3-f~|V)RUe45a%3P+hb}F2@&IqXkc;+Wl|;B6Mtw=
zXyB3kaEHCqwkG>x#ui%_J+xyi`?M43ebf4^-G;ANX%L)`t<F4`gBe2eC7i$BU~DE-
zD)atx2km<FS@IAT>)wtRg3inocDHYE6-<WMug`=jlfndQ!KHIMN<FeUgtu?eO-l;4
zhq-6XlYysBoD}46{iMtrjqwgq92GY*fIlVlu6GTUc;N;Ie_l<woicDqpaB$Ne=XBq
zgzdIWT?l|3{Y)B~FsN<-A45>=+!?EVvz@LX#T!?$m_@(VV#wiehr0r8Ur!CR9HX}P
ze*IY}i}O_ylO>6#2&&wQ6U7C^U7XC5%BhQbm)KGZQ(bJ;EDrXyo?Xb3@`0%<Ux0#U
z{Mz}mQ4dT_C;C%ncd0>mmh0c{9Ky`*7W(p|qn~%!mSNW(=(etF9o`Wq%<CyvRwVGJ
zxvIjGaYg_3gTse^{h)b2Ay%h5(HYAQsUd~ZR1}r5m_so0P6F1}`$W$KwgqhOC6UBa
zzm^FQQ&_=d>!M3LN<IybWd0<clay-bC@a0H?D3}e#Ub-&-q322secB`v5eMsrW=9V
zt*e3EMl=|y8<+%ZO4Wy-?Y(IaS?yv#Hw^8hZEQx$e&FX_C>h}D9w*-W#pa)`h{YT^
zl+SIUdsjeRJpGA6`Fi-5!e$Jv<^b??QEX<gBu#EH!@`JW^3rmzIz-#fe`Y{bD^w^?
zCr2;4p@g4WeexJ~%q{1HlQkACY*5_z{EHc?DCejdHYpvevGb$c*f1%`qqnFB>ksVB
z7><D0Zc7`sy@z`R4G%ITX4>%MZ9-bd5voS0&lE#{?_e5Y3JK&mmd*iw`Y_hjTW0W>
zDxi$}gY*nscCePzD~4EybjjhVgJ*5FpbS;deez!4ym_yt_C>5W|EjOCbKoHYT)8^I
zJ8H`<<7%{<-7&zppL22&pYyb22%fl(GPM(t_LOfaY;Cuu8*1cQFq5FvG<cX0NDD)y
zSsKmVTL{x%s8Op_>Ez65|IXX4kO@zm&|J~~d{}<^Ht^CZKF)YP3v-KG*h?hBV?wM2
z${tZU7>KA=y}B4Mg5V6Z%_$794C5uDh$xV>7#zAdhIn7Pd6C}ThN6$n9(#uwrH`Ix
zm&u*!o#y3w{*i6KJV8n#8X?3zF=5mPf=ZpvYfY<&b^cDQyAj%9w1f&@0p&QoVz~yP
zyEBC1oVJ$iO+=fst3Z~NCv#y8ZqE}jOcxTel9yXZnSy7@UG2u5R*HVAFl*qLd`zR<
zbL7hP>s~wAIbMA0k?J}c($*b{26SlatYRFV@5ADEI%U_Cnj?9;&DxHBLY85_;Vx&A
z5)Z*tL?I3Sv^O%+MIXRqm@+PJe}az?!S7_hahJ80-s=OFN0jRb8y_{6FN&#h8!mwD
zFy*cjhn&(7;_U%jmU3h$&gO;5h?dsx9Hy!uaMc|I2ac^HI{Fb+?fKHbDY7?O=0z1+
zH2XciTeYYsAk}^y!A2`T;NnjFG;0I`wgm%GkhQ)AO68!J<?m!vIfx6gGuUM<md6NW
zR1O!l)&3a@R7KKNx`(Xn6pu`xel|uW`aA#&FBu=>Yx6+2@k)r@UD$%j2docJh+PyN
z-$0`-ux>Glnw(F;VT@BpgBju>`12b!eI2v2vmG1RnMcc`2Oh?QXiu5YHP8BwRc94l
zzo$;c*6%cmU6dDZkwW%Hu$@?+nA|YGG}9;>*1RMhLJC||Ve}9UtuNc}4h?T;n8FsG
z4ki{thoZ!UY;;`xCNOmo3z>@cAt@C28)n?hwLNUd8@|}*6MN}bbfF68NXzRL7bri=
z&P+~DYy<_Z&n=vlSqvF@Zyn^*sM~URcz1}-&{Y`_J1W^IZ38RzQW;V1F75smBOcF`
z1Xdvz#NKp#pQ~y=Dkf+ClI<#ku<+p0MX1!BPb!Hw&6Bi-p_w#+9mNeV`0&g!W5rix
zC@r|Oj@q%dAq>o<y_kXoRCb}G-8)kQ==bLy#(j))bcI=)vx_e9Oz;RijE<@%XS^vy
ze|_F~oWYO|k{$@#Kt>(4F`nDr&&)++#vM;y=)(%Br)=H<@>o7xK9%jkc3Y4q(9@-5
zCO%0%Kr_Y@X56uCVm#?q7`i4|>ngDSJ;*XoDQ9EYc+%1SZN&d%-$mVlZ_{9;5q_vs
zxxEkyp4Jg7is6gi9DF+;uY3KiC5(&eG8!ZmMd)$ncSVS^AmAC5RfI-Lj$4(r(vW?@
zcGLRq;%uTp{pfzGGu$7hnicGSinFKRlu*&i7y9hmp>bDpDK;)H;PclK`F97PU3DsH
zD|R>G8|2jyLuYSLQ#frKH&#*}1M#*)&-HiexYJeZV~$^$mF~~n-Ui>&DIc~KbR>Nn
z+`(}_54S%Y$oA~k5ZhT1|7tIlqKUQS%-Q|0U}hykEwv^oAR4xe=kLqkC3A-h{{)4s
z4>0AKqGu1!AjGO=-6{m+sgLO=Pk;fo@%oqIr6e0oC*2q7M}2ym+k=V^09tEOKE8%p
ze91U$o?^G&WOkQLYXf>$vzsZ)#GeO0OWhdpdiyHDr@cz0=cdUa%}=8*RJ7yMMd$aT
z9hRp;m+CBCsLVP0l<-HA>MJAr_GWS7o{918K^xTm#2<{!aN7F*phcoSrJPsB6UT#l
z^X=R2g;rGo`$(I&Ppqz?Vv<r;UIS}-d(dl!Zab<WGfs@L59_8=_C|fXes$Su6p_gF
zZO4=4?!gTTMXwyLYBcJDWU0^N9<jqkYHqwWG7dH$pReXce6kjkwLnub-MWkZIn148
zQ~R!V0y+&*Rj5&$zhQTga%Hvdgom8h@yW)<-6g^H&Yu%3<%ltAuDy2CRK0Xow2bp<
zcDjYQK=F{>*kp-xzr}Q6???dSr;$;%cYpy%7t;M6n4Hxji=TYtRV(~+)-u80-y12T
z*m^ZY)MvyI#`f<qRxTrnmli6x;vuKWi-;hn!9WL<VbX|A;Y-{EhCZWH^_vcoR{fn)
z&<QTQPNEQAZJ#Ap>7WE3V6i6ztscHu6WMbY<5wD&H9G*jHg3r)fSa$~YphZl$J!v1
zD@kCFzSo)bU72oK+#6!kM`a=*Mn=VlQ2}lE<`XH(ea=Hmak{JgXhHO3lFMKcw#b&~
z4R@)8BIt}m#_!c|**X3|0y!kF_5ctBx7hT4l+OSMU1(g3qI{{2@Ay^E|E1}=6v6|g
zhRC_y0`vr?_p0H>3txEJ#_f=TshY#v+g4pY!CLAlkiqaW*cmAo*|N)qvki+@jZwi^
zy}j!epiB`weC&ICEUjwibH(16^$T8KEU3K~Ww`7Eq!BDPEOlw1#cW8gZMzC~zAvin
zJ+THuU#u+ALCmlIh(NxEf<Zp(t$m;{H;<`TJ$LzJUZSTsPM^9e_&NODY@WD!mAK$-
zQk&!*!vH@zJhi;rqJk1K3r#apEUz)Ag+VbD#&v!hWGJENYUD5A5Ao=yL|N$5g)jf#
zV4#KmO!R<C8e&C-=+j>ixVEz5;$_i_iqD_P?O0z83yrTcEln^dV45DcUHEQ#XYvS-
zfR02Xh=(0ubd+UdYDr6eG14qSs4T<wBflD@C-p7C3Kw#-VZounIyjY6DQ*jo^&eDo
zMmK%D{rFHs!wLNd*MD#ioBE>B49a`4wru9e@ZcV}m-BBV<o_cgFXwK&j*=m4g|`Y8
zdoCryJ#t}Nzpc-{Nm>uWsBLO%0Zf+t@eX_N+(b`gglxs|wF7`V<nS<i&*}5F7b9Iv
zCD`@u|C!3dsbhvOufN{e;5{Q-KMh>O+@YNUiF+=5KtH>FOUUnUai4#N;Qlua!Lha5
zZe|bZ_mP8d=J>sa>mdk5h#95tZ9HnT7Fpk$rG<nKv02TWk1y*ee1doc6e+i&T-Eih
zgqI5hDJq^sRn`k%V7Re==w^``uF79&l~@?>2w+VT@j?}K7cJ{FnPwE|!?B*fi~e17
z{($@z$U2}^+*h}Kr3$-ikXg8_`4cHnQiK#G;yd25yl~CIMv>E_e>y5$v$ZJSy+X@r
zg^|k*<>%1u2uH~wT<Oreb6+0o^MgXH$#Af>!%n-yMCC?F&R`{`r(aASQP-H4<S|U0
zXQZNf#eMNh+Pe|*$T=D-{;8wo3)vT@9{-IL$l4s=!Zxoqle%U77?vPH%1^5SrS0@W
z1j{3AsC>EQLDS=9v;YU8;tpz;k6-pbp2Eb-yP6VG|ICklSfzptr6BQtCN`>bTJdMw
z3Sq)M;|rqPi2bDwm6Y95LvkvLq3nbW7z7RK_6K10OCI-`I^-0U%|<3(dF~Vs4!SR|
zDM70#2hM&uuj+lFw!c17I$5w)jyHpU(L7ch*q4};UlOho2-6tmrF2>2=w$+V{5GR6
zlFk@Iu%?jMVtkQjb#@A=Yll3U5ximcgLqVKqC)lB0HyQcdg`ebHihdge6#%#mY_2}
zI*Lau>iRzVZ%Iq#OZdu%%bD1==}<A1e^3Ddp0k4*`Et>q9k*tykaj%_aU3eP2j8Yv
zTxqDv9F|oehc#iZ=I7ppX+qX%ZePtjA7k`CTM~HyJ5cA(h%$p6jPlSq0|(J!_uew8
z@a5Ri0S$GCQAeL)73nJ0m04`jw&)`rX8$6(!V}y&i*etxwdl=eEC#mY(U<$=2&sKu
zSE3o1&Iiwn4S=895EEaW(QsRR0k?<hL(fFF?!6;v3-{31{i+Es3oTw!bSkkOB?0Js
zSKuJQrUHUkR9mq~cP!eAQ$5BUp^9-4S8E>A3|k6kvg-;q$KWbeA%5{-Z*R`X!Z%Y%
zErC*kVsGE5*1Y}vQa+ha7X-AteI<)b^GZ>qnWisbLkTli^RALfYOM;E(I81M1Cf*0
zKs3n{Y%?#OHIO=OI3p5Zl9Xl|fFan}miPUcqJ|*@Wiy66mVjWHz&lOrUyjNWKf0Bu
z@{TXQ23aYhxbw|0AT?5jX*4wNJH~UytzQ}vf;S`ojB*=G$<ISF3H^2$RIo>PEW!PI
z@yN1T$=-7okY&)9to@3#`Dx!GCaWI2Yf-m~(dC`B#F&#C))ls5{oQzVmvL3gkKi^Y
zz@}jVkjs%9IFEDeb<F(3mlh0AXp@ASSC>PijSvn_XcVaBcS(RbwjBcLvu}DW<B3KG
zTRRjO5^8&kiUz1bW9p9x#HU^!xv2S;N-Kn%XU(toYNYbYDwN9+?S9buE34?;mYvVM
z6PQ$448gN+hfYHPv0Pn*ML%>%Rb0+lxm2*fke$|rHD5AK#b~H~S8i)NFxJcejmPEZ
zk18p(AypG8Ryl4aMNyUmY^bB8`??eHpwnXyMmNfZYwcaq{SwOKY&1Yb@pH?$MOo6x
zL%qGIjj)}DfY&zyLx~p3>w&SkxNeI5d{B_zM&>#s=*QFbt&gvUEn*f(XD#1GJt9!5
zUfy*XJ#SI@d@|E?A`$>TFDdhV)38K=&?9!?Om;yVz8W`vuFx7dT+=>Z0&i82GMVr{
z)1Q)^cfs82sbuA1m}7yr!NQDR5-uS8Y@g?vMTY!iH~R3ce1*zt0{Er#(1lCniyqF`
zC&?*^fpU{RMSwy%3)wUuBUQtlN&=x0Wi+FVB~ysQULYU5rHtJIT-9%UfY8g#EHIeS
zz#gJ^i15yCXRYHNFJDj}jiA#WlyFaRCQmNo8W2kO%NB`ECWm{U<P@sGz=O~gf2ro2
z9#~b*x#7O4@KvH^0Hs_P6_D<h*T#Rukm{ebMNBTHN7&}Oqo)F<f_0q7oUCM5+YkSw
zgT)pa-^MTUq%;i)77ICDuS$Gy;ccVv@9Im^KsPp8M`-2-`8PQlN@_7O!J(;H*Adc{
z^VI1;Kf@%xNwI=-i{#`<$jvTgvPp$cuxGWYC7C21EjQn{Oj`%*dlos7OuQ$Jx(re;
z5yI`V^;cL3k+iNXEkIF?r<m=hC`f{c^%pZNi6WiTg*ElnDW-evMj05k=(aB}lfoS5
zd+#x^&fiDnT$riSF|a*KlS)jWZC}}#AQ3P0fJA0*FRLjvzGl<u4g|@`;&fH|f$e7i
z25-NADZOy6kOyvP|I|GOJf;pM2Y+E=76tY63Igxd1=5@IdS^i}#7u9DT}BR<3jvnn
z)U6dg##tRTiq-%^bm`yYUU3ND;CEKjR4jcM#BmXRI4M<zXzah|$0W};3yk$($$|Et
zR=iHoq2g~m55MLKAcsZP4S2>%<O^?v^!7gaz=fh~eVOne6LL<PWjKmU7~yIKTct1q
zAvHs5S5m*GxeKv;@ZKJaBw9j6Zmn9Lq}B+q$Nb7*FR87QLV~1Yv~GU5%_0H)lc@Dy
zaF^KHz+-QweZ6qH^z>GPvNw^Haj#8eyT0FwzYDbYYt>VDz;U;J1Db1NQ?1z4tnFAS
zd%X0Vh)n#E%<){K4gECWIl$Pn8zDAU9@$p1SpCPhBjc6LbuLC19C|*_2{8Uw*45w0
zS1cyfKVWo7+QKSR&GdXV6~M~XS0yhhxxUHFReflE{doq?l~3NkT2Hq(4XQ%y?zYTJ
zW1h5VU8gS4w&9-JvZ1Mu`qyEfY{0O~m&N189#`@3_vB0IUlP8kc%<{eUk>2dy7Rwz
z71(O~5fF(~YAEwUw)~dt8#G7FBh8wdha#-Q*8yDO00>c}(kH3EVK9K)OPRs<W_E1Y
zF?F;V)?en%`tA1BzLHISdAS00HYBYuvJ7IQKjmg%<7q6T=<)o#p8m>ttu`YIF!GFo
zC_0qpHIfu$yE;|TJ7{D+LGy9HK|s@HFw#1}54fC`64~CZ;1#H<yELYCgQ1hF`r>0o
zu~<ztnSx<<&BvDSWt>+74%s<c$&My?yD-T2-bQ@jIsWA%Zfq3ptJXrKOw`G3KrBPV
zLMS6(x7=|FP}r+Ue%fNn!rG3cr?GtGV_CRt&4xgQ)$Mh+$v0oEN3UEnwZI&8e0bk|
z;B?_(j(orv(bp3<rx9`h;0tdfq^Dvkd_cJwxNfgpkVJQ!+}l3+g3ucL43<n}V#tt6
zQk~;Ro1g80H&T5+eFMI?&3|wYEO3g`l&>K6m5h(E+Al}v`MnpG3Cf_L{iR`WH_1W8
zZsbNm1`d0qWXEScoIKZEt{c3mY7}FTpc7>;9pZEGtX@Nxf$+Bqy{l@;b}{S`d1BTE
zym@+(>bij&ADuGOB$fvXt@CwfL4_Jrj-u*SNLs35-|z~RL^kP8wP{XK2|iEv%n*AX
zfSDaz!wr7l*FSPr?MTX>FXuYOtSbdP*&g%XvZVFdkixtQ3<l@%*>*M|m2#wIBH5F%
z=f8vhnP2cUTuXOM`u9|3E0fc$5AJ(${LFIK4MV;kWC6CO-)+(o5^Wu(8#eF-AdY+!
zGUR}^OvY3YFoE|A84|=0mA-8iRETm2t~jGFioTsV_|)42k$DW9_D&4rsM#<2Eodt7
z8IMCpg#N8d632uk3O*G)*S+oK)(AUS2&@@IR5AyBJPn5zYU$kD)nLec@wOOT49<dJ
z4f=>94TIMo{m~-krHT<7d(J8-*Au@g9kw>?F6;oFWWU2+o`2EYgpaPm-|{V^2t_a#
zHBMG_J;%cL!~M3>Gsb~?Q)q*h<D`(;t*vgD9XJ)O^Jg%nwL|u%IfF6S&{reKNhPSL
zl-k=3%6{*^X=|9Le+9<($FV1=SxO+#iBWsc#bsne$6#1;f!ilK08)|eluRHd_c#kd
zC2x<sCkAfjgcz8<NGYcfgl))FW{)jaRv54B%DbODnifM*)BQlR9<pk`T$*y)J@uN+
zTYksnhfzf!XHKVRwM^bj2kWy>x~S&e8$-6P@TwLSx-n*9x!BH+s82eKtql(80uOmA
zf`0d)`aq5IgBitx-f5<mT>(&k^iN$!R8aB2yE2sT#eMJ3r}g;UKb+tfHR(x5fl^jM
zK>Qq@6&0u)F6ojMb3&cKZ;-Of!N%l83W92#8a7(R^gI9%5P4OlWT(?DVr4OBu1tJL
zQ6I|`kW3j6PXRtKcs;mGvtL-K2!vw;qNkV{*(q^$ULn$Efgq(U`LAnaqYbDslZ4Oc
z?d{E2)X_ZS%wPUR7>!#RBF-{i-+dzI)cIb%UGVirw1K9*G0OY^P{?uU!a_?M^V99_
zXy{JDn9+vk;xK}e?~W<IL*1&TG6Qhk^d*uggjmgMpi&v#G1H=q<Q&v=s@aeY=s(R6
zqCMKt%Qz(|$lkJ}b}yFjSix&@!9^pm?6G)TTMKh}Wuc!gXFa@8r&zu`86AhZ%W9NJ
zjzyFk@R~(KD!Xlm5w-BVM|ocaj4uqCf}R`z=-|^C@B6(myau-UM-CZMVDt~SGzsRB
z4-i*E^Cd!Rh*~(=b!X;qKec<3GBt&$R#|(549S>ds)4j}xV{%HAh6<my;*V#g!kQP
zt||ur*Xy8~=8Dd}pQ#!FTQ#~@cwMK)E~VAI@M<#?>-7JVw@ZR78$+mG;T_x2@`-uW
zjQKTVn}G%Y?sm@(-}+46i-Pwe`j(ksw>A=5f*{p?S?2q)Shi7nb&OLx>d6VqNxVA2
zq`W*j*0f7UwkSDu6hAm(qGgi`*-B%Orddmv{#?Od`F2joE$-{$HTJ12K=y4Ba&kTl
z=*v23zKMLLmuvax_rEZ$xneebSzmIPt=m3TQrLj3epHK0Tv5^<Q4r}j>n{AF^_LU;
z50H}oU-C{Daw7QkehtfcxP_uN9{{clAp0A)8kYKZV?|l?qmhYD=aQ70Nq>um|1Z1U
zxf7cSm_XB?sp~Bn3|HLFzC%xnHXsxX+ogNlSR`Lg{`1ti(k6=U&$pVlfW|*V^t|>G
z<MkZv<(VUH9?kX_R0ZXpHjR3V-qRl{{rKTT@i|ilhly0vn`;Fhq&{5$umjkBa{@sB
z)mG0!;QnWTP5-X_f9z!B*gosDWMZM^cFF!r>DeU_rj=LLL}>fTjqiGEJ*%^SjGg{d
zYCoyuuyyexi$cK~**}0K-mGjAl@4o5;oh45EQa`z13*7%>-qqEG9l;R1^sWOYxwV#
zNi!IYkB-?I4PJ?LPUHCHdV!BOc>Qo`A>`as1EOo&kwTKoeC5E^{RxCY(p<YKu0&l!
z%&%kxAx}-8-W5Nuy1R><kgVHeJgpnFI=QvS%0@HGqC9iq_Yzr0^0OSaw6yo{YmcgR
z)lIWdn9GI-fTrL3^v}r7#oath);u{mAM3Td%}RSS!>YwP3wpGPRZUxDi`#2oRd2nI
zeILn6k5jk%4C&;EobKN@Ha-BLPi`71d2Ma7G-HNbB5PNcimdFgQv39>NO9~tqCy9N
zn{~^<$lZ6yuijW>XY>A@v;#m~*B<d1OQ4Z0BUUn<OCkg3Mz+>iZFRFM)$gB)6WR~g
zUgjIw^-NeO;@aK+E9nk$3$Xu<bx6LmWH&R5b+$p|PrBR4$`VWH+yhp48HsqPJ-xAS
z#$wog<675M-48=ftR4WiSZL|Xab4D<5_Th14*){g9XK27mFku=9QJQ%mn+n*%pCy4
z^H{I^`tS88^7rav`=|E)slC4+drq^+Q}g)s=7%@CMVF`>jXdGY8F301BP5)}KT7xg
z$79wh&RD<4_<iw+5OZwcVWza$`n8uXSr?902br%~{aE^sX4s8)yRhtgA9<e?eBd<U
z`3z74un7RzKk)rWV_x9^@PEhT5YANYns^xFo$?rP(VPMLJa@s|H=PF)3wNi3H~a&G
z<x9nr9j~Nk$nsJ)X6EY_R`N?im;P?Y{$HL;XbE`&`K`BbkF}QG;a_{2upy(`xqQ>*
z_0E*&_H3~KQ}Ob@&LAm|?MbeMDO%w-t6w7;%k~!<c*Nc;&9)JC6pGxnUEA!W$)*;v
z4C$5T{oxl${@rF)VpnHCbmc3*SYXt^0bsD4P-_=|Z<v)~!zP4(t+-R%xI3;jDB6yb
zF^{}LmTqdFyj4<tH~*sB#CZ$UOK*O^B*(J`XXz#|i-K-rBexKVJS1T?8FN9S&QaGg
zHs@y0;Cz*;(J}kpFzm`Y+|EoAW`DW5l;)Rp$p)5ko$iU6vXYaN{ebp^3(JJ}3b7i0
zgBc4jy>*|d+@-OjbC_n|ijM1V7&_x^G$YQJDixTti1jhr{36Z;OiLwx!X)Ug7_RsX
zRHlujv<e{Tvd}4f3G(5bWguGT_!m+a&23l#=%c18#39oJyCOlGtbg+&yNaXA)Io`E
zkz`pj_aHZU!(V;;1VS}IISo=vvaz{W-78I1hqqAdhoX~kW2qqBz8Ej7LXaKC61tDi
z*7TlraC*lWv<01xP<K4l>2>s7^QEAimGOs1cqN}r1{tR#I&gdG?m4bfet8f@Vp6s6
z<L<ack$BmVPH=JR1+{|sbe4l-dJRSPl!8?erGX>l?u|egUhdV*uvpJajBV<O^EJ5s
zlef)MHN0V23*7fhq>Da%u{PK;;ghMm9w|n4s+KZ}Vd(lAJ5`JEjqMD8$2YuMM}R>|
zj?sOom3CrBh$C6=?E-qm+ZL@gd^PO)OP4Yl$Z_}z&9jhxnjtrlnls_uv{Xpm3M{X%
zvH!3<tfC-uukwPWo3mhdXeY{MM^$Nl{Lk_TBc)i@U<nmaZfU;^H%Oc?0vlO3$!e&=
z?4*e}r;HM=0P1AGxOX3vS@+4xZuUvcC0Qp*yb$uLOHd@C_}P1%);9xR`F~z{V#PJY
zK7T)H%dP&jnFTA`N0Q%UT)$RHNUe@IKci7&V0eqK(BP#XA^lA7PJ0N+fG(-#t3{sz
z$qN1$c=~L%|3|%J*~0l2&&jtDHXHMt<(GN*!JO|$o;XH6I5e%?-8#<7&vCm+vbZ8J
z3D3~wKFK13%3oRRTFHBAmO{(A4%>Uz2wd!AdbT+;4ZTQOV|%jg+wOq@qSoDyi6}|g
z*D1?3wfEzE`OfgiyZD>GiFAH{>#){<vt~((oM-ul6BfoY4hY3K!bWz^_uOfrx&RtT
zS7s(|;^TQwnweLsv&Ql##{3pS2`ej<nSnTDZ|q$-6ZLVZQQ*B?noOeZkMF-7^(xsV
z<Q}!nKP;<|`yKwIb@C5Y`h6dM!ETRk8jeb;JzHP|t#!h9d)wA7jA%@n=Pyg&3~KIb
z5`k}_kS?tB0zOkcsSP)ks=A8B+%k`j5>xn6jx2bI`GdHngHpS)$_Kxz3RpSE?tWC<
zdV4xUwNtHePSAWk(9%G*)&iz=b!^BsyBZN_7}7PBg0?L~Lk*M|U@aSvx<(_MgNBL;
zZPQU@R$_gc!ay}3q+oTz{FA#bQv%VDuT@nC0P}DfuliBj7V)I9Tc<ostFIsR`C2rq
z@u??e5SMR;s$4giU8*dff)&GcdZ4se{`3zc_yX$@IH^RMJP9#0=zm(7so5jnr?F#o
z9uCX3urco@o{@jsIk}b1A{GxEE7_hhmTse;zpU_3cu0<+)^6RIn)b9HbarOg;e0d<
zRBX<i6l#=nR>Cf*hc_z|jWfQ?77=5TG0_{CfGHw9j<n>N&vW)hnruF?ya!l*jUx$s
z<ybPwnq$f|v2-{G{q60|rpw(=t)`B*DhUzi+{h9w)lIUCPghun)M$uY`lKgF+*E3R
zf^U&Z%i%7MBlLCHme($b3yDjDk>f(0C$;8pVCsF=OKptVZE$5=JNNO28h%43m&=Rq
zM^%*zzj+awYo2DLu-R*6YSht5*Lx36_67OS5sm8VZfMF0i>K7=nVvLD%Y+JI|Mf}Z
zG>jzZ|6%XF!<u}%bkQjGhJ}uZO7BWXnuwHufb<dq7FvJ==_O!npi-qvS0IEIqL2_e
zDuQ$*p-4hNO6Z~Y63_elX78CjXJ*cP-(1((*V*TqKgpFhd7tNfvRLb0_kFLzAsPW*
zq7<zFxto<A#gO2OY5vxAkWpyUeCDUFy^d(D;Jt)DAQnAA#Hkx%YZ8Zj=+TrtacQa9
zuHeF|)sZ={23$z6f0JHYsAb?czCN8Eoe&69c<L-+*M{K?!rI%-rC<vhi-c&=oDqEm
zxFfjpkt*7dw#(of)&XhZ-`HJ_ydtWw#0JeI*}GbWAI#{q%T}fvX<>K^7+oCs`8e0b
zmbqU#m=jjS8ah{-|5l!um<SfvJ}8Cm=&YahAqs6H74v*CX}HCU^m|(dIe?1%6!hL}
zKb*Jp<j(Dw!y+lq&3z|Clu@TLkTn+RVg4_?GIsJ8aZ=KYjIva7gZ@W&)6C==IIj<`
zg71J9W-xkDAk$V`-nY(Fh@OBqeU@vsWm>dmLr();EtdXT<=hcdT;3S>+QedB3xXb$
zFWbZS1$*VfYE^uyi2FR7y~XB(*sMHf%4|nQNw09KY-*m>tH04Tj;G7)$K3}?stnZ3
zMQh+ZPeNpNw;PqSZvhqEE7Ux7KW%}q`h)bh(*2(y<-c9}U-;|tbX4QyB>)nz{{z}|
z#$5smJZ~J6|DgIxgDrDMZ{IObih?SNJ7@+9KOLydSkwN^{rDJ@SjTZxh6pzLFY??!
zR7sw5ZO&Pl%Gp>s&Ww;~>ih$G&cC~7_y=UDSCR4u#N)UzhhZjkk2F;6eE1j8L78Sa
zwi#YBT+g86GSt3vqHg)Ofkb!AEKR?#Jkz{2oy_ACO0sKIV!BFxS}z!;^Aa1%9TP=S
z-%6Kz_IH3CY##grx>B@TuSwr`+=<^X&};*$EW`aKCcA3{YPtugqof<RH~6hF`;Ae5
zKsR>L{F6W_gk}P@->Hfw%{9Q4FOk!6KP0Y%%ya~{;(eG|+$w641ibeTDBN}|XJ-v~
ze-w_XuGbILj56bYK%E*zdOMn{FceVn{j1x^n*$26)D_eezeV1D&W?Ozr{<VdkSjA3
zs5Kt}Ral(qMhL27yK#-R*pz9qpY90w>XfL-0R<##=O$2Y|0w()>v-KS3e;>&BbhbU
zZOd$Kpt#fAe_sPsfqh{PIjc;W{ieAjR3fmp)ScJ+;yq`8{|h<Hdr;KMoCeNh2gS*J
z_}?4x-y8A&-ieSi*IyQn`Y?RD<FuEs|Cx_<L!*ZxPEb~5SJfMmz0oH$+)6a9nJ({|
z$oV@Tc{Q#6fE4}z$*B|Qkjaeo?C=m!#eYCEcN%aPnDmGpre5dIKcLX>D5!}s?#Sky
zzd{eoX@g~Yb`1M>#gEBe!YRSBTB`Ip&gi42;W}Tx@O6XRzTPrCi)XWEC*pCdH73cb
zo_WY$4FSbSFG5hGOrT?nb>fm3cs5L~aqPU!`V1b4?5IWRKTxFKx05sE<~4awqO@wm
z1zluh%Dgi#<PYMvH{v88O_aNfQ%ejOLP*1c6gK|yir3%sr*a_Gz9F{i_>F3TAUUJp
z)3<8x4xBD{Z|I^~QNnR~qHFD#cVlNO=t2Z<VZ!ugCbch97|=m;(!DDO5C{H-KTQ!i
z*W-Ro6LU0W6n0ftrKCI*(_yohHCSI=rrFaR$|3c5DOK(F0?7gTk5@muk&perBAILb
zrDZ{GG3^IMJQC6$^$MLEinB@}ir4m2ZV`BA5-hoWl$8aORm5~}QD$wSm6Ho)$#i^<
zwGTPSt~cSEBFtb`;CwW$TkWOS-e}^~4p&a1Ygdo4__TXsG8pU3^UecZ49VzOn8k&)
z#*DGL@^Q+GJT3ZKSw{?+aiwfu85mrs%ARe>xQe{p#c}mE_dRhA_EFxCzgiq+;UD11
z#$ZFRE_}pYTG}L7rzxdNLYh=(VV|EnIhmUPrx}O|acg);B~|b2q(VmTX25g^Y}Hwt
z>kL^<RtlKCxI=kOB**3P8sAj>l#^MD=#NgiIZ~8`H>bp6|9rT7*+;Ig@PL%m!16U@
zu=LBP>vTnuZ>ro#+mMu0AY838=U7k}o)>nngx=w=mdLfWwEEaZ;~wwpj=lHG`NH>A
z!lFAO6xbJLza=kDu;uq3%nIg(c~b62U(EnleN~l8NSw|r_RQ#2g-SUsCX=R$#JUH8
z?2Q(mSL~KBXU1tr?YJ9MR}ec)ef2O!s1fNUk^f4Ov{IvZ`1gxLMc&49*4_bi4w3D<
zFqg#I`gE^`$Ud}(t>8G-q^y#r&R6YM6HvR@o)~2CD=g_(n_~8EsL>G_#N$WTo_x&n
z_GbT9CB#mYO&wP9YE!8XrWr1=b4y81aAaCyG15goRYQuE1kA#!0utP%ge(Fph%{0f
zh;zx<N9d*JSecY5G2v>Ct#bLL!}vQ2fGD&_dvd3?N%WmS>+(qrFNtdb-{Qn0jmp5j
zS{pB?{ncrTQ*h+q79_UWHxN7`F2~$8HQlO37D+TE<CC`n`@C318=2&Y@$r-C%DGwQ
zZ8wJnbs~dH1f{ihesP57dfo)Z-UJIyV``NG&rUpbfRyZY(8@j1ds384AWZ`|qef1m
zr7PizIYTsu%?2FAuD>)?JRR~J<{x-A*T5N~;P$jTKdYJT{n>BdZBkZWjo(c8cqbIE
zN2426`(U`%Je*w;y!50k7@X2BSk5|gW0Q=ug~`4QD3t64L3j4kJ3L09zrbU>V99B6
zM;9GR%lL6EF(@7bc>y$RkBmHfPz0~$tynuOk@yS!2PAFhy@p52AREe&5JQ$gUsMn0
z@yRR&LlX_lr#0)9uLhYM<^94{*)wW6p2S$nUCG0*BK6|=Zm^U_E>$U`l8Tc-(eLTy
z2}T&PZ=r1z)1*tL-eFS6dE~-+jel1uG||*NCc9ffsuN9<$D;9G*!1Wir~0~q)IcK9
zdzf1Pc`bdIP0y^fW0HE8$DV&9;VtXbkZ)umnmY``K`AFnzy(ul*{B0;j)wa;%U@-w
z-0|MyL6?|}ZD%hI*La{utvaN}<^$4Oe&aLn1ix3#Prm8D((Bxj)i;gDW4hW}#|b`D
zMdCf<=}C?r2HqJ&=s31)a6`^8B|W!+ZG8WrSrjLgzl4Fm)cbkqZt&5%wT$2^V2+{v
zL^c!22)&!1UKz_azp+m1Lnu4E@0Lh7l|3gWI_l4k)SVjy%O@t&-Ox|BM7l)OGqdQ3
zvNq_*W<3s_y!26nklR#7je<n@>!ff$k1mA&Y%MR`Nsb`3vz&2?{{6B`)$U2rKxW^d
zNB%&A-8!)lx7f`m!pS+(-D9Gz))n&LZ@w@8o4Lxq+0p=ZZq#!Cq`*Tdb@!+TEsfi#
z&B>4**F8G_%F}2fj9H+$#R(Ysv->r^W?lZVs;i)(f_lsJ%&wIE2b15!&s1_aP(RX9
zgWvggxp1s<%p<6IhRlJ~m2SvB3^iDsvumgtvO6*L52w|K|7{-rf3$rMJI?Dm`FFzN
zSf#cXZ->Bx%Dx!Go0JcqzrA?!A@S$opbzI%Ee3%+`ut3w(k-Wz;UDzqBsE-ToowbU
zewX`UCEvRmhdlt1!ygbr50`>!F#QAKoav4vAKXJN$}nGu&!W!pkHt+!yN3eqyO;Kd
z)IFX4f+SCdtpF|_1d|2ZeD5dRrth!a%xh3AQL@kKNGNWv-g)!&hu@84ck|6&!<4S2
z62pLZM>H?2+Y%ms%#TG_nV)04ZkIc3(ZXBy`%78CLXU3VTyj_rv7AoW8lW)_G_R`G
zjIp#4Sl@DP5>uBUvw&+`-X~6_lYtk@KbqXAdOmUH*Zm)-7+b*t3irWZEi>rR7-cD$
zQs)kOJ$ax5y8bA+kH+JXZg3+R=M}32-5*FrP~BrmtXwmz)MlTpl+Ahho8272xo-zl
zZi_;>zuHe<2`@jSVD|D=min-BM?vvsjid5jn-|>k9^mFyS%c_7inKEg9Om8U4)hsn
z=3d^uNZxvUKzdM=()HEj+)o1EKDMI4KY!Jlim!V~{8(ffT5LR9y^3}%YqMRTB8F>6
zXuZ~3Nso)4OnVWbM2{5G6s5CfM1*u+zh$@cv=4_F;^ARM5s-f1{;T+ByvNo2iz>=J
zTyw*CM>-nP!}}Ti64Z{yf)YnrBo=A(IYKofqt@+e&Vfa_36GwzuI>+)Q~SQFi9h5Q
z$dm4*5gHt0w2P|`JVLhb7^57>l%?)yR>x-8kr@-Q!3g+7<is0jL5!JsG?Nhp`lk!!
z$#nNFVa7m5AfkP43H?=mP_`c`v0fWsa6q*(4EX+OP@Z90X+wk16lr@8(^bxOH3vTA
zj-`DmTg-UQ-E|o&ys(gNVw7PG-XRn(64?70{$WrYHYIMcrm;xY{Q^`=aNsQ8P*g~G
z?A@#FX`MP>#batuQ5(iIZxkl?1&`x`*7R}{1_qF}1dj!KPkNh(hhYlTKA?VJ3p_&2
zwi`VkdN;KL&BwwScd`nwfX6ec-$EY3nO0vT0N13zCpWtgdECAVG7-ZRb(P9J#?LO|
z6|2GTl-Sy;lE&&lbrypaq3jQ4LsOM;rWCb#!I}uz!*{GB-|r~ed>^uU@WDItR4N}$
zk$x1P08{AQ5k5(2_ee3x3)u;q>*-C=9J@~1AM@Dka8zr3cp-QtIKuLa+Y2w+)ZyD=
zF--yj=}DP{NVsjiLNDTgJ!^!*Mu}@Kpw6zqx7L?_>Z|FY?Rz%$y`-F~hOOHT-=rHg
z36_1K6G7*6Wp9Lug4=v`6tPGwcJwE&X+TPxhq{7O@4VH;;fy2IL=QsugG;(DT-+*e
z6jz?NwXc5^CMQ{vXxLPv1HWTCb|$);CWgCQyLvJBEceZ@TLVE|&G-m)^u#eUwhAtg
z52+ZW{mK3?>%(;Ks3dk9oIi0(I8~0ptyt|ynI+8`-9cpHVKRobdyV5U^>lKPNTix6
zYxwV&5fy2Kw9|Pi<c^#mDLyOj(|r{e6^iP`+p@sWCS{4Xf;}OweKW6IYe$q51>@G-
zZQN@GrFuD~TJ6dVwDteo*D9iM#}YAoS41DL-R%iHvXabAt4{Pvu{iuA@Q{{ZtX!UH
zGy;t!5wP_eCaz^U3Lft=Gm|W!=>dTaL^}wwc6O$#7K*x8FIhPlK$eG1RmBEnmO334
zd{7$j@d)4a=@;jM3t`PF@+9M~`io&1GwUJ2Z0T?v_mMUPBd>hE>^U4aOZ*J>g$Kgr
zZya_`P#O1&27zU7eYOA{20v0h@{=5CY|u87(W^vA?ZVYvG7J6OzX>^Lj$;_A-3i_H
z4g`>p=}wbTdLXOF)WLMeT4+XtLx^d6U$x{;0=&dMDKKE91BdwNkMJmipr589+8jM9
z(+vaK?{5Q%aT@$%Jw72&$V#CqJnN0%`SU7|0PE3XT1NstiU@VFQ3#6!tEJiLPl|c@
zS?K{4WQUOkUD`DOsyfuUUBOf%GaCR0rJv0~!8ywS6~qySnswXs8J#d>)&sO4k}Y*`
zkYE09X~2IK&-x$N{k`?$e?~<3=YR13n>-uNbeY@Wd-E<r8@i@F-9Bd9LdsfmZ<7rE
zfEIE;FGb%!cB5)w1MwhMU3_>Q`FxsoW8=K;{23Llufgbt30K$!*bb!vlL4Tku+;n5
zjf1Z5Ddb|2G_O-&0o^^*6y=9T(ciC~xlP^5C^^r1Zh7k~O|L1S+=D0UN4%hEg49De
zwPH0n?dz}Gt*X{Rnj`GvE~ASIfY0O~5K&;TLvs|so1)fT$%;91j{%qvwSK|caQg}1
ztBw+UY(9~?oio)o|M)5Z+i6^15v=haja(Fp2<B;ld?0m1j9{Luy>iO>e(Ws$0{$q4
z^N^ON$7@RgExlyl)gg%zIFOg0jyXdXAwOCHSFh1|+#T@W9to})yq5lu3E;3_Tt$NI
z8<hA6_5=q$vZ(_(5pYAVFWql|`2Aw7k{CY{<cxWi@ttR+LinR_9t<Y*UG;H<-iwh{
zIS$?+vA0PVh@wr1ak)f0b9ecNei@sD9LXBwYzx?JP+@D{8UCgy*eX?uv}s{2ALtcd
zq`QmhfY(4reT`X<Q@X~7c&3`2$P9ed^-9@q4m9XxQ48q;x$7cY33DnFSg1;aT|X}Y
zZ2i&%1{tDN?f42656w>A9j`7V8?5(p(-775dF81A6Jn}{$Tijad+Mm$HLT+wJz&xu
zt)BM|i}GJ;`-E?iDtYS|ENqk!J8tM>^xzMOHg>M$0@B}fGiiYVXc>AuWCSoK9^9xt
zb&Jt0tPtBM(pIRxH1$q1?%9Ghgsctwe2};&7Tz-N*}VB2&#Ed>(eoAIxb+%$|7O1m
zayvh#w!J<pJ9RTgL$|RiwTbM2Z4fOedYIv`C0}2VP8|}i-mhNrm<>~l)rFjO>1o=1
z`d(64aU9w5E=yMZ&iF-P)Kw{Lug+b+N1^1nq<!qr$A)07uK5MAAx5ye2)AL-kZ3Io
zXQWP>tmd;kx>&PH&V2z0MXkuSKG1{)Vn{7`xp|{IEq}HqJh?-tfhdx5Ic2f<>cd*3
z_=_kO4wb9#E2_0G3_49PU|>Q4PdU7n0vkD5?LHEfn&tqOI>VEIu@Yx)UXQY}LYz}f
zG|)Voyn|hK^#3@#uY>nGfiA25(9Cw}w&17L>y|NBR6mT^Slm8z(;l8|sVDeZy~{^0
zJ)d@rYB^p+tA8vye^PoNGRdnfv*dA6;kPTj`N`Z!N8t>5I?SufZ=Zn7jv7-x8LEVa
zz?xDbZcZs}p}n%LdiKoZE@b~=N85^Zt%i#C#+d|&cNjAy8WlTX1$n{yJ_xh99dwEH
zyjR3Q!VPK3GS=u1wHNf^g9a&b(k-jsBYxk|7FK*M@GgJ)@&tR9QU}ig1=F6LT9Gn}
zdu*3ptT=0y_Y_P9D-9{-uBqMekP7$%f)M)<etU0(Uz$hS4vZQ^D1U$C$qCv1H4LQ(
zKWTqFS?wv>W6Ym&Iek{NTY4#ll<5%5D>}kl>xT!>%ao%CraBIkZ-5T=v`+)PuM+>5
z>g*wNZ#nhVM`R3Q?SA?7arm7DNQWRq=tj*u9txNZ&RYK^LH1CO<ZZ6WMEbXH7e<G=
zz#=ertm_=U!fI46z|ZULQ~=%JrBO+<JmF~(8tGnIsh06&z?(8^t1vh6Ygjp(_t-7J
z^S51+`2^NvCM2Y$*j}8z3qoig>0WGGGtSaChxH|M_BZJ_t0<f`tBgylU7$_&cA-^t
z`b>se@LstYjp})v>PjKXXhf7we#7NumjWPT^|IP*M<SnJ%kqN+yixOXI!e%=vYpgx
zQBtH2f4Onh$zFuFB_HngV+{UnR>I(N39TRMu@ZvMw1}>DJqfK=^%d$VMdy<P+`CBu
z6|p7Nvm+ejOLtb(_vL1NUIzL&S2V=-pRK#eWm9wT;c?rD5Bk!QD*S<5`V@Mf)g?zF
zx)`d2a8vm))Qpk^L!}a^E-4$<OJV5hJW&#XfG4^8gk^YH*Ah02lt@8K#tode0%|e0
zy_`tS$@!ILENyHnZ-#$lmtW<!oCE*9c+-}gT9M(?DEWI#nBWbFdjsmpJ5rb6FohnY
zuaGq3OV+&_x{J8p+L?pE0F&;;1=kghA{5qU)-F7<Bi}*$X6@U&1mx@2PKIp4dQz+6
zA6AnNhs694THU+lFVLCk+}6QfGPT*8Nu4Vr4C=s@E~cv6oh`@|30BHAo%D`upeXKd
z4C)jlF;Ds}+n<MR-ccQl9WZRYa{?i4$pw~|RXKglGvSU(YfCft7wlY@_%e!J)FL|5
zstA1y2hT9Vgl!?;lcN0QWFkuQ%x)(3mUQneCPorn(i_r~uKh$0B5(*lsCd}L{`IIR
z#mFGDpTqWTiCpK4D0hG!#N)xd3(d}|Em_7eUonHkX!Ba*i)KmK%`j@S9vo3NjLnx~
zh@!7J=t&2wS36&^<Xw_59P#Ra=J}J#{LdPo&JFR&nG&E^UsYuz1N4bf#N=eP9Le~c
zo116e<p~aI<4bxjbS60)mmBPkcpLXr76}rQ*9|(SVJ&f=D||NlCK-feux55b?F_a7
z!|nQ@W*|{I4KsVGqqqYlp;vs`Pyf+r|Ek2`tcgcOX0KVYWxX>Cp?W73r1ig@Pr{)|
zQ~ff;8t4)qJ4vaSRP@$7PE&p=$*QsjEIitTs~^I+kP?Z5r%r&b82L6{A9yQLg+C+8
zlD6WyAB;H&)dHOFBA3@Rf9o+DfbJ2gcY)s6l6nwQ^aqq*LBy45xcx)jw121U|0|>U
zKht9QxI`ef2PyZ<Ewa3eTSB4lSq8*q5d%9G{9}JPCSpWw_Im4?LxF}ruaccSFfKLq
z?;aTzeIi{r=mQ;zkkS8WVLU14{N@+~$ThozYMEL}nj1i4&&6&<&TESY80ZBMhT`Yx
zIZH{X=3QADX7~Lc(6Hmd5la&DvSt&18&}^pohh<Y9`dUdcm(HeGWoUxbX`48oK}(i
zaYh#0rl#ZzjbgXEC7y8T?eav^Thh04>hGDs2-Fokljz8Ns(+4B_3U3B-WkKuv$K?#
zg<DyDCl&fXe3#Xjps&?lldE`wuxw8;Z;v;Y`r7tGPcU~BA~8!}QKbwT_h^B|(A@5c
zaOu>5#<Gs5Eq_a#L4!K+2FhnjPh5?D!FuF;$ctN%DTzkv=Di;a$Thv#SXG1V;IV^?
zOM7=(+Lg<+gdF{%&u16N2RcQsJu|gtdH%fF6C+w?LBo2fhAiQr{&Oy4+`uG)zy;h4
zp6p)`XIV5f;0z?_|5F*Ckw3GUe)-ryi>C1PC1G0ks9LmbH#DvKk+IzKpCHl3S}wm=
z7LRIm96EXeOZu#~&>9tqNjbr)5<8xi<?@AGfUN3rPn70Fm*)I9>%kf8*J*!1hc!1g
zQ<*7ou2M|-#`%7e1EH+?Fz+?3f6JBrUzFK@Uj=aJzshtzd>UDZ=p)p<6)$0X6kW=K
zJCk2@RW|!nww^cGJt?INsu2S%!Sq8F=H7c!kk~=XLC3^<+3)|IyE>laFa$^lKWk4J
z9)q78J-y%^{_eLT>+z2h@&CTbbuK0X0spe6h$)m1o#^ri?vLAh1o8Qfs+tLF2As-2
zcx{9UFf~6IZXdT@NKSFyLMpjR-a-|oTZ<^aIt8MU35HMy8I5+!bhTt56Y-`OWtcOu
zm<YX7?Lk-XAKm@O`tko9L3kEF7X@Ck)Dld52AWJT0Uc@+L4&+=+%j4~=n}9;er80K
z+2izOKM6#T8}KuI{#J;8PO<3H`E!-s-FzBsl?0s#u86+7Ao1tF4(()5PG%c{Z2s24
zpH_nc+~$m&U7(3xAr+KH+>1di{{b;tH&%PL+BL@yxDo#eEccJm8hkYXf4?|+fUN#T
zbN!~n71#a0_~{hKT|4zm;x-U;ah96vDFGWBKf3;%hxw0v*I$_7-y@#55o(H|&80)T
zvU6mH77N~#`Z$&G#wy83R5=HpvsSqr`3-MB)^TM89tbWN?1Fma4b2P@#6-a=aMxA1
zd`{cY7TL&z>*uSdmn-``OC=|J2{WZ?)3L#m*&{X+BL1DS$2=RQp4}+kvwm0pphR=H
zKbg1XW>Ro2Q{27hcUah9ex+AxtKZlj#bIz{s_wA@esagNpa$8_kP5c1A$V9hNUuo8
zjZsezg=b9?2RSM?_oAotVx5ydR|WVVe$@W#*5d8c7cr3|_QUIi`PBt=41@uKwNVk<
z*GpS?e3X-?pEvYVbbe){Y~h3uyxQ#Pc<+{Coyo*mk8dgO6b`zhjxJ!uf`(*h_a1vC
z(<LEvk)@MYbZk~F#JB{<R8|$(U3O%IusdZ8#9M{jDcG7w4b?_F4U8vE8ORvgjch3e
zWH_E(AGL};YuIA9SkDn2mj7M~g%^tF5#xCfr*?0~%KQp9_6@W>Z+iI25Q{>dna!JT
z9Q0)FZZXEPh=vDZJTolA&evBlB_+q-EF*a*&*}m^7(dn#mPFWmyIyWRuvuriVz#7R
zf6J^g=V)`jDQ}vz)y71MYYa565)wp9wpLS{bbZ3L16H~9wz{4Fh|_p3Qw4%$vSTN3
z&;TiO{Nt__u*3XVELH;dmga#mQj(Y(<-}baXqoGl@KDCVN37B}5czL9F2`J=Hg8(U
z)Ugk9e=#eqeX){}nJGM8dH+>z)=oZ}cZSKwUt3}~pX>Ji&PpxK=qtfPw|&k8SC>Vy
z_JG?3{3HzGHjGS~wnESZJjye2RYw(J79^-YDQ$UX#5Pv{l~8DNe60PmG;=$c0a{OL
zLJLf&&ymQqTSSL(6t^iMb2Y@Ja61R=h`15=izY~FTD@7n+d#qA>rkU{{!40h$>{o|
z5P7ofA;E-$Pv2u($!DHU`sBY72t?>!c_W4_Bc#gPWBKg8IL333wNjdCN^nmL)2Jjd
zS`}Dl6y}aY3>fcjB5SWNeJ`O#!8J~M1oQlI=NuSF=zQ(b%vKs$PFzmlM1*k-7;BKw
z;<5qJ`8%m=woq;62r8_UY?M2`bIq!lC@)s6yC)J<vY+@g&eA1OB}}i$>gl0Ad`Zmd
zPNEXA2<FS0A^Fz(awIjYpVr{kI(*{Gk(bZy%mYe`WM25qwf)F_66x(xToE!~nJyyn
zy?@pqZ+lGC4(cdZ5k*J^ELb-P3<R=?d39j_W&zFJTiaD5&Z`g_+-_%Cw^OEAaqSPt
zJY4d|Ih(Z&F4G*LGcts2K4l%{MVy!fKrX}O(jb;45R2F9?sGXU7~!4DfM{qk!C|g`
z6f(1Jg3qx`VP(%JdP8`<7KSjyG>zWP<mUnMZ?C5v;g+e2zT1Tt9XY4tsPs8Sgd!7?
zB@OdgnBc+cc=X#DQ7BX^yd04b!9T<>LnowyZv}c8r+C|qmZerGGc+fhh)VC$j;0Pt
zyVx{zan<g5iZk%~t7><8H<vpLhps+5=cAjHk(p;~g$Mw*Y(^o)d~FFRe*#l5{io%{
zSI){bQQ?Dm2e20cGDIjg>8;Ibj(fYWJ<glv+RIpoNP`Cq;5J_;*>}*ZY@Om<1a2Q{
zwLY@aGSO@#Jk8_p>THauOW0159+YcH?VY8=vBDMx=lsT2zS@qC`4V=l9f};`=46Y{
zp%R7L1zYC*d9pSg?D$o^N~`MYDtC=0B|%R<A%3~^bnA}SjemZb+K*NlYH%;XHFIkj
zp$75Q_37I<1bhgsb7H{M+LWG8A^%RMcrddSRvc*!l(WmJZwpB4F~XBgaIb<9dwa<6
zoBg#(gEfPz{=qKq-i+v6H@Q)H`Y>9T&95>~^p5dQKl7Ii(H}X<TXoVOQiyhyuFACo
z$Zqzqy|BUtOEIa^3E_<LepS(e48cC8$S{oZppT+_L1sztwF&IVSB??2IQ;O=Q>R$&
z=i>3#KbzgmCcMmuM4z-%5ZATjBjc}E+dm@J`nsDAY;NJ4U9uxj*2F-+Wkkyp=t@sr
zGRh~7RQ-WjE&kdD+eJn0mDW+NM+qATISCy?#n6MS+~msI_f9%B8hR_mFKjM$e9NRJ
zdYeZQibaj;A0_1p7gYPx>+J2^SGEauqNWD+<$-lVqG%^-lwraWt+6hjP_gaj8l3OG
z+d{}couT4aw6xDCeXOMEY;go(c1{HREtB!2O3>+XVujTvJXFTEeu+PX2{@i^2a@(X
za^<YH$n}HYDq*uLnBqN%A2DsjjI;3mjlZggzgNG<lG9hG&OX@)uM8+}{Bn5e^06n4
z{vvly+26h8`R-z#2BhW36A%`LGla?7c<5JdUF7@Jb7iS~_{vwl>PP@V)L6~>alAb^
zi37xE^v?<C-=6^<I@;f-cvHQ(sr3GLG;KKC^1dus<Qb5=8;c69z%DrmXrmAFNVpz#
zSh`$F6n|oMZiRZ8b8PY0&GVpzFQ;xOv-~r|@QmXHJHs%Hi5H@l9)F|coopaW{~H#J
zk3>hOn8}6k65YtD%sjUebfDiBATi61Jyt6E2-aWBIML1+s&(5H93774!YRCuH{VlI
zwK#K7cIC;<SqFLd$7AgLMV<+Oc`3RV@_Ei6<&>Gv?i8c(x5eB6SYxylK*9l9pD<9F
zoN9!}0gg=k`&DS>UF2oXgJUTAshlZ(uL0ByK<rBdK-TapRDM8Esk!5Axc~Ck@5UM6
zQc(ajzp?kU0(iY=KjZbj=;p6Kpxr}&zBAHs^2(2+K+`&B=MHA)HFYCr_ZVt&SaVFT
z@(1v>tW0||ASv5ame~bpf$i*?o&WlF)GIZa&rqx5sXNC%e?|RtW!^7hKHNNTWj@c@
zQDWUTWqkevT4w=hjBJgq>anMpFEv-gP1ab6^P20x=e1R#zQz5^g0vQ%IIaV$ND@cA
z4{Njq*6GSLYGSe>Jy8cBVCYP<%qr{S7r@Is`yb8sn;5%22P~Sa2>#_fDsV_<jsuJh
zG1R;N-j)A@cE!aCJzm1NilKU*IeG0%eA%To^FJUX;S29`d%SLv)eHZFbD9n-^0+AK
zN7j}AX>q<guQhr8_SYjmC;o$Tp!)x}lOnevIG|udI`(PR!jLz0@1D%F=#x9Tqtn|w
z6W_J@qM~7jCtIt>L}a`StV|QUj5OuSUVa^O7B6A%-VtHve{6QE4H9N@7gwpF|37gE
zmYD75#Wc4NzOId^9i<Cg0UCXwUfF_P$^A)mn^>(DpBqm+vhkT>)jC5ZPu(_U+vQi3
zYy3QZq+gt_skO!n4t$0!0`m-+%`2J*$5E>p0HvbYDl{22y~G4xYNS5UoH-5rI>iA7
z4eHT$4)bN>juGJxXuNQ;1Q3^^R`p+3enI`@WZGK-!RB9mh-sTO^C>{gj%S4f0@x2S
z`&A`Ot%Im>)b2STA}9iM?Z~_Y+&-Y(ZM%Mj3PiNqjyvAg`!Dx6f!Rgtd_c^C1BzL8
zJt4;(KxLb7SG|&j`K)nu9Jh0PQ|2uYHB^CkLj}gS#~L)QZT$fWzCn5(KRAS<H#@Gf
zE;wESVj$266{~FAx4isM%Q?UKi*@(#U!k*clK)qO2yj<ROmjGDyI2KSU(e`%!ZpSx
z{&gUxrm~}2H9v=%0MT`Hzku=wv|`}{EHI~WM^O8}x8%RK<o}DOByup_>n-DI0*cW!
zVu9F0RbX`kiacFKxLf32#u=pY6e%$j9osJHTYNG0e%*)d62xsp)<AzT)UKg4it;E9
zP^C1rpCz>qt%0Eqggb@1prd|fi2Kp#TD_=P^eL`%JWS$_oVz$<D5P?9q&v1!?f2ge
zLm$$%Am{Zngv!&h1hP)a={8?xq1pIpKIeNQ5DCm@wPU!a!-g;%`RP0P7S8QUPV4SH
zmM-b2mnvcWU#xh{yX4DhbC-s{!LvPvI!PyZm+qDxK6)qkx2yWubK>`tMet0K{u$C>
zo4OQz$i~dwG@TqjB9ZUtSIf*U+u3Y9Qwo0&NoLr+`UHV$`JXbpb?f`U-liVU`%m#o
z?*ogUb%pOls8sEhT|%seFN`eC-K<zOkVuvg3J_kzuq9YtA14ht*mvQU980Q8##xWp
z1w|~XYhmgtsw3rC(_B@;v#(R@h^jV8!{D8O#BA`Fme9yWI|^7#m$`tYg}|yqmy)%O
zcoPEp6%*iLqXPvVp>ky7EHCsAg-MCWsy%RdUvc|8Bn}sgcY4pNA4eA<_A0uRc&iK;
z2Irrc*(q@&&~OE?)Wu#Q!eSD($1goIDLn)&S|VICI~@i=Qb>-Ww+OZI(%0+yN*C{%
zHc2%ThGHS{7sGX{;L(Eb&Xuu)MY4Zg4x2TQY6h<<H&c`-vwmdyU;vd3Zwk|Z4Aqn1
zZ8*bv4Mu`W4&Szkc};bB4OyVB1_^N?!mt~n3uSKwLrL=Q%5OY4>3fBHsM_+BTxL=h
zxG$2Z_Nac)twcptdC7y|l!afkx3^R#BlgR^Myx~f%W}dbse=OxGj%Fs5{)88wS&_M
za6`jAEi*yuBlc%AgaeF7<$BMnZGkB|RbSOPz-tnUv&BB7-jFq@bQVV~g#mp}tLo;}
z>Wd!Fs7sY@-*aCa1w4%|+J-8BB71Snk;a)P%)HcWh1xitx&*qmQ8N+Kyem}Rpu&Rs
z<OFzOk!X?XYLN(^hFM5$JtWZC*nz|tQjwn=hy~`&ZouGP5_}HCTuM*`$w=cstyPHS
z>ctaR>9#gLrTK?X>|TDMm8N4nSOcRe<eAj$jTYC0oRfVL2(?T{%I|8<%?_2wr**kC
zvM%^V0mgsXTc*|F24A)YkD;#KXgU$mcRIdBU+~=fDSTXQK!ccsissw0L1y;63;8Xw
zP0tPE&z|qqO9f`mWX~$RZ#;$XxsfI<L$3@@53E4u0FFMc(zat3_WQqPny#Li&YU(r
zmGHvaJ>B3kWp&6_VH!#7tz578oIf=+$>dZV&h$eZ$jmy`<fjm=1<OeUBkS)XR(<ft
zpDXZ{>D_{BDXvx4iP!I(KN@rD%z{^%&v6wYOJ$lxktMPp){+siX<)y&Iy6Tihpkr@
z!}W&9Xu_?8^pwH6V9S)bfqV7&L5D}RYYd}!X$H#IUBsL>u>%ioT*V}`8uwPkr?z^Y
z_mR+d;3Y~)EqS0z8yHfvuKs>gCK<Ug6t83mgm!Qcnn8Gj-u8ar<*<7?YELKqp|=#F
zzActwt9?v*g&~;o;AGSD+2`iQ;>p#B3C^JAd9M0(D2|NCa8qgPGg1|vXrII<T6tK{
zjAE%Fm0hP%N9`!?BoC`K+PAgO!Po>(yLS2+<YW}W_L*vg<DoBC&n4v@<?2pvl-yZI
zId_d1t7n8k*U26>nbixlL<8}8-M#>$&B_!ja#v-m+6BzlkHm<!6hlQ@PTz8Fy)*&C
zsvA1@TNz2J%3oU5rZDWLy0R3tl-Xsw(GaU-tRIC$7bBQirmVpU<Pj^6dh9exwi`Qk
z`m94cpZcqmS=UcgFk(vVf!p9Cys_L1&RA`hzUXJ#>6?k0Sc1BLY`WpNL!6P?o0ps3
zljYt4H7P_7OOb>5`KOF6X9((eSdK}m5wo}7=~5L6ul`fXbi%8HZNx_WwU@ZoaVfHQ
zd%~1y422G-xzTnFYanF}0R~+fwko#nSQk8GE>*9LsUOkvC8Z`T>K6p+_?_G>EnEYM
zh8kXN3GApiY6B`ge6|TEn6No%N|L8{wO1wvHr|@cS{z76|FW)4$}TfCtsN1AcTgxp
z^LZYG+NViv)Y~5(0*##DT)=W<gY_Vo$b2q@jAQDQ14w(++S>`-4woLYzOgO4!%;F!
z6lf2z<0Qu#!x?4qE)k}L-Y?=!!~C6rM-Hp79co{yUCw6T@1O~x=pUto`hgZ*L6*Z5
z4K<BXx^T{E?H%Xsb2TR?s$*QjQ}l<AS>NHdHMv@H=EaE_t*;+Wy8YGq{Aa?}|4f1Z
z!xtqS9JDdtwv?nlYhO$WeEjSKDifq40y?Y@+y~^B(Ksw&&s;aMU6|FwY2s*_vDp*@
z*?NwL*Ejj~>v!DC*FcQ_^c()oy&U4!eo=bp$b*-yS2vD?+&?bP<k~yU?FWv{oJ_e9
zz9u=G4NO987ZBX=aDCphBIozv80#f)0blz1vDR}(`<yzQMi`>^Hvz)~nEp@xWaq>p
z(A;>kh?d~JvS``Te0G7p3-9!*J{<q~Z<`pw)6I@M90+D5fDf3T^?9TjE|bbkiu=&k
zI9h}nHaSp|!<N15`8PNGA8y{?-g$=M%2Y$3=3h1LN)-z&H|p*1v1vw`?0W-^?Rdv8
z{Hrp*P=hrnyL8Q_xDOSYTkU^98!K61ephY-r{KTN&=W{^W8}dKoMV;yDr(;q7w1WK
z{y1a-0t-GnE}ZyR4iY>gpAlfdSV)<OAFw?4O7_!HoAX*noX+bVxzH-`LOk6&z`e_j
zOp`S?g1Ton6`lDv5Aq+jJ5t`kSMRGW1?OE$IR0ph1N5xaL`tea-=;uBXk1WRrR`ui
zzx4~>vD9LS2gkg>8+F3-<vYvx)QH%-4|r70FVFmz%|7wr>_4*oSS0dX)@d44Ig%@4
zI$-AbnqVdfB=i=bpq>IvOG&y63LEK}X|r9pfizT_%MYVQCC|7nvFTm^<>RYy?*X6l
ze*tg%3z<6vioT-t;hdStDRdq;-WGB%`K^n7pL+hQ$wZ-#*MOcu4~v!rfBm(~_gPS5
z*Q!VjP#@Nc4?xXSrDWt5HmQ2Il2$P-l9d137_jLsd=a$x*!H7yf)cm2?wL|n{|EX4
z!#tpr|J#pPZEYO4AEktXpbo?$s&DdtOYHz`iS>RujV|>yE{ZTS(gp^#ro;bQ(J>*+
z8&90{<foX{bYbTvvHP7lq1QBnJ_3*ZwhOfN^!*Tp8<sP@vEtqb!=ykXRk2WMFuaT0
zF9K8LP%v_!>P8#-QME6NKTml)Q>?C<4O-OIIc5{8U~gZab%KV43<*sE^)4<~M(dV+
zOXA%?!N@X9eDZ@6%4(~uPu)~7$BoS}3NW220zd=7uL*s4_Mb;27F7Tdi{s7N9g|^3
zxxWpS>1FEau#S`efG(rf^R1VU??-L&Z!G2v6vQo0%t-betTrBmx;jFSzx#Wek7}dM
zjTb&H7nHc>*VlG?1*F6~dZpk*Qqb0qgR$?LQ+*!5zY0}F`fMhLMU0+m+(IK^l+D_;
z0HYGsq+qdI2buWQNMpOLie7&tp_(=qum-g=I*QM}OKQHZC$qm6aEE<+n*NA4HmInG
zQ`z8V031SWpSKJvBS5hCX9?Ub=GKug0!^g2g1n^mqiF>Ky9Nk1KK;m>fBW#N?F-4z
zP(fFZdx>{f>bj~Qr|4uhKWTVCkC-aL3eH+3voA2%#mw!Lb;NvDsWh;!!71;WDZ?~X
zU7<TN6thiS_L{eO$QpRH+E=8ka*7_}Lle33(C@(4h8(K!Fv#h}>J+2&QCt@|X?!f6
zHS1bce176oThbBkwwqUy$!2rtTLx|2MoRFDn`Y_mN;GBK-pFdNPh-$Gj>!_!k)P%X
z)&p}Gi2<tZ40dtLRjXufHzMI0F=6f}%|Oso4>K~X8cxLvWf8t7<a_j_Jt37xi00ma
zDD;TQQzFW4Ou2WBS|!3^#+qj=cdDt0Mn1N)Y^9laV=LoX$XyC}-z$L8(Vk$W;ZYVc
z;n+uL#Y<4d%vwi!#5;KPB;P=<R<-)uGCIEVC`#~-5xIsxiCPkfOS!oRL-&*KW>?l=
zq&yj7Lh^aQXeZ+?uqXyCwk8vzkauh#6;J1r#<2}UlAu&0DW2NizB*`-3_^ZSs&G?`
zD?uCM&RHV4sw;TvXxibC8z(x{5>+{r?+H)$WD#z?bC^rY<C+il!G)|5#rq3ObQUH_
z#$u!5ae}V3kxA(=TSXEcQd<+1Qf}x*tHqPYyUg#Ok;;92FJ;siGMm>BY0FiCFQJQ<
zR$_T{AHr9w9tGkSQ;&O_8J{n)QgqJ|&VnRs!b*(WN>+tjgT>sj4_;ZIjWdZwV$#m#
z_tV1{`l-o%q#C?^;8abg$%X1VG68-^^l2E++)AXLtRY8#1lUqeRY34rS%1(F+3O--
zOR<q@(HpXjX~CX~L$1NadJ=xAm{6A3t2i#!AH#(sIC!rb=^CbaZbTUt2h<Y`)XQFb
zmySwu5?y-Xi{_m-1brocN|bHC&L))`|7N#6KE!A-lqI&aZ+iRD#eD<4N%K10=|;9A
zE8AEJOzu|LbVrVCx>-0WAY?vhXdYcU5|`55M(AV&W{l@;(o76V!c*OhMW-y;J6)SW
z+InZ+Usb!;Q$68XngM!X{Y1H0tS=#@n5~)=f)O#hU{qH3wz3vngorOe$Wvou&7*lC
zg;jlt6|-IKdH$|0q>xNZ6#U`xI(caJP09dqSGRx+`Tp_RMXigTS&!_m>uYn-l65yI
zyh7HO$^BLZqqSV7>5lCOL;<2(n`%{wi0GOZa@~A;d5z*gjc=TalgP?>YAeNCYhYDl
z$9E;Qc<z?TrW5C=Yx>~*yAg6{d~^gazB%*x^{8aYt@1oEf148zcwNpN&of)BH!$1I
z!6(^Kmf>B>m6To#XXmCj3@X?2!XR2)d(7Y@rXKCq0xpq>0_#$Q(-B>2;VW#}mzn*+
z0uc}#<Fwm_kFj(sSlQKQ0&Scbfg+22&&&>`9SOR-cBT574DF7Do_PPqiUeZ`ia}_}
zNZ?kEj6!9cyyavKoo&v*Yb=J##1GxkCEB9a-MdhoZdIFT+{OX<!CCWYSbdl^knR4-
z>uH`cc)FbY=Wi+9#25CdFv}Dh+NY0eob4y^!}YDWu<p!jfzC2+3?!mHD-&IlWCt#C
z8*j5EF0OX9N!bTqpBi<^Pc(GNC)6YlbQk(l;nJ&yX$wtJVo-+>?g=+%3&BE~&(v+}
zfVP)kdTUC!GH+V8*U~Yj1?z<LUII=rH5BKe+7alVJ4K2#D=~uTNhmjlbP+nRsj|lV
z9Vto>g)kL{F0$_@z70pAY<1O;!L&0ozv4gsqBf5`R`XiJW0MjW@mF2dlR2e@GbJ0N
z6#TF-pT3I7exdfvU`NHR8i2U2(A1YuUmqEO*m7X>WhDk8r00`o{(v%!qHydERNjoU
z@3M?!uD$40tcuk~Jaxl3uPNP#mCx)V^l?02`E()r>hM8kKw{>YIo?vW+st6kAn~;n
zb!#dwU>yk-RRNDC4iz=!C8k#8A?@bMVutLlY-My*uQc!De1&uP-=~<XNr1=%Zp!SK
zrvb;@QN_*XR<ZL=Rg~Mo`e!U38dVh+Ddtn7&0wp(K1IF?FjWx=Q8Zp9scgdjt>I8x
zKFK;IMohUV^dwD3F>x!yogo3qAm_y|UbSW8%GPf>bUnc|&4;DTA|Zb))hGKz>pY}e
zt;{saxC<>*OuoB62<^POm?tKTa~bIAa-e8rgvMU_DkiD4``x@th^&X?S`(6}dI`Vu
z;E1J;rR1IB!c$e3GZVA;e>*aB25Uozt|tmck%D-zgq@g<U>R-&j#+k_!5i$a!le9a
zk(DEiO6t?sR#*R#Ht7FIl3CLF*58gL&4p;`FP*sJY4Tmkz5b#-OZk1}$T2OyF?%p)
zD@bOB(s!%Vvz3SYqpAoo>1fKyn^_5>f<7vGX1%RdK|@I|Z}Y7GogGj>BKeT~5m}OY
zLHpujAmSN7O#Tfz`RFz%;V8(rQqg?gTo_&SF;X-mEGxr5ZjZ>x^08VVDK43CoJ9`d
z51O0#e@^cIvr>v)uv~hhb?}x&T!FoQpvvoGCwW0G5UWn9OrM$0?O;KJlfusgn8Wp?
zpaJ+A7mxwgDkRu^KA3&bWCGgwk;4<0R=}bRnps$aZ*ZlIlkR47a$Co|EZUV#5Ix-g
zzhtM!vqJ%JJ>F$$-s=wtePd8qVB2g5HLJgSCgWf?^#EuGkbQ4aX4IDdmTIjz^3E!5
zesO<N^<p|?|HC`y2YQ`VbSIPgI`8LezAw#aai807vWqLdDB_3dCC_c#w;CGN<A!(8
zX3@RjAHFq+_nk@4AA!Ya*=#$?pP}F8vb1cOw*2bjOZGPibj8GYNi?lKC|WI2>Qdj4
zsesQ>>vKoq3B=C}?H@swAkYoaZ_q7}x`g&x<x<J;a#QKZOtxhIB3X9!(`f<Z`8Fp#
zqUmNn_x!ousb?qMqOKT7-I5ZAo9Ne&B2!n5>SYevLS@7FB`fcBV|RX!l_qnF@J~g%
zN}vzuPu)gQA*yYc&rTYm#<~>cUpY!r)_>m?T75N^?Wrr=y88XuZ;hw+(+X_4gZ<Y;
zX{ADj1q>jP0n!~f(w|ThZw4;Cm%AQRD8E(nBw%lIXP6=5*Ry?Bo<%svDO4q}7)qts
zv)3XEA_N3PlU=0SF&>Ji0Bu9r?|k=zou5tB8sMH0u<ZzG%Y1G!kCW=xUnVp5jo{CQ
zF=kC!oTYt*;)F-DNKbX&^~x_Dnx}*e*#M#?goaih&+Z*NYu0*aB79t%a5v*wjFJ+U
zgmGpyMqK=-@udVXRN+VgqhFrE2VJ06u<IA<vS&^8>o->}kTd8;>w(6`ZDGlQ#Wx8!
zZavPou|=DODb#z}>I&HCLcs);mtkezR~VDpN(r*XS{E+mBn|joEXpU?ycUPalz+e(
z7*m8)*7m5YUDAa$OQ||}AMyYtaBvsJJ92KqnBtf4G>_02!MswraxVEXdl}V(UJoPp
zRH=5FO0)!WM@bI|?ni&vYAr^W7B@3anI>7g%=r+vV7MuE&pvUfX{)X+V`+zsdCVlt
zWGw2)$}P7WKj=e>&*iTv$uX>JeDqyi9%<ivV0iJ|&7T&?{)cak_C{+=!!p@|`40d&
z4jkK#hlM#NBO6E+?t4XdR_#W|YxmkYtYx<&ei$u>_b72}nQ-K4&H{t|1Ome<riLW~
z1qbE~2sV!@O)-r8?71?0lB4cHZf1Us(CSTCFGfxL={jcN!)CqM)0KA34)=g)|3NQ-
z<0i}B0S5FNg`2*40Cw<2K`GV{N96UYxF+yqmA$us0`%Nc6SuTV-2`WKI%r$PdsG_6
zpVzM+i>jZ5dW}~#``WREjlND+7D8^+K>X-y>RXP_rSOJTk9f^g#o~3r-%2GxZEeaR
zAFu`?R@nGSk%~Kwx)D-=V`V={e&q*l7Me`gUxpZ6q<$N@LfSXXPm}T&bLcbRussFc
z=^=~<rKO#-mOOm4<s^%;z|U=OHaFahyjRYA{b<9qjv9A}dh+J4)r5vCSkz9ik+G?V
z-eRA(VTBdVzp@6Zrg`bCihmY-5i332;PF21b8R?96pjh{%%7o@b=l2!vwX?A)#~g0
zlV#%K#+d?ov?B2hGx!i#Je3|7EY!JBx?#saw0Db_(k*?>V|a|vb*R9Su*A?JC4awz
z!HV@@e34A3&f|i)AKfXAtZhd-TvfAT+j!O6Jl}-{W1aG>f(Rye$BuJ)*zQ@3lV)9A
z;>FrCpOl3V%+Tb(noY;kA)_V%CXo61&JOU@fZsg-QTxloO(C0uP0Y;oP20c_M%vk$
zYct=|t2(HC=r@(|uL<cR{g3z1Cj;vZ+o4vI3JVX-&*jvM?cMTnU6^~i(gi`-Kp{pv
z#yxuRzGJ^Odf4ZRgyRoz7fsx;R~r;j&br}Rsw`p|S6x}+D_D3-#82LWb=;k|GDZU3
z&91P~#Svy8@lFZMwB>YqUy&U@>wawvfeL}N4_;p(WWPlRy=p45p*h&t!p@hPQqoSo
zbc!w#jGNZ&;K8*!=z3SDUQJ977ZG}sLCPyRZQ_(!^h0;k*o=Tjss;oq7q&;6ZK-Ec
zBWu0365&foDM-I9FM0d1T|XeF3ZC<qC%UFg{a`rrOpV+zsyRTPIP<f`A}-^&vY9?;
z$<n9aICqNvS`v#cwsmmVgkkb%mH3*>G`52|Gm9MYq`nUsz)^K)PK2r8!aNfQ3*))9
znkR>YDU#mXrW~USTPAFqyYcVwAQjly(bJ0S!wpvB)(EBjA-0jSr2L&CWlU#-$m#kT
zUx(RIV~UNyV)5r!!R{i<jp4?<4s}@J#fJXPei`G^*uM&QIYQ3%N;NPU>>|)lt}IOb
zcECUBcb_SxxdKpV40KQ+RBPiyz|Va4z}@W+=$yuj&Oe}034m+d;=l1T_%94DsPVPt
zq<cRT=!SnhwOgmRm%=-}!!M_Ouy*0VU;S3yr6B<FIh@>`0SlJ&9oA+eQL}!w3A!y^
zP;QHP&vEC8iWw^lDWP{wiVyp=a?o(Ie|BmwVm_JS#~{tSBIfgiYn}~%TYeoB{ibb7
z_qN~giQ!ifhXz&5ES}vKypoh(oft!Dw9MNH*xz%vaFj4B4}cBLWz{H9tHYhg3K@$U
zL;l|0s9WEE>JAE@7l>(<{cF(iz1BNR@%{PN?z}$zPLHjR?8rk;q^vNZl1T_^xxo^W
zqG;`r(%sIQu3<)~F55s*+$p1ml{5*|F|DJeR>!913_WbIQ^c4~uGb5s;P{r(%6S1@
zWA?hi_)XDMb3R5MK?cUF5u||H11e_8R%p4cHa{Z;TmQUX1ZbzRB^r8#7#Nj|P_Vab
z>lG_w^TvJ=PU9PFF_meLJOXdXKkf?8REgR8As~9@++cWaa-ibSp|2Nn6O%X0OwFRU
z9c2`7gN!y+1;2%*himc)R&@~XutzkU$IMa(CrlW}J{`jHH6Y$j%h^k+x$1M)qLfoi
zuI%k@Cn3&I6JA{o>)Yi&uKjvq^X@DM>>IejO?zm~Z8&$L0|u2}H|-Z(;;J2Cl+4PL
z@RRuim1af;^N`VW2CXp?*q!oi8}2SzJ)MT`{48jFv1!wDc;~S@SR4!&ykp6ISpV@G
zhU(Lq`xu$;$$d_X<JoU1UCsNZK2}rogj(>v!Nk-y1YAWE-g8XT!KNG4LX}Fa16`HI
zbI$SZRb^5}9Zn;iVpRl~t!YZf9#Io5teld@PIsKY^580ewQWa6w*LdHQb)&fer9kw
zea|$~XDEy!JZpQ0jap+r*r>43$I<9ww7Orr*G=7g%7^TQA+hm7`y2_>d!HGrf|nN7
z0;RuzuN|j}rb&fUiM+<=r;6Z~2HqGUY-x@heGlyGm`r>MaUk`D3nxioDvHFKJW9%J
ziXb$&?qE4lf$@K__uf%W^;`aMtOynasRANM=tZd_2sTQ<fP_vcN)I6*9Rx&CP^uCL
zNJ3FUkrGfy5kgTAqy;22NeD;@N|z2&eDmD7cilR_nS0mFyfbS(f3dO-Cpr6+efD?n
zPYHxlBQ$oCT@1??C5WVBV#JhjPptX#(z-j)I6gHk7u%vVX^t>As}qaXQk^scqoUVA
zzB(JlgfCXq$#r4${7XmL_wIR(py%+kfl9)>linj+!vV-ro9|gPd!CqUtmQ$rYu9DQ
z;wufG2^GtJZ;DUwDr6a8fJz;yRAY-?h@I*nx(ZZkYQUG8z|fhsV7Ywft$|esu`rgB
zU!$0>_%NorTya4OH`2cV^n4t5p!}Gh{H^ALE)w-Ov@*Nw-*Fsdxqn{I&$1_zIG;o!
z$yQ0}IC>@#f=PU(wyqZc9RnjVNGw-rvIOe+cWo7s)aC$*LF=hz=-l&GMB_&z@7<AB
zTvHo!Z~n{_h$Gr$O@1NJAJ$&FQ6$lO&yg|$inw6kHB6Hml6%e2rdlNd7e1&J5^Dn!
z!rPV$=LmyPO=&`g%UF89`K?roINYFlb+RXxTPfFfvYE#ZG<BmZ?qcXp|MG~Q8J^F(
z@@Zn&9Ra5iODRhuT{lW8FsRhb3e}rXi(NFZg=RE#q9*1hz{LoOtgQ0XO(%79QIST?
zJfdP#A34rGA0(8JtuL2vGvsqjme&HwanuvhSZ@;1DX3h$5|I!)(TOXGXg31UK&2N6
zJ+`Gdjgi@F&ck+aS2S_DSk7ppp8+ck9vJWe*Y`F}35*DplF6Gnrw(_dKiRJ?;JtP7
zO4l6VFvz%7llH!9L5dfm@_27#(Veu3a1)K2%P?hHiEjzJafYNYg682X4rFNQA|oy1
z!;+9RetMz2T#RKiZxhkvBcjvZ-t(zOD{%OU=P}n&F%bziG;z4-bmf2_CY!aK5rI^a
zYDeO<>Y#Q<^#mJbd$PjhD?AGq7e?m2kz|+zQookQoBuP>j$G)28%OeZ|KPrsKY1_l
zym`)ncV{P^ovVfONm(xZ(|nT+LJo_0P{;XtH-S2=6mW7l%xNTX;75spc9ku|VF=h4
zZTs@!D=zKamWj@2kTdMcnLE*jBrft3V0`psrCp2iRH9>trJ{rUmS*{ukl%pOFz#jQ
z6nW^~a<#&$eewE~StW$9`phD;um4DEFWx4wBcb$lX2)oIm7zefrCXBtKESPO^H&U=
zKWTmwKE&I`=}!EXwX>*>*@6{~e*vu+XD@aLY}xS}e=BczRdMsTrP)8NM{qtUQh-r2
zGIWv9C+6^$l2}^kf9Ks51I*Dge$SUk-KWk?K0oYfH{G{EclhYNb~GYvo#l4MF6I{Z
ze!q=G3q(&?7#ovfdxh=#e}=ThyQnzUI~I<~uz3|{On%!~lANErlJf`+n37j0TsqiR
zJc`vrobs*2`^B<t`jqpq3KM6|*mEptikXn}E8Pq4Fa4`DroWt_obcIhTp#4dko8kd
z$<BgB1aTEHHr@Kf*x0*w_pPwpFyFhq<e0eCk547;4LiNpWsbLUojp@IMCMy<BO%?L
zK_~O#0rcLW@XHRz(joaDOoU~&QX0tO!rF+vj*>U4FOQ%86WMB|JHBCAp0SHyq0<Ua
zPkxNza8lZp5xtrk)xZMUzRUgT;{kPG%VD+bS@bxeP`e38-z2$T#FePO+vx>r_mE9I
zvd<z)KyYNJ?UQ{N)EDEE^Q6x}xhS^r6K8Znl2zRn9-m<=6%xGHy^JH!e7QC)M$gyw
z8hr?Tv0&!p%g{7iu8BIjuT{uYK&)LUbV2`s@;X<jw_U(1iJt)%M}s_S-TDLXl^3tA
zm&!Js9zNN7(CnNNLy^Zv?)_Jy;a9&eRtbm@oqO1XtZa!s&0N{=*P{$m>k_N_ioQ=(
zKNy5`Y*@*wl)^qMo=oB5#3Sa;bGIJG8jK8gvQIy3W(Tqv4JPJKE;2@D2?Sb;sjYrt
z*9AYTIVL3vn#KIq1XiAESGXjoST;r^hqr?9Pmu=a(k~i#4ws0zREa8ojrhhRSHu=_
z?=DJpu{4p{x$v_-V}?ZT%i!soaD#QJz_)vzDQ2gRFwP8E>5+B!(VE}^E|Eb|rO**s
z*5bG=*S*p3!pYYz&W6B;U6x1A@i1X}diiBrY3WE)le!E90me{|mP4&L)SZTr3v+{Z
zp?%n*2-UZ}3*t55IQ==AD;-GbL23oJ9Jqnu*^hl7<p1?paZ$*k*7kz(GhMn7sMvPC
zBr>Nab#5YWFa^Xy;HNKzBqunC=B7yK9$gh!-RR9>xWo9a4EpCQgxX!}bY0nbdA->8
zdCdFw0@_oqsYVwzcq|}hy<?<r2;Z7u`Za2me@5*jJ%Y9aorj0n4cuES#^>;mY*)7n
z)5CyNaip~E5a)|Z{kLy1TuBtd)kEq5$g8-p(aT0Pjw~D$9TdO_MlAML-jD_!fmq{#
zlr!6^8F?lh<?-|B&?Z**p}fY<6kkw`XGbm9R*9togMCNeO=zu8Yz9y~L<6#wNN^S*
zmPn{yRGzG^R$3QEuOXQsTZlJw-D9>kUKyAAWc3)!2Evb1@JCvdv4H4Jhb;;2_$zFh
z=N9yOpEbz@G(f#;%bAKBsbm6DBCX)`v+=~R`_^@%*~s{Lo|N|C2xZowWPE+ptiKGs
zY=yQUkZoKP8HScmv;&0_g#FNF_9?f(L+bt8ZH!+42PC^<Sil@DKDgJgRB4v%5u%fo
zp$@)t&ah2F^05E=R?E~o&L2<OKSDMeDzu5bevNW;?N6)74>a24TQ`1XvB(nSA_>72
zpd@Poedg{@rKaO52I=fMaQc#K09=ImDU+9cB8kT+B`<}3_QBmN$M&5r#&6-LNJ<)(
zLUwKI#2k!3xS9{N9y*#aM+#?@Z#3W-ivg~iQYHbf;~sUQd*$rUp=1kqN?yE)Z#5V>
zm@fAIw!YjMCq{|fjiO6&y9F|Mx+&sxFStCrSA&Md4VXPXy{&j2taRBtWRUuyC{&$p
zN+vd_Fzij;yaqgbwGlPq^eV|O&#Njp1h`NK?z(q~gypJ!E11#0kg;3STeE_2SnVG=
z2Rw*9;y}wPU`emgdzi#g4kwQ35gI?P_JWH?Nq4z^z60Z9ilM*yyvfXk=Uw~RfKSEv
z0V2(LI+Jck=2;iX0_Qg5P_46!7=_y-)36$~&g1ny8~0)1#jD9r)S`Zjj4ba>m_NDI
zFYi|83bX2(zJ1MXztVp0PXNDa%)zYN!jSmMXW~A?R8(#lxnX(LXbjk`7=p#S6r%Mc
z8kA~>@IQhIaNp>Y$nautJZy3O3FzQknYOS10S{F7&lUwj<^8MZBKH!#f(|Pqf8!hI
zXR>B<xS7Q&?xZZKkbAJ#<k_+;!m3XPLf%cIsnoJ6!8CdULS(^zfDd0*bG31_p1)(j
zHThAKCK~=)!uLb7RPZ<*(IT8N3k=*{NGi941M`gYPFSQNdyFF1q56)?8{tlwj4%>8
z<TK$1xF9ATHefztS2BDwQ!?Jas$0ogrPX55_Tmc9A+`eorBegPC9tN3O><Cd_nK1T
z#wxYV6o^#|p_qq_j@F}#dZrQNHAHsO)z_@VElBI$2_0rF@YthPp%%tt_n$3alKz8r
zGpjQx-ta(o(&-Hg^b)v7P>p&bdeuE@5%mi&J8|jfckSQSlm9v^-$1p8uHSpJL)fp_
zgT>Lc)VIw{-v1ha1OZNfCHpMtl`EfN>T@Xikiw^PWhEj<+-`HcIU9YX^=$HybI%P9
zTB?rE^`m==YFrD^HT{>LKz<`>|26mZUs7EZpw%a$Ux3V#>KOHQBTT^PsWUGheN52-
zr1NdLI_Y!F?1O>^kAI{Tj>^(!ZWXR4azkuZ@TNYW(&L^TGF=q+&VLl+0r>v<KWapa
zRaeJ%N#%st<o#AmaFmoN+oZk+_=5p{>sBkFd4YWumalrpZm$QIbKuK#<{9ld2DsW|
zy1^IZu@vby4}$ytlO6THJ|+L)(_zViF}i};$7R+a>oE5epQjJcJ$4t_=Flm11))IK
zJIw(1r)!jRk3H9(vcc5p4iD$r8{9H$?n3&4fNeATe7c+YG$0AKwsS0TIp4rocJ|e0
zAq(Gr0q!xFPV1G&0f8339qE~{CF?ysOarcAFRjV`#j`PEChPt>_g&d{W5#KN1ziVs
z&ca`=H2w`t;x8+ozi8ga%DwRLFw7Qtg+R)_aS`G@PIxa-ig5E*KS4clUQejpjaag)
zn2p}LEb8%+7*Pi?VR)~ZFwpdBwF7_n#{UVB&q@^Ej{cKIG%g3ZzNlG8v(t;Lx2w&u
zLpdZ(5wG((v^^vpOdpr&pjoa9MX=ELBdGZzIBk(Kq+YgQHkm)W?%&%kqX{4B*6Uvw
z_!d%3rv$-N`KV#1jCtaO8&)VoN317uQBQp|#|!iA$E2Hw2tK27ILq~#ejmd1!aff{
zu%k@jU|>#3w`uK)C}%Sw|4Hv&)0t=Gz{d~Wk5o1Xrex!k!KYeQ)S1b)d;z?TTaVI(
z(1rNa0y_)qD!fGj*mI1hprgY#2uP8ZX_?Jbbe$JK9ch3W)9S-1&EQ#zR6DaXr-qI}
zO?L!lg~jx)QCz@3`eVkBM>{aYxAD4alI97qH*^AH$Mun>7|B~FJtRKfvj!WNq)p37
zX{s{t#zRK1*Q0?GA&cQ1dhNRtN1#ZYLHJb@kQ1~ds{)Gf$Rm*%*@r7iXHFZ&ju@9-
z50XxKdnPyh?gGEh=k(w~Zljb69k(W<c7eR7AG`;(^LxEcziY}Y)rhnM6ACWwT(F+{
z<^xu1^T>x(`uAwsY84<(!K9Yz=p-dskm^=>^=wiUWKjHbg?EARxp3`Ld4zDKSYY&o
zSic8J>7?hEGT+!?7ytLKtOiEw;}bUAu32*5qs?Rys_^+~)I<~xrlls4my=f1S@(S)
zQOM4*H!ZNH*4)p>j3r}-_gXZ7ECqe7d)GTh#D2+l2A#-$?O0aTCh%OE&-G~N`*ZTk
zH|K1|&SP?Qg8OE!hL=DRU2x3yy4kMbQmZ^1e^n~zVo^kic1q5IEQDpcOgHNBS(s6@
zYg51mFZ7xwsDZDXC&r5?LnAeP3zL7!xH@-HE7D3TX?U1m45@uAZls~cUZfdx@fyx%
zs3Za%<YTd0h|`j+XhmgD7L*X8xge-Z{v-MM)#+{5y!flEeXPxmW_tWa(X$t{^`}-$
z`Uyu~ZLPvfTV#aW<e^rAK#R_~MC5+5<%9>g)-dFBv6_D2Iq)5Q%pCJxoV3w~QEz?8
zK#l1Q`qLsSRp<KtuupAjf{Jcc0}6`8wDo@J^%{|us)#p^42&MB+VuSUl+LOv<>c`*
z;YMv*4=i0pJxGG`?W5AxL(RQu#T3RTV;uh_n3_lUr*V9FP6A^iS23a;X2cH~n#E0c
zl&4qS(}8M94yv$B!Q-FNgDxu>VlY~yYGh#BQH`Oo<HE|fA1tZpd`qgV^xpT-;r#?p
z5yZ&uHRKy;CM(-ePrYVYk~S|{P@|7~*Xwgh)8stDCvO5`(p{t>o7A6;0nPa5C=i}B
z^_qGVibL&2r%z+RzTA%=gARf!gW~SSi5+tZwiFul^hVhSm|EIl?$6!PhegS)4<|FQ
z5)0#HSy)QlVvp%WQ#UN!hviX+)-Df@+;YYH%*)tKdj{TfEPXw#JM`QsG6(K(m0O_m
zLL1L>qqE8_q7jv4Gwq25{kO#)AYNQNlVn`8CSyE)pK1n&e;}!j)8YDAPAWsq1%cf<
z?6T*JIb)<HbJkH<LCLau1)z{88b(%K=Klx@4cNAvOcwNMz$?7ekJUoi7QTxHJd<!l
z4Cj&|`wS1ea*dtpyf^u{A?OHBxYR1P3v{spCbL`-HaZefJ3!O!u}03OnHS46#H!x8
zOwCYI#R{xw8L$jy>=wXU61Kj=j?)QuH||~@HoGDb@Ajs?H?5QUi356Rgx%kvz{=Jo
zxbaD+leA>7|Au(o#-+P4jI=r|VZLTP*gt*73?^BCO#r%&k~=gc2!4|Zm`F4dtbj%i
z%veJ&y&6Q|$!&@rRVU;Ng2F>Rl3t;1A+bRnnfn~*lAH(hXUd%KHe1Usrf2J8r~`2Q
zfm)iwa$VV?0%ITnV<cmQQ$q-sjqlE?4=NJv+q6~`Z5ZDDtKSHMi{{sQB^%)IQT17{
zRG<phS^tTPFMmwpQbQM&2r;es{4i_X!u}olZsneQKb26>0qK&n$dL78M$kuQ1|r@J
zazc#O*JXytjBpYp7|eJ_F1N<+A=DLXEyKNiyw$G-sn*6Gy+Iq-6sz9K%g*Q=ZoEhh
zP#?Ty$JX**|NNtXbw8R(0IMl)v8V}>o0l~aCi#w{ljuG35-*uj_f6f4P9&Q+jwj8-
zOKLRSJi|wP6~BGrU#{y!N8ER|z4@c;fJvVRyeQ_aH1stOoz8zY|0;3<wvT!Cf@O^Q
zcu77j)#n1JsEyLjQV-9c%PPxD|2zdDC;0=FJS0;=j&`c~;{`vYf_P}ABZyKw&d1jP
zd1NizRF)~?QvH<u95AJ^W~a58qcTgRY@f&n+_!_6M|fmLNrqf+TQl8aAs-Jb>`9cE
zE3Dv$Zxs%H9W=n2TDm8nYP<`ruZr};Hj9*_j``6LF?<(2$VrR>6c@mpDR;!~X2j%e
z?vu_kTD@tbO`65#PK-o*HwmJVKLNKS?Xaqt$4tAkj^*$AIbx!CGIE$ZHDo}0ofKtM
zBEf>N{?nk<KNbuZ*0T9Tynvvi*Hyvw>=R;c(O1r&Q9qlUb?Ll}I5$#GO#FfL^rhNa
zjdk}jKCQ3pNuRln)0AxQv}rjQs9XVs#<eO5TAvkB`-_?V-&U800Lmb49+<@Krw^)B
zPV!nDL$aU>ni4<QBp+P-em07?lN2IrZ4~#2_Wu2&K-Pp+rFimM{$XNV{l=-*>gE0`
zT1J2Bv-}-Y_b)1)|NOSnFc;s~9}x@V$)T7<16jFOKTG#>GOq}4?3_F9(v=e8=gMYi
zvs+02E}m7T-!Mn-II=?lX!@+pYRj(=43>@<!_aKH#$o->qrTd%ZoE9^#2s3*Xxgjf
zmfW&O4OQ?6EexG6ND^^&H;@!ch@qA3(`o^*-EGkWL~OEjsFiB1^Xy@#lj^r@Zrtxb
zNqgkFq^TmQUhIv4ko66P!YKa;o;}O)Zx9EW8I9sX8YS$kyK!ia6^C-O3*@8pf}t>{
zU6=o4Li+kNX`+|1I{eNc$LMIO@#4kBCwrGnMQFx>Z`82R4rV3)%DzL_<=BQqwX@1c
zE>2F>*eeKhZ4+@rEtH=unV&+ERgXpoN7izhf)7+}sv!KHRx<-$kiAw(SyDwm))6OQ
zz`&8?I^!OsF1{(XoI{~?2Qdz4K5cf(0}+X9iK6l)ZG{sZdLRWm@Zd&XO}m1^rRFX<
zTS-Dm7K)cIEo<gADX#&j(IK@{Nx*DhGNCjJsNYwPrL0}n{}|Tt3vjC{dYA{b-UiIF
zT@jCQbiVUt&sDnqPT&PMfd#wh-C-HYTs80OQ=m3~J$(~DLUpPYvtKC;MBt%O+5)-|
zS}iD^@p=Bv857}(a5WiteooFzYGpWgC>>G>8nDs+nz!#b-DcG0N`>~cFVVAn<HB-6
zTwJoZVWugAt3JzGE0Mp32{{iY$QA4RBMcZJ_F2R_Oxk5;_<;=I<e;jHNdQcWFH1O*
zPA&x*qqm!{A)50muxwA)gp9L|dT*tFIvrHYUGP308j31B;dc?95UoCcQ2dR@!Q0Uj
z-VWiKrtT#rQIx<wA;0*lw7S(ab88efC>$r>H*x$lO4D@9yDtmkk9gg@Oq}ekB$LP<
zX(MtCb&nu#Pvm*3u7n(Ft*ouwGEA`v<5!Lg*`Jvl%9Kg(QW3O@FD|i^Ds#|$T^HnK
zR-Zn=ZK7;9I!E@2FOcgm5)pRCn4<Et+;|6O{Ji{v!Iw`5*SOv*+jzU_)gHc1tY4Ar
zHD-$q1WF)}Kdu?!SIK{D=q}~@g7z5zDsL+gcDM*+b&nV@SolDiRWXofP;QE$HSN*N
zH^Looui_3r%z>d}(U;weAn|urJM>cLFU~t`mal(dz_!IMp&hRu%0u`GKOf%dG3l7{
zxg!j_>rR_tCq;N4bjdmMvykW$kYrL@lKo8vNVCY&^cihX6Cz<}FzY@nLpUy!PO{1U
z@uck%){DgIN!`@)LTx~l97E?fD4L4)(LX}bE~Y8;aUkXsvi_9l)%(pt61|29>a_Tt
z*8%=Tf5`J_kishpC4_5Q%4GUtepVUnn;!&@(rS^x*Goy28VyX%)|$!WHVsyyJUga0
zj+w;@8bhmTO;w6_4PKWm9Yq<*6s93-hG=lhNy?jLf0U+bZv?KWrY<`d{e?;J-Qr)3
z`nlE9u<FV?YQ4J@HOS%y|MaT<V7%Mzw9d)m3mX+8VCXewSMg=kT>84RjO$5S+riSy
zA33UxpZcK3?x0LZQ=CZwM|OuX&=X<jc635KfP9k`9do-Iyp-^ID<pmnE4j#zHMof}
zzhx&$P4L>;n{)&6l~t#v+Sjy6Gs+9~o+Oov-XfBMW0yx(hs6nmf=Q6@bFAS(>i`w#
zs2Eq<navw|81Hxt$Wp08keEGTOslAz%upCSSDT@XPIH({?;gJ?w2>iaU!GUgKLl!%
zoT{TY=NE~b-oTZe_I|^%uJcnw`HA7TB`e*0fnpim54ok%4rtIg49z`lo#vJv3?KZK
z05eZ}rE%X*u@u?k`Eq^GpnHM5JuvMbmWAy;<U3MgUok#lo)BKD>qo4oFzCzyLeaCJ
zqpQh#1BcNxSTwE#MvF^({|^oK-sz2Gd0=yuR5mSj+yZwOlO(9VjJjcLXhCO@mTdCr
zWliZ)&46Vs-6v!IRZPdV>@-5nGxLd#>AAp41y^{Oq6d+vBG&XV<CKJ{_?b@Lr&eD}
zPri>n<es5sWHHkFI<=|_rf*&e_wnEr%`7XJo9-*Yg<frQvJ8J+IA~E_fygdfl>x)B
zp(a0D^=|i2f~1Bf$d7NZr}W1`i&PXoGW(BKwWjX>s_Cn87>z2BRtgH&G-|Wceq+z#
zjoz4O$L00V6uaF0;}b2IVQLp=)-qH_#Svr&5QQN*kl{xK@+<}Cd%G;L8{a83zI2vE
zm!jR^zNs+aqKkG`_PrzXXzr`GmiBy8ki82GQluMSp-8`G$**cYnrYV#_Mf4H3f!5J
zC|d(B$KJ@PV)X)g>R77r$WWAeY{7(alFq8EHoyA#x)#Vemb#R9-=)kYI8SKKIncuZ
z$-qKhz6i<KhlXu0a7FoMN>$cCU@YVUS9mS1g~llG#Pd2;B~I3Vbdkgb_xjb%=Zj$c
zrWpPW#3WyisMhN&8pE6DsA&;`bku&)wdIDr?B~p#Fjlv$M)c=(>4=-j6WdB%@gcDn
zzY&fL-{#ba>@>WQ?B8;^?Ea0R^zFHhW%Ht)d;I;EK7#^l$mE4yGv<&UgCOJoPPXAa
z4xt-lMjAw9xUNmj0$sDLm2<HWRaOD>-_M?qv7aVpAU|FHcmb?X%{YeCPhL8e_+sdx
ztJDG1*&ml>6hxJKXoItezy^e4j_*64YR5qnh9WU|p+*`0`go_(k&vgYi8-#WY~c4v
zt%kQn0#HE1gZr;e8yRO_WR$Mi>1OzL6ASc~335{I**V2@tONOlmE-B;k%{>XYkvNf
zGVno!|DF98haa82L5e-t`B-sF#O@l8^xf)%eqgZLQn~Hr3Q;DtO@E#&QNB@!bqlWc
zo_o24Wy(R(i&pc6INT~3K_&fgJ!#i`+s7xL$U+yvLx(>+y-$(K6!z-ysZ@0xgHpmo
zogb7JNeqx4=Pyblq~HyVn)_==r(>8JP_-BRixAZh1T+Jw5;yYmX?61@y#<(FxaW+H
zNWv|$F%umQOP3@C9MISPV%zj$G{Rr`!Tb48I~nT$#B*UTSs6_yOCYawL(KAu-R}M2
z)GBL}u60or5D?x>;vZ0;t=A{-ybVTrEjfm~)aHlr=JQ!C4?`0KN5%&XY3C%4O<gk!
z`M89?;}&>S-e2U&p*TQ~dzJ)d>ha}V^`v%1Z6d1IR8ItAvXoG_K&wv$%b6H~;cgOr
z<%GJeat3{~fZArP6!S2PK_79T*>`a3`N`|LQ@YdD^O5=K)Ehvv=Mu3OlY2=EF&zFo
zAP0Su1)1;JWy4O*{6HTcTRD90$8sIt7(6D4>Py&4vm45%6MF9vLV^SC%lsH?AjeT~
zYhOu3!wIDBTwLm1cZF&-J$I1F$=bL3ruOgKMrBo3f3xD~ji_zl0Da0VcOnQBDP%D6
zd{Aj(U~&N^e8rJ+6~68|s?^a?JKx|jHdx1(Q8UEt^Z}-T?>I9mepRPi!+-7|@?<16
z4*A7_?1vva;g#NRQFPkhj@GuK<Al#p+k%EL3G)hu5ZE<Z_$6ePdQA;89#uEchX|Jo
za2(XDlWL0kGNl^7uxt#!+b9G(BN?xz$w40AeV5{5PE<pOU3*ZJZh3oQ%|C)t>Ok97
zqjqEtIa<~K+@{t}<E>@u<|@7w;-<?xz&N;^WB;m+T3V8ul5qMm`%APqpP}2WD}fTq
zIRd2;PnT+t<%t(x6H8zOU?7@xOcDgJ8W0N(D^*3~SN&iY>v|UmU^|MDl0`50o_dby
zjyT`4LK_)9zA*liG4D8T_0;hBrLUj3n~&YnS2mu!UY*74c<|CV+Ar-AsJVlDcQa&2
zj^H`u#i+)($-HYn<>X>h9!JDP(t|-ndL_vA#G|GQL)zBL;Gp~7mi2ANVu$5#6m~P_
z;)k_!oECZ(T%W&|ScG(aGmy+GX}ISP)+k^JP-ispcFt4s>X0=_y%eA))p72W9UT72
zkW`y1>(k*7RE12i4b~AvSgNtB8KN0MS}&&JFNklg@7**r;K^~l`91Z?Gm4YKq@~bR
z_YUc&pVGNvcA1bM3+%c*t<u_#zzcJ@NN(3z4MJ6i@3cAUbg9zPsi3y@Y2BC=SjoMB
z@bUpxvG5qCcs6Iy>|J%AbB$h7`q#!+mY}mQiLt|SlixZ&q{`-Mw7&DvZl@J>=I3YU
zqpK1ec+oYzkqdZ9h2}ycsMH6I#8*T*44_E}g!?3YUR&o*(ikh5HpGpc_pbK5d+ttb
zcgn$I3-1B0X|<2C%Z}=d`&pj5Xga^J4v&f*Fx$*&3*57GR!V8PwGk#V=s3`zMkmzN
z?+$??M7b&xOmb#s#)WJV%qN}dW4&`_IN@+C3EUd|pas0lMZFSMifH#MRqzn39wqzv
z^~=eHQ@*E?`w1^u&Z*)!!B5Ec^?0AX`GtWtIU*7y0jIpOGkx7$TH`)5A|s~Xy-z~c
z#Nc()A<eH^(I@mJ<x<*>!&)xfPw_EcB8>cG=^N0e%o1qI{*K^JsNL@rUyl5M4mFng
zAJV}Ph(2<f>r~s0k9Mm>x@6kEDFKNDKcRR2Hm?<pfn_d=p3QRv2$R~Kie5}1iMZn0
zY3w@iI?OXU<fvYIu8*4#P|nG44TRYkDEv8Md`IGW*z2~b8y1F`*rQ@@LC4sxS$tjA
zY`!^O#DAD(8Xi1Tce-b-s;B7ngra^v5`l=U=-D9+noQ%4iJsWJ9qJ`Lk62hJAjEJ;
zaN`O;q-N9e2=S0131+^gM0y*}=jUu*{50z~;m|xHX=bDE2?G{PpAB9NAK7(SCAJ}6
z_5EQ$^Dm8LSVN0_*(I>MUOyspzN#N!GtifjfXK8PpGt<@xGWGPXm!Xo?SU(dhF=dk
zTHrN#G`4$a0YDcSf8F+eTBJSM?a3=aq;MfK@xW`=!0L|;g1`NvfBQkzNr0fl4}b_r
zCvD%y#!oE}b{j72wV@=#PxQ&_9}_uus<E65mZtTybfGU{VmDrj)crrZ1Al-;{DXPR
z-}e#z`adn}E1y6}>0Qi-R>gCn`8QLlB_QS15CJ!kAmqs0)t8*gOM7uHFE>pV22G;1
zJRg#_T<kq|WzX2`PU*~nHp*`r{3uxdjjX&XsIk4Kw9OI@DxA7^Jn&2?YYg)Ts%t*g
ztJ~t|VOm~xG6r7oY0{>Nw@fd=J61JGL)eY@(k%61YGM{gDamyt&NfVLq@$AT+mA$A
z!)!?*Q|sh~Ib=hM!|GF~TVRWfmAq)<Ap0bYMChcmK7;-+>5ABc51Np>*Blqs>S@tY
z>k}B31?GFk9uyt|q_pOK@kg#9%|f;m)RlcA1dHqyS~)%w=Gy$bPaR~@W&sKxB{-4x
z4?gaEpa-wrUJyw7iWSiEH!)A91po#0DXL$ou;xOXB#{YH&7YjCpd4v5whZDMc1-s&
znxUxq*bqt({r#(g7?WyJSjC!t^>SMIw!q|(%KeRMp11KIAT4?*&a4Kqzy4=QyVs=%
zHLdUKOs^Sh6Pac^86W!07b;1GJiwhqWPm)WU=7Mrpw&p5fSpo|JNhV2c}fPMT1-`r
z6NkMS#<kZ^sJh%tgnI9DKHE`$T_U0)qX{0#gTaqMlneV8(jvc6D50|otd(UqCeRt{
zKAur6ZKPs~a?12C^`|*;YN#N5&p2fEHjN3nz6)<-zN^U@XUzMYwn}6lcRq6Btsb{j
zx^nTP{PkmVV~m6Wgp^<}0c)O-DYwWA?9ADrfN)Td^y~b*Bvjuk$Re7bdC!~We-5`b
z((W*3)Y%1#vl8zmsoq|roSB935q?r=V(hTC^H9pfl^%K_6UcMnx%Oj^6P#+;)PNX|
zvN2s))D#N6fuzz%c_xdIDY@d4*}OsQpHfkgsPJtP`TM_t&p!SEe0GTiKAX=&3edF=
zJ}=fhgFVLc?ZM)6{|j6j!owlxM7KYK&o+RRj;Oa%(p#DasJ+83p_b=zU}X#CbC8*<
z@;|P8K9ZlhIeEsF+xV0bfcsDB?Ok~Mg^>%W3I57{;|ybs6YzTd;UFYQ&J*%XLj~O2
zu8k`vK9fx+85yY?fut6i7g8_Tel>nE!fv7MFL$o^d;9xXwlC3oH}Y7mfhsHaxOW8U
zh3vr+O=G9SO+L3lK0XVGGJ6mLq4Lo=E>*{D_<8>F)2kny!wL=no_Ch$*LGuQ#v{3M
z_T5oo{_R#)&$O|DO!zj{i$Zj1O^eL(c@?;2HDI!o#9+2&qm$+rnzag?DT6WCK1FOz
zeRXw>p+wjnQdCvhg(~c)53wUMFJ!f3<0S8&fCd~JFp`6olGuC6qv^rswDx&9N19YY
zPGRzVsTNS$q<vs2X3Md-PH2iSH}caHLinLa$i(~V%$OIRSI5vq8Twq<^ME%mJsCo9
zRZO9n^{Hc)E2_hzbsGGFmz7ip+hvNw+nV*4NowOrvsPRy{)sZuLA<ZJVgT$b1ZwZ`
zO{WmIoK9>8ZyVRehHF6+APb|2@aCQ`+VX<gR^bxcft8s?%Br2b#8eq6z&l%mA)^tB
zIf2li>Wn=K^sKM#GPYS!Tf6|)kYYj3XVi1jnQ3&?Vwl{gvG{w&C?}K(;q8wSn9rf?
z{$ce58I*VbtL;n35FW^FjiX%t(DqYLTa04Zm#GObiQNT@@hn1cmC-s$LpC@eL&Yj#
zM5e@#oC^MgHZox><j;pMuc(Dd59z?X^C=7iQ&K--va0r~{3*r3>nSO7SC8cj^SX(p
zJ!roQ=p%#&!V1wnh1tEPHJ<qS6|k;qKl(mcOC|eB;}IYUxv;#x<!uA<6>0iFkl-+L
z$dL;zM4><cihO39QgyOdFTQ%!pPA+hhiS=p;)L+HAKx*RH!00(ZNb>if)45uqS;}@
zDj~!elUGN5)4FpC&Smp>P_jjHk4gmQZ7X-wwqClXcnmJHas#aSR7VH=K-w%KtInSH
z<;W644iO?yZ&U410M~Iv`#;mr)iWD`A>`<oaD0CMWF9rdYXEVv=m#+W`;W|p^uzBo
z%o;0B8Y&*E_e(!FxhT~+eC_6nz6P;R_|Em=_27OgJf%JbTyN~%YnnpL+Pd5i4DmNJ
z|5o3B>YK6qutgY|0Ywiozinhe&4_C`3A{1P=2aze3<W1|YtEIzbN0pl9OqUuO9A$S
zu7HTTQ8lg&m$`xAF5~TTCvHc`{gt}8b(lKFYk568%))6S?LOZQ6(MH}4V*&<SLZcV
z&@gi8fk`<sDuTC$;`LBrZg-+v5BMQfqB+kx&W)M*ni#<e{Ts`J1$Ebq(aMGES@urh
zm*=P8w{HEHAWfo{)x3TISj@T4F_Dhvb~}!*>^#eSwYT+juO=tkk$o=aAHR_Qmm*F6
zP#YX(+0D>r`R3ulWUTketFo=_{z(1VSP<8n)|uZFBVQg<(6V?(UEntw5Ku8R#FJb4
zst-u$NqH{x8^|?w?L*3oEVb+#`26ow6~Y!@H(Rdn=T`N65ohDK{>}Umx9HaDwF`2|
ziUI;@FCJwAwDfL0kbO{s1)KmJczNIr4*>sP1uXgNL;B|^kN@G=Lo9wuaEK~p;0bk&
zFB52KzK*!dE=#wC9)E;?l*pw&n~5lCFfMYhH#Hdgu8^x_kxGJIHYd3g7r<BkfHC>+
z@3H)@Q1QD$#qSCgzbjPyu2Av2LdE}5g$e-w`g_9)fgIgT|DM)YgQ(#G2a$lpVk?O9
z5phx$#ODMRM3|iW1>o8C9!UP)!X2DA?}4rQzERcSt9sW?r0lfs(;^ZvCa~4+vp3$-
z0-7rPQK;GG`qc+zZxdS;4K>lyePS%~(&>clzDev(TnmisT}_MM(0sL^=w7f;`WiPk
zvSDs=Z@Zh}b-WH5Jr#n=t=;nFmE1k^`uT6z;{U8>|KDS6Wk#oecs*CcQQ5_x-!5+b
z?k{Ng!3uIfuJ~Bl0hxmbt_bj151y9qD4a=lOSWS72yHrZ=M&$CL`12-=9f*2YSBRX
zSI-{=1^%N_$j_QzX}o%*@iVITwu=a(5m`7k7>j=xd!kuap|3r3>Y&z6lK`6=4`{!<
zne>e-yp~ruO0fGZjsXAyfV*t_ABg@9O8H-C5&d<;=ue;aeaq#InzSYVr2hg;-&AXR
zy2n%R^b?}<Nb(opKFf;KPj_{=i&(>{%_^=q?j_B@h*ge;g2)jmRCMB7o4&UkT1d77
z165ho;>@}l#OCTsq=q8bH)Qk-b-PPz>=z(8^;0mCA%EO+V0p_sX6OCYTkRj#4Z5Y|
zNXeR-<rzoyRqE$UgZ--Rmr(7das7Dka$}Kp!BJ>BC9K$SBzY;sZrUT#yD9=K`HJ%?
z&b=2D^2qdE=KM-bb&|(JN2RNhgYGfU_FG;VJ$KoKtwXjF_HMZcVr-QfwEMlhGQrs7
zZ9x102<KG<)YB`Fx>Ta@y`l}g-1Z9~k8|JaO0DwKKc1WTsw&dd?Clx9hCcbPq(i{S
zN{|O%MC&W-7cYW!GdYxAI2^Op*Ghlc5W)c}qCih>A^q)B%u=%uKCb=MLB=Bxgr0hp
zzx@ivWT`;!B3W<cQtA`A5sH!Bv{X?|{#?$-9QD33WKcTiMd=6Eg9kJQPRey(g3hDm
z>N+Fx#+_X-+>+)SH++kDyCx1TR9hsTLKw}MWns)V90sKnD%_czVUF*aZDDE@f!-_{
zsJVzuG<ac#3Yn^3x`pwB$$kGYep#RT4Z>1aecO`ld$9Pfc=`ws_9)Bb^!V2#^3@|{
zf*%CVzN7Oyc9{>Al;o~Bs2v`5E@LW10(ttGo(#uXW3`J-`UNKDdr&ngo-B;lg$P`=
z>RkE!!Vps<esS@3U)lB7=;PXq5B~BM^7Rl2t226?c@FOjU2-&y+^P~=Eb~gdP@q|U
z6E7tPyENYd!sFD$bkepWJ+Ihk4fe@Eu&|d2lM>Vms>!m;a!57R&o0kAQ+j#s{^`n`
zU0g+N8=m@MESnu9@#u~sDW-E;j9V~nNKzdS;D%Si4ERmhp&JVtc6N?y1-vC7J+<~N
zlF3ioB|XyPtdY_$dNk`0Q<R!iARW=XqG%nsN;c85zAslt)UdnXYEqc-{DUXP-atY_
zSJk|73-iL@w7np)CK@p+v`^sMllo#DCTqgHLbfQZ9Tbd`IsqjuQuOD)|18|aWcO1a
zyP0BBbKha_&*1v9QLh%mYRMJCqwO1}MW3dCiQW6(tIq2O*Myn?j|T0>ggbxxllsqb
zf`!AxX(9ql%)@&L4;QceCjKLdH1-S#aQJu+)LUaBBPFL^J#2wynk>a5l;YZEsD$d8
zMIIxMA8T_3cFI2^n|SWTLIxIs-^_Jnam~nSUt>bzVFeQ9#9(xPn2NV{R)GmvbyN<v
zP~qV*Mbtz<_w;r}_v!<EcLfiH^#1}xIIXQW?4ir=vPgIS8M}{IDtgpnjGcR3SU`!X
zTR5=pMZE1n^~$TV-G2MaA>%@Y?`+)6HzsXx!;QKjk^@aShQ9!u*+Xr5)pE<*x{=KR
zj*F;#oR)MOx%qofuVh~zUmQM<)}UK02+}K6be$YjtTfVq7pL5rfIsO|z%gFclIk>$
z;1IAdZUYHv>OS7#&Vh~A8~z6MTwLyS@j|Ml@p21Gn}WJtI#&(s2x?sfb`}=!hXJcL
zQxESl+Xv-d7q10F{6W<f!AmfiPx^JU@WU8+ZD@(Tae=)dLZ_`P6WV6zw(|8x91}oU
zk4Ey)_^h|JZ)@z+9H&_@rNN`=2_=(wJL$`Wo|WzLy|o(q91rQ056}%3IB}DZHa;@b
zJ&dTR3JKl{!oemO*LKe}5FQp1(YH&z(7}0b=T)}udp6M5ug&gNr?xMz$3DGj!=}g;
zQY85OTSw;}uW6=(ZukU96|><RB0VA#Ak)>3jjc^KlI^nJN$wuov@hGTuJdqH@WJ+N
zF8>S{kx#HaJz|_Wk4tR5y9E5$cB=JB)gfozcd{SPpM7XsK!Kn%@G}x~b2PKGIW#@9
z*<cDT6MiX3w$$;YzjeRkj0~Y)5l;7jU*<5k^Bg%<U&&>o8sGq04_z4J+V2|VY&G54
z;inmNZEjiO{ks#;&JTqJFr%Xk$1X^v)iZg1ZDf4U#pO~@d~iZlW>y}SSJM$}a;eUZ
zqS1=+8H5CcfCvS{fpL1;4#h$OJJ%pzV92hg3hQm_DF;)J2EFK>dXb3vVsv}^qR@$M
zt-B0s0h&c|_jqXs@iR(~!m}}DRmsBL5UDWRYEXfd87%`p8dd@>4xZd}rEU<ND6fh`
zsS~Dk9M29>-qj^jZC>GPT|{5Z3NT*BZVO}!_DqsI`(8_mFyFhQ?{7bLqECV5%G1!S
zzRgF+ML9nr31+8o$a-!<Q|YZhTd4zn*f$);<~|%ovaguOLK}0JPYy)Qoz4AefG`q$
z|716!;uoOERWs^L)Y`(6z2_`7il<ihT!Z}`?4iIZY+!U(n+;oPcWUTU=wj<bR95S<
zKG&OvnQ=D`Xo1?y^R~Q9K*b8e7T&|d=_MzP);BG34b(@HnicQ0UAk+^xL2%+IN?wr
zn<PEQ^jS(up1m0hhZ~C3M5%|4C%L6=FUtbvyLDCehpm;Pla;dy4tZ9qrw@Rqi%hR`
z7@0k`*aPxL`r=sTWfcw`gp@b84hL7U*uE@}&PJzQzJBgaC+tpgyl8XL-bL0M*|6d(
z=NA8*?kqzW2NoUs^w~Cdn;G?Uv#Y*_^DOI?%*p@b+fI^QLx0q&n3MHW*0bIe@e6Qn
z$}_6oS+~5X$T~V)j8!^7s(TSiz~u0!&S+>rji5x5$hef?g{u9nCTy}-zutq`>9}DD
z6$7;C`?Nak(Yp-)y7KHA2k&`CpzGi*p%;!P7r9adwOd<HU>*uRfByc`H(8_SM-D!s
zre!Gmk*#O&QHrCv2%`k1mz4=ci`6pGCx@Ibt5p-J`$ShPS5*3DgFZr=Y&_^!efUb8
z?=kkwBM!@#@Q<Z$jrkuLN2B2r_Lbp|x*Y|`B-ZHKVKH34ecpd)=<13=yA?@o1V;x$
zq0_<i0^hH#X9@A|hZ!IQT&;Fssru2$U9_q4#r|}Lt7lsy3B9b-ywAY|g!5$wjohM{
z3`UUycV{K)1vLUw{rgF8H1fxhMtMjWVi5!)gwrjHj5P`edio-?_+ABPbf~WP%7cBT
z4kw1asd{puesj`o-$U9DJfwVze)gic1;oF;#7NdG>L_!H@N>6X%Dp^0drrq4X*8JN
zqf`bZ%twlBInPV<kJm0<300)Z8Or0B??`+qb<Jfdczr{`&c}I+aTA`6?ce!qCbdo+
z<=&S^xd_sr90}J!2&LJFA>;~k;xFZAPw<B`2$7O#E0%u!Ks%_|0Upj$1|TgN7a-G}
zjvmk?lWNKM>U4?tahv-TOs+fv1OzGMKQ+Rh1s(GfDe`4-@Gv)#HHq27<~>@r?;7G2
zjfRIStzo)x_7S5;VH!gDqwp1JLKTPvFI@9ln48)$A8U#VIfa4Fe(?29`6LlFbV~AT
zC)D37z7v@x7Uq1Q^WcFEIn988t}@=jt+4w%sn1mG8@w)<K$XZh7;@6rFd@e1jj1|x
z^x#}uy;DY182x^CQ^h?6rJzcQhG;4jmVUYZMs#G35AzGV#M$kFQ@}Um;0aixaKA!H
zv5D#=fsi^C(Ew9~FB2C#;557E`P3NvdJym;A}FYXS1ug)nzn8=Rac&H&ouTI;B6<2
zmob?>F!orTstxAx^5+dHlk*dADe{J^F30RMl`r|gn3>$dSdj@o;RP8gm9@CYwT*(X
zUe9vN@FAyeFtpbp9b-3ORag4`4P54QyQ8MU<f*HwH{_qUzkKlB&`tY-6^Lsh2<RZ-
zXNIuo^)i}PV;vO83+-jBk6y8YslmRFQ~kn=7+z=sI?b`T5WR}f&fUDBFbPc!QEO&2
zuaRkWA8{vB&IWx*2F44#Omxj?eG;JAk+JVe#=!~cz|@3{;ISWzmDXN8mHp%Z^>%Z=
zG|Bpww+^Qe>f6M*R0PQtSt-I6>rxq7?uwq-`BEB*6g>XUCJvlS9^!o$rrp564!4Qj
z0*w@8cO`>0E$^>RqJ52r$Zbloa+!3DUN|sFs0eM;lVA5m5<f7QoZ=g%W5GzTnPp)p
zE9WAVX(e9VUMXrdGa(l!JkEM6^E)r{l4Z18Gkc^sMbY)p))Mt-O1c@>Gx>8zx7+h)
ziVfzf39jV?FIj4hUr1Wy_gOjrjV)wtWEPB|ke`~0qDCE^>a|#%+Hk<JWY&&Q?XO-g
z$NB}lZVpTkQuq*atps`XD&qJ%>$dL9N0OF0zA1Ny!%zg%Ob|#5q~^g_Bc~QrxXtjq
z2~7Zdr&=-8fH23OWSp80jRj>U(Ly7dgqngvLZVJJ-X8M*{8hi{c&_*nLB<0>n@kv+
zmJMIz$MF*VySa46+`uou@iOevW#sfu$w#MiiLVxxwaV*o_u(XXP~>(ca#QD=8(;S2
z{{D~ZmGlnI7l@{!AzQnP8wNg@=kxm#F_Y)=AFNo>(<ZF!x>N!hg2yLHtgJRLJyId1
z@T;EKi+Xk{&w!|T9>y-6fkRp&B#?%Km}~f4vjpovN`EcnT2jt_LyN3uX0aRr??Vm>
zC*HI^mzKVg=)5aFoG}5fTQ!C=NS#=Iyz68w3v{vFgC5~E{FV;aDkV$QJU3Q7sVXj&
zx;Y&793&5xKG1m{#5b;Sck=Bm`*dTQ7W<xrA+Lgtf?O%J(Q`g5iz5`CJ7O?g<BT=1
zJ^`gO+^%k9Ri84Gddc`H-?(~Qg7jUBwBV$c@X}XS=HD%%WeAbkL|FMW!#8k^q1tN)
zQl%Z7-wo;g3Ae0)%{beHhAAli0^k*;a@N1!xC4?}Hpt+*J@=IO<AZ3|2V<3Unl!-e
zTE03uJq((;=B2@OK!Qnm*1k}hI(Wr4@&%Fl9b@I|0EGcdgN=<HMqmB`Ht|o3bNm@%
zv7a!XcImMaJTO6CIf(_NI=96d7$x$aJ$V)InN0~1rSZhw_&AsbwY32j%w}bOiXqkb
zL_3Ye2gKyYM1Y^E9(enAzzxmgCSeg*<)$x1JUezFn?&-<QohSMgrldd#~uu;XeC`w
zb_+VPua{=WlEY6QXnlK~<M9o%7)xOQ+g7(Z<&Q4D|KXJ3&msJMi{anfcA#5_#pZ0S
z3Rxqu3iTK8RIVMFh=$et$iv{hUE{s+sOjo##P4W~-_aPqqcMI*WBiWB_#KV$ub?qH
z`gbJJ#8)Ru*U4nqJQtOVe+YeXr!!7iV!d~7X^?}GH4iuzfD-j<2hFOoOl%sn=g9EV
zaPkn@R@^vS?=p|WTuq0AQ@B*YDm1?!_$SoHZUmSNIumU6NFw_D;zFZD^7$x+-kE;z
zs2hUVfLN>FuFs%#Trr}lk8IN$kSv)TmXuLW%GLk>^h5sC_WtW0{l2LL)}pyjcWr9)
z=Rwqh?iOFiUcFM6RC2@Q9nqibEN9wqg^0JSul{ipo_Aqh>^B!5Gq+ev>F-~8-Ly}#
zj6tpq%tUb*673%0X@QB{150g6>@JUqWS2I<#t;6ZQBS9Ie1?F4xyMWRq$6(1d8L*6
zHDs&rCR%H9Olfc!Hu12K33vA?`~^0J?Oe%>#%WYr55Dk1>r0`Ix6ukNcb=zw6Dwz$
zzv!F1_N421R4E8>N$%(o)py*~{u_Qb&X=|=B0-w+ogfc)U}l`V1k!Uq^Dn;gufZ1o
z1)u&Gn(F{xc8fH`s|BM5)PVZ7(TS6ONCWLNmrG~i%^ing&A{Z#sP2sXKEKc>lE@my
zmsO{EEz_+<&fOi;rHWHS7JHzmuSz@5ptS2-*o~Kaz4%{%oF6Q8Q<mEH>B}h7$&5Xg
zQ)cVsd|kBeJ<dPxiv81`kAC0r_mlH~>dwJ-zs!_c`lxhDuDHs_B3frMyG1Wt*+kR3
zFV&Q$a3<S1?5>y1<~#ggRroy>8l1^l_{T+!a!{n#=ncK}*}K*Vtk=Rf!9B|l@y*l^
zdM0($)XK_wVl^YS(V_*^7*oL;5`s{2VcR=3FSkvN8m-z>V@4syw7P!*03OA=NeT0u
zJM3&bQZ(z0{9k|uj~&lFdSgiL9-wJkh@U39$<4WGimzA%u||~Ln?1Xv$BVi<`<|?;
zE8%s2NQnN(g*lC+?(OC-VYhwRN1`?laL#!<c}9IT)E(2IHq=S&ZtG4MtdE?k{RQ}O
zSoF)6`p+!1`SYm8$bzVQrrYaLEzjm_rC5Buug7%XzKwkK3-ItP3mCm^w6~hO!5VBQ
ziPA$&R#>|TM7cO`U;hQzfAtrDeI2zst-CnHN(;KgAK5G^qX*~rTAJ6N>>Ygc=P*_O
z6y=>i1}SLwEm^)?UMil#9X6Sia<0bU<b^wl#&{KF07x1znuM7+J|*)v0fs6y753L&
zsEC4j`F?BC))#uRaxD3lG?z;-J6D>X<sOfa1pvVIxACQ{M*ZJ8q56)v33|xW>qS)t
z@<p)BiPnd@@mDf;Cm;Bo78Z*TJn`A`?=F!zSgG0WObUQVRE{}Vr6T5$@`X8>($>*B
zpB}7@3_k|=+f#q~|J050Km0VLd}%(L$*0$P;#KUuuZb&8*9B#o!QNE(RC&Zs-k20y
z4I+}pS^AsU#=lFB`KPvVYHzX#w&Il0fl(GY{LVk-qXZE?hmHN?8tmW0L+r~g`vv%v
z)V+H*;}<}WaHF38JFC*md$I&$K@)U;LgY3N?CEWD{@gH~H8<GwTjlfE+j82gSE(p}
z)XGY02fEjkV$nLK0YGMZC$+12IF2JR_sU_wfrmdQS!6}+ZZ3VU0&ugwYzL!yvajR2
zC8k(S5vJ8}uUTo+0?oO>0#P&+?a2AgM_7ll@`-fEw$gE$)8@&j#{ADw)f&6Ix?=|G
z^>VdQKX^okLVc*Lr1EHwSMt$rTf^e?F93%wVaZ{Fl}cXjbu<NM>>U*SQLHMu0R9Dt
zGTk)Wt%zR~-8saz?kI$B_`yn1F(8(|oWJk(&#1;{fBHq;${!3CjN>8Ojx3mMJ2h&w
zcaJ9uK2Bx{x9_{Un-M#&v~xsv4C1LfjM>}E{ej(f;vLc5<lvmE)qq8PWhFL_)T?`w
zqZ=%vvKUd?X89895N}1fjggI6d5`lif|TAHYz}$0xBt=q+7LxqA^rl0{=*or{1zii
zlH?!9$o7W|`Dy2We~karm+|3mcPi_i_`5q5?wQMpui#`TtRdU0&feBAw7HX3+<NZw
zUJ%9Ud_~+NtmP*Z-E-*sLZI3Eo+gTAVSauExqjx8uOnzW=HHem!fele0s2^E(82dC
z@IE*qJ#6Qa?%LY@n?JKMCU7jff!wL&j5!ulY^7aydn~FEJJhu0vT?3;ouHfJw8>Hj
zJipD`u(SMZZ`0|=zim7F`=<Y%vr#ZNw)1xTdAMC}x6%&#FTjfiXI39OhvhIcdUTH`
z{9=^+{mC-}MJpYwq!BeG^@VlyzNJNNG_oEzT@Oy?v*AayzP+%huckXqe{n&d{l4kn
zKO0@9E$K_wi&XUEpLAYD-8!Kh`qdisEYaoayZkz4rQwEhal1`gf#je(39;u9?!tl?
zuw+<NSr3w4<eKPM(+<~8%JN!NobHnGiW_?P<3IJb{(rsmkIh3tgh2(zmMv|1Snwja
zE0fkfyK+wMnDV2hV-swN@o{=!|27BR*;hUKgqv!5j*pmGz8<dgfxSJ2MBi5|;iJal
zAD?!%q9&UMS=qWgsuZ&4)Z#St|FQSpVNJeU+GtP|D=JD85Ttjccd=0d0unl*NGF7Z
z8hTMwRH`Hpq$?dlh?Ec@6qR0;&=UgEr7KmcC%>8f&AIlR*)zXAv(I&X-#Pow<Sohb
zywCfrweEGVb%$_MXoQHpqu+p}#fS|$+Llw;%)LqL2Z~~~I}A_w%US<CY5t#6@Xsl*
z`~TAvFnAV@-p!}9ySg=6UoLuJT?sS#>Kr4zkJR^T6BW@?5h$M?DpuJ{b}!pR5&d=7
z`}rGZtxKf;Rx0*ShBQi-xPJqRX><qN)8Bx1X?x<Ezx*PWmkv|6m8IIj#|;|2Tw$`G
z|IQy_)M)44xTvw+uaS!5lRiF4W6>Lih|qM}?50w_`|oJ{TxUJ<H9Vp>pD;S+)cC~R
z$*pMq3q?DtNx>4^bMJ5UDfowN?*G}w{|`9!O)cWMVC1-w;W!dHTlr<GpEkRg4cEch
zCN9r?S_C48*!psYHW)_3wk$!<GmF@wJZ`8xztOAuFJgk)=WhGNpFVrMemkeCkijfZ
z7(2gbetcpw1qvtBsA^p;7IHqbsbSz&xHnlgEF%|jLymx4tlNIy4}VWkv}>q|vbaDO
z$+|h<F3GlWrk!EFqZKA<G>Z^1%oGu(kyP@fqB_^ZSTR7mf&ip9C@u-tHPG}K$G?hC
zp3EUur!2#^R~1%tU~8-SEK4^)sFn$<#5W|EW4R7}<S4yw+NaM(=1ErOcrwHe8a!Dr
zSC9^LC)eruR}BSNVMF^BvN4wK9nK$WBA4WqTp~@9?=D9gy*(M<(l6X~y;q6W8*ZBk
zLKG@lT=FJlsXkc_4o@u9hXycD)v`)(V)&Y8?>QMA5I(a!_N~7`2XIZqt62AAK#<mZ
zSCVW>Gv{0}-_dmeR?jE-O&b-JTH8zXDX{g?<q@j^GJQQb-4`bIiexVrZd~i|ltrIn
z8FS+OT_G<%cDB+W{=D~Hds+RJ#Jai)Diyj|w1z}2a=)gDe^Yj-p477e*v0+OVj5M;
zlb$r=<kNdyb@m%f>v1pY<40vRBR1WL6L89y;@(Mju{0~m^#_h)ffSv_!G->uENO&C
z$8*^>`m#?k+Lyl6X~#gAN^l)smy}yejQxh3aIC%fb+_f71I?{4kS9!2@V&rUH*yma
zmWMjtY<$)Blc7b)@9esx+x0-d(VIbe+JK{+dHpw(=VDK5brNSK6{LPhx4CBunF?_U
zsATn>T@};p@@dlK%1W@26Cq0o9U_Z`4$BSED)2cGk1Dg_om%`<gRjxhgC=ra2t<n~
z_W8KB7ZMYtY{_@-UBP5(&`0MlR-*T=k-XDT^(ZrMZ#;e^xAEApJi}>r2puPw9kNA;
zSfuDJQkI9WN9vNpdK)Nr@@k^o=E!%HE|tG6(^-#RD9Sfr%#G3Q#T1|_8t1?2`o;-v
z!vyQ{sMXSHeA87Uazu{qg~*9zBg+e3FVEMvt*||aZ=H010_G^s$T%TZhUaz$nM?%<
zw=sE!_}-I&QJnorhkfq83oq5GtTz(Ss3Zp*HGeapLIQd$OR86f%2NlwPmc{N^S+)5
zdY;hLKDSP<Y~47_vvTVAyI}bXWs@X6=AYH52*xxZfh^f&m<xfER3z$xee#9EUmvPO
zgskj-*OrRG@@MsN-PQxQHYO%j*itaO!pea&<5u6IIM{jjl4i4_ib2V9?1db6yAH9d
z6$DK&y@_B+Gv~fqW=&#}qibO+l)Bo>EPOz0bar&cH>gX#cxD5RsU(f}vb~*k3Sag=
z*479pluwJz%g9OB-GwM56Nnp2;Lz%M(t(}cB=qulAWFCDO|$xH9_ZypmwJotryq>H
zrQg<@MJTaTPuqE4eK!8ZOWmpPbcJU@aHfyL*IV;Tw+FP!8n;W<;xc}wbr~ir`|BSy
zk8g@;ysoZ$`LZnZE{tW-<L)N*!V{UA$AC=*?&PQA33F3XS|?ARtiZDBJ_5JFMRX^7
zNYG(L@;*lW>izi2Vm(*G?D?F$0b9@<0aZ6V5*G6-MZfwoc5VotH*zKK^|gVP`1@Pr
zvaTN4WO~W7^oZ#kle|JvF9U0&cb)!HwsVMG2wPj|;Eb8=64KBH55$Kl)Vl0i4{Uul
z+gO?yeZlx(K%4zckEz8=`xh>!?)!<KVUS10q<l^vCW|dYDZ`yaPndq_Vfvn!;1R2w
zCwaM!i7UXMCKKjRSB;$3WK0zAuZn#Rzfi<h4r;pf_?EVEt2ux2q*#?-Fs-vaB|MMn
zwuYzJ9I39Tz@UbNS};2tHd7Z0ds-0Z?6E~*f4rdnL3veIItk^ipHBo5gDLieZdVB@
z{8p3xMU|(t;GC}g*Ua(V!s9xjP5D_DjgJx2uh*S5*2NBGju<D}kJYDXN`VlXQH(z5
z(rAA9i*Ju_e(5)WDPlThzFWTb6|JiOZ^3ncotFLI^wXcgB^pzwXk(<CZ(@;Kjx)YT
zBZ$wXY1LG#KGq64@%pX{-N`FeK43Ps&aw=7G;a)QE;_v)2RH2$2w5Ra*2?<lT6HR}
zP;-X%vgK^B!#iVswWzXCjhDdwZDp+Ofyp4;V}cnyZ&p_$^5(Pf=b~>P80hqvRA!>N
zTqSh`*xJbhNlB(CcfE=5=-&W|9kUuu5oI93&BTb<Z_7mKZBSiyCN^++erhy)f#n$x
ze}aIrudh1X<s9*DsZA5P)U_@+FM;p$C_bn7*xUpo5Iv8Y&u1SrsxFUP%ayBk@041%
zUDxzYO9H<a_%W2pU$zz6+orErA3mI^p!fcX-+8L{wjTDRe)j$9Y`p`~PjY&0yR0|d
zd>)8W%%$P4fFA{F)v5(Svos+T_gutcFaKVxJu@U2ij%U9>W2)z6c4htH&RxYPqK>K
ztino$4VA9CO{g=r!VwMZrG9!1JeIA#T;mmEdq$P`VogVx*e=DW6F`5oq%=|=X1b|;
z?I_RM-B>px2yc6|+Fj9)Wrg|Q(nDUG5+*2_JWE0ofEeQ1j%S4|7G?VELB)@5h}EmC
zZcse1aN{gtqm|NGr_Ad8#=cGGQ8XQF*0k_k@}fh~3|l@IM^#zzhGkhyK)`Spc^qN<
zT>25Pa}YFFU5rB<t*1OF+um@SJnpj*GafXy`nrZlUB_J*CU}2Dwei4mgvl;^D-&k7
zy!({++>4cr0t&U{mPA3%cGp&ed~LoQj7+A$<7q17%b~{U)?bt5kXEZK8L$BxWx_zJ
zM>?sxJfXQ!Vo-8TE_IE!enX(DmQZPlWU;XO;;<xp4XJ#y`Xql`CxZ_v$!UV!I2M_~
z1um4db!)IcMFms!rp&9;l0j-iB3%>9u@3uW>z}$H8)aC}T)%r9R>~0B-AphiV`J-H
z3}eJ>sFw6S`OXNF=X{UnCobm+T`0|y<e=9yFj=&pk@8P7S^)bt1^f1|&93@wR}7O2
zPtU0&r_@mgO{#WzGVB=!Owxz<ffEO}87G_f8;(;kW8cxcJJ+qhwn&JtkG3nORfrjK
zimrX(1ZlB{yOLKvvS=u%I4iY}bzhzV8I`2Z4%N9!9`*{*>U5%Y7qvA5N}F}Fi3Vp$
zX~|o*{f82Eb#<P(0sguQBVVhUi=YZ4!3K%m?<r$r<C=c1PhpK;H?*sjhVC96k8m6g
z&(26ivMLY5j9NrYjCT@sGmMG)dZ~>z@7ETczrQe~qPgTD#zpzcese~ZBSAL1Lw2bM
znH3KN7q`KWiJTqQ$_OW5aEjT_J8g5J(_OJ2s!3hmnd6dY_M$ZX`n(WJWIZ(Yx_2xt
z$2(eIue#wtgMTCTdakG;P^&JbG-yGrb!7`_h1k%4v!o*Ve%eN?<!YwNH2a#TM45zr
z7Ux6L6Q|uOZaHlbPG3Q5$UZoK^;r_9*KdGXeNvL>kndc;uFF8>(o8SRs*<44ZSZ_=
zX~^GQCRbN_zF+yC%%0F(9Zblv7%IHYfjzgYPbwU6BoH&5wJTWGnS!+E6CLUK4R3Z;
zUS_ZGPK$E{K?e18UznsNlS1xE?)!>$7A^l&h4+Po&!Cbw+wkWXG5FfqI((i<{?Sla
zVl!}x*i;UDU!CZ+zm-y8R2rl=`)&N}gWmucwKl?EdM<cF`>pPXrfA~)dox*+MPs9d
zf{8lK0_@H<)UIxk&%JuSZ0-ias5?=zSAaR9oTdlI;50U*|809v@Tb~twO~-DuQNY-
zE^`!o`yz(9)AN>akG8;vLQ>69p};xO^tqJkqFGes+)g<(HA2h){C%i9vhk*9TJzYW
z7|*FDzSwQ@QrD4VLC<#fS#3ELf#(6Di!zp!(ik4mrD=f+WgHjSIBCK^YS-J@220Gm
zhLjD4hg2t_p1#*b+Rmzrll7niLY~Q3Prgs9_2-NAzx@WtkVIhkTPf0pp8W7QUk~^V
zO|7`<Z0Squ5)^i2Cw3-tm{qwcFRoX=#K3F>?FA_ovonQTV#n<QbKgt4Cue;jo6Mp+
z+q{gDJP#`x2FCP-a^@Wyc}AfsrOOW0GF2kZOyF*o)KfDZZQ>nB>cg%bFn<>=Wi#Fm
z!tdPLoP{-Tj(`fm1DHGV$VhKu5t%qQcBoGIoH?WWT!Q9rkH`;=yBtw`i2S9=luGcV
zzQR_-h3aw)#1k{xDPMn^J6`1W5PXhlj<Z;MlhrNhM5}3|*BLK{)5(ycc2-dz>w%(t
z238CxI(!x1um$s2!_`XH72Z?$<!)M6-LKnUcWlFq%l+E%^^kMN%It*?n(2O#HYTdp
z8@}xIA!uMzn#}p&vi38f4p#cGHGhOT0h$@27?no#*{t&(AjqPS>mj(CgOPJ(In`KJ
zMqIM4#`y`V-$2>Yf^66~DoFp{eETE4k0Sx`pO?6<Pi!jyc|;T`hqJXW?tF53$ToN-
zUZ?oIQi)%Z73euAAiZ!MYuiO4j--C4jA;5SLsU=%IcI;Q_3^Tq(OkrNJ*tsSSsk~P
zRm<0Vi8^iO4@_P8PIUlS_=HZq>XY%#!p|A#f|7D-jbZs?ihhk?dfq9vPsA#uXG1b>
z#3%UKop=9?wf|JC{r80RG=P>fqJsu9k32YbsgG^{b?MMZeWmbdE+WeAJ!O=ZiLJNW
z?$y}3Vi%<Si?+?tNAQPI?WPS6L5E{5g#Rfb^LJt`f6u`F+^tVOp=HAM)9v<uaqpkS
zA-`z6)IM&+b!HnQ4-rkv1Bd-118O{fXTp5u(EB%lXMm;)cy%vrLzerS#?J@471_JV
z$L!%RJ^u>UpZg1}zlr#N0oMPY%+?P`!3ZKV;8A(`;EiEb^RD7<$zgQ{?`L2A+E22b
zXl#>ie$;G)wTezp8(LXQNJ=VaE@y^-O1{0@vJvm){-v!(Yu<I&msZnE_+_SH@hRe~
z;&fbCl<aY&#w{8z$G6pPi&bN{JK_cRzaD!w>ZtLZZ}ZY$U1+o&%X)M&Tv+{|*Zp%|
z{<mK*GTfJJpehls9Y_d{k$SDCb9^~YxvOkT-m#mL1opyLQ8x-0Euya_E9B)6*KoVz
z7C|FXqH<y;zSh`1kChNaXzJEqh%yXUXP_K0qmNn2t9m&p9d>sLo8W=C)IQ-MoI%=q
z21WKwIih8@cG7U67J>^>Bw{?LzYAlhNo=Yt9MRxs<74@mO~<D1v~TQWaZ5Fq_Rk$&
zj__E{-nw*T_^ZD+o)+f29)&jlpM2yB=%8i4AoaYBt(8Fim2dUP+bz~_a>ZNd&^PZa
zSv--^x#s(q8Mw7ycJer~iQX5@&1`N`3l<ZInx4M@JYK;?Tw92325<t{2Uy7G99`c(
z9Wl~#8}o!VJGf6=0Xu!QzX5k>WCj{}@ZTS0_}}dyGh9s%V<iVwe-qm?t+dN@Qkne>
zN5T9ja$aPM{av|#KNnWVV<Q^hx%X*o%XBW<D8KCQy&Ur5-eUg6^Z&Ucqkm(hd{P!D
z%VCM$Dzx~MifWV1#O*Sxt@4^zA<Fi7c!TAR)z76YOgUIiU3jl$+40L_%VHfqGx{sn
zPh6tEocqk~JxJd;GFYB%aYMV+6f&3&_NC?IqeuU7IeA)Fq|`Nes-5|ugvYkjhfj|D
zqOW&!1UryC?ekvPPYlKIh9_k#3nE?8*`oSkNxRzUIWvS1n_)7owTDH+NUHAvUrW;#
z=Wjq4g4S7q*$`cLc=#L8X=IIWT39~@UOw*lDRso4v5^V=4QMs$Ha-rIm@QI<Mtqq(
zMBY3~oVMF%jF?lQrSqe6|8nUgA6ltycGDjJ{lC7owuIr{-fsZ%-5iY~q7kv7^KwV~
zb;NgNTGoHr?pQS5DtmMDH$dQSH~2XGH()mL(n<mojnhDL4n&5V4ox}n8Vd`@y3f#r
zLmE+_lb3t!h5+pyTsStyM*J#Kc8~b-<uI8+!gKF{_8Sj0D%5B!w!2>r3$1<wewz5u
zUeE08JyAxh$<5v00RC4IPJt=M&$9OnXj#7LqPb$)KhoGR;r!>I|M{f<?DE#}qhO)>
zBUr!Xqx-8rtee$dgm=@kN#i)*i3cekG=F{ez<NghtnOlAzeK|crsC`6&lh^qJg4+L
z?+-3lZAJc(&^_6DNL&7VX1Hy;qci41(;DL+CN(<t(zw^(CM*{(4t>k&_`4AG|86(^
ze?#LLBydaNj$GIKl-AZI9dAx2!6VtYg-O)-EaQt^AC8uvC0Pq6emxoa!|>BV#AztV
zJ<$Mu^Rg%yQ^pUpX3i+*7I}DyihxyAXh@$G0PMK`o1)zb>~^e5(j};0q>eL(rJ?uW
zWi6U|vrNUCu8%TrK3)gRZ&9_vMCbfqMlqEOE9NvrNlG|ZP~;N8rY%=o>FPUKo{r>4
zC(HiM2<z`oj&DkwJicEya^z3j7W$c6xu;FG?Gopkf8oO%_qecdzrWBI|6GoPu9Zrw
z9~vr*7{O0&Fee-~B;>_M>_uGq(XrLFqJH^b#_}_QF`{D#b7cM-aF2OAFkx3*@yo_-
zmzM|geEUnmh(Mu=|G2E}-=5fCCtMiPXa!A=XhC{<#CIn18rn7rmfHW-q?D!d8<6-s
zVwrN7x`N+mC;g3a_^Py(D`p<0<h?*14ayQvI8?>e>EAxneIxWO-6dH@3|r8(6FV_E
z%{dPoW2-8<CY&}q?xKTqJ|VR}E&xuM((&CXZ!3wu2JrZ+RZEvm(`tayS{nQ1<vxx)
zYp!jagjC?nd-YL9Wuuht-36?WQ5M;ACG*iUzY?pnKbWO>ZOh(yRleg}y~6nXwc`!2
zJwV0k-&WF}<Z%4Cu>LPMJK0lpX^(N)ZktRqWDm@*MZ7j13fE4*G(EJPFzb)6CD9(j
zY1>>3Wzm_%CqR$r@DzD(#(M?8ky5-So#k$wgm4uI)l`!Km5>{U&1HWBrbH^YP#ZL>
zR=Ja?q*3+bh(>06l7_yXq!Nuft05_K<`aA0CHi=;ke&H58PMq3``3lh`ZSF%{2I1#
zGU&aT|DRZ4oHmoR_CNtgAvV7OH!Xexx<~hQXtgORKYjx)Bs?r@?*Er5_>*0PXai)3
z4YjX6cuc|`f7w}=`3>+KtDofS>v7!;hij)03l3uuWiGXtPd=OBOGNx?#j}Rr03sZU
zz}KZ0c58X2r|c%-@w>iegshRpkS(?2(8Xi+k*e1@=r(8&))~yszeysqyS#iH9kxCn
z^-0{ThTjV)SaSF^2iG(8${Xe0r$~&29Tp39?KiqYEr|uSw8kDH{iwLi!CHF(kst+X
z+IOV6zx(an8KZO@<IHiSbj0^M8sq<MD~&E(Znyu?K=?PHE`svQvp3^a|ICkxI;nb~
zry9<?=ycUkPL03j#AI!C*2RxnPeSun`M5<7V-lmd$G!5lN(OTSN=nC_(wl&CM?(!m
z6R&Bcj|EWLaN1lbQ3WEmwT7~4{IZv(C0WS-VNr!bsf{xIDG1V>N~|CK(Ok&0X#`Zf
zaP9F56~e!3yCsOXF{{I-^{1Iabcx713oA*AZJ$(lR)eC-_ORffnqi)mT~UltIr!I_
zN!W1DImaw1i$bG@kmB)|N%E!FGcYF6`0xBP!&hl~XQ8y7ED`RKk_T^lm5gIKn${g=
zBx-YJ__NE<$VL8ri<w5wKwXNZUrl}g;rGUV)d)yf1L`72x#j_{N_jINwe8Y`GJ7s#
zEre7Iw-ohGvRUsH5EFvsLe;lIn<nI18r_rMhdV9lN-7XUp{C))N&T>8KSfEuz(dut
zOuZKLW?$tbhV1@fT-oB8(k+VN>2G|m!)FvoXH<=OoWxaTz4C@i8r?QMuU8<Uw!PRC
z1g<V!uyQ`OAak*(V5YJFHB`30J&9{uxjqq_#zK(9P3r}%VV&#a^=u5zzx)ljZ?io2
zNuuU4i-3lhlG!N(R>{$Gk+Vtm5~8(T15^{wDZ@R#MZ(xGKJTHUS#Z<`6Oz|hTNf!Q
zq<VX@cZsZS*uLM;_VS&roh7Fsr~8$csu$uDQ@Dce%tZxuEJT}nx_!EB3u%)C`xI<%
zHICFlh*%Gmv$|GGNzMXe8?BwenEa&##ip+`P?H{5u=JIzUu>w>FHVlJ>qwY?Xlj}!
zTmP^E?(+E^+a0d>l}wTertLXjCwuo;VZ(SW3Y36g?hRvA7_QJ(r&=*#6$98x;;e>s
zzi9W{_E(pE0WVqghe|uo?BThzZDhX4v2Kz-MnW9HI#VAFC5)07lqXuBomNuy0jvFp
z^n(l&O+__(zm(d^>Wbw&s(!s(R{A|7!@Ub>JF5&z0NM!7?;ji+7Q_$Zp>{0e7Qf`v
zLgID}y(QCOzG6?CWU8RD9qru27~d2jZsMtUA4u;(aA08H*T7fpWIv-ga{79yqs#6*
zG7NO4eRQaFIz8?zuoX_xm6WzQS|Dr`pre~T5EctR!f|=xi~i&XiY&`=@UjX@k_+LD
z3{##*Pw3TW>|E~NObFq77_-nH&zoA$eK5Bf%<UGVDaf9a-a%wY<vuTHTHW{Yu`SP*
z2}9Yw#0DB3->K%_UZ5HC98kk`TKtgxD}S#tI{Ra+=M9LJ{9HCg?T(Xz|J{t1O5k;!
z9>61z0%*ha)rY$mTKxFUvyHTF9~giL;(SA$4a(-5@N^1#%}P_AVwif62oakwtT1nw
z+*l6r^uuB*1DYFD*7f>%q7H&PT4#0g99HQKT63OP`aE>I!*eu{ylMmg`RMti+zfr8
z)I1t{G&0v%ys?-c4=ohwOREwP{6^I3lu)tlvr|XZQU<U6#pnjnD&;%2FC7IDj-LvI
zBphp2&{%6Ro3CeZdu-ar4NaX{-FD((!hdD${$iQwdY6Lp1`PZf#300vvJad6%)ANO
zZ@g}}ayFm7>$#0&e&zf`t_mx7@dmfx#U9I;PQFZ1FJIWAbGV{vINhCdPmN6PoKF7t
z1>JPXrHfafX7gmw&o}p5#a%r<bT#=~WS7*<ZhkFxer)=Rhn*}~F55-6En-o>cZ!<K
z7Qe*#&H8S}H>am^mJ;+YAzgCtZ~uji@!#cf{I&n_$EP4PjWv0b3Oy#$La*=9(+NLC
zgK-_3_J>xD<%jXZ1eJR<*LQQBy-lG0L)=>}HtQ3;nV4)oRQyoV&`R})@4}{V@qw_i
zaG_vrR@Y%&6Q8IAJ2rK8Q1;s83?`MX;1@9ml$WY?!n4yACVTKD2=lK!zSj7&B%dtV
z@q7lC;q4nsatBms7;-3+`-K27uQu@OgO^?8C&+6q))%r2Yqz%+&Go6B`OaYpj^ar!
z%eq${#U#O)1Dw|({yui>!-@mq=)j4<_+pP6!k=VxUI<dJpAyxp=_<N#mjCgyUg-G{
z_W*s2p=Q(A?E*!UWuL0-%Kiq_LOiaMlY@iSq-t?Le<$(OT3o&^`YX6OuumY`Qb1=u
zOD>2%Ff#Wt8$sOk8Phw-PUQm?W~ZhgTM@bK7q=~y1y>8@kOTO`^vr9SI$CSj3TEpJ
zLc7t_J;wlwHo~PZyXE%P@*kXL!Hus5?g#C3yE!|`RfOSPU=`veJ*F`}v<kZ-2L21H
zH$R(U4Uj<NVj%{`M174Qgn>eT!&SG=gDrOx)O?1>f#z+3emLWP8AfY0WMMg2#?5NH
zuIaVJLLDBxp)7$=lH@+R7=TNmubz5hk#tx(Wx=duO?<4yP4zBlAeVuvvPyD8geV5-
ze!uv9t(xj%yob-F8JySV5YshUql`o-V%)|C)RYT<<yw!d%Ih@tpBNwQ!Zhj}d&796
zs8@6ST-f@Q7vG2&+toa;D;a&>=o?2{Ee3G;u#vnXl3}lv)TU11kA;tQV!(h<+Rj0e
zJ2IOWbKP`3BHuIb<_PV@5rk6Agnqrw7g3s;GSUe4<DWg)^le?NsP`jLcbPSVQ3c1>
zzL7SooEv`wSekw?hBSZ8RBR?2zINnX45-9@;?mD=ZEjWY9<g_}U);R@{g*q*P-iIr
zI%qW@07&T93M2S{Q%rrkub%pO4^zyz8|(OmnUbd3*fkuWh|jw|l<+F_UbtJ&rNXi7
zeS43H;H8k#N;D6xd!03C*G;owX{eA^8}q^>Rs<*1m65jjkaSVEBJvl6l(wC**yXd=
zs?;h^TB7-bQMOFg1Zj6)x8Hy<R69NF;s}MjuzJJ8N#|I{ryOofgo?BsUSKZUYt&Z4
zA!?OsJe@LEdxv`k!l=0N&)F(3CRHj@<ZBTXm4r0do`=mZR6Yf2Rrb;`I15(4%PPhT
zcOF;ER~nBkRX&+}(z*(n4At1%HaaBL9fDM>GlYTd+N*9jl#k&LkJ;@&jVbN~yB|kM
z$lIALX(`gJd{x;liG2f1vP_?B!oBjc+KU~0lQMN>e1`^FjAHG~*_ApACzCN^FdR7T
zuJBO7H1>;DRbHK~NUJ<~X?N`qsoT_C1fy70+MFXV>w`mN_H)LG!nK>cMi&x4Z*=q&
zJnX0tHa%zlqJuiIg_sx|Fp9OUc)o{&NKEgk64&a8Kbs<vXuM5+Un46$R)`EFI6IZD
ztgNmz7u@lXTmJ>*<-VOzMy;yhOb2H2)^H*|-fVc{Xgz54+$(PJ`dfsqO^Vz?r_eF`
z3bA9cBojDYjCCqG(2-idcMC2?kTYx81FiT4*Twlvw%q2KdLK`+QR%IF#wltwHMk|Z
znQ=npx%_j~i)#}|jMdffM=x|f-$<#-8(4PuHdxYjh4wVF`w$|v>MBaDZHg=80Tb1!
zgy-1Y%m4Z`H#I#uJ_YUU)EwMJ^Ohao2`h(dN#F-xOg^ErT57qiGptATPYP137{d1+
z4d)Pv`x&n{eG2w+n-rT%AXv5S1N`{Lmov?tJOeoc5@lF?Cyu>woFr#PqO^*!CoAez
zz{>4y<z6w}r6*_&XSW-s=xCiYb=Xbv7>+TgF>;dANqt7&Th?FA57l<bkq@r=<0sG|
z4e)I<D&N;b?Oee)tbXaQcydU$h$L?aOzZs1iw^IT_+`LRfCn5=UTlvKYZHGcf4{BG
z7AkL}HJDYNNu6Q$uP__w4=I^0$<%4ow_l-oVy#7F;{^Z7hB;^>VQ1N~2)|O`S;?i8
z!x5I{N>=>lx#@d=&Gh$JVCxmgagShCKvPn{6Z@OC6bLlc=C=983_JOQNdr4cn|17A
zoco<WA`sSqKhTg&nnOPl(P5^sv2z<q!$;;0HJbSb#6E2OVL1LgW<uBXtMIegv6ux*
zP#MgMWTzq`;bf6#-ZuWy$wxXPlBlD;ta!fDM86<c7^4bNwfhYK5^^Eqcrne-odwg|
z=EI7Fg$R>qGww@UM4C(&u>N46=!s-OU2=ZbquklkcUU=8-ak5{q|ARoSyT5$*Kpik
z)nwY@rd`8G!9G+h+CX+EWk`rQEXk@edL`SoF<8v3zmd}d!fIq&zdJ&*Iw67H_}0zU
zs5MFDF*(2SL$>C^iPPWC)Er>DgYd3GrKP*(o694JN=Qq?Y;KjYVX|8p-f-@#@sIh>
zdXv>(yd%8XY83S#5}i=Zx8-5WEMEhCEKbb&+@<$6G7wD>Glz4ZN0;4(_6F>&7aOC}
zAm8(_0$j@IGz|%s=m|6a?5X)|Z%>39$(p{Y@gVfMTnHNWsrvoKt1ENb7ud@W{ie8G
zS3tCIQg$J3pD4c`V6|1bc^3F3>o;IyBLkx97wZrG(y&$^AGO}RlS0@bmqu$+-y}LB
zc%1pQw6wpi8P!y5iH<*u{PaA@I**W{EHGb|mt6wY9wScb39d6URHVpk_!DOGkFK<i
z9!e1g*uqf8!#CrcWcH*dMDGD%D;J<=I4q8)1|xk!NQK<a9VpnnP7(Lg%$4CZ#SpAi
zz<3FACmxoUL2C|fN!>QA`@TKKn*Yn!-Z#)wlGc~@RUbUOU7!<sS8{dgx$51iT0kw=
zE3wvV)5S`7|LJvBi6GlLoVsn<LG{{aAH>y|3XrZ$bw($D=`j%IDRw^W$9y}eJ_Lh_
z*|SF*$&PWL4>)wr@Vxb306e)f`Sgj3_XFNyynz3Vknkq7TaZ$>SH0c1Pqh{h;vXK-
zm1x%@0WF&z;LU<<EHfLZd5T{fu%BsdNMCTVd380@a~J&vEE@?I7qYu&AF71ws~cMt
zmIz9GqA8G54zc(;uuGNN&d8KYDvV#VO#Unun`dcXiC#?`7QCM%!uF`yelg{C+#7up
zbMah-@q8|aIZO;#zG47A{GBPZvsHjutXLp_fU3TG&~1flj=5;C1nyXqD%GF3*yA5?
znyrjcI@K8Jl-LXtWd!nh^UoKz3UOI;_{@4zi9?I?wAI-bpWDCKgVZ(KMS{il{3H#(
zUF4lvF{-z$BDF+v+%LzDcHFXc@^eXUpE#Ah&eX$(%Dip>FGYHy5(SfUn(FElkcMGQ
z)g|)~Jhw}gfpsr-mPV(>2a9>S7CgUts6w*ROQ|-i&|ALmDyNXc_TGs<`xeiur?>h}
zZnc{#EBAg<>blrysmlbdEEuqEK&N3dDU+Z<vUhUwbOCB<a40S8ps;~7ly5I5MJM=F
z&A7GLeV`qF4qLx#zq+#`e65Ao2v64qxC1KDerVQNMe$6<W6%x8O}OlI+2AshB!r>9
zLI5Fmc^3TBGZI^GKYN}SLqy;mc_pe|vu!H1#MOx~ZnbxOj3cIVK_v~tO!SKdoL!+%
z{}FJ56iyRPpzRU^6_pdqh_OA-Lhy2k7$h))mIZtsF7$FWfN<;xpA6B+TK>pkR9!YS
zqx5MOWrgL<9V3L-QS^4q28MQJgBv~hu>*R`@U{JY$+n}Le?jE_CkQTQK`zEH%!_Og
zubuVwK);hNx6+LLB*PqXF=<{Yn1|Q$Lpsx)i&!aLLjTl(`Uf5s$+dPrWXEK<rS;(#
zzC^Uk!aKG{06_nL1hSswvmjkHiwk!=)pBtj-1o#Y>Y=08mkXt5E%`jr4+J>M?$E2;
zF5C6kF)#Vx&hm}j5#+COgC+3n+&dHl`(AEnt59Dp4@cGCfGz)@LB!u3gZ!zeW9HEK
z9Tmz1?sV^$N}P{ks+4??Wvh^^z4&24iS{~firp|%JTDH4ex`>$n8Xr=Mn9)~-f!tD
z=0~rTU*M7Hx|eYGAWP#T-Pd!SpNN7xqZ|1t4uZMtgE2;C(Qq@pZt8KPw%!!>#te|@
zD6j2dI$&e$t$o0@`0J5?JC_XbUI`Lkj8DBlU(weu>=_<e3||bO)pBqVelmgcyLBQ-
zOJY?UU6D>P{$DAH8!x@bPY<ivzksoJDh+{K<%m$|vCS9T<CVp&j3B!Z8+Em<O*wf9
zl}YnzWY<sn4+i;Mj9Pbh*?69H@I;=WzkH`C$s{=&Wvj1RxDoL~H#UP?F5u{TrEQ#B
zpP1e+XyGE^7FADud#_5lI)39@FLN!YNVIwhozW8_;nYVSI3O;G47Y<7WMsFx)-`2=
z1WIPficO;Z5W@EE_uB_ky;1pryXNMs8_jY#t`&+BI|^?eN7_>|PSBkUKMmmYHqt*3
zlgGsP!~}0t(>6y!!|w3+VqmX4o)k0JUxhUD?3XajN-=ZQEC}?U)NQCAw1-@%Lp>m2
zn1u`Yg&Qr-<ej*rnp(T~wDs)9ClFY~AUq(QxCbf7!baO}CGAu>a!6pAom3xumDoB}
zqvw+Ng4#ncoM%=-dce=)&Cf`0Jga@_FE3%6;db=4IWeFTwoKY@%;xb-gXdDoM^(V^
z7hF=Gc2vyXkWa7+R3*A-ZR)1*I<)SYXnrdv`~Q487&}mWFj~~D$BzP+*%%M+7viAU
z7-RQ5j8rse9$HW=h&{xL$%h#`Hcefru(^7CrA0;{J8>2c%CRY2zdijzvAkP)EV3mt
zH(#ZxF#w(R3F9{lX@!QV4-)ai`-%Dog5$xPo<|3hgaFUP)OWwG$en++kN_Gg1Dz7B
z-eq;r3nS_R9Igm|KA8k~l6S$c)lPM{4CO;@uvyC-SX*s!IY5#s^d4ZL5Q3p0?{2gj
zm*;c=0SQ@K<*#rJ%&SUvc*9BuoN)9};)Icdl>4Ckwa$IGaC2_d<T~XmjT7oe)>mYA
zuWQ>mTwh8wo18jMg%;XCUb$+Jd15drsGho{EJeApQW@osV^vO>wGMjOP0R-4<*`Y~
z_~<2F^SvtEFAF{)_7MF!SFT{ev<iyTZ@{UL(VF8+m76Q@nV|PI1AG>aNQFD3&(}nv
zW~7smvaxSYBs*B1yK1FO03rMu^ft9uh{QtJI_nSOPQwZoX;ye$op&JSK(~vmA)i+@
z0!t^-sshI#{)#FNsRD#XWRL(;vXJ6QCeh>vbl$r@XSqg)WfJ6-9);XHcO}dt9Wn`b
zq7LAztT;sEL8c?EBAa;9j_&XZX~?eeJ?nE1?AHCMj@Z|3kKN9nXoPdCPWty|IkJcw
z^ww$waGDN<j}=OYPeCKR3z@N7yQcdMh{inQ@J<33c%BA!*QZ7J_}d`$-lN_Jo|0pq
zPLt3x%Th&%R&P>Y5-1<u8DD;_HOL@LM`vjg|F%%5uOQ#GFAcV|O)Z@KVl$f6DIq>E
zpr1(-AlYL~n3_muNoI^s@G6E%*F=6(IsevKhFy`?Y4I7-{D$SJ;Mpg4X7}F9=M|Tk
z!b^tT%^L>mu$kyImbsoKW&R=aAjy=9N*iOd{)uH94>E7lFK@>Z8}(Ld-+OUcl}?HG
zwY((rM>Vc59z`Gwn3GPN{t7tpN`oe_0}&FQwAG@d5W{<kwg+R>v(-a5*RGt|Di}W+
zi-16(0cNh|o_R4LW1i1<C50XsR@SFh$2>miX9VM5FW<~;SNkC%<TTST*BgMbQop*$
z<q6*rI7;VFa+q<>2?!w4RL{4pt`9!>qmEN@{a6dDdfZU<8}OzyVs0gjpO(q*{uL3W
zU0`ni{a?%-L(DH<+DUdxP5YN|n3jlI`^JdGO*xH8Y3>o@0n8`$KSZDYd?M$+Ef2-0
zZ8Qi+Kqhrb9No0u(E(3RRFBQJGWt~5ya~Px0^IL9?-BP=<)Y$40*MC<esHBNFWbz;
z!IC<<v9_Y8T2AZ1DELI`KLP>&Fn4TL^RWndAa-(PWVi)i_083hyFR{_CUX3Q#iElV
zie0y(XbIpJJhGEkuXuI`y6nI*J)W^Dr0S$K6DsqxPK1Hp8O+32@&x|%A7CZ_L$ms)
zOy_@*N<AYfX<vC?qB&1G@?CxGmAfwI-c??f>A6?*Mf?tDqSmS=oQhncd`~f-<(hP&
zYyfQtvuNzrgRTFCmj0iUD)muRc}_mW+2<=qpGkKf+HjoXIUL@}i@Y8&g|xm#n7ud<
zT13}BI{K;L4!XLCH%j`2(H;`m>EfU#D=prmCoK+qci!(m@q_H4*YDfP*jj#g_Nbbn
z>&>(B!Hus53=;Hj*-y^Lm5T==W>3JlEfP$%PCaD3rO+J{z*8^dsH8NN__Fs}%!clB
znO(q1+rQ(j`E&2r$#XO!omsjN$`^4$|2IJGSyW1b4$AN44=cdC3F#_lDbLgIeV^!D
zS=@c1$o{$hLp!@r^^GTLhHXu32*V4@%NOe}?MU(R4v#!~l_%bFkjd_I7%Mtkv1Yun
z-NE2UOIey9Pt*@?bBnAtl6G)&z}<me{>MMmWf)K2WjHDS*NONW+2G8Ze*n#d=-YhF
zQ<*Mb9)twEo!E2EH$Ol3+DTe)klbcm3$(AjB^}xFMijYI={Jn7XxdF{>V&P^=@DS^
z#bvs-l!zEZ;jxC0F`|?}iNOMRI%1FBmX<lsZ$FL>p2r?42XlNqmeBawzNwwCnBZAp
zwOCh%f=GNQuYhbTn~}jf3$I~kH^%bf1&Bysb(KM**S+iamN+D+R<?cl5UHuL*1L<r
z$TSly*Hq`auU@j1REil%xwxIIb&YZ~lL3?1dz_At5~y?U)LN}ZRmYXB${*RbmgY6-
zSvn4#=hZyX$%)>0Ya3{kALIlaij;#-tA^oTo--GfO|lkH5t}Gxqp6|ri5S}+daRKG
z>IDLFDuH+h2?J3=GlQ^T7FH_{%Wea<p!#Y`c;@aRx>dH<3g5dk*>t+V?JEPaKCMdL
zM4oVPMT!jJ=*y6Tv(ZkMF%j5%%Nu5<phxqzht@f@=$H_B*c45;h&ogq0J6D;+Ubw~
zu$vZNVh9vqF9xH%Z9LLEsr6Qleg|<{`o<5VNP*bZy#D6}<E?UuPjK#RbURhuPbdz_
zyK>N)TS<-D)<YNvlcPEI<_dqG(#*`#bZ@x6))%TZCS_vQY`=kl*=0N>c}Q+(zXpTR
zBu=cSg9Y!G+CZdACp4Lf@>%asS|<UYqA8uvy9I}9-iUww=vxcW-gqqy4_7Y6uPpjP
z&YEG)`p3YuGi_IeKz+2jNP<f#Wx{(NqttGBa2?J{Z3@=C1YHbl%}Ym_4`@c1{%jeB
zdF?E6qNk_NpEtkKD}r1zk<q((*)!<o(=&FW!m&u5vPex0MBb#hb6&nOMQaa2(l^jY
zz`beJ*w>Jt6k0%M_}V?!Ko(tWGniz;n@+mDk}IN+w<_;eUF(dU>J8pMUIVMvj7{sH
zE!JMdtwu6|q4)Z2;R5ZGjK~kp{LCO4@bB&El7Ee+njuFe^_Q8I?phTh%9;9GC5#Pz
z1E`QPqCEfBSRuRHP^wMSthe34Ny2e5Ry5+G=TD<U468;|$}ddBqFk)NAWp6r@p{E^
zlWplMf7~3<d-n5ibq+ADUL4tT8KE<Jiy?vvx^S1AEFhSBBUFEO$1H=~*eS%1LiO9O
z6l<rIVoMw17%iwmf?E|$Ch3qcjHP8|@MeooGsOMJ#F)Oo7|P=V*_s;kNygjL8RpI3
zb2*|6wR)kPc@MSwM4(e%5-jgV#qQ$s$Uv=2xsZuP!Ch|-T}c~B^pZkdu<FtRBF`hU
zHvN~)=GHpf#Pa3Q`zM-V0inCzo#N%XUvn*)a1|%{ufpHPb#fy4THZIWJ1K|O_bM%N
zJ72H%N4XnF&*@v<HW#bKU<B3<c3-VB`mOD`mq1t6+4X^i{tcrW8;k4eE2W$7ey(ob
zzgUl9rNAX|H<_9t0p4e#dOyoyU?;oP@;lD~&~hNl)F0`#j*uc<6(LR26tFL_P1>vi
z*btOHW;>GPV3OOhB!rXDG*Bs;_+bp2*l#zPPNt9+MRZmUrAnzw7!})=eti8?kR#03
zE#*vijmlj=wb3ruZiEEynoZZ71)Z6730Pq^1D?JMgFs;XnIxz-A^=)Hft<4{vmla(
z;fw8+5DZn_B$*VTbqb$xTVQBgV^ybhR>imZ6h800EpyL#vF<tGD>B6D9)>SA=VHl}
zo|zXZr5ZoKWSXE?G~lf(-GJ>mT68a44RDI%UsdWiM2lWd4_+48go@eV>1#nlLOrWJ
zThZMu9Us7pX&1|@(0Y`Zn_Ls@5^*)M)(Rc2-n{QrZ$>Nk``j_p`Fb*+rXatL=to?`
zdm=M(fkGj-UC8FJv5>yC@9DxKU3#WU7%{P~(y$z;U#`pS7S$&YhkzSivl+wA<*%UM
zP%S#)IWt|EImwcD-42Nl5*LDw&0@iMD^6bQ)+aw`A&sC~OS<WHSK+r}2jZ~d&PtPe
zOiAg;xb(R>_<s9X$!n@scj{;BUaF)y%fLZEER1EX7VFp|3$;>s@9D>o?ilnq>oFl~
zPzPxZ)`^9c0n-El$v0D<Jywx6V;fGZ|1rdp(&B^n+kQrspOA@9Fj;#YzK%~Y#0(-y
zlmQG2QB{|**KI(zvmivdPifhLNTJy>oMDf;p~{a^-)0>2%J>(7fs)bCFHczgK(#vk
zcdoRQwmXFO&~?|xTT*l=W0rncBb%kkT0KkktKqLDUkkij3Vjr|Xxr_4(1}&q0#_eY
z2g~36!#a5f(A4Q6liRBShc9TgJW`H}eA&l#&4)7TGQ>*{{>7bAvun=&?<v^-hkhKb
zCOziw?{&^_)!W;9y7oG$HSMAV&~ly6p~CvIPN0Ov<I;#`0TSxa=;Qroq5#A&`pxJ)
znsUmAW~LVp?wlxze?oVM<-hO>8KGAFb7;-Ms?X)_w<J%m@zo?06KXyR*)Maxl{k60
zbS_03(2%oi1bvk1c=1}fbbKKHNAy{9j@&mFVq+sq&jK%(zUqn1djkCj`o2y}R;y^F
znQH1CwBfebJBSeKxVD)MVmDs$Mm6ycyU?Ry#BFgH@-rW;ydD?7C%uGzb35!eAjJFp
zg~#oECUg-~%-}`@I6ZxHLLq{8JmieTAs(@l(Gx*ddwepyT^~=H+3<KDP1abue_g9-
zw+o=53#h%r#(IN=w6;x$`2yo4ltjuWZyXo_MVT#<K<BU42*ZQ7-Z5&^@WVH2G~%HR
zHeyTDTl-hCy7_F-hhqsli(_r*zq&l2ngN((LHvB60~+e{5Txez<%;@4_{R#@ld3v>
z!nVsk@o^Z1Dj2k|0B5K;egl)d8bZn68m4Yp?MXJ{Rt6qbqe=Jf8FI9=da;QWgG}Ds
zQBrfdlJ#y-R}|8^()~PBSp+*hU{2BYX=p@wdOl9GJPmew0=^=6Ht=&$VCX6OilY?(
zqX7WxuHi8!f_q)PiogU6fHCTsYsB&Bh`P#W!;*`8*su#=sWbOo`6YK1&CffORwwp+
zO{yNxvTzzZAs3%GPs=rAl%S6V9kd1a@+O;vH)<DqT`|=e#hrPxg9wOF{(ziWH1IA^
z4`mC+Y;4b0!3WLdlh^BF9(pp|SGCp)@<jy5Q*+1Ioexyxynr=zZ6CnRH>P`uey?wy
zy2Hlt>^`vd^YFYk3L4NEZnIWewxhcn(1`BWZ+nD1xY#9@KPf?3-T{qg*_~^#8U_cg
zNw|D?w$k5y<$2}j2aoeGa!hR>-wsvqnO!&wqHA@ZrviulcaMdSQXtAw@-DL|eN|w=
z<U^!U;dPsvrFJHJLEr&x1e7Z8hlP2Dx8Ea_r>!9*7mVHjWokk1UZKT#&gF@ivR|;6
z&GP=();)G`8h67Txp_2GpHc{K^dL4OOjUteSL}A?R*n!Og-)^CKj4`x$v0w{>dkg$
z)g%*M=Oig7y2L;97A3MUoHEd@ND?rJ2l>RVuixubS1_8ZG^+%~4Wi5fg3ns|e#a_G
zI%69aXuO!*LP<h`xW|@!6;(y=#H##I>oSm#didtDq}LURsYvO}mP!xt@e?hgPjLCA
z1o-}>Nity!{GhIS*Tcqh4(dlG?l13x%Z*Kb90td=nD_UpCy$@&FCCs&Zxfo!@k<kV
z?<amTt{-jo$S5Tvf313i3<UaxVr!ZNabohW5V^Hf^ExB<9T;{C#=qmf3$#(iUd3<o
zRsWbCrKqu_DBjYOYYQsVezV!j2ViT;q<{0|&Lb8jBU2;O6S0vK{m~?vTw72z1xBr&
z9ZzqdgjF$b`=GI7He0&Gy2C(PsWcYa^t#%m`CACoP*M*XQzYpCeF=T;cA+A@&^$xu
z#_8t_&LFj-9FZyyF;t?erGQ(JR<<a-PdY_r_;7JkS+xy#&?}gX<bdxEZEhBj>QbZx
zW2Oia$r)Cm#Y7_EH8xP@e2AL|>~TG@8k|}dT9a<@<^f6MTYIrcyovZ)Co%L@PjAy&
zbaK5h`P$sI6|AdLrx*k(R@9|X1$x#b>%RU|cPA;ILBct}O^JXAp%&F@St(n&_X!+{
zH7m0Ed&S+&tE?$cyKgVfJ0$s-z$4l&`su0#vg=&uHE%TmwZ;m`sodb=!u6V(z7cOE
ztSVccGG|@4=$;6_s2#eso0C#A?u6<u7AQr<j1g3As%I4Pa5*bg%R(Pw+xa(bDy1Fy
z=hY8qp76#C58dGu)ygea=0{0<M*_hk;OaFBtidkFOt+Jt3%u^B>4eTkO!`xTD<uz_
zy~nA)0d5pSZ+pKEKBS%_i=bxbU2)%5HF0B!3PW+7cgdFsb9pquFqgFvtySh;s;Z{M
z^}2~2vw}4w<hI?5Wxvd|Dk#+xtct;4R41YX1-rzYBb9}KGqunmB4gAy>&|Q$yENHL
z>(`P3>$CZ3^%rJm=v67G6zZdAh1c-A+%1`F)X92E0BA_w=|#w<Z^-y6un<23*TO=5
z_>*8T=F9=4`|<hez|NpGtJN~TI>o%^odgvgkPHKA$Llq_TZ_YFH@U}u-J!)WB?U#D
zTcF^otScMV!=0Vyx|uonU(#+0MX*tvlK2a+VPOTe^_0*NgJ#1>@hsJvJmeHjFAdG7
zDqA)q$DdRSx=f$$KY+jUB*?A!+&l7vJ<y}wAoma*@Jcte0T)u(9njlD@qsOUKHgOw
z8TUel=w3>-BvZ5uL@>8)C=gj}q(YQ@TxP!WqYDXDvTtr#Mv4l~FZuJ98J=UfrWoLd
zoy9rtQjhrsU>dmP{ovH<U^xYIf>o@?Jb3EN8)=(o9rs>;I7ROyO|4BADo}Yu^K>O@
z^EFgEH8qlRu$zMgdl}#Z={egBQp#kIMsi&6y+1PLF+>{c8$$~raL}e%G48z(ZXm7D
zXXBWADseG+H24oM<r>}eG3~oVjQKw9__^59Pwq7f&+OUI-b=eZ+S`L$OFs;q{tF}j
z*AU$$IlH|Z?`c1&K&##1$I&XBJF4xre};RjA!xqI8Crl%*pnTD&L!mk-@pT1+4A)i
zA7&FKpb~%)$o~Vtr4R7FV%-$iG{_R8*?IbI5|Y+o;*@c&HY6h|{KibO{)f4Iz-rFx
zo0{?RXI`BsDWWsI^AW%ZIQfJD;3Z7=zfh(B1ZDA6X-vG8;a+Du)EIZK?rODaO_U)@
z<WsXGFw*1dRVGHq01zD}-~G+fkF!(bc}z&H8IMGrrf?DSUpAMFI(VW$9bGLawf-S6
z3#0#T%W(AuKEEjBp!FMt0$6!@oUSZ(k;dLH+t3Q5dv^}%Tnas(zL@gx#Y=@9SYs&n
z6moU&)a{%J0cT~3SM$X?94am^opVngaO!aYdyt&<72K9CKBTU&S^wKxbeKOL^B+@j
z!}(oAM*xkKS2o<V&s&pwsGEh^P#cY4!Iehv;jw*x0&P8UKIW~**KV)H3y+JW_~;*5
zMiz;;T&TQUBHMkLf!~N|1SUAuRqqQ7?J)$5DIC&d6!!!$VOP}u^$+|5onpG)z$V==
zyN778a7lZLw?_og`{Y>%wcv`?+da_h31b^0x@$?vdI7qJw7Px5yE!hu!Qr#OI*@;y
zPK_eIwmM>G1uK=}n5fwF13l3i2CeKI*qZUla!9!w5W?M27X7m_=#kjkqb2P$<<rSd
z?>RMX1lU?hFLsiwOx>#n2GVYHiA=7l3%I;ASRd_Ao)Iz3@;{KgI1o94w{tr@N*gih
zvNC@K_mImJ>R=%|$L^%()uPYG#JKTOueYD)#%p~QTXPVs$xM24RW;7f;JE*8RZ2zP
z4C1FE{kU-*uvMTdb58a9II8g$@KdMY+^V}^E=g@5bi5i?usc`rBHcg6tQG^E990>j
z&i3E;f^GSwDaHah<1e;-Ixn536D?QkHO=$Aj85`eO0Pn)GxNI2ph$ig)gZ7rU4N$6
zWeA5I9`2V!=&l=BZNNteyfiXhKFJ85Lm3t&nY$zpH(}foID=Eh1Qq>9m>xWiw`h^2
ze0GuUxB&_MHF|<R`mwUD@dAf$v4-pQV#}^fk)c?uv!pg#)l5kHOpNU&X*s{$Ks2{d
z0Ksk&%U_lrod%cC?NnT=I--)HdhhE3UL$S_rU>kgJ-klh<d^Qk(Pz6J+(U_VEsNeV
z12vjxo|o#G0>V=zbx}FHMi~QRl0Z$R#vRbFBgzJ$^M*6qG(LYd1$a*)U}4^z)@N<w
zVAx>1Zv?TT=ISk(3-$PNY6!oDx`*|I1aW%TyRS9ctdtIq6sZy7V)d>_yfh`VYxzye
z&Z3WddsUSV)d;)Jm>5vKQ)X%MNPQY9FX$?A0PP)P&`UPgU4^g<K|fJ(K{hqx2s9D5
z#KIb!!P{}(QgSA0vNJWy9wzoq(8wo8!Rv+pnG6=XUBJOrf!kKMT1<v?FBj7oH;#xe
z(24a#U~7Q4!A?M<rYPw>mxK`gMB}FIDycf!fb)xgEmBX*Pr;T)1;2G`bR|Tq0$l6F
zgFZT-^LTat6zG#nz&P8K381#uZ=<HG)b^`)G_;gDCl+87`K&*pyMwqDx;SxduBxzy
z9N{7jRNW?~SB!<Az^h*ZoAi9c(=w^AhW$pdPSJYybM@$T6rXh~eXC<?rYY}DOP5D<
z3I3LbVskO+rT-Uu?-|upyR8k!`q(Q)L_{U@CSAIsln_HNl2DW$LW1-X5JeQFN+6&K
zMS;*_Kp+H?P?RP`K)NIZq=a6SD%CH0pLg%G&-wNl<JsqX-*<dJ&M(FqYYnpQHP*f6
zoY%bObyW|FF~V0CBnzZ9rwe?=sZC2PGR8DU%_&$+4^K{JvImWJ3RTcrFo;;2-c%m!
zW@^%q$Cjgepqy?lIJXUGN>)(2(6#Wm_4sR_?F&+#Z8X6&d1|Pv;iNwiZ5<wvoS8$A
zeKwnvQv60F&DL6$9@w#IDG?gonc=<a9mUvl&K#_5NTZeu|2!QhqlkD36^#f&x;zt(
zP=~eHndw9iyR5p+Q&vtkrtmpwi`}hpKIjHn>5vO)veZoP>yGilLXAO{6})0aFuNZ6
z)nG!-fRuATCQiky)2iFZ=qL1(VouhGd>3S!ls{CGY36m#p$X-*ed){~^;s77Ly?Sj
zpCCChUdLJ<#J=(BAU{{p-8$P3M78)?C1J{pgvA7@8bhl>zNg|4xGsMla`quNF_k%w
zlt9M9T<ap$GRdrbSUN93>G)dwUjJbn1CF)oQ(U;yHu2BQ=2ebY7%5o!vL}ZnGSz5-
zsZCipGXz$hs`nH81|qg?<WSO%G@p7HLX>u7yJl5Src+4)*~lGO;q5~mxosXu&+?;E
zvHOJ2HAk?K{kK$;b39cFoR@*8OJ4X5^Qb=ci95Uy!jOrUM|sDfhc&uv+x+lw3KfO{
z^+wlH52-Kt73jRrMk<x1N)^*VO)afvBfpwf>O0Y=az6}Jzvt=s*gqq6Yp+N0W{DaP
zHS|3(=^9EZ>e`hNajZyB>?0*BuB0-~WYeS>+qT=5g7-Euf&v%ovG%g=G=Gu4zVZ15
z|1X>7latYA9?F48m`D5gNvkeV__b}r&raSC%fek}dE{;@o=rV#DARHtSo^W7g+C(p
zSZM3VG^&$wO>0a{h_Ahej79|wV~huZl)|W}*)wM8H>y=9vw`Uhh{GGh{!)13u%tB)
zjX;DK&w>J-4vm(J6F*5dT#Gm9U)Dc&mz$OQ;NdfyCs(CAZjNWD3G?#xy$cUH>k~`L
zO)`Nu&Cq>y3&bS{w@YZ0v+z1@(jrw)-Y#sq)etm?ST1ja`>e=@*pgZvU2e}Gnwdmw
zM^eo-yYm(&&h1Y%zsiyv0#mh2gl@iMzqJ_p)zTqYmpi<O70I-_kDuIws}tM6bUK32
z+g*N-#N{T8!s`tY=Rb!BI+$fPNJ^_p+q+S~B&#*6j?WKAB)%}KD35FITsC!5#ORkT
zF1iAxUBoKHdI$uY77*Bt`;@h~s%)^H986kf-N?-Ao?@z|9sCyJGN$$$rNjKuk`0U&
ztsm~h^#Rt%wJ_P5nAOaY=Jz+@tNniW=nkSN+wAW?_0yzjpIb^73Ou?&YyFHAqQXs1
zfAwGOn(nV=O{j&+`ufbBkP~+cydsf53(}s*_(O4DOXI;|>4t%l>YCK_E@-8s@PI#N
z#^~5>mb4MyF9c^OK+57k89?mg_fr4?z}rKAuD7d7vW8>~I~C5{56c%jf78IC>Sc(~
z`8uPgT6aF@Z51e-cL6B*wHuv;?(_9D>NYI>An}v-<7abJa^mR|d9T9sjsm{^xgYxX
zbo4(@7@o2Z=c)(BAqh=e*akPmk%w2~DsQB)OOBn*FolAGuG}$b1nAHN_DCxTYjr0M
zVfA*YTl6KjC(@tWe6<C1@IkN7k&ee3`~h-v^2)m-y&z<8&Hm-ZNYh_p2Sll}=&y$g
z|6#cCwES1?33XEV0K#GStgY#uu(9RlWl!xG>wfJ-M*oz-U-CHQSi*}Rzuaufx-PRO
zRcdVDmUWwsHYY&k$|cE*X7^BcPuwp79?PkI&r%}1FW#LjUWTCux)+!b4+JKaGBVcF
zs_bRIj%sW1NTT-t%G|rfTe~*H$<(tlsKoG7_Rm+fV~lsace=*6oR~8yG!!w10rr&g
z#Dy7Ia_}S7F_=y$1upawHGx5r&KIYhdH#y_ye-fwwX6UN{uSVD5@Mf|i<Q(5@<9)E
zv#ny-edKr#@AbrIoRT1DiXZ&wo(K!vg2I)W(vdj}*$6r$+`0rIF5BIIZ%wB;@n)&M
za8)jE1{d7k=A8fiIR47`5yWU6wl$W`d(<d;qfqZW24T=@F;L5|PEKDsYB&A98+k9r
zJeu_5Q|r+@qG^Gop0!oKiftDdHoeR8>EI04O+zD7eQfZrJy}y9(BK!&k6*u;i1tT(
zlFWHYz4qpy#K@cpZ3m0BNLEd)<wOvdtl@T85J+8J#UGj8o2m=kB|E*>oXjpv>IUg~
zSh3TrVIueqFP_&dt#Q*Ni=M0G3`sOx@qu`S90Yh@lJOi6Mw0)o{EZOSesS@Hux#Rh
zlE*i!cCg;V`SdiRs2f6L2$p18wqY&7-k@^V6yIvJsSsxSLzEsBNz8VkHt3W6EwAQy
zq2M`{L|s(7TmH=f;dA$0D9aDzTgr=o#}%(%TD*C7C+jXOGu{J<R<mX3SQggVWid^s
ztm&ZMG7OR-JxEmENDD6Pkn4Zcgnzc-HH>-6*s_;{i%j&bb~*HgdMn{=HEH_7m6Z{7
zeGR^b&UEYvO!FQ7VT1cRysgnfK#b(uL}M0QrHv0RZWPc}1NBQXPqKrhxm+MN0+Ts#
zPj}B4G`}a7U1;qu%zY$xHGwYH3Mo*BK&6Xp5JA57HMR7Vjz#4ljBtwjJ16x0$P~s`
zvNist_eOordp^)1i-LAw8f>sYSK53MqT)wJV2PUj1uV}yWN)xVPwfU2QPd97RE9S}
zm0Yd8HZNK4eO&krARr7g>tQ<<;S!CVql7()ku8YOQGdyH2|Gvhg`Flf@=>8+Guz<n
z<)nO!lh<)z*+Bs_<rDixHY}c=2_S$#`JXe-2Ww*Ul#5G2Ex?IYYr2H#BvBF}>vTIs
z1=Lb4Roo}SaPa82@*J-EdFcZKTBSlU2L(7YrIb@u>>u9c+%e1+q;ODhE@%6;l<p(v
z-S0<zAmEgCs0t!%0j`WOeLBquq=Bl3^txkG!30`dQAYe0l?CS)MY-<rhVH62sn8mf
z&wTvAv>VYJ@&QYkk;VG&5a%Da9AxGS`RD^*{1kh*J$TANR>4S3e^8H<p2J9r4K}wj
z#<nhc%(kFwcE{9jr>oaM3vt`(P3C5BR&jtv6%E~qmeiQmK!<*<_mXH_XT}hl?|fj`
z4e4Ahdl)Cdyt&*d?xXWqIF2jDHB@BaHN)dv{L3y&m;Rw{?^sI?b=Tf?-MXB80V}qw
z_HwSx)I7dWrHYFgSX0t>gAlMvGc;4zK0c=sQrMANqKNdmV)2@3%Mh-UUp)27?zFP}
zn`IW*fS&3@wE|eCN~E+?Mfr1gnNTPUB<hFjV%ag4RC1_R#1xtJay-p@p5d`!Y$@!Q
z-t`3OcKW4%nDMrmT=1#1AD@tLG3#f(`&*Yc%^a0+R<8=1$Hks{RGRgrDH0Y)!8EK>
z_pIWOS*#brS33ksq}vS&fz*u@&DqhBBEz)SP)6$j@|KK6IcP=QSMyrwPkAYxE!U@>
zNMX$SShIfMbFdTY#K6f?z9EDBQ_YU?ezvc;F^Yg0H!Wi{%g;_%8a9z9)(sl&d_%!9
z1MFAmG?CV0KA1iuiPqL-qM$pDB{oRaRIx3PWWkaec>@r^aI|oaij_Ppzj8UxodA9X
z)t2c31`mg0vw3FJ`7Rx{2F#z$NrraOFu4N_%vd4CafHJgBbB{71d)ksR}OYuQ?l-n
z6=+&I`7l)>5R7dk@3F@Db?HTjdp}Pw`s4CptbLQ;hVO~KmYym<2TbMZ7UD->TwgvG
zHgLWF?NqGgbEVv34JBQ|&r2jb&HEdWz}W2UKJ_dI`hru>>>7|vS)FYx>gax22371X
zg=aK+?;mRT(UOjl6hgY{)$czgaI7@#GT*)H8WE?Jo*IHvpn0@CTA*EkQ;fHVDNDWB
zBDf+7DSf^{<-qOd>ULUnBl8t{To&=@>e<;!lLIZt%iouk?Vx5+1sx?x$)aWsC)nH&
z&+1`RNFsO?QhpMXD&a9J(F)fe>~Xkco}96S@sK!+oMp17SWKc3<Z`CT6;6P@L9gAs
zNM71nr|;>MaHbAQRuegnk+P$Ee3#$YMP>aPejz*Bxp}cXypS_is8dsXc8~phb5H-v
zSB`pIL%5x>QSrg`f140FZuo<p5y#!2{0{3Sk`gR`OPxK-8+*v~neL~L0v({1Pio+k
zWG-9o3Ucu>%^0ihnT`Hd6HtiuDi5la4RmO-PFfNN&4ek`j-I)<I!#8S+vsS6`^sz+
zr~;Ue-}rSmqxm)x=qf8)<ehdlXMp@`EkVk0ywpR2Ni<v#MuT%xxCBefq8f50GhtNU
z5F1VM8dWGr0TO&%jee*9c<yVkt9BWY=hArl%3<%?FU^3n&-wE)Q|oEW-ZYWnc0*pa
zH>Dr7>ks~Fipso}@NKFhQ(IPPOMO{d8ljAX&s@?v9eIgm%d#(pRg<OFZ@(781{gRk
zzkQ(?|Mq}Xmi5P`d4<I{pBWO-u)df`LRM(86{bRh-p5cY=by${^7-7j0mQ0u>@yfM
zHg=SW`64WvoN4XT69nzT)G5OaXN1ng7I$bo_1Ydun%umQndH{qX(Tb_k%R@2TrR#s
z5DH=V&iR?*u;#eY({2L1ilUDSK2fSFLZ;mqzb^L=%vWa2G~utHZ?^MXxyg4|f`@yA
z|J}DH2YKXMB-RK72I(P(Ib-d{!MgP+?UFLxRTj26SrZdk7$nP3T$oP_A)QR!+)Ray
z+`+?j%ekoO>#Ga$+NT*H?!vYkE25dMPAdYFiIdJ|O=6$Fu+7n82lz9I7CUF2DHgrE
z@Cg}^k{VdLf)18>`e>D{-0hpHFx)aIEggu|_>y@zD2&Vxze{Ad`D-Ly*jQS2a@D%a
zAJw+~`bUn4iE3DE+jAxE`I$QG;y71M-|h@BJIs?|5_<&?s{EubjY*nHEA+&7soP0A
zFJikV3&cAH0w&8@iP?qjm{~JkFthDWP*raH5Hs>Yif}F3OEM=?x%($gdH?r_eFfe|
zv)0}LRrb-XTX5GTdNt0gCc2k^umO%Sjf*HOO#!MOEr7n*niORCEiCz4i*m+RDCD3l
z%E|HS!*|)<-rRMS!rT?|sY5DWEvnVQEbtOHpS09CPnsnuPo}`9a!{F4o;Sa&ga);%
zpbJ1sqP2{gidihlk+AfHB%3lRE<)wmC{<kAPu5YYyr129dt#GbFZN2P`NvT$FUhL`
zbqNyDkRp)pt+l69{+cZ1NhEq;0~X)t8weVfP}titHQk`23nc5YWb8&@uh(g@+Pxl*
zNZL`{jjVL@7P%pyZgemaD06G`8_%;WPdPxm90)j-M^_0vIsS;#$lGpXl_GGRDJsUW
z`hK~X;iCi@3Q{?9kY&GKQw)Rly$_YZ!JfeV15aidx^Q?Tk2-SF8@XPetZTTJvK%=k
zhk2(HO4etwAyl8d3o8g0SB#gwjKu=4j4O$^%G}5p|7L!o7jI|R;{_vp>0`GchV8zA
zM)^TfQ$20%Y&#bI^VOuF#5`C;VQAIC;m7w2kW~J%mHm=Q-v}H9Ua0p9nIMa<DMiD;
z2LgS=J9+<@NLK<IYgs;`tx_Tf_IOJBL@G0;H8MRb;u&|O_D4qRCkk9Y@IHE}@<w=a
zAr=t(nq7*4<cZgXwlGYS&zpLONu%e`^Q$!f_V;#4rsi=O9ZJ$)2rNYsf$T-X#RfT7
zSM{d`R#bQoF{?{fa6?@BX7Af3n0GGP3a(*Zo}L`^jm{_Vh2`-uN-HFhz*IUH$05K0
zydzi2>C@_XZ(k%3jYofFEDq5Sgb}MY>Cw3WT+??lo?Px1>GH77AX5L!ro4e^A~~<U
zrFpE}XR<(|a}1a4fH3sNSJ;h_iU!scz$v(_8m_UO-A1uu>71oJ<Wv2x=kEj`s#?JZ
zUk33E?j&&;OFh?@`w(d)-}u7%O)u(({p$`%%(0AFaj_A9ZnWO)07x+j%XTL`+7N9Q
z)l5rgql#MWhS#f$3D~7~`W8QMvmvq24|F=EvLY_)h3>jl{Po{}FsvvAe`<VRraI;E
z+b4};pHs|ms1-w5uV;$gQ1_zZ;e|QmF`p`@!`Q4%+U%Nj$ei<hN}FGCz!t(Cccfn>
zanc3A2RtIsx$#;rvFYei30KHI=p+6|u$_%C*;4Rr&04`<UMZ|?)-1%}0S5s8mnQl5
zWfsh)Y-t>xoT0qEY5}mB2-q%Zib>&^i%W<Bx9*?6c|kb@*;H}OVNRT#<9V6U@T%?T
zrS}5|&y^0v7w(gTWv-zoF2ezH`Tx0+{Ew}Ye>^&n(x=!mpQlE_?5n&Imdm_qw!n4Y
zCkUK;NmqRI`L*PEM%QD{nUI`|Rr@EuVIr}dS^shW8$lDdTMgo{eyCgPpWdGQuPfMp
z{H1?(PiiKANNPu$1-L7^<1OACJ>hsirMW&Ivru;CO2jeUDZ{+yv8UYkW&TL8^{7>*
zYNti**-3BQ_R!2xT`5AlwR@lUU*>tN_Ck8BJnq309<i?vOt~cTS1nBdmp_^uB>%@Y
z%)UwJA3IV0#ajy;MY$}=XzhlA*;=9YsGlBNpO@94Lo=LZ?8i3Y;r@z&3iVuNFpOj3
zxL(l9S*L(QNjLZydfqx4uw*}^O?fuLPE#o)xaRwsZ82h)C7VlG${J`15D0h0JtI>v
z=gtKUi%35HWM_!UiP-mP{7UTF;Ve^gBUx8l;7kj|iw9T3P{%H;;?d}X-Och$;Qntf
zuY;S;x7B|a6HZ;a5Ab<-2w}SICJqUOR3J#O8XU`Je#w7$!hE+c?Q%(=aXVt#aWF`S
zU-fDrl~xJkb|J^RMiM9!%k?77XLI}#<g$mzY>SGY3g=W++C_FZ^|75s2u(XO+Xx~m
zl1&6@%Dl-Un;9N6w8bs698!ywvIDZH?~B8Fp-w?+e2g(z8=golTDaWYCOg=b9RX?V
zSBe<Eu)%|5=75e!06q>~yl5oDQ=t%xht+_Wm;7A<OReeEtCVPzd}Qi3l&PJ}CThf?
zG-YD>m({iYQf8+&LMc+vHU3_#aK<^IL&7$1Q<M)jkrFR{xNrFCl%%!ttWjA-?N823
z2B;;Nr~<^n84%?yXH49U?wOO0TX}7*!#H)K{S1+SK%m#vxT|9ad<z2AVk1D<R_wt$
zB@Y0WR}J%<9XXxn_`}Nfo!^v#RxDC8mjouN)%{moSSy7E48!Xj+lmTVx4EKfb)Z}E
zQ@?3){^~vKSVhIvQNK_K*Sjw<iat&+Ex&!ZA>m`0{7%A;<9gs09>N2fDNT^ZmE)38
zIk+<VSHreUT{zWO8o8v-L=yy5{i}kV+}@FLXS(n4!i$Pzp^&Q1iN{ZTAHVcEaW-~Q
z82`ZaJI_^%Lt)Y`^uYeD98ygyL%6Sk?l>1N3Cmp=8E~MnqH%dq<GrYBHSzHIqVHC5
z9NFqcIc@3lIbD$B@9tkh#g>*v#8$Co{V6rwhTv>AvT;)>*oLSM%JXZj?vAl8LwaSy
zMa!&dhBGYp^x^`6iYT6@!S7@$HNqxWq1{I#Dg%B2(6}=VjNHHfaY<ctVRSy1GtYXg
zRbq50xShg8EmVk1uojsMZ;Oe^<*3%BEUQuuB~jR!gs|Izlqm}yU_yg^V77L*e9zme
z+X~%uNoJ{4jotjActu?zk*#|clKsFo?Ioi{QddWD(>%aCmYPyAW&EaPSl)OTuK4~H
zr<yCyOjpMCQiBy8PEtMJkM*!2ELIf+@#z(edD{tbh|MY;YWHO~F#IA!5{(aQg6{gf
za|?hlC-hu7Vhny3q_K>zd184k2-PMK3~Xbk$7vcR3vA-8!=tUq1Tj^FB>h$+ojAOp
z+bZAH+GFJ{J7dpRNiU1^I4PXo7~9Q%^Z`$S?;+|wD^;r_xP}xHD}(HpqvGtf#K4pM
zeGu)i#-;#zY!WhOvuH$uJpi_ddFY`&l~>JG-82r&hyzJGr`fkt84DGB<-%dSE_pVZ
zk*=zuxP><{e4=toQ<wH}dFvGdM$ME2IK}-NuR9pSVH&F<fQg*lJy&W4x-vV04v_?s
zw>e|K%)U2)!~F4+OWS%3bj<PGTbD4f3nlV0hDV(;#77<9AThy?x(D;aYNdr2hnXq?
zG!^$E)C@!1y{~_xv|Pn63ADT;3(HyZ&$gcn8D!bn*$l6me^NGuNu6y`GZtvGCw=o%
z**|%A6SLFxIy@*RyK!Pu*m&#1&8x#hX*IKv0yhZ7m3zRYfW_TOCM~6a2$USb<A<j_
zAezPeK1v8!A}|}_{(dnn$@+&~SrfR^X8`Ff&{ZuWNDl7WpZH26vn<k}O;3nt&%WQO
z0?l(Rw5lp&Nmh#$mc>qALa#{5%G}Ez1gdlXDJ;K<34AAfgMdIPwNEl9X#p2Q&pQ8P
zH3Cyl@8*>74W<Y3y#o?jUp)pgDd~j=547nTSRU>cZN)^<+sqj{Bd+!f3uu-WtOn)E
zO!Bhg-JlNFj7KIhOhQ{b`Wf=x5S!&iCMaE%;_J2UtBC)C*5L4#U;0*f;Ts&UiabJH
zJ4*khyi+c3yWwywyv^SWxQ6K8m|x1z+PsJ!9PYGOtIim()99a{(oh|}I+|=C?Iklo
ziKPe2$LPH8KKG^b8WcFsd`-DKC<<Udg7)Bb`6b2j8>P9-7%euBF0!iE&i7IMz1~za
z9|hK~#?$_a_>L`d<nKIsYUdbBo5w!y*?;cV*WRg(`sEzr5^(w7oQi^KqqHYH`u2#w
z0q>4&Rq1c1@K0?DD%{>(IlJqxsaAD<@L!6l2ike}^z*~#+G|&jN)ClDOQ-IJI;0s3
zgg4h|uPyA|U59Qu&FK7vG;rX&)xfpxLFq2&*!siJ826u(S~p}Gc1m<|66D?LWN%Sh
zvjLXfs~{_{1p&+c$?bzzOhRKUP$kTQDWErSUSlvMG;!hO&3{!E@07Vk_o5W)RB=vh
z$IWdBMTamZ_VG%_xml$#aiaqXEW-d#_m9e})n+H{4^hh<O)xpvC8lQ|a^Uny(3zd0
z*nNNeP~7+KZ+wD%Z%^Oo!rSzbgsS$wE?2dW$PPa6L<ZQ`%J^1j{$XofKPsHi`1QHa
zTw2=D@Y08z1^A7nJj8t1Bk}tm$_Y_h#VXR}>wVly+|uPs$ad}dUAMi6@J;d4zXk$J
zI3DI-1NUIvzX1v{%=@*|r+)(^IU254_B#8+r$spmudg_I%a=cMd>U_!Y<hur>i_4W
z|9J%e^A`M{+6Y1l=0B?UJ`e>K-*z|UX*mq`Ifla>ZFp2ucVAi#XpAeOFNN>^5zelb
zT{(@6;K(v-?-ZNw#QcOq%V|fldaV?1J+mx*VtI2Ka1ijv+w5=S90*UHL$IC+e~tF!
z-QC9#c?rp!0PSYJ=j?l9jtcbE-++sn@!ES&YnO*pH=`&VX9&SP>w>*o|F<r=a~)Ff
zZ8jifKqcHGda84%=8maTTf#%OPspnvp}dC(HGerjxu6j4pO^c&!$<?AdB=Tp=I*f;
zd%8%pq3(xu{dEH*y{OW3SvR)@QSJDE5OwLK>5UmDT5*xq-x+m(Mt5}I-#)khi^cU{
z|M}l5pYtE9w*T_zUlFYML)5pZy}+O!dcnp9WaD)KRbKI+UhLE1F;4GM!|AFChna?v
z-~ZuoZemt_4)MBc#-u0TqRS_otANUNfQ0Owm-`zpjGl3xIN<oN6Yo^Rz=j#!-)CtC
zg6{XVx==>n7Q6Hg8yhU1@#bP3Y4DlUBwaY%^rqkwQAb9)<)g5`B_u|iH!9jfBj-hs
zi&le+0r0?ILpR_pU^VBDv)@NH58mP!W@)c_VwY`<x3RL@;lBY!ceiYNc9)BHslNd^
zcV>t~8u$M@-DlM{jve}mnObn|?m5ZN#J%4D&Yq$s>?$Wf6Sh+n_P&SDGzDPS^gEvY
zjac`;V}|!1P=f!T=1zA{-fo~kLo;1Y45);WkWqN;5@+)l$-e=eAl!{#+L{2jbOn<E
zY9D?+C5nKpib5xViCBisy|C#k-_o$bZcxB1a$$@dcb@}NWbZRQt5f*otHfi#fv?8^
zxPSeX`b!>%>+^dv{(3e9WKj(`D&$MyC)+2sKMrWlzQ+IfxPJQk%h${v%epgq)q3y#
zd>(xd@BG6+x&2_ep#fFf(q9;8tKr#v>+Q*qzYqZad#}|ge*0f>SwTKa+gi)6+c%Hd
z3B`@Hosg%u#_qRx&X8vs2tU+A!yiZtBxv54>0XfB+V{=I{&xP&RI4w*=PsvW6(Vw+
zFI_sjc;w*aBL^L+!n{UC=dIv_MPH69UHNO*<uBhGv;EcOL%ao(FoUEkj)ZI%{}Xv9
zsAhT=KlDw46c@6>F49(Dc7fJ+)yn(a2i&SNkr!Q}|AEu+4=)yHou@cjg?qQvyt<b-
zTFcQtIrgEo-)k2+BT|s;{_H(=>~BD&;FfnfA<T5;@2Tb`6ye9VPT!*a`tm?~hU4+t
zbhU}cT%iRL`QP__6ioMRjZ@WvOFQ5>>0-*g5Ob7I9CO4*wk276)GEkrFO)-icAWbS
zNU+$o&s^S<-D%z;2u^TJ1PFT%eglq`)oZVCgp-qa9d<$zh&_7_97W;RVP*--;S-$v
zlLJ;hvl-3YT;W_FQ@p3C-#5c)OpW~pe9<b<-_%})hrbT5d;g<zXOmNIG;;K#FK5rL
zaynQ)!zTqTvUf5!6>Gozr`s@H3kh%gRl9P!&~(pu2gh-A|3TE?s77mrZ_064(x3CU
zs<qiW4ji)$vEKmEJqRbL{<6&A<5(DI@4Tk{28{QH{o6X~XOqK|egi}}5pqYO^8{xf
zWbWOy3;#K*RcyQ&&b#+u%}~3AvocOvu*dE8Jba4NQxlP?{k0}&owrjP!&%(_Jc$2!
z5dR0?h&Kf}LFaY9q7Jd2RV1lBHyQR^dR%`H8O#@adBm`?J5o^5GLut$D;PYO=??uG
zmq`rAt1<ox0R!ItdFAr|oFbipv2F(tNE0B-d)Ztr_XUDnghBg~e^@N5M}sYLC>}Gb
z9t(C_g)_w#^{zcE6s?H1gL7W}_)q2>G_uw^7lxIh1?BH4xEuX)aEg_R+V>$y^Yo?Y
z4Z)ol7mjrj@6`Fv4$IdQcG2NUn%o+Ko;P9mIGvfBpKQEP`#*3pglj>4pUVm^_i<$R
z@#_~|im-x-E++zhCXBx1J{)FXB5&;DV{GQWf8lST{O?~~4%O?wPWJxs+`cD;)48*^
z!W_p2OkM`$d}}pG55-3w4E~VBygII}VHB74_@W+leLy)daW}yv&R3YO{JkwL_=6T8
zV}FR+<7NXJGZl6B1CKZ%@U-Dg@5?7SgNSzo*L!{g^jaK*IpLLR#sO`A16C(G3GLb=
z5*!Pu%&j{{xa#_*zvCmnK96N2gt?5tUgn*aALhdF@n{@|6vkXQ{t9{}Oa9Ty!nw1l
z#UDQQMwLWc*;YUtNK4`AOYDkU*_^NGKKOu|RTLZ<0(#>#WRY)v!N<<&ioYE3kZ6HW
z24eE3d7NQSnzGjtC3W-3yRmewCClz2&()bn?f!~)OF$U<z4f75`9(gvdTfXOwW>`?
z0@5E+G^5DaBuTBJHTh*u>ax}`#%1uFJ)=&DUyu3cP|19F#zF9?<}*&l#~74afsq$9
zR1D(CkQ2|+eU`6Vf83|=m>)4-nzQ*%+$=DP92tB$J}qZ~J8URy!G$!RPN|i;3U9Rd
zMRi*uS@fDEle@&B()lxV`hf0_ktUG;Nj-j8kBgKF`iC^n4~VA@uc=(+OQF;o-|mX;
zD;)_0#N%RJS<FabEf<uHn5YQG>x~K*qZXmL7#}d?i7`ui(7Fel>@}y^7PaT>q9`Q;
zzYq;ILO;(&S;7z({9q}e;u!Og5}6;uz(*78)Wt)r=7p5}WG7v1)QEhPHoed~LD7oN
zQYxfubZuvw`76CEoMLZ~eaKYj0ffi=Hgs{O>g-QmnDWzxOqa5Y2aK*At#PObcJ&f!
z{|(3x49}G1r@IMO5uYjM8O2${`^u>SF&Lld)G(g8niiI*s$yYlN+EVBjMHRYUawxA
zWZJFL*G^vwN^0+O?)ly`+<E&=WDPvs6?5gu&kI)KRbq}dAM&moY*sHxkjT5(CkwYo
zSJy{3<w>s%LQQKHH_$ecf&Ky)VTBLVhlf{HNrWP%5z~)8i(mzHTJ|k|@2OHbl#c^n
zD4xV@5|+o~Jw0FExxrBosgPV4F0$CPa}ixM%Pb4{MG#3NPp8Vz);KN<?M6TI@@maw
z;C`{@Y-CN%I?iT(esPnN3)I(0R{kh{b|1$dr`8|rg{qgHrun;^Q(h95zHMk&Vv8Z%
z6at=8@F}wp;;-E1NIIj(Q>C|n14>H+$k%J;4Te@`>sy>0;L~M<e+XmPn%b4uuwZP`
zO=h;M4G$Kr@lTfey=uNHMXhgQV!L2$uQXLt>?a{bHHWHaN;z(N{z}6daiVBD#p=m!
zmW{{@OX;KSv!hmAs|?%OEe8u$H)J}41k>egzdG~6phxS&%!XR0dnghLxI*G_xl>so
zqL<*;(LjX7wPE$-4<8WXj+rPovPZe=DMSZs^!G#?ZeTd>x21i3tT?muQ8d(i-7DO`
zc9gOWw&<&vb1A+xs;M{EfYY&`HO<jmRhKg0^F~d)czSLgOb&8&k<dbMdmE8BG>AOn
zgkhfUmw~EO3+#gHA}-{aT3k!-^F;H|)ZwlG$SP{4TG4}X865nhr@ka8w+9Tq3xzmo
zbP8tretCJVkg}ru^RdCl`+1d01l3lf3WZ<dJ;?!Gt=Tb;0-+wd2Kj|D+8zXhwst)n
z#@;Gqrnot!b4>iJe@yskm=@kQ?|5?Qb9Dy_{<V|q@|ZkCc`o=^DDetN;AMwghXgJt
zAtZ3pJDG}2hDFnQ^x?t;@?0RH5By;9opZM9*iw5@S)V&DFd$_9J<X4199;!^KjIMM
zE(Lj>8ti>ws&o5p+Zkb}XSb7Ai~w*!50_6C>IOF?^<oh%%Iu>`7uGOPzkoOfM6yjE
z^}M^beEm8+{3sRdoQFa&2xw0%cJRwDx3QXn_a3IqPJuTRNsUywPbX(8%i=GvO4M70
zqP*{)_d^e;UN~W4RV4RJwGUZ-EOgeiG&Vg6WWR*i)QV@ku{Yu<jkSqen6R;%Shnk`
zRVix?>`xPi{|4~0sa4N%cpRK7-#Bh7I<72yAX2)7TDy+xGwZqaS`Lb-wp`RnP_SSP
z5z6AI78xyhaHVj6a&0xj-Oa2p8f!3ffyHp(!mx;TqF%uwJNTMB%kN?O4XKPt0`~-^
z)COkvdeW{ZHDSZk5q2{?pk%j4gp>8AC1yxo^w74BoqFUZ@lt8$XR<|7?G7EftysQ9
zS1RzgH+kNw$jTVPn0b4QEdSiCNoC$1loY!8w<7nyliUBf828Trh(872ANZs3V%Ts2
zVQ6q>c{gL$J^HhV;b`T!&oceF^+UFAV)J`R-HuBoOFRR9IAmyFKTR_u4sV8uOiJkw
z7wG}*q-TaH_Wq1JqCeV()N8HlfbiQ#*LMU>Wq=mg@$!MT^;cZmmcJc1R$Lx@T;y2U
zZo7?Xl@p&nPIfH!{oWq~tPrs4W@wa=U^QVOY!T6<05dX9X+`8!6?G3_+lW@>E@MmQ
zruPIsRKK<v28Vegyu2zqoP#E9!2D5eCL&V#2Z|;DB@#g-c6+B`G#H2I=%2{_zP;kX
zf(Q&ZT{rb6nO3wNX$2!zB;w_*m{`$8X+d8^!`}7&DslJ$hoR{Y9INHjIF6rBlk%p$
zS!0daqaTSAmI=Z-i4jKUGlfj8yfDkq5!_<`bP`m?HB%l<Dvwl6#zSPBvsTMVOTK~d
z@*g9RHTRFbRW3zyUGCNlP{hEtj?LMu#M~n*4IR&1<VJDdo(&ahg?&ExN&%`Q{37-$
z%EmNpEMsK9?<8eW{PSRWo{9n-4&Sg8r#j%29`Fp{jV@ITf*ss5!NOr)h(<wfnN{^3
zf+YNhEmZd`6~p$jS9J~QW2n1S#0^^d)_3Ry?n_8cO3KHlz5AhOBq2MFrHzb2ht<{w
z9Q)MuG)B0vi!~Q!yJ^4D`)PhXJ~gDDAwQ)(QSZknWzp*_HoVws)*!Z|xl6Ok!9{2L
zlijDZLlSM3vV7E*I+Uc#5kv72oS|t=!f4kvt-OdP@-kAEzq)sb--_&6l(V(n!V(Uk
z^yMLs+lBlFSoH2_2NuF$`s>ZbKywOPG~!OY4%?)i{d(esj`bIt3+(2jSf$+LLJOZ^
zMJ_ySaGBazG;7`E@jfY#CN!4C;FNJ)R@1wa?|>WCRD7SbRh)-cP+-IG)t?HD1yI<a
zel|qm$~llM^Mt{C-1X0k`Vs~@DghG@rXx~mb2h%ZtzCUhKT+Zv^wOTqq=5cL-3wHm
zbY^6--Fiyl`hxRPu^YWqX2-C)lG5{?Qjth{{w@p&mue2EGBx~+mJC07HDIbM&Ut)6
z!Yo_Vz18?lxDvKkdtqvW(XPmlk;QO(5Pfy<$zG*_(X}lq(`#06h1A|qCAaSaV8hC<
zRc*fLkd)Nxo2AXEXPZe>mK}34Htu6Az~BZqL51U2@=Mg{eOid<kvtw6QKg6u&+@5)
z*e4fi$Deyf=vz_0LAOD(6h~n8{Zm!iV<)}pFCzQ%xRiaT*SDSxq!9?PPTV*`UU2P(
zSv`QApl$k$Z`q`7+u=!1q<Q@8GNvlkA!JLsuN+!lZs6NrRIuaW<Arx~ZybbKE)rR5
zH3@gNL2EYme?q~5+$EH~b{sl5X+aQvkJrfnBmU|ZX8T3MU8YXl_X*1tG@oNw)<!}1
zWU5SuTw$+OwPg;AL@GzzR!84^u$$2*VI%IBlozl%<Hk+enn5eX_v|TyeS?p_vI)aX
zy2Q+P#ne*jikNp2gc_s;y-u{oVU7T%fN&5;a-Hou<(%f_Ucr&)$6If}9L7MTL#ASS
z=5gH-Uc==RDeLTNJTzyQpUN?E;rKdSrKW^k9&U!G3?Mx?Q}@BTUus~_QViA|6#<u?
zJv6?A(y-`8dFNRLSj?hZWMAqm_^Qu@UCyv#bi3SnJ7pwzi93CdSKR^YKZ{-O(^LZU
z*3lB8z5F$y3c|4^Fk>Lv1%VMtzB8=z@sHz&7oL0WOrRt?Brm9jLCw?glZCV$(`2rJ
zT{IX!SRB1R$--Hf#JO<$Uxq?RT1V}2YiGtCxOX|6gps2`IHasWH|nl({}z(n*jU}1
z(5ZE&STXAl>lFBrxCt}h%JKUjBrG22gFWOUfeU}=-q7lf4c>G>*UcV9_!C`yW2)V%
zMy*FG7%^-!45LFHPM0<>jfR&(jK{*7(sNHjvY(vWTQ=}pe|7gPa=dvP(wRDGF#7sj
z!8u88A-=hLs+EN%*le>L7Y;93M-tm4Em@&V5b*K}S+{~uzs2YG4T)FQgYC@&C*gFN
zJ3SQ+{zVlQip9~m6rxKI<sr<$VQ^Eb6iOHwWQfBM)aQ3#*%RRx^M#*CRf)G#Rk&{u
zp;?j4esM#24@9axtg$h-STM#i>lqiJO%z>c7HtKoBvWN}ncJ;kn0Az2AWpCNJpy`@
zT9#_a(M9iIG%5J5Ti(=TUm5dD<4{A7N9gIPsw;W94%DsThktGqb68xpQDL%QXhKR}
zVd|_<N!N_biy_7372x1>_SKMQ2mS&n{^=(2KVx$JlN$E#CECBAJ5g<|N9jLn#Wwnd
z50!r>E+v0IL0+79Qt#8J&#m<mqsiDS7o4oBfBXh4uDwD@N3m+3D}0<jG;}t?QLF3@
zX&*Zs+3WaNjfi;dC1kU}5{bT*9P~}?`kIy5t;^rP9#&2tOP95-#I<%zs>&dpg9uT=
z&epNmhiB``4oTc{K2cqNKl-NAFO|JpXTq7ryZpkTDdu}@@ZQL8Ku?lZsv?Kb%>e~a
z;WKB|JT^{W_+R&(U3i>APKGzh1(-&PIMyk>ij~yr^DQ^Nam+W?J1r(k0y9-By+&DI
z{&xCx(W7HQDO-WGDtc)K+-NEgH~J=lsyy;o0Py|(v8{WqT;hZab#Q5nDF?HA9<oti
zdlFH@V_nueRguw#dT?(7J1lz8#R7EVzFsTnid_A^@<*;p?6Eo12B=@QSSP6)RIIL2
zxKn*bV4aw!Ph^0d6x8(9xLjXG-}r;}VLE)j`Wb!hiE^|Jxd);|^M)5Uo>UJAgeYz+
z_U!OA&t#q=GX*t^oaw!6`eP<YdUZiD;;^cm5CCtHiGNag`S!7Xv&on|=Oj#0X_-$#
z9dqe&rsQzzV53iq(ZX_WRz`tncIgUKTe7HVUGelm{n447Z^h-3uS3huF<7=QNr|Vf
z^C(=9`~cuuY_@&+3ZiP9As^eFs=Po7W$mmPXV(mrf%LI?hsRqNF##}5P3}b+OWH8R
zp&otm;)0ClqStr?-^F|LHN7KF`koUn0;Ybw{N$UqlGu0*DPse*pNsafhAZ~fO!ikS
z)w~lcP#&NM<n;PMa&fdZu&xUMn`rZhdq(o1@QSQfb6MD1PCDzZ{oveG!06$j-6cH#
z`ftD~<sI^<X%CxHbWz9HM!!5WH88M`HOqai(APm%J5HKwsaB;JOM~{S@P0}$z$HJJ
zY@*y73T;W2d9E<Ax5VBw(&L~;nWl{#*jQ#<f4<2Fw-gM5j1Y>sk+P_2$oX=8*usrE
zo*8#h?kTjU|8{Kq?a}IIOM@AbF-*xANxyP%45&dt;|Rb48*!#SHocGvT>p5HTA|t-
zz|rN&Ugrp+)Q4f_U9*yfj5oD-*Real0p9~Di>v2HwcebpuHxBHdsdYKQPB52S@+rd
zCDZRkM+v|pQ}<+S#Ai|2be1BP%5`yij35piNJ?U~Ar*DlR)KUB3SQlt=ET#pVrpGI
zygT^l^C%@fk5J{^=4aNrSv+?7n#$5Wfa%K^U;QTU%<Cn<W?!BBv2kE3)yNN1o+`D`
z<!`-#bf)E=I$EGxv1G)}UsGhU9vI%fPG2pt9uti6(y*6a4O;j*_{J=_*xu6oRMXY$
z_%p}pEqwR+uO5E*ZT1=#YiSmKLW#21z0*?PVy8>l<ETbXj+7-|eV><?EH&1<v)5fZ
zfS&Hue-7kyNj_TW9xJ@D&*J{RdB8``#L5tXh@|WckHuP?iwpn>Pm}dDh6O7!En=Xq
zuWVtTglYMb?Bv9!at|s3=Hrh%l<U0+W=+{i=v~Kd>lqmi2Zk)YouE?BZ=Xv}eV^UB
z#70tj$FhHcb8k*NQG3nAWO!zehm)TkJV)Go6D<<^1Y;mvp?tJ{zb{ND=k3@kN}{F3
zu5vJscXyyqQpKfc1D9y2y5zqg`y~ZeTRz9w08{$s{EAO7r(;5pcQMKYZ|U9$eZW!S
z3lgy}_|C^49iAHi4rnY%7)CJUlC8lb^j$M0sKq){+Z%}%bH^D64li~#|E&Gvmuv$K
zvP%Zq+03jjj=0;Di!G8wUQGEtgaQq^mPD_#f&dr;RCU_dG>7tyq}=h=@g=*au8pKp
z&}{ciR*!zWSgY)Y{oHyqh%*z^9xSOHOd-?fh)`CDed3QTrVb4p!_P7lyXxv(vTZeY
z{lXdZ7H3hnF9wH}`43)-Zm|d;lcc4CCF#&MJ0&QryJL1{`a8ZVjOFD%U5u_)*CMtv
z8r#ATG6v^P7r~5!Pb5(`Nf=M)-R%?Ti6~c_$Lh}=_I<o^3VS9MD4>`W<KwZlOa&Pl
zY2p!&7)XR_Q9$l0HVY56(;qc%k(SQQKvsO~P5vA3xUYlbh0^Q>*|Otw=@acW9X57&
zcfW+skVAUIIg|4n2RMCB1#)qrmfycel>gY``SVAA667`MQ=DEygFJKH45oBqyGrx{
z8&(3Rzw0|58Ot)Aw4y_EaRKng0+AXxH=hrEQ1fD0pG|J&_YMdBAKcHAS0GXqA(0!`
z@oqQ{J1yeyc9$gJiAhEfU+3-H(aFM~1?`t>A&TY8#^B%pD=u8JD|sR?dWM%J^Ba&y
ztO+Zwm*l^9jl6C3PKsy1#7+m(5nrNIvzyqID+Pp13e3J$c<|^!JW6XWl3Dc*twN{8
zdhTGN*@i84FX;u1K&(L}nPQ!)fY=_GUG(_%^b=3UReFL6d`W82F}8lvrsILz3(Aso
zN58Pjxkq+6Q<#Txnb+tk6pW#1EnPCu9*1&JXPflsO{AAYa_|m;YX!KG6RSOWuo>_6
z;A7u9R+x}Wt*K|o&)#5xXTQtb8<&99%&$P27SGYmA}?{J#5KVRU=TC#9Wn@sCP@0S
zMDm11G71bOT8e1FBUZ!f<kXQ<B-8}>MX{2kdLq}uHg9BrQ_94hccw-BPDg<Uh|kPG
zQ<OghL(F2l%|bim0^-(bc8Z(+EDDE#2Q^Mv_wvL0Ai9@~>CW+PpC6s?T`ck}A~!F|
zWb_Y`7>F=Kb;&G{pkf?QD)z#D+t1GfP?kEeQ^KNV{?|yI7mEEE5*<bz>Wl>&QKWh*
zFSn5*vsMbffgLW8%o_nKudUJ5WKRVdF17Ta);1^bX5D*VEnaee;yvKnlAh%EKJh!s
z$^ow`bKO`M6WZEN^GG9;?W+dBdAddGbZb`?l*03`{z5l$mxS9&YZ&y3Sq!Bi#o?5c
zBD0Z3uB?sV!gun3d~`G4qz^6!Oz~5jb^@A)CB%zeobetKh7ugj3(#ld<cy*vE7qWS
zDw!T&1W{GWPJ(ELL1D1g&(@@AO2$=kl5wrE{L!1u2P2NCT3KBpiUT6FqOQDhH8n3^
z#05g!dlqXpW{WbO#-<4jSh{AkYb9*a0zBG9e4(=S+XB}Xl#aSp_o5z{eb8L{l-YdZ
zdfnCX{S)4pqX%+TNkWUP;%LJT<1qwB959bINFK9aHf4yjbm9D~0n0NzZZwFiY#mAA
ziwHPo6Pe+fK0iFQdk)0cmJ(#itF5edz4?IZlxj~z&RZ-a7ZasiMX`be4==1DtEJ}Q
zs#L1>v-S#60sdO>mW@n-FsZLaicB)M{CTvmod4du=Yn)@*-H)fn?>%4=2wyXoOGV5
z^H177=>S<8saQ%_+OI*qb4RN&sp?gf5DIxDOu7(ny6!iFG|I^(lrLSjbfJ|e$-*xK
zD!wja#+o+F;*Y$Ewh1Hpzdmt9e4_L`83lCt>qoDf_xVB_7|obL$kM?fHY_{Uq{->*
z06g2Oe<M8HL1e*E{L!U*`~x)+V|!h$uWi9dFCQmLipi&#Dl|y=_5O$7L+)GjL=#Z3
z%En=iDu`?tFJhIM%Q(d`_c3azT&79``*3|*DsutDq%xh6PgWEh8P`{}@vv&%9^s7V
zDW%@Nym^h8a{tt5>c@vi4iLmX=_%wEw`qk54*CWrCAf}Qhbc1pMP<+`&fU?pu5y8-
zFcJYvUO|?gJ_!HejvOs@!L+C74$VI|oiylPJaN`SUftzX$94JBss)V}rm>U+VOl6p
z#W0qDuu~>e4UraDmntUGZv%^4LIjU|DI*5y)LWNE89xxF*~}|<!>G~sE-HN^osa$g
zZ2Z;7HK8kKCaZIHiAZBRr(Ddh)a)MPYgcyDf~C^ziU=e|ALutAWNU;THfS~SX~eCE
z-4jmsw>h{dxNzF<WN#32xltwM*gIzHt6Ob;Lq0jwWTyZsED);l2(y?nSDcP1GfpwG
zf)Z^=JX?gWxmwKCvLC`lnU3o`1J*wkS7KfkrHu2MHOr+h&wsK4NCKWdoNEDAQ@Q-&
zRDFF&Ijp4)S{}MQw;+Ifku6G0wm@w}!+h2$l#pr00&0XHAMjP|!e6ut+-sLLZ*vU3
zIBfE_Ap3ES^q6Pu+}O@o(A=KhS&nR&*RosbK%1c9--6LU!~Oo;xj&S=N2Rqu7lU}f
z;<k%{WjL_c^>MyLM;Fj(BWFF0Q{FcPweIbl?vwQ=a%R&~N-5j6%evQ^fi&!i_s#6&
zQJaB7F|P(alRIwSL?=8ApE&!+E}7#BUTWRqqP=KQyYL&ZtEw>LYrN4~yFRs-cs{rI
z;m?Tw4vS<;mQ#f&<nD69&8k81<>KwV<9n0Zs|-yK?ZtbY+fO)~o{wSOC#d%4*8Pv2
z!T<d9{=1F~M<#LV?hN=Fr+6i)#R-YR{5A!-kCuRQpey@Yav0I{0Q-=WA}kCYEnGR_
zkG=iw#QS|#2hZH%J9zffL7yYvqjS^jaGd$$jl0P`*3i5Uv$y|WMd|;IviIN85>4@a
z4MG26?fH+1j>giMYqqabZvCMgl84t4a(<%H{P}b7*Gv9hqc`m6l}+;zr%tMQTT1kB
z<c=teIT=g;LsO!Ef!Dqn+IOTwODYtv`iCV=M$=azd+4+(sB-#uS&kC6Q(oI|z<I!r
z-Rj~T;T%T$wH8li{VQ%*;9`&La%}NMiFm{J+}Vpp-f=~^JZ|+O;xO4iune91#f|$&
zT~VorcMNhcPkF4ki=`sXU6jH&{A7F~WXUkK0T-(*o(ub|Dt<ac#ucM1hCiVGnakzF
z`+M|ILd4_xL%J7DAtN}COT;W+OhVNHg)~#x^JP#}qAX89$jH~s>(RZ&HWo}3S)H^z
z)YrXZR}8cNR$mMo6sDB&&rf!-<?F_@mCU@aN^F{wU)PxU_{Q#^;yw*GTw?S@vUdm3
z+HrwaBi2Q&Tjf#e-f@1ZWy#t6VT8^fS{=K7#zaa7skT8t$Kk}S;tLCnUj|}O%{<0p
zLbk6#$0s=oRBpn}tPZ(Ghcf$t(_omTx7lJbpNba_mTNmPddVVnhdRk#DT~;k?-(Qe
zu2%m{eHqKhVT7vr4!S29luG4}qJZ%nJFgGK*Bj3|zc6pz*mq+p<5FQ7!lIgB_K=KR
zcWce4DX88W^o#@I^QX-#RD@L}H`2V2(tU~)Ft~=;r)URJBJzjnTsM_@7k@vmaLI&e
zT)@|a9#<k5pv7Bxt1}W1Me!_|@)E47Z=+#<NG@G*e$U#dvmnpr;@|ms|GstqQ04Fh
zucoWaaJ&w)bc5EyM}9bL$o&T7cFl3n2%o0#q0_rJI=XA}H~&8i*Kovr{*=P>zR5l5
zUva0ODZw;_7lwV&WODR&XnC+kxdffR-SfE=J?Q}IsB{A-`ytLN|FZlIsFq|J4U~`I
zOOZB1*)5=fd3Ij1na@CVMhuZf>R2+bz|D5MOXn<$q==tW4WGi7o+<vUEqP|hw-I7M
ztuu`&^I+9jLx~Iig)EOKNPdSruF9O#vDdWB$PAv;5{zboPUr1D*A%n`AKm}utV{Ha
zkUG>ECmJ`2Y`at{H7WUQ<qs(pB?w&9kepxa=3Zck>#7q6r=|?gf^jD1aRc(UEett{
zvyZw{%R@Kt(f9$JF}CfErhkQsWKYV>jg{khbGRn_DDikbkT+EY>BRNO<8B`Bi5H<W
zCmZ5`naX$HUg-e6SS`Y(T8ejD8Tr8J?y058J*G7?O-sWYDKXgXrZW}7(D?O;G)zr}
zrK&xJ(W&bdNLM@QVBM>jc(N+h>iMjxkfWy7`sk1h>z&j>5fCe6AKLaDn=Ge$He#?S
z7?j(q<Q=78h1w$HIRm-B9E;mKhHwZ>rvbs4o#j&+Xvh%hHXcV;pzJL$@D)4Xfs1>D
zBHefPgN7-3>%ms{7^==XGl!aP7j~lTuXL5%8#!6o#D1bfBGra*^DeeV76RAG`&1Eb
zaF95GPZHW4-~rOr6gPf@?jl`KCRgW)&G-l9jtylkGT`og!|{Z%xld^Cyg{UXi9rKK
zK;5L;#tkEP#YC!^=jUTRn~68yO6ne{XoW5m^hRu05H5U%wPDc%=~OF{E>zY{1mkVA
zX%Q@>Ib@N;kyoc+vskQN+j0y{Z-JGY$>V{0`~b<N=1kf08G#6_nl(436CA`XUCQ0N
z6^?sh>(5t*`&Ft(V;(+(mXuj+D$WiSY(t;{5Qjub^%k%t;@~xcgde*a1oD-}ME1(M
z77Z2UV*9ejYnA#PgW}pJ(}^BuZ?8-bSjU>FV(wAi%NrKF8RP>V3LrLh;DcT*Dw%o2
z-POa@#i<OouAMW%E@Jb-EJ=PDFDuR(y?1X6D_lvyc*xtfxxI(lnU^mVnlAXM$GL9a
zucj-<c==>Jcp~)1^@&|zgT^`*69_15*6Kvb+hA)<ipyg1#Le;a_*AHjU$;lcMnWUp
zPLr3uq-DFA+?_0wR5k!>>a>$~T@9rKK#JTDRU_Pjlvxf4prRb;<qMp_@OYKgUA*D^
zY2TP@SSP=W^S1;0=}(%(jdGI9O$Z%HeX44&qLKa+ka7kD>=y^~&K>geNxRQr={Du0
zXBwd_`HAYvNxf_h7~*tPZbs+bJCyR;ZY5>hu<+3%m?KHfbLU3S>0D@<FH|Y|Iw(;&
znNe7-y!)*#wtLTdfhs`P1F;%yRQ2)bk*v(mQ5oIqLvg<Wiov$?+siHPEQVQm_t)vw
zYHQQ(@Ukm4+Zz3}2%y|+Cye-&<eM)44}0$&)l|Ff3uDDzDJm!ydKIJ!f~b^$0qG?a
z3oXP136RjEA{IKKNoWe86A(y(BoqrEp-Pv81nJTtAfbDgd*4&ObKZTwz0VnAf9H<x
z{f9qbti_toTI*SJ&R>}knrqHBJqf1`3qIWBVqAW7?M#x-lxb4k7Cy7LF9ZRtC-+9G
z*0`338%(ALo-n^>Ds<ou_}Z+Lt^(L5(AGe?L$M159hG~DUzk`aqzNi8F>a9Sk%!Qd
z<zUa<JI?7>F)FoC_?<C_8ZUhkd;OEPKX~f6t(qm_a4Oc*q0?;4VX3xi&5uCz%PbM;
z6VEj@!yIz^6p$_J0M(TrM@2igbdm;eDE%^)YIPUi(A@Wc_nD7DJk9rlawU?pqj<<Z
zRVPNN21R8Jv!O?U&lWgmY)&U&&U@$}RU$wS#_*Y$8I$SG>;xO?@foz%q7xAy_YoSu
z@`jQy4x%JN=q@Jv+$?55(OA277eO0?sg;Fxft!+VMRcc=6n0X{x6kd3?6IyJ3M;l4
zl(`zIl3mmrN$?|5#{z6v5GsLRIo>qE)}5|qQ@_y*FSdVJiA9gwl~Vc(C)?exuyR6k
zz`?zJHSk`X(GOSMy2v99EV+ZHM=)vG5Ahj3Z+EH9<W+hq4moey0CHTz#Ozedd|C66
zCScHBPtn@F;&b?f*%`BPG=+n}&!kX2(RL+zoAihFz6C4a2EILfHU;%N#P^C+hrH>v
zq@ymET=~osKMpT`Lp&P!IO5*kiJ1{%>coMx%zPFSYehFtRYMHcDhX6%(LvfxMw{ua
zMrQ?6tLp{meHPw`rmvhTmVJAa+*m-e;_7ByS@Mwe-n6{7KI4P;?^N88s36N~>xYOm
zbna@pe!uVlyxsyt5*@f7XB?N3V3=G8>Q}STk$KyajXpC9BuHRUY!wj-syF;@G$ldI
zsA5<_Z3kFsg3+Ek8{gEibx-Z*!A3O4oJHaj#12v87j*S(S)OCa2wN0fLdFs&Hcpwl
z$L(_(q!ge`4t8JZSZ0hqO5YE<SKE6r9V&}c|Mn$W!oE(xErsi1fn@%DUW@A%A4W%0
zfBfRw3FP0~)r=mhs*dtTzepy?wga#u@xg?{wL<iCGOZ@!K(K5ElgxpW8Ov8o0p7xY
zY2d>DDL?-|{Ow%)<6#YejCB5`)@<%}B(}y-0!SAC>k5xwT$8j6LmZ|C_%c^$Ex$}t
z3V0FmZwbf0p7S)WAre|b2i?P*!m;i>H`V`v+;{$I5q>A|Q_{A7ri%je-Y98qRZfq<
z&jz>J6i1@A$-kQv$TL=-VP_Sl1o~xt4o(o;`>}IBngw@9R=(Pqqv@D*$ohex(=Lb_
z8IQB;3=dDJo(3t&pn5b}&jrJEN+h9qTPeBTv!g5B{hb;@_wZ0L?K>PkgoxEiUg_p5
zS5&3LPYIUN&3CG*HMWBFW=%~uBqbmll-#NGoI+-5fy{)M7{ffya;B4%wmv}X&=j0p
z7a2g;_{@&b3q=a-2To^^Ed}(SDCe0}j7^}pPEFuy-RM}TgL`K}^`y+qV9KD;v`bfe
ztXl#=sEgd{URU???rZl>#{S~k=biIVrtMAQwCek)ZacaD%(&pqFDGw(aE&qKgX4#u
zjEDK0728|HR7Y02&rlpItY9i|4mF?GDos7xbaQ}WUp+QWUzepzxo9tR{Dj{$&#=I)
z(|hL@DB2$0`FpxW_>;51qwE8l4Ju#0yF*C_Ou|7l^Fmo0cdXZVxaHJl+Oietg(*8<
zjNgsoorx#H^N=+4We0aU)nVctonG&J00PO25;u7e$*ps1hlSodt^=lVDPD;LGGpo9
zsXUQWKN1If=Ub~CP5rTdP<!r5tp%u@Z7IuCpm4od<zG9$D!1_(K-t`W<^inE2U>I7
z+o`TlNAtiRe>d6mKbDmL`gooD`|O#ry>jRdhJu`9^@`*PZw1g9^*SSk2QGVJQjeI2
zd|1X41Do|=js#NY776fn7@~{?*sFU}`WciTwBk1^m#Z$YE?rdci;X#}vQy>4g~vW^
z<_YJI?dQ&xkaZeCmGro6+t+H+6Zo6Di_&l?|6D{QYVMwmue*9cG}+$H&atgj@i>Y0
zY~Kj-(32CaQzsRUQAd5C`|iB`G<v*VNwKe?(rKj%lVm6&K%T);Su2qV^s(}?kn!kv
z0s>YIA>+suowF4NgCAqGVZ2W&DOh?h%#SeQwfDk?V!D%Op$w(5BQDfKX*4KoCnYt`
zmUSYo>Mb#?_!k#ya-$a%sDPLh9V_&>>j45f!#cv93>G%dokK1(O7s8|vhr3@GB;-B
z5}~s>);MO%;ZsZZT#q~mT5N3EwTm?5mTlikzW(S|9)2vyJl;HWo4>gg_HzSi)M~G;
z{w=UoIH81Zz|pz_MhCp2>gk}udOz0V1$(?@j18pO6Cv#y5N>nHEh6Sh@_wDclMNlA
z316j48&QIM!n<^EkFXxNV=IAl74i3Mx)t~uj}J(_L6$>xUk57^)FhM$@o}b<Ud}ib
z?J*22k8};+UN5wV9~$Z<4dShPx0RxzX-&r(U?HGm3A)#@r-s#y1}Que&5M8uwEFwp
zOjNlihQ}_UveK!z6LaGIS`A+(LIqUQH*NxRi9_^(r+S$Et*g18pKs5JDOdD8W%XZ*
z(*MO(CJO%enmpRWn=GPwgI&k{dLQ?kC31Ws%~}e~W^YP}opY%S?!KQ&c0|3RSl$U$
zo=Z}iZw*k|Q_>$7SS!1|MBd7H;jj##mQEnd9z3~AIw0`X?hOrQ^ScxJ+8hH>!+WUN
zhOTF71rQ6<R45Gw6Kh!u?zHP0gAXS55lI(7*$1IBQwERdQ`3o(mK=x)X@<}mV9&Rl
zarhV4gV&u>RGJLo^FBD<7bo65Dmia$Ijj?D^sN^<c3@|^jYSBxhqk0lK*N^%3}s!N
z{cJa;=M9!}I_wHKWwq(JiX5tpGO36VVAXNA*HkIK3JGZxed_ko=0bw@j;}FIzW0l;
zml~!FD3<}|P<~E#LZ^Elk%;Y4>`shS8ZYW}@9L<>4|9wuJxVYo@oF=$(hs_y*1}6j
zV}<A(ESwrXjV1-Wvb}Ke`gDk(A&<QFDVkjDk#Vmi*_}^h_cz>`6yukj{X8`2RNRy0
zT!<Qn$LEZQgM%XPQ$*=-4!mEKfuM;vT|Ii}i_@YVO{r(C)N(^uLEus8i4-k#nbae;
zABL(|iM{bAuG&yNO%R7H*qWp%vXaWtSjR(FS1OdlRt%<8j1?2IKmqT-P(sPsi!3%U
zTtmjEx6MGt`P-^9$-G;*=OWCfd+q^Fye@o#u_mu0XzCYxCDZ7fmQr9vtT}v7igf0s
zbJn{2oCHvhX>`ArJI&s`+alY0cwT&?qt|k5eo4f4L$%8tFdGz;!f*4p=HySd&QT$-
z?c@0OPXp|AhbK(JCi#>hAqPS&gr7d83p^@`%eb=lc0u6a#i930QtlZFSS$+b-X`O1
z={^nSP`<vd;KTKc5-9Eloz*`9x+;@IN{RCzF04IQc|J8aw=MSUW7*i-50TFWG;bZd
zLgm_lHDw<`y_4Q}Rc{_Kq*X!fCu|GY=nV&mbgfyutkFAtlR1jE53t?rL-bB<aGXUJ
z0(F~Yt^xz*U&5U$5```^UKp2^5k2Rkm?{_OyH2Y#>VbBQ6DlMcib$z06T!3fU(AaL
z^D3D}^On6&J9Hm~5naz2O3@{#8x>TDa4{Vu99yCs3f0WwE1pa#^u>n?XzY&3S38$=
zh-c#Q+&;BauZ#60WF}74uj^FGH2?^2VjtBbSy#@DM)OlSXT`}<s*;Rtm+nPdp+G+8
z6Wz|c-7*$ie7|%aYmK|Z{rWCerVcSgyZ@$AI<YjOGK;^g$1urI(+F0hJK%$@ka81V
zD_%ip6dMNdO9oZOKa3{?UFs3_QM#d^ILmidVR&jv6v<&1b?%k4uz8^W_&U!q>YWp(
zO56Ot?9f5p>?c%CXsNg6Y}-Ot$tMCkCj!_FnwFuRYttn^U|qk7F8`=a@qe8hv-9z;
z&KN<x|4AKR&)Q>35W>-$l{KXp(cw!+zR;s1m+B(fl(N*q<Bh6qx<?Ls^~Qy&h*On3
zTF*7u=%$PD8%6pq-LT_WxvxCK^~zl9?0=2<Rs%REyqVuNgJV_;+OZ{@TY#qRB6{N?
z_tp-~SiK|r=#1mZ-^L5SxFpE6n-+ozn2Gsq(6N<oN7sSmxH+tLROtV44mCgu(muF}
zy)gSuXn7AHdgH}3YLx~W|8`~A%mJ8=i{?lmDb1)|6TZo~tM%g`z}5f`iNV|lT!%wy
z*T4XvHJmpJkbSf;Z2cGH516m~+jhVa=eO$@wE#gmI|cTOtKNiWwH*xf$YYPf9|Hl%
zZN4uAgy7-BnDrxoa9kPC+=XTROEl*gJAQFpcU<$d+6>v?uLDy0v%k2S;3dDfc=bda
z*ERs_h+EglyS5+KvWH97xL4#}{Z)z{&v4uZI;^!zoL^kRF9ZHul3!eZF3JD2rzF;P
z3A}g>f5LdHlG+qG=&|CH*VZEwF*>5!@W^x0bi_h*E2nwwBJ{xP{cV@m6Dsiu+oe{9
z)U&zI<R*F)0}PvUmc($p=!cSHQAkvth0t}b;xKU2@%Re2MbGZHH&0qdin!^*b?m8f
zmW+-5j@~b+KpFWbW+cw_-^Gmn6WsM5KTrR-aDqEM5ZEYVUFN5O20-@ZKG937rfZl<
z{q;jBTkA<%z|Pm@b(Q`@W8q)48Gk1!r>z$=(lD|8-VlH%=$VcOmoc#&H&+4V^NY}y
z1n(xWyI$OSu@#W}Ge2unb^YKKfUF5@u8ybs`m{%Xw?zJ~c~VDJ7Cq|R0woIiC*=@J
zDa>rV6=STBHkNPkjRkX(cOG~x@Cbysm|C6fc(3A9$=0L;9aUYt$&7Pv8#`xURO>3E
zkr|g*J+o}@FpEI@r&aY?#%aUFViimEW19gp31&=au-cmS^O1B(cb&Eq5%wvTvusL_
zBaC1<ZGIK5>lxoOjDw>=Q$@=g?eYtomUR6ftr__r>%-Rie0Rg8tw5*gUBVq29#;_7
zW3jICc5<)P?o}4RKvylYbpq6N49t6@jvLrjkvXPzoljE{mDq8kj#qcWSK_M+C#nX_
zSyi2Z#dfr5LS>~xY6a-aYkMubUd6$~)()r7S5;DBr?QqzomJmE-JH-z2t$R}%A9xX
zMc&rS_U@+S8)3`5;=qhs)$uvFNRE+8FsF)WSHij+S}EC$Ci09X{G{YJ{UrDLO9fQ-
ze|2B4d5eDuAEgjgOkW8A^S3LG454QCy8^>`^Uo}e+bI^k4HJ*xYxQaZE59v_P{Wm@
zd+-cfv*^#f!3fl7mtCU2j+B_p$%HtHWrs2rBfz90+4wkP+;sZ;zMnEknFA|L=4C47
zO=S%o%@_IgWfjg^1|S#rMus)4!W&ei5Aed_8$a@DQRX5hVua%SW{A202rN#s?Tsrp
zHISGz2yA9Wx_t!Z^{D9?7S^lqjq#(p40Vf_edPEZ4l*J&o87O4=?ce8(nF`3HDX`w
zeByGwB4VdPyKq~5)XDvoOA`Q-grAZv-f)#=SIDZGZ6di#b_A#?#)YAqvS_F0hO<R+
zmS7@*Z*DGgtO!e2LCh+ymYa9)I_UPcOQfPJaoue`Gf`K1R&vdtP^M5f_BAB1_*B~T
zM)t=6^SEb{J(0LvTCU}oG2OkZ%zg8f4a>l`(E0+egjuf4l!0OL!+6oR0ZOPbAH`w<
z|Jk+T@{@H455-x?oiL#cT}svc*cNO(=^obNc3UIuycEen*_%=K!m}XG-2J{{FAub)
z%_<N3ti+q3K1G1xm%;DDd>-gZ&03`f#+hKpA=mDAPNkK=O`~CN2Vg4AduIEIkbwB5
zL;D4r6%S0;T$msh#l7ESsl5{5iESaULxWQ7)eKUZ1KyMluN+|FV^y$}!Q_wXK|l6H
zOHTY-@3eFZOWA)CrjiA8E#O}2_T#I0TNP%V%daZSsR7Aiw`0nK(vNj~7TtIB<dr#J
zhLq@sQ@jI5<PCg;vkO9Hz0>n)-OtQmB^Tkvo$e64J0ntgBrASoZ|{_>lJLyB7c!4&
z(@#v#l^AAN2VPTL@xL!ZB5cRz6MGlM^>4-8N)fY8+J`;XpyF&&je1VA_@emJBEMp;
zfyX6@T?=oVr7IZCNz$4$7_2RxZ4Hf;B=V@oT2|A9>tLdx?p$X=apDWT>?ulA+*a})
zPX9Qm`}l>3&w{a_-I=?j?{S(X+lum<>@9bm+S?!U<VQEP#5BG}Y*vJiTqWRTBts@b
z>zA&j+FIRS`i{*y5VLCf6gm&JmB+d_4|kf7U*)8f8(#?25qqIUa?l@2oZh%W-|hCG
z(gFv2d43;TXPimfAf4xV?4o_{xW<=aeM8Qju#P5@+r!bguoY~EBqwcaqPZ2G)ynH9
zTd8vuo3i>q_asvSxnv+8eT5hx>yl7B+Eu2LxL7~;y5cB$7qgycr+yCP;H=v1R_RCC
z<%I7^B6JJqM3sl)f%WXCa1}YE)Sy@HKKp({y1E0S#MM;-k<Ev7w^c2(gl|-pBMq(2
z=~q_t=L>iC=gT0neaZ{Yq8Nr%*zthN!%bFJ70-R?r!DqNs@PS=@G{HpE+`@j8pIA+
zAdA<a-Oy?o7hn)<YxbZNy^YOex>XW0;|sbhJDS?$Smki!v~x>bt-@GjZ>ytGfJypK
zMHvOy3b}d-LF`1|ys9khhEiViwQd*KoRxAG-XQEd-R`W@{3`dL+;FSCl&u{}dYA-4
z=AN@^t)3&eHXnZUQ@F(Aep*U(AJs?9iOC43jQMMgcio?^w<0%;e|8cxGi<y|1Q%bz
z3S{6U`U6{AE=7u6f&1)v6ZmlVgMBJmu4nNRs^+u2MoaP7noj&sGiqxsk6C@L)8L3H
zdUVD8(T~xwIdN7mr7#O+`J#H9Js0SSks6@oei;{uZ$I!saaI>a@r9fSr91&wmm&|`
zIxVXlbIx=ZueBLMvH+Z~Ji>zuOdTk&Yqd3^H8n}Vk2p)c@4INaf`lq2jAa=ZNjmOC
zn}G3K<8-P)@A$Ic`DiO5yV#^x{q<w4f{mb5NlV0?LWz&`561`2uz;bn>L3aKd}Oso
zsy)eQ%1{>vKlRC|$$b%3i-QLr_V!o&Y3VkkA-0D)t<rZ!!-PJ0=gZlgZzd0(2fSy}
zZA^~s(KLM*ivQB4yW_&%i*eOz;LR(z1f{KS^$n(g$W+R9@I>g~jVW0hT_Jb*z<I*x
z@DMliql8M(gLW8txghffKr~v?0lxoJLhDN&TRRQ@(2gLn#(MqEKluIs_f(gEOIvmU
zE&$Jj0MdO1W;0yn7nfj3`gZ*XOnb&=z7=3Fa;<$f(Bm)VBmhdVfgE9<CIBRA0xm{;
z9@}bqE3&(Oo3M--)Na1Uz()R3RRTp~%+XctWsfzW;%Y3%EH-JCJ`(zE#3BjgHKU(5
z909NcC<_fRn~yP{j%H!nYqxb$esM*aY=r|=V20M3DUf%F3ei^w|5DYN0SE2cJ{Baf
z9Rys0^x!5kdd80Xw<}9i0%q;<c3;C^Yt;;(x)fRn`7yXO|2usG+*IN*_rGgRv~QaO
zbtvt{N{z~2icKKkHLm{<bk+tx5Su23o$a`NTZ^>#*J?2rxPI=<^Xn>`Ky^84Q@c7Q
z^zHr8--a;>K(Widw^ahH1yBQvXl-BD8shG#ofrg?s8%4O694yWc=XRD{BsHaFMSFX
zej2|><TuD^B;j8ouTZQrwvtU!^{r~>aze{DeTV<{n|S}M-0jXCXJ(&}fz2%Gy+|eQ
zYqZsc&FSF&r7ZRnbxXA3-+VcD6}<RJ=lvx8?o*lWh$Kz1sOad8QwD$lt>bTR5c@Iz
zAH9E15MMq~Tv8MU7&ph7lIbibLS&QqLYsD@FjC9*$J>OV%OqZZo=R7N{-tgd1v)9A
zR1P!02a&J8fBr{re(QeQ>BNIBxE`Hrom1YtGwFB!3fJwJ$l%3{+ECXS00w+piS}}v
zr^a#JR5L{M7gsO<4SQ-W544dfM>YPksmse~+;sLsi#$Wz>bN3%+Tgj<#?bza`Xkzc
zCw3{!UAGPC$bVX*8{ugdJvSalf%Y2?Aq^3T^n7*Dx6%Ul6}sYmNDdvCM0u!ONXKMy
zV1XN{Ag=Ivs9<<(=7;XAJBuc#vgQ+X+<$-PxFYUSrLcvMMnoZ(_Q#2sfF<o#)vL$^
zwL$}#`r=k~rQBqh-G7Jf|1`aQ({})v8N45}3^6wx3XW!9702*ptOC5@?2EOJwMHEQ
zhn*7dZIUA9g^;!jW<KE;*YwEM^&c9KfA@_4KK7fz1ejQrs5W;Y3<_`i;e=I0zf5&%
zXgPR6RWP6X$t1{aEitOM76QxOa9>^u`s~xRLP1UXlvnt4#Mxg*-1EIzrF+Y1>C*YD
zh~0=AH@T)$^ChpJKXKH+)Q;9L>sZjSNevDnNy;VU+o&tf{4`>onH~64w$P2@2tA~{
ze_xw+-|Z4CZr|~S(bGFcsxFH<T|hTZbsl?rGqmwim^-v25=oo&1sbP`1}gA=5p?ye
zfE20O)tS3hNWylY&%Xk$1oy~hAQEar&Ohyy+U4aVLMrNAf;5aDy14??XdJPG_{3(3
z9bmy4H+c5=sELxQM8y1VLe=fJXS+B>*i|RMaHQFi^??-^29gW|Wmi;-i1y6GEz_h~
zDG)uAg&EsWx}$U#<94YM_4OI~@lS1n4I3k|@q4*ppE?YvDGwiie`Nw{TF)2H*V&Xy
z!u3tBjHclzDD=BE97xJR=6y{mqK~wU9t$VNS%ocC@AyvDC!8;<NE{xpZsYKk>2{nx
z@2YSjyhbcC>!8#dn+Gv7s?z#<!xe{w2Nf^OtPv3=o@2yfoWJ-K79C+fkLp>*L2Z$y
zFo=X`whv*x6*V_l53G(&p!A{fITm}abKDv$_3GY+G9s{)B%B~j#$J$&cp@xchf1sU
z7B@>8HkeXCdm7)Gbs63kuaxpa((LiuBA!cuGWY>RTu@0%W^bz~vpA)vkXoLyX#C>v
z)_@V*qhwEYnVw+mFD|FsDIxN3T7i^;!K2Wzmq#xjJ33GVxHDXRXPGiKwrXmm(Td#4
zt5<tiGkemz=<NYGQx-OeTX8?=ST4F2Y`--D-_SZz{exKD+lbvh2!iKWudJQezv4$t
zx+@$LG8cb4@zX3LGIyVsIk_NPwF}$ZYn;s9!dI3wF=}N>pzb%~4EVbGyW@vQJ$=&V
zggJ5+tRI3~p~y^X3T%Io$6KMX5Xkdm4E;q#ll(>t);mI7_?fiQqOK;MJsM?&+~~r%
zak%YV-(+#3U0V~I#OY%tOn@^hE#{pu*OWZKC|fwp#&)G7^J5VnCgD3;5d+@cajfj7
z<kMYmFT^j@+X(ALb|-k>tJfi!f%B#CJta`6NC7lo<_xUW2H%sL6%MMO%kU|1?{zov
z&%wbuh-}Qzv5Hs(c%Y9T&EGrk&N)H6aqCInUe!eL`%mSuju+3iOvu{p*=ct&;%%pq
ztUcq!=Ng)Qp>DI~YzspI+;9iCai-oIOk~V4%D`kM)}Yb*-03LVa3vO2xOAVeqVJ?U
zbYDa{c;3l!Xp{{g?a^Msq1s~piRi0pienZVU07(foXfm$&8cEn1e|v!p&OA7mD0s>
z?&7*24p()mM**{Z+i5~-ylr#oLbH2*9;o0}?{xma7e$j-{OuL&`(dj1rHih&QZ<6z
z*E}xf(GM!y+|t!}7a=z<8CQ@kR5sp&rS#+#8cf!+OgLFZgyz9<gT)okoNhAK$jAz`
zDVG8^>q=pw$bFlaK%To-D3SGTS-hRn4=eWa9w-3q*+Wzwaum~aIh1U^R-^OTbKJ5=
z(^*7#R=6kC_D4}qZ_2#STX}?xQW+TH-JOsfFf~W)p~7G)qJz+(r9&Qvdzj2k<NYDd
z%{QM298wN^dEOPpwM#gARB-mL4d-N7{^?H`4|F+XQ@Jd<ZpAQ{U3fe&O5p{yagMS=
zS}SG}dN^}UhTm5s<88e;R#wO8%^uR4_bQHLI6J$IFwasDH;H={JYu4-yILU#vq&45
zYHQmTBRneK2Ey{VmBu0v_GCs3@w&BXBw7*8&>RmG8Dvkyf-X704|E3U%Gh_QST2GN
zDEsceV2Zq^drG2x$G|b9yu4kMDWpw4d^sHH7+K8ekSRe8DnvMR#9`S8jgom?n6Jg9
zbep2N;u-9ew)EHQUtgvhk9dx23zsUsIePh{FytlkGqzqEX(RLCw3n`&b3u}9Vqj`t
zVC4I05rpMe(31VkfS+CBx~%zzmw3N~?YdsU?ZFz7N-rC-UpS;y*I40V=B<ItHV38h
z?p{5S%N^S$>B_76Ub!=XQDO0;H=2+hc}?#$Qb{-t2Ad6z9;=}MO0K)B=+C=8o9Mwj
z&^|In;wI-4;L3+m=a{@jrinB$nF};wG8l&Lv*)og6z`X^W%810t!nU^(}v_hNJRjP
zGc})0HiRF^jQR9WF5&)T%lZGcAG|9m<<sKzSx<Z;-Dw7W`Ptrz*l07E!r;kQ6JB4&
zZX4UU?L0nwkRT;RV7wl2(CmMB26A7XgV#=;rF@^adi4mDA^4RWSc}8UhMusC#s}GD
zx=la637;*(=YQP&$p5MM&ia4ndH0X?vzHtNCY4t{xIcRTbi#l0O^owhy_WZ5PR7+$
zo==v%LQI*_rA_j@k}6O0g`j!~Q$O!m_7CcvhBq@OvpYiHe5#S`K7_-wppn|vtB#6?
z#;%{TuxOaD_=xoC@-aZW=0<u*eP-XyXXmT5UR#qZ2gcP^XR=~R6{RyxZ@DbExGr;j
z=eo*uP3q<ndA@L9;d2q|N4j*+T$jS+yMvbkj?tX-Doj@Jr>Bo}j6dG*7Jkk^=BkV&
z+*qH|8J5HbSIceD0u_RUq{+A22y5SmiW2z6gvKLWrLwoig53r&{^~Tr!=r|np;l$Z
zXO7bJ<?q);*w2R2AL@!Wvg;my*9^9sP~yq#>$xD#ED|xynRUUF0O}t+z=uSMH3b#j
z&Rq7*Q{+${p*B|524>~F+gEQX?h?&#3RFWE*fZ#Mywrf4=a(*tC%DKq<-(K?%u3Z3
zf5*FTt$qDmsR?Rlfoxcv9J8s>EPjS}PqEz4Cz20OuF=uNxk=_n`x4Q?w9a7Nm=4AH
z9n*CGerp53t3gw{`^@?cTdSkh&K2<Co1|MQk0Vu7PDvT1R_01del<FY1=%a@&Y1;9
zVxP62VU+Xg=jrmMjrZu+lV`e8#=y&HBO_W+0=ht+RB~F6|5a4}N?s!4cKS6XLPVZ0
zRxKo`*z?@%=uH)@LV@=2lNs^7-Y4?$B<mNFP`R=<B?d-x5w)ca2D?=@k20U6ll3MG
z5L5WI(mlhbMvUm**x)Qu?epz(<i#Ti4|t0iu(4`rSNnVQ789uk^yzTfUg6D%H=M?T
z?4pAD*#jo=RxVS>3J$bnocCe3q|Ah6E5}IIA!Ryu6ly#azI*Yi+vP7~{mM@iFQ{CZ
zwW1*PU0v?ql)r0u;)wiL^MIavufQ9F6qBG-9zUTiYEw0w&_sj=IVJ?ube6ks<lg}N
zmWHVtO?*}gtIxlH7ed=r_&COVnOc*BVCPHdpz`qnDYS6!lmW^5KG`I97N0&<OpJHb
z-O5bGQ$*PE(2iUU$>8POnKvud62U;<q}d%6;nU}FiQ9Og?#wT)mrC+pS--fTACy$0
z3`;5mJjyRzdc@}K0JM-mjTOhyE^-r|)M;jN3N{$bTpt1N9s;I%)ZSzGeZ7}0Ptf3t
z1XYoMpA?Aq*wQtQ;}aR8;rsgnrs@*0x}Z-*(p)r}Di;!@Ns1CRdX%r`&Sd=bFE2UD
zyT9w1H>h4@6sNxc0iR%eVx8;UG{h&%_((W(8}Qj2uwQE@4f`f1AF-0&xu;?OF4aq4
zS3P;$N}gstb3WUXZJ69lafe(>Soy}r)|?|?*8IRmCNRCZZcoE<OQsK*Vy~ff^01mu
z8hnl*J5d9BomEN=rHjLJeM^N>RMG_9Y*xzVtr{&q-q~L)DQT2?NspN?`O_5M50Xq8
zi}n*~nJM~dJBw&)lPnsu@G^@$1J16(pbLZI0`paTytn$wm;H$Oa)CMza;CntB|09Z
z?P+#ZPm7`nT%$dV3GyR2Wm)=?jBgEb^TTX5%!fNCU0q@&no=JX`;$zwyU>&s$AkWZ
z#wcURbahKJXuQ{ZT4;}*;J|19mA=p0smm)iX#d&d!;}j@>TvIy8Qs}0$+0g;I9AVt
zjqLsCYD1u@J*qTw&+JG>wZz6%57(Kg;6>nDYi$n!pD}9Ji}f1%_OqRLDql2qtK@{S
zJK=ndGR9dqR9k(QM9O*BU9si61PUehUxhZ`nzl3w0Js{hL4$LwZFI$rLa0f@L0osf
zt<cd;Y9xsPh?e^<E|St;W&1w+oNvu^u(p97D>9)c?+<Z`$QO>D&}}|b(&V7)S($V`
z4i_pW@-n3}tMH()Q)>PfU0?t?i5LKQnW*M9MVNA~r82^(9-KJ%e1Ht3$3~!Q^?_|q
zph~vil#gPCYvTBqS?4q3tQ%m;R`$L_UmMJ$Q@B-4^||IPkUd73<6|$R3E2fU4(?je
z+$<)UNJ&lR*_tvn&ybAoegky+lH9jPg49Za9%4x|!<kgA{R4h<Y0p&?zQGxeG0)0+
z>}w*I8gyvSLFMIv8p~lTgvw?=534vHzm~6>+fpNTu$toKFga*Mx4tx2Q2NZzU2LH?
z)TqOuiXb{y)3eeeXH*pRyG*=7%2-_l4BLxO08|iiUec#6p;7NU+cH{<Uw&~J=wP@o
zjkWgx$?D{myBlC#qWQE17_cq{RHY3*Kfn6@=D+@3Ms$Dl{f&ZVkt1`G6IDk{+vaW*
z6hxF?5!`cUhcK2)5C_gHtZ<%q(+TgFswjg*>DicHJ=XMr_pbKt<1yNT$Mnue?JI!R
z_ZKQ<8GF;fN<IYvNAQ>bQ?vJ<$(#DOcJUv@`p1oBzz_WX#HZfv2lmi*(G=u_*ERB2
ztdI@io8rln5&TXkp2T3^s=e74Rgwo4bSG~I?%H;kNf_8MtyI#g5s17kI;LlO=Mk3*
zan`8M@|j(~L0sKnUBr>2KKFX8y`Ao!Ha@gt_nkdc|6)eI)E-vLmS%3j0bWqfnbA7T
z0Y|wl2_fw`Of6t>`#xhG;R><mPX7yeUQoc-cEq%Ml-hIFiLATT;tpzZm5kW8!yI$!
zG^?NX#m*1nk%CBn(XFSD`~1_Fqff&lEvwgv#3UOrG-|t@O(4-dj<1>zUasmg_~`q3
z&cxA!sb<2aU=HqR6fiz@p-IknPIs5W%5mR^wq9?A*S%B+eO#-Yd%XRN^M9@sN`5{w
zaI9;$$t5|aEDu8J!*{a&ch7H@;c&F3e^z*EnsB#ThGanAAk)~Yz_O;K`%C!(la!d{
zSMWAAr`wVzSuj6hpV|GHJ5QeLu?AZ9Pd=&NFT!om7l9w0XR@YABzl9fjc!hxyr<>N
zSStpSIyUhctS}Bx5>Lw(4Uwq<jbP$Stlp(WRXw+Xf(sAIg%rLAPVh+Oa-;npB`D4p
zMvS%0t=A+?RZzQ=c)CZNp>2S}MMt!3S{#dcuGdnBs<ngu8RqpM$OlshVMzkH4K2gv
zlfL}1ya)I7MV_=-?7PG>2G!BQ7p=u7VvUWeli(yMQ~9Y>!jgUU87MU;!)FW9os}D?
zSlTsrkrF`AouNB1L|Qwr>ZpcYw^Dd^W<3@_em|6-i=J2Cm{W+>Vi<t(ZDtFC(kXE>
zBbj}%AVchY;vzaK++HXnR#@xc@~LG`S31)L%6GjFiI?%Uz0u;dwE5;{zDG>xhYzPT
z#+~8}<T*U%rY2oO6%%j|3W{-~vmBXJHOdI2Z$f5aezv{-^ZCSdo(h}gjhsY3k<N=)
zahv|5ugi2xOH+<Vwvx2>D0^YG34Vju3@8qGb7uy~i;05Ica_}|7ujcOMHFd0x1pGn
zY1CXCHk%0f3?z@m6kB6rc0O@`0=ugGLYxT7WAOcm`pU?vSF5X#SDIV}3~*Z}lWOJ_
z0N)(B6+zrj>==3t{*Iw_$i~_|>1wy64wJ1X_$-#VuR$S;>*=cfn(&FR>)dLW=5)HE
zKTCMkLLOEXkI8c4s3a^fw*5@>aD-p5RrO#RHf)wBwrL<xp#nQKyfSFgQ-ot%;><}@
z>j$z-eTx?w-U8u*o;VY`*gN2U<sQHV@fVjpcE7Bj*9<)j)umr3H%)a#Yo;bCgYR9^
zrwNPhMSf_sh`V>c?wDN&wq9R`b~Z0B!NI8~z69@Wu*J7x_||+Ln3G;10F!}KSdkc0
zkJjZrAHJfOxIZ1nSakA&ogMp<%u78I$zu?k8Ou2T_|f%4JI>@2*NEd4aw--AwzL&;
zddjH)B?P1fGMF?|5x^|w)DoEUUQU4PpjY0jkQQ8*l-;ES$!wm2*YCm_^;o+TFMPPG
zD|OD1Ss-;Q_v)*yYzZR67=ES;T%6XWLeC=fnmjwRA$u7tcg+ml*ZDEmSD9f<CD&eI
z+8H~$_qugyz$q6Q<)YtW%1aKMI-aoWkxTPgzYN8R>?vLOq%BGpWeIM-+|z$aWOvp+
zdwOcNIB>T*#>j&Q91l#g==_8#`3J5A?ZvuyduCm%K2mwsXi7e&Z6~+L%M1KmXX`UH
zN1gZ00yoK=;M{LtsmX>9!tAi|St?cchied=U}!-8a?}eY%mRzW-X1Y~ai>Sxx!MV8
z**1CihRII3ohQC<c~++EPQ5E=8a5hz5i!u2kl{zIWiJ~HiL}e2vxpCJa5}=Za#j7r
z1)prf1Y;B%kPi-n&ab=x?Jkv|`FWjkO=w?lkRg=?YvXcV3UsoYEe(){w{X#tCNqSo
z`SKHysbXk<XdZRCD3!E~XogEWt9&lBC=WM&$}uHJ(QQPYys11+JJ5Lfp5F1%IyJgb
zK%TJ2$9gf;FazEom^3Zoy)_qEYylI=G|W6=9*^xX2wZ{aI<Pqbj>$~F3M%?5X#t!a
z8V2n(W7!rA984AsLzcJ8SzT!~pSMw6;@QK!>r~-*?_uFAWBt!F5Gxl-A(^w>Ni!D7
zQbM<y`3(-%;Bq@A;nbh-v`FndpfUc>=^Fp3nf_BV{ikO7PtEk7n(03^)BiIy)33Q|
z$vbs?>lQbg6QgvF09l~qkLgrrgR<BdZQiQkxJM`~xJ1l#HJ9N+MC)FTBf7$_oz2jz
zPTTOydir(tZdahrwQ8bN&W+v>=gfl4f!E{bS(2a59NOa?;i8SyZt2i{dr(Kkx7(4G
zD<U*%bOp?CZtJ$HY(47fr6lKLujApuq2RpwSi#eG;8O$qSE`Bt{+w?<;3<78^q;Gp
z{x6GLxwZ0qU7EJdybD$;oF2?7x7|y9@>N~zL>}$a?XvSUb+79@o3k+eVRNwU07ejU
zo@%n)eOssMOR=q*O#AhBrHVT+#)~4)v&H&H;+iUViL!j$WcOap5WN%Cq*e1I=BMTP
zr`J{7epkyHOT#4qvkC*jY)L$?lo$Gx1n`&*^u9U`&Ue?&iEXDO_x5Q|0PFTQ^|yQe
z^=~^4SzT^xi@mCTgCT5jw?SD_0QMMUNpJf0@GM^NZkUQ)Gu&d`UR{apui38saLpf|
zM(LkQqbgM(-S__G{QsN`>QCJLPu%@a-2G47{ZHKe{|C7Hr0jXfOS-7^+mEIubd}R{
z#i2IFZ%y~*^sJ!zbEvsK)m?qwU0|qim)psTpM%De1k1_X{8#seMv2tzukX_X7;le<
z3TM#H+3AFoU1WUTjZxnt-4Ze3w&Ur7Eyn{shH&l48%#iflv%Irt3BNMRa%`_?lTNC
z;WpJiaC{=6Uq%KU{Pedy<3G=7@IN)<|B(jy+dL==M+^op%Ma+KhQ{(fzLt#Cv^;xL
zcArKFj_WhPOh!$8PLo`BGxvTztr8P(l%+6G5cR}#()`HIh09#E9(^*Z=}iLfw4ypk
zF9~ftK*kmXX@331Wy{sDC>CBkqe!J;8@4-#r68{^#*UB^RY&z-7nbX2EY4bfKHGna
zThfnb$I{5AUCpAyD^I+;^2XS`;~VBT-4Dmrjkdg|XP1%;W>24oPy8|Ku)Rp?&C+j%
zLv9``Ck3W7`XpIq*w0$LnK#n#SXSlvN7rC#%~)9oBWEz$SfvX&bk0v)mLOL(QX{lF
zsey*dbbjcK^pHzzbZptpd#FgrDUgk%`i{imCLa+WsL#<WTm@972qMKeCgj$jw4_(l
z9a81PK3u}=k9mHd;zV?Bvr1j3`?1xqUbteCuj0n5^g&g~>t0{p;pG!>l$-T}i1}gm
zmEOyNWrd<C(K5WkB&dobD{NYvNSx+ZB{<=F3y|jKwx(VMnXItQ_(ACmc2lp%%%r*s
z&)xpjCIOZ1p904x1h#Ip9eiYJ#Sl*PbZrUa^?UW=!CFk_TIkpM_y?8l2RV=MxWJy$
zqsd|-G~Ux{4ZY)FNRoN=m}s{dOhu$!jW~bC+$@~vcqLyISv}L8U5xb)C@`YUfJWd3
zG%=gIOHW_!2JGpA?(M8v%C70pqz-&(k`)zIE4}Ef<*mE!X*YM-VLCzoqjGm~_GubP
z$cKqU(pM07I0-XH?2_W_IwI9t@u{|tJUNItf`}|^o_Bu*AGRjq+@)@~tdA7<21F3r
zyI_#CQvyD0`C6@Rs91I%gLo|LW9spz2O~>;X2!1J3i5w(DRtd}H%PXbaym`G4wjKU
zbHsA92t{}EF|Dz3Q%?|$oW<Y7h%;)MW6h?U`4(@l95$%C`sz(r>j3}7CU*1KMV))2
zc1<D!2VB%f;&ULXEzY)*Ir--4rQYM2KYQ|Z*CEy*RT>OaHcOF=FR@JZ_Qb(8EwP^Q
zR*?Mq{Q7>yWhi|zcB-89WvEbMo=)FrNdZfrJN-2ttFL@w+SjfPd;G%dH0%S|^&O&A
z(Rfeq?+LZRBR<*L^R_0o_;@qBk`(Xx><k`=FQ|2@`k8$;+I!8+6b&X1I4X>xjSYz-
zB=j(q@xUi{=8v4QvOlK4@<f@7?~X_L22A1lE8CQ=vJ23u_#~+5qcLjmW;cQrUEt9V
zOv4e^HD6a#+Xz#cD`0~9ZO?I1nkkE|n<d`sfx-8!TNb2u8FjnDa-R+VZ(}TE>|Vo2
zJa_zKhJ_AGzR;zc;Vz~7wzVnaie+3G5-Lo7p`tXPhfh<-4`Y$#u(WzmvHAR|oX*wM
zbb=HlrFijH4(6yslSP(X?tr}RDQ6kP1nfvl<;QcG<#n<a;yE}|gK1YN!75JqGp)&d
zv<u88r%$b*f?*F5dum4=I{>=u1fc5Zh_MQC<kSN?P5^G0EST6M$C1E%yQZ}znM}%o
z^(9@!uUM5q`d?<p+=L0ADB>KG9Fx63frUP|&<fTGW42u4AmI<yMxz(jn5pp)Y^_{5
zXTVBnZq3%9t1Kd=$|3Ts0vxREmSP}NxU>-)A8%VWZUjb73umDy$$aOO-v`~GGwA}&
z0bP&6dV7;%g^@QR&mXsMY4r$vrY9UQbes=fCJ7fYua$P8qa)?qYnrik6?Rc<yC!!N
zfbFRD>aqvRj)0_uWmq|j38&yV9(>qTZy1aG4qEoPo|0Whv8a3AHG`uiRK-7c)ZDF~
ze&^7jo5Th1TW3sp!>&gs(`B-aOrJ5=+$hC{I+-C1dm$~#{5&L^Hja$e;H?FOKDFUC
zMly3nTMhIL6|_f^ZEyOuZn;kN4eK*7XwCt0ey+Qy*)FZ5@$ju$C)wKRWQ`IzH@9c?
zkC8+C{+{VkfmQ88=4%OEoEpVAP%Vmsj2uo<NS!HAg*A?57LBzx&TI>XHnk@N^rB3A
zr>+@C%jK4KHj-iqqm}9OZ!Is5p0K+etMM}6vgHNH)1sR@_wnNFdL+yOj53YdTC-0Z
z(Fm2P=D{vyN#(hw1*9Qvksyn?%oKam@oF-v{A;#SPUMjK^ab7!J*Dmp*QmMU$3*ok
zMG&bi6(^I-W!o>_KKOX7s^yHkW&E4!o|!Qz5jXZnFPb>vWV9qXT+fZFmfR#MZ<a9H
zJyO_f*A@7RJnJK-;tdQC_@W<gR!@&Djjj`sd7do&<LThT4Cpb?<qDgKZRkr{^|PF#
z<xk$tEL9xt@r=wiNZppKqQdu^+jSTRJHsTDnhW8g2`TY73+J=>0bmXePftP^KL^VN
zIB(L=Bt^<9ZhXyKuw#UOn-vKYFl>-tiz<zzzw{`5)sc425EW_g^d8G@FEn@lz0OvR
zQ+m@RD5qpoXO0a(OsIs+uNJ{=SFjt$BXA@JxPe2CLBYSI_%v<Pm8t-h(uKpW+n@FW
zW7<*OZ#Va0`kH=mt)p%xElvPP{}0UMp|^_)>d`Z`S0z}dM$)?#Js)c@Ir0}ys5PHj
zDP2410+}zDqZwr^{%|y())wiUnwzJB^^%<VQQg^1-wOaUITCTJM|aSkY#-N`Qj~!8
zv}+2E)c*>A;D=^iw>1!$>1Va;G6f<FwR&r3d9=cfH$8uGb;de=5Ms-H!}L)wwm7ZN
z(QnGNIKYMdTuck{K6f2xWBi>aTYn2{|IeJif2N4+A7KUj=PLzbI#AJjXUdY@KTwjq
zr_O`t6;?$!%%V^7=AryclG<lqD()C}(CU!(7TV9GPkz;dA5;FtB@F`xif7+!7OMKf
ze5LvG4<!=q+QlL5zjL$m$3q$wabTONjOz?@v(hfO_xsK8Q};<POW`pMu{k3V<n99s
zj}$!Po>-t}QaYsML<0IzR`B&QQ-fJ4<+)8(Ul0>(#g?jxJvg<$0K4sd2ZSh$Eq96*
zjL>ILAIazKzI;kd(rBL{bG(9a$9Q|d%YATFptc!~_{&g~Bc={z27n8=NKON|Jw$Oj
zv~q_nUv;vq&G6mmvn_Y`ynptDZ5VSZ<Fz`1Rdn|A@hYAN+z3#UC&S1oOT0fP^$b{*
z*n{sK$QO-IO-)#PdkW-UoXH69Yz5id<Pe(qNMH)3CgcjVPkCNxJFidEG-2?8;1j;<
z*1Cj4e6J;~8_V7<C2<h?^xe%CyzrddpmPHRdw|odTBsw#2!fok97p?qG9fbnsy8TS
ztwuJC(SPZn&O%X_woi^-y-ZHRRb3Ndu(CixrPY8-1T;1r{#g3fX>_AgbOL)7?vWXX
zN|n?#r&o7ISFKf+oOLb>>rq=mM3_GuFy)Bs*M+hRmt-vv5W}JIaX4Y5x%{ec;H8I2
zNBuM^_{|0&)r8Lm9ZxiFYwze4&%DKMu+Rv7c`q$hz0|)IKXMgCbVn|U1P$XW;|7!S
zl?tIEygczHWt4bH`=uM3CE&CS83If~FBuw8QD{`>xbWiEx<Ay6X+Hq@v@(A@hVdc-
zqM+e+M%{Y=pZQ#YJ0@c2<2VtCcvSQ=Rcuynv$NcRZ40qn1~KQ$u8i8nWfs3xWg|<<
zN-!u+&<QKJFjoIt$_-+M$qOs*RwmK(rhw~XEU(z5?t4#D7tXSe=w8$uNr_rAiKxCf
zkTe3TUN(fWfP3z-B0MG}CeE(?(Bg3b@71c5*24_5*B43OcV-6<79$wa@)UF*dVS~3
z-LZ&E=p%;wM?H1b8x*SUuh`}zCtZeG(T$9#GRrae0h94@==(~&1X6Fum}&1MNS6i@
z-uhPE>1wF4-%H@5<claBC!cGlt&e@!IHsQmjP;BlySH?x@MWLvqWsj8fPMc4Z`m)?
z%4{Wtzmg&3_(qs0xHhR{dD2bxsYVzpzPWqibb@|g@=^dOplb}4JU=gMW6;zw5syeE
zVEn;0<QBgZ(dCidvKf+e8cUv9Re7@9q`LZBu6L0QWr64)+KsmAQ&9o!j+R!QU-5aa
z?CraHnNfdbkDjxMaQjDK=oXHq1M@)*T}215+nNGw?6YBvTg&C$9ZZs|Q}+IT+kvmO
zQavhJfxXo!gWv;}HT%fr%8?UH1Mh~tT>&>Y@;)iLaPjdR7RZ9T#Cg|A4&Mu_aY;$x
z<P499Wsl?5bd==$RP$Jt<5i{xYP^+vG2^C&c-thUbsAv=s%9(0?k5jQ4GkU{greWI
zyTUx(?HRKrz7%!t(2y$y?M@kpL^BCp-Q=g_PG{lo{0GH1Bq03-D00Pkg!w%u0)JmJ
z4R+3@dR!uBbb@CsO}DFapezMhJul+BDQ^ry7P50tWKCYM%!hIc^?8T00s%+Vay2y?
z4!gZ~=)SC>-wn@Gv^#G#ZB5|98P!dxW{JhUP>0^}F{2LTxO+!Hy^@g%68e4#1Y%To
zr<DXdxRi(ph_%YZCsXq#SJnwtiRhOiPo3#MkP6pcUWg9?Ts;+HPV1jPlURa?RP3@<
z?4m$9V7{~(Xzn<!+?bZ@;`MG-dpDVF&vF=)3EwX>^4?b&|HMG5yxxPSvn>Do>FhW)
z5srMTEh<Sf%C0PO7B1#2!<&Uls5yHQ1xkLOQz_f+7hmZQ$a@N@O&y3yFK;V~<!Pa(
z@cUB7aHHS8Xwfa}h>k8c=wxnvosW^unr^Rh<+;Dm-t9Rc7nfA{lqkSb&xRL|@Hg{I
z5ecp>aYiQN6F&;nTV=8XygX3xxT<(tqgmV5T%PUS#I$oKuXTRt+dHLdF}#1z$D}re
zy1=y2wUn2jbhm~TdPszLKzbXU0!FHIN>tF`I4E1WD?^NeFP<}y4CK%=11BFc!lG3I
z3cYMMtG1WI-IZD89rxc=y{`!!HS;57hfCg9xcKZOmsyL=0m-Z#=OZ2;O`?uxYR&}V
z7|Aq@PxG*0lQ9cjo!%<i1$S`hDv=D|W=DS-#DTM6Qi!xTqdrAzpA9o-WLs=`z32l;
z0eSth66vDLHe3h=-ACG^2brmoGLtkgic+&}yIhe6^3pYDb%lq|yH;1Vx*z!6lu)<%
z#T6}(u|6cX9q#@rP_AQJPv_`x7ofDpEaR;fxHrRBgnrIt^yWk_jQo&p-(uHp1-d%g
zbI1I4=y~OK<%`E~q<yweB*-N3ZkC#$Q*1kTwEH@J5&7|6ycwe1*=uZ4NzmZ}4PRV=
zy2ig@)U_P|^bjy7H(_-v7Ft-x)q}sdF7>X&Y`bm!&?3%i0pmG2i&_oQ&Sq;OzqkOm
ztfSDQ<I${;e|MzYzaDu0&*T1Fm;d?C%hC@~(5C0Xx~8dzjD+*im13T;4lQv}5GCQR
zm2kaW>vX#_iJG!9N;520#0qZh=Hy@ch5zlW^$%0of9#k42ygY@aKOI-74DX|`>cNT
z){ohP4`VGtPJPRR7w-^(z@+ZIL&bPL6=!<MkgO)XXZmPAHm>a{ADhCWrd<nAGrde&
z-tQ4Ud$?R-T8krIzqssxouLD6A{V-@)%fG>rY&Y9dOJRB8*ojC4gS1c-L>A`u`L+1
zC;1mw4PX*c5-~mfhW$J4r7gpuoall9njf-UvAh(0@kW-|*By_!z6V!o^pzW5sWW*7
zHS;tHE8`&iloZx^U8cZ>IHP%1so^%SXvh|=c7E~~*8#?cBQHy9^?<^5^Ji4j_HLnt
zd_|!-FtDi^ubOO?gv|?W?%`f>5Fpkrod3lY3VH+BWqWL_V?IUC23i4v+VA38WeZF|
zCH;hZQxeR*5r-M<+UCK)hN%GUdx!Q`(sLm1+ov^T>ZUc2vb~+LkoCX+;nA5Y6)5Jr
zHgFAb+S{XpoMqtjfDc9S;xDcbcQDRFR70TtJGyF)JIVos*tNNv;@f@o=;-a8Ascds
z>5i+%FrV;WF_kJ?TUtYUD>YJ8m<1l8eqTf<aD2$W4-v4Kupa?--#7nrL*)KTh+qCN
zL@gl1?LQ9j$?v-etk;463qt&--$e}YoNoTXb9#m@_IXz7GsiH<sjR5+)ZtFPQ_hme
zeal*DUREtq!*_r5c#fgy%KqwUJdYF~Em=VGC8Xx&DW!})tp7dWz5RQ*1Ak-B_*a+j
z|Mpq@Ch8s6_z>G<px<J47<peSR4!>dKKc!<b}%0^V7#Srh49yEd}n%=KMr2hhu!N`
z@oMaDmb9gk^o^*|Cm((mO~~q3dLUAQuW1Z|o1giOzM&9nmZDZMBltxozQS;qtx{DD
z<O1gMF>{4?L9t7;rrD7wBUtvQj)-}xJ2Um+U;#0a0`q~N41Aa0E^(uGtlYufsv@h(
zzL#P%2$3E<3Cg=UEM-INwEx~UCmIkqgm_@{-75Smh}8e~!H0x9Dvj;dAK6VsID`h#
z9NU9uV*I6wGCRA9?1o8Lm~B4I!~_azD+u?OVw(k)VVb3EYRmC6112G^BjOJS&AK1z
zrF#54s4DXj<oFP4Q=g$AZZR%;HhTO<_&EPfK9i`iJUQkkVCsuyou*T2lCZhcga9O2
z31M%_iBB;B7Y!t7jCWN*O^jqa0^9IIO`LMmL<(qfE?-@&R4kGtC7k9Q(stndF(xVU
z=d%M#ZHXH$Ve?)>;_qL-9<O^9zttfyS?~4!V?eRRrQHluO1!IRcTk@Xtr^x|d6Q-J
zP7Ub*_R>|HP{w*fKYn3SDa827k}7l20b7Ih%f8Vj#L8}h(*B2@xsZ>NcKfm`UfJHA
zIQjhj`%8$gH>CDH(%mPkT;Eq7zv5nyyV(cUt~gbwW;h7aQS!4@v7&Ug8eQ(lHv`;t
z5?ev_Vxsg2M=1nYU5Xk&_5%Z|xNk~Q$EHL>j8z`lg-bQd#lPZx5$h%XzuG&`s3y}k
zkK;RzYe5-6+JFt|QIHxj2%>@}F)#@jIw&9#LV^UOBaScVP?bPHLel_IN<@K#5(om)
zf)PywB#<~LO?rnIi2HbU_dWY@=j^_7cF)fD`@?gdc3t=Vzy7~}_6^;K6KSZNz|V#x
z|1xq3Dyp4FP98v)sD8m+)%dJQlk_kq%TP_O!S6aSH6mAN2hs!oMDdA|FYnzGEcHTJ
zZ}g$N6;GP6*m)zI$@7ToXHn3@AK<i+kW&}W-}MfIrqZOglV`}tcHSNImN>OPE4v9}
z6F@{F2rL|rl@)`;jc9|*)?~v-0^S$`Dli)gj_Dx@PV4j1`aUMj<5K$ztK>^dMo+kE
z4aj!y?d9yBVfl^Ac4Y4WLN#*3J6_tFkIa{0{U%PnpJsm#)$k~Rwq?zVmyygU%hG1Q
ziJPI1RU9TqC+2iMHk9AgzUCh-4AP(O1TQu5zATCoeT-i|-wQ$JKP!+=JS#Xu6@I8^
z{|Dj<cUdW-gO=-ndrJHH9#}8tJK?Ikn8;Tf9tb{244nhG4s6b|a0RV;heq#Q_$NYC
z4GoWHw#(&go{rW<r?3idv@2iDq%-p?AVw40qmp`ms&}N2F;EaKpGx<<G$f;~>yUu}
zv-#2GgM%Vknj0FZ@NpM_lAf>nP0H5V0|>EF+KL5mOw{tc{msKbO}zrt#Fa9?{+vor
z_o<9Q&+Z^U^(^bX6%Sz5!)MAf>+XJerl{h$B~k>1pSUmRrazw`TD47t5s-M;Cad>j
zu=@aW3<I)b8{rqDOhUWqraw|}I*iKRIa?GmpeM)Nw5NiY%AfLej^K~1?!kup2OXbB
zw1V7RJ<q3i?>4z@6K-tUv?QyRJ|BPHh0#@7Lqcu7$i)avn##obP=bH}=?>8?wGl!C
zB^oWwkpwz>N-x$UGmnVJ3L0Hu!S5=g_$|~P8O5n=xi3y~s`gb_E%XvfC1yibJ@Slk
z?4#lYvjmc)S9$MCy9fr!93~$=MwzNVu9zf)3yqOXH#gz4wR6}O3+Sz>61L>{wUf0C
z)$6L*8G(T1fpv{o|E2lj{OlDBjrvfJPtAXtb4gm_MK)O5de8tE(R`O0n;ui-6}R=o
zdwl7LGGAJ@N^lr=vKMY}5n5YA0ya3wogGs3bfoeqF{wJ+>S*=GEhUiU<$0GuxZBfJ
zOAA&(CtSVXwiZCeVSS9$ETF+g=a-Jmv^Xc=cfXL{c^HieaV$a1o=Sv3%rdV*v>4;T
zND-M0#M8mb2IAF7t4<9->=2y1HpuTio7qnW$In;9qxY%}pkfOkb?49I9B?KzgcuFm
zdHlk(NIaqcL)P*MOsOmC&bm`|W(BFJ=f_?RN{yXG8UOeJ%FOt6ou}<~P8kkql`bKO
zC9NU)`#b>`hY3HRj<i<_u<fw=DU<QDZ#894Y*lQrwMMJJ&san~s<kHf(DKcWw(2*-
z;L9CmB)yQ0vZdJ?O=O78X%VTSctD?4Lq_9Kn9G@AC9_~*Kt=#yp-?etn$2GJ5AZap
z<ISHfY6-y`_|#<S;0%;I$4_;D1CFpdv~5EpkMm9ScHN7-p+YTWjVP^&h|wSbB-y;E
z#AFZSXnb_C^=0wNH}Dx-qksV%SXIck9;`ix8vu#@`xl;U#+w$3cWO)0hfwzxjsU6|
z2vE%i_jz>|Zbd%^Bn4xuPYMM&2lBF=6uTpz3JzCSp|_1Lj|$Zl#Y=~;T{p5wj}JWT
z=Z%zl!zDOQvRpHW0q_e7s$j5YS-e~mOF{b`r?w~<UQlJ1C%^7lX6JS;8v`qXLCoD6
zeS8{tN638cPJAJ!;AD}DuVgdnHYB9?^~-`-EVU@*iLSM)KB9!45ryHsZ6#)2Rj^95
z@p7BS-JG5tAk6v(?%$SQ0iefHd$(?6f0MGIpJype0$YE|y+sTFSF`$x0&V;tu@TFB
zUALchxUdntqIg{*@{+KOE1&(n>yHdD{MR*zKX2s^y_S04X>;MLwSe045St;psT<S0
zQXIPjA=!dUKE-{h&&P!xi~zPd+oVzsS{HKzdL6&+;8XI`a<L_yqt0y#6*kF%cTG~k
zYS$Q#kQu*bq~z@`uk{rsx<rD6Jyp!0J|fWx<5C+wzQ&xJAvULbto-Kn3&JsbnQ{ky
z(>*m;BVyFsRxtEy>X{?ATg*{6&U((9viNu6);{L~ztxuli5oUtlhalBfk0d(BEv<;
z&5ZCdDo@;xckO;lpXny_%5RUD^N~9KN<)U|e*4vC%TU<rl{w|q-;0zX1UrW`eu$=u
zEyv_{E~cGI(_)N4O^QcHD>*w`;g@eJ4tr(=z@|8+cxQSUuCH%JCD*RLHnMWnwtgw|
znOJ#rXVu?YP5rObw4gd{NHTfNOoHuOE!U^zI8(^v+E~Dplbvq6t1f<M>I1jdnAtCv
z$`C;Pxd<?4F%&KAR(3T=@FVY`8I9}WOiH;%iRzf=!!$PQvx(286t}=_-iLcw=QLs}
zv)iz-`*UkXP)5|gxy;xJ4ku#zcqY2EH#gL~$nR5jy$;OSp5&E7C@1i}WWdI_po1Pc
zytWZl-@54TvATwWPl8$e&*+q0pS*YOdtoD|on=%ydhDF^%!nYlAE&LtqZc`3=YZxF
zG+!5Na-cLfsLs=3N-F97W7IrZX)G#mMg$;kU=}@aL6d8kIxtFeN}I=n6->>25-Qb3
zq}(00@E%P6eCFK{bxd==;RB2K>-%JY%;%7V>lGtbn7DBgd7a4R*8*7#vFU~CqxlLq
zcXeivVoA|J7Q-ZwiP0e1zTztse@!{Xq~d2OMCGCXl*KUrfM6)Qt~MM_PPz6)akN?0
zW1iyXxvt6SiF=`~BQn20lI-yLPCmhWC!e4I^2x%Pw>yh7HbxKn%E9GfQgX@~$-%01
z1n0WwBtxMg>GQv3F@X2|BZ~obA8d?hXIs#oG4AVS)xuzAFsSxi`&`B;m*3$Jg}WRr
z2%w{-lkAsw|K-CSoAZ?7yld5Hzr;Eq=01O*%pC5uqYZxripS64D%_zsobfB~#0*R1
z@Pp!|->hGGN0$5`_26}xZDVgPA1*8ex%b9J64+?;eT$;dF|3#yz+w1wWya>=ABT$2
z{dS9~g0ZfAa_a0{JEX*$Gmud9Ucab;RbSt5Q6utdZCrJQVRcbw%Uz-FLp_LIqSmc_
zZXweBFpyh$?JgekV^)|0pFIom<ZG7{P}641A(}dN?Editk!NX>>NtHy_|+dpU$CL)
z)C5^hIZ#iS<?;^+Y-Nj1NIie#FHpsr<Wi3~$xB~eHW~id1XfZxZD2CM)-8?hZns^k
zHT^_HcG0?O?imq1)Zf=v_9KE+q3m}-SsaGQYu`qg7~XU@8se6Wn)`^0Zh!Z|;+RT4
zI$A><T9pGcGI_1Q$k5f6s&lz82orJ~==5e2@1i}L{;b9~aOY*yc|!zP8*rjenH6M>
zWe$<%BSD=bNl|c;7s;6ZVxbI!|1rOB*eqF>6xjDze2N&pA9V%1N0#8mmjA5-mauDy
zn~c%ensfY=M-Qupt<{3{!jiL%(aA#HvS4NgqLU1>6U-IQMlUU!M(PY&Vgidff(!Pw
zeYnx;M(bnp`UB_E(`T%ui`5ja9m%}Sww8KNj}FC9$?vH7Jo^U!n%QN9l}R7@76M|N
zf3J0?W-W1UX-yR93=KNa)<W0Vjr1r0MNmm3s1)Z|PPajQS^%%6euXfW8HB|^bp2_n
zHME7v+^S2QcGK>#qSqxo+(lfwhY+0{4$q}Dai4c>%421n;|H`l%q3igCPi%2)7W+D
ztiCi>clkWR{5MNW#BCj9OkR__!Xx3L0E7!yW;xdb!jGjdnQ$L$WrGxAaG;^w=$hib
zQ3^LapdWYg$%1C_<U-C|){Z(bvbFN3i~7>6;H;yg^V+Y6&t6)#1vB2OT|GCv7S_kb
zrnAx!EO;Q#KAn*#I^CxkPCz<Lu=?aD;C{o7kxYRbd0=c}J<kovSS?6aNEmBhF;LIt
z(2lt{$foZ<{P1rD-d)Jc%DcAvO2ssNG?iWVndu*X0~bH@lJi8}T5g(I!<gj;EUo27
zI(n^V-csD;;y^BLp)=&3zD+GM<MF=oH6{}?E6bHt8YG|Ge4VJKvBr}u4(#US%}Pm!
zkPZd2q0=UmZ&I!KGfZrGG;@&Yq7KiuIlbRwrlH5fD_Xl`#jUs`3>c1b6>6qI4~8NC
zu5stY{9LO>+KD)U&A~pz$7?u7Gj5e7W@Ynx&cOI)Lh(>D5itA$rtE@r>;JA3^8a+T
z|DQBe{Nqq$M_BbYse@pv)mE=9#Xh+WucFPgq(kjbBqxCe@M7ifG9slJt7(B14RL6s
z^Q}vvcr5Pg#v4|H%;7(;$NA@+SIbyzlz*qze(VR}wXmztE?rnC0Z?n)^c5Abc-26h
z2yFhwZ_?jJj{LEMrvKO7C<M*L-RyCC!Lm0KdN6q*)Uc|C%`SGE^rMBglP#asDM$zR
zDkuA|lc7kO!(OD*BM|@y9fWuQ^N_UM$>8RNvKT{vN9-jsya}}Q(}h#-o3j_QMFpK}
zZ>%J7abu^vzO$1{7dkgZaii@6-=q!|{ri%8f35iIe*E=*{O|o5ejWO<_7f&-agcA2
zy<JaM>DZ8CsEYUNTg4e3hDk}tw8X#&dVpQym}`0C=$wGaT!9+YE9s@2{qAu1=Tv|{
Qrda-U5r58ekoh+FuQUl8D*ylh

diff --git a/docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/01-lesson.md b/docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/01-lesson.md
deleted file mode 100644
index 2e3882eac..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/01-lesson.md
+++ /dev/null
@@ -1,124 +0,0 @@
-# Lesson 01: Git Setup
-
-**Create GitHub account and project repository**
-
----
-
-## What You'll Do
-
-- Create GitHub account
-- Choose professional username
-- Create or join repository
-- Understand repository structure
-
-**Time:** 15-20 minutes
-
----
-
-## Part 1: Create GitHub Account
-
-### What is GitHub?
-
-Professional cloud storage + time machine for your project files. Every change is saved, you can go back to any version, work with others.
-
-### Step 1: Sign Up
-
-1. Go to **<https://github.com>**
-2. Click **"Sign up"**
-3. Enter email, password, username
-
-**Username Tips:**
-- Professional: `john-designer`, `sarahux`, `mike-creates`
-- You might share this with clients
-
-4. Verify email
-5. Log in
-
-**✅ Checkpoint:** You can log in to GitHub
-
----
-
-## Part 2: Choose Your Scenario
-
-**Scenario A:** Starting new project → Continue to Part 3  
-**Scenario B:** Joining existing → Skip to Part 5  
-**Scenario C:** Just learning → Skip to [Lesson 02](../lesson-02-ide-installation/02-full-lesson.md)
-
----
-
-## Part 3: Create Repository
-
-1. Click profile icon → **"Your repositories"** → **"New"**
-
-### Decide Repository Structure
-
-**IMPORTANT: Your naming choice determines your structure!**
-
-**Single Repository:**
-- Name: `my-project` (e.g., `dog-walker-app`)
-- Structure: Specs + code together
-- Use when: Small team, building yourself, simple communication
-
-**Separate Specifications Repository:**
-- Name: `my-project-specs` (e.g., `dog-walker-app-specs`)
-- Structure: Specs only, separate code repo
-- Use when: Corporate, many developers, clear handoff needed
-
----
-
-## Part 4: Create Repository
-
-**Repository Settings:**
-- Name: `____________` (lowercase-with-hyphens)
-- Description: One-liner about project
-- Public (portfolio) or Private (client work)
-- ☑️ Check "Initialize with README"
-- Click **"Create repository"**
-
-**✅ Checkpoint:** Repository created
-
----
-
-## Part 5: Join Existing Repository
-
-**Email template:**
-
-```
-Hi [Name],
-
-I'd like to contribute to [project-name] using WDS methodology. 
-Could you add me as a collaborator?
-
-My GitHub username: [your-username]
-
-Thank you!
-```
-
-**Then:**
-1. Accept invitation from email
-2. Check repo name (ends in `-specs`? Separate repo)
-3. Browse structure (has `docs/`? WDS already!)
-
-**✅ Checkpoint:** Access granted
-
----
-
-## Troubleshooting
-
-**Issue:** Verification email missing → Check spam  
-**Issue:** Username taken → Try `yourname-designer-2`  
-**Issue:** Repository name taken → Add your username
-
----
-
-## What's Next?
-
-GitHub account and repository ready! Now install your IDE.
-
-**[Continue to Lesson 02: IDE Installation →](../lesson-02-ide-installation/02-full-lesson.md)**
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/01-quick-checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/01-quick-checklist.md
deleted file mode 100644
index cf2ce1672..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/01-quick-checklist.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# Lesson 01: Git Setup - Quick Checklist
-
-**⏱️ 15-20 minutes**
-
----
-
-## Part 1: Create GitHub Account
-
-- [ ] Go to **<https://github.com>**
-- [ ] Click **"Sign up"**
-- [ ] Enter email, password, username (professional: `yourname-designer`)
-- [ ] Verify email
-- [ ] ✅ Log in successful
-
----
-
-## Part 2: Choose Your Scenario
-
-- [ ] **A:** Starting new project → Continue below
-- [ ] **B:** Joining existing → Skip to "Join Existing"  
-- [ ] **C:** Just learning → Skip to [Lesson 02](../lesson-02-ide-installation/01-quick-checklist.md)
-
----
-
-## Part 3: Create New Repository
-
-- [ ] Click profile icon → **"Your repositories"** → **"New"**
-
-### Decide: Single or Separate?
-
-- [ ] **Single repo:** `my-project` (specs + code together, small teams)
-- [ ] **Separate repo:** `my-project-specs` (specs only, corporate/many devs)
-
-### Repository Settings
-
-- [ ] Name: `_____________` (lowercase-with-hyphens)
-- [ ] Description: One-liner about project
-- [ ] Public or Private
-- [ ] ☑️ Check "Initialize with README"
-- [ ] Click **"Create repository"**
-- [ ] ✅ Repository created
-
----
-
-## Part 4: Join Existing Repository
-
-- [ ] Ask owner for access (see full lesson for email template)
-- [ ] Accept invitation from email
-- [ ] Check repo structure
-- [ ] ✅ Access granted
-
----
-
-## Next Step
-
-✅ GitHub ready!
-
-**[→ Lesson 02: IDE Installation](../lesson-02-ide-installation/01-quick-checklist.md)**
-
----
-
-**Need more detail?** See [full lesson](02-full-lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-01-github-and-ide-setup/checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-01-github-and-ide-setup/checklist.md
deleted file mode 100644
index 504e24c36..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-01-github-and-ide-setup/checklist.md
+++ /dev/null
@@ -1,87 +0,0 @@
-# Lesson 01: GitHub & IDE Setup - Quick Checklist
-
-**⏱️ 25-30 minutes**
-
----
-
-## Part 1: GitHub Account
-
-- [ ] Go to **<https://github.com>**
-- [ ] Click **"Sign up"**
-- [ ] Enter email, password, username (professional: `yourname-designer`)
-- [ ] Verify email
-- [ ] ✅ Log in successful
-
----
-
-## Part 2: Create or Join Repository
-
-### Choose Your Scenario
-
-- [ ] **A:** Starting new project → Continue below
-- [ ] **B:** Joining existing → Skip to "Join Existing"
-- [ ] **C:** Just learning → Skip to Part 3
-
-### Create New Repository
-
-- [ ] Click profile icon → **"Your repositories"** → **"New"**
-
-**Decide: Single or Separate?**
-
-- [ ] **Single repo:** `my-project` (specs + code together, for small teams)
-- [ ] **Separate repo:** `my-project-specs` (specs only, for corporate/many devs)
-
-- [ ] Name: `_____________` (lowercase-with-hyphens)
-- [ ] Description: One-liner about project
-- [ ] Public or Private
-- [ ] ☑️ Check "Initialize with README"
-- [ ] Click **"Create repository"**
-- [ ] ✅ Repository created
-
-### Join Existing Repository
-
-- [ ] Ask owner for access (see full lesson for email template)
-- [ ] Accept invitation from email
-- [ ] Check repo structure (name, folders)
-- [ ] ✅ Access granted
-
----
-
-## Part 3: IDE Installation
-
-### Choose & Download
-
-- [ ] **Cursor** (recommended) → <https://cursor.sh>
-- [ ] **VS Code** (alternative) → <https://code.visualstudio.com>
-- [ ] Download installer
-
-### Install
-
-- [ ] **Windows:** Run `.exe`, click through
-- [ ] **Mac:** Drag to Applications, open
-- [ ] **Linux:** Follow distro instructions
-
-### First Launch
-
-- [ ] Choose theme (Light/Dark)
-- [ ] Sign in with GitHub → Yes!
-- [ ] Install recommended extensions → Yes
-- [ ] ✅ IDE open
-
-### Verify Terminal
-
-- [ ] Press **Ctrl+`** (Win/Linux) or **Cmd+`** (Mac)
-- [ ] ✅ Terminal panel appears
-
----
-
-## Next Step
-
-✅ GitHub & IDE ready!
-
-**[→ Lesson 02: Git Configuration](../lesson-02-git-setup/checklist.md)**
-
----
-
-**Need more detail?** See [full lesson explanation](lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-01-github-and-ide-setup/lesson.md b/docs/learn-wds/module-02-installation-setup/lesson-01-github-and-ide-setup/lesson.md
deleted file mode 100644
index ea6c86801..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-01-github-and-ide-setup/lesson.md
+++ /dev/null
@@ -1,203 +0,0 @@
-# Lesson 01: GitHub & IDE Setup
-
-**Get your development environment ready**
-
----
-
-## What You'll Do
-
-- Create GitHub account
-- Create or join repository
-- Install IDE (Cursor or VS Code)
-- Verify everything works
-
-**Time:** 25-30 minutes
-
----
-
-## Part 1: GitHub Setup
-
-### What is GitHub?
-
-Professional cloud storage + time machine for your project files. Every change is saved, you can go back to any version, and you can work with others.
-
-### Step 1: Create GitHub Account
-
-1. Go to **<https://github.com>**
-2. Click **"Sign up"** (top right)
-3. Enter email, password, username
-
-**Username Tips:**
-- Professional: `john-designer`, `sarahux`, `mike-creates`
-- You might share this with clients
-
-4. Verify email
-5. Log in
-
-**✅ Checkpoint:** You can log in to GitHub
-
----
-
-### Step 2: Choose Your Scenario
-
-**Scenario A: Starting a New Project** → Continue to Step 3  
-**Scenario B: Joining Existing Project** → Skip to Step 6  
-**Scenario C: Just Learning WDS** → Skip to Part 2
-
----
-
-### Step 3: Create Repository (Scenario A)
-
-1. Click profile icon → **"Your repositories"** → **"New"**
-
-### Step 4: Decide Repository Structure
-
-**IMPORTANT: Your naming choice determines your structure!**
-
-#### Single Repository
-
-**Name:** `my-project` (e.g., `dog-walker-app`)
-
-```
-my-project/
-├── docs/    ← WDS specifications
-└── src/     ← Code
-```
-
-**Use when:**
-- Small team, building yourself
-- Simple communication
-- Rapid iteration
-
-#### Separate Specifications Repository
-
-**Name:** `my-project-specs` (e.g., `dog-walker-app-specs`)
-
-```
-my-project-specs/    ← Specifications only
-my-project/          ← Separate code repo
-```
-
-**Use when:**
-- Corporate environment
-- Many developers
-- Clear handoff needed
-
-### Step 5: Create Repository
-
-- **Name:** `____________` (lowercase-with-hyphens)
-- **Description:** One-liner about project
-- **Public** (portfolio) or **Private** (client work)
-- ☑️ **Check "Initialize with README"**
-- Click **"Create repository"**
-
-**✅ Checkpoint:** Repository created
-
----
-
-### Step 6: Join Existing Repository (Scenario B)
-
-**Email template:**
-
-```
-Hi [Name],
-
-I'd like to contribute to [project-name] using WDS methodology. 
-Could you add me as a collaborator?
-
-My GitHub username: [your-username]
-
-Thank you!
-```
-
-**Then:**
-1. Accept invitation from email
-2. Check repo name (ends in `-specs`? Separate repo)
-3. Browse structure (has `docs/`? WDS already!)
-
-**✅ Checkpoint:** Access granted
-
----
-
-## Part 2: IDE Installation
-
-### What is an IDE?
-
-Your workspace for creating specifications. Like Microsoft Word, but for design files.
-
-### Step 1: Choose Your IDE
-
-**Cursor (Recommended)**
-- Built for AI assistance
-- Perfect for WDS
-- Download: <https://cursor.sh>
-
-**VS Code (Alternative)**
-- Industry standard
-- Works great too
-- Download: <https://code.visualstudio.com>
-
-**For beginners:** Choose Cursor
-
----
-
-### Step 2: Install
-
-**Windows:**
-1. Run `.exe` file
-2. Click through installer
-3. Use defaults
-
-**Mac:**
-1. Open download
-2. Drag to Applications
-3. Open from Applications
-
-**Linux:**
-Follow distro instructions
-
----
-
-### Step 3: First Launch
-
-1. Choose theme (Light/Dark)
-2. **Sign in with GitHub** → Yes!
-3. Install recommended extensions → Yes
-
-**✅ Checkpoint:** IDE open and ready
-
----
-
-### Step 4: Verify Terminal
-
-Press **Ctrl+`** (Win/Linux) or **Cmd+`** (Mac)
-
-**✅ Checkpoint:** Terminal panel appears
-
----
-
-## Troubleshooting
-
-**GitHub Issues:**
-- **Verification email missing** → Check spam
-- **Username taken** → Try `yourname-designer-2`
-- **Repository name taken** → Add your username
-
-**IDE Issues:**
-- **Can't find download** → Check Downloads folder
-- **Mac "unidentified developer"** → Right-click → Open
-- **Terminal won't open** → View menu → Terminal → New Terminal
-
----
-
-## What's Next?
-
-GitHub account, repository, and IDE are ready! Now let's configure Git.
-
-**[Continue to Lesson 02: Git Configuration →](../lesson-02-git-setup/lesson.md)**
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-01-setting-up-github/checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-01-setting-up-github/checklist.md
deleted file mode 100644
index a93f57f95..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-01-setting-up-github/checklist.md
+++ /dev/null
@@ -1,70 +0,0 @@
-# Lesson 01: GitHub Setup - Quick Checklist
-
-**⏱️ 15-20 minutes**
-
----
-
-## Create GitHub Account
-
-- [ ] Go to **<https://github.com>**
-- [ ] Click **"Sign up"**
-- [ ] Enter email, password, username (professional: `yourname-designer`)
-- [ ] Verify email
-- [ ] ✅ Log in successful
-
----
-
-## Choose Your Scenario
-
-- [ ] **A:** Starting new project → Continue below
-- [ ] **B:** Joining existing → Skip to "Join Existing" section
-- [ ] **C:** Just learning → Skip to [Lesson 02](../lesson-02-install-ide/checklist.md)
-
----
-
-## Create New Repository
-
-- [ ] Click profile icon → **"Your repositories"** → **"New"**
-
-### Decide: Single or Separate?
-
-**Single repo (specs + code together):**
-- [ ] Name: `my-project` (e.g., `dog-walker-app`)
-- [ ] For: Small team, building yourself, simple communication
-
-**Separate specs repo (specs only):**
-- [ ] Name: `my-project-specs` (e.g., `dog-walker-app-specs`)
-- [ ] For: Corporate, many developers, clear handoff
-
-### Repository Settings
-
-- [ ] Name: `_____________` (lowercase-with-hyphens)
-- [ ] Description: One-liner about project
-- [ ] Public or Private
-- [ ] ☑️ **Check "Initialize with README"**
-- [ ] Click **"Create repository"**
-- [ ] ✅ Repository created
-
----
-
-## Join Existing Repository
-
-- [ ] Ask owner for access (email template in lesson.md)
-- [ ] Check email for GitHub invitation
-- [ ] Click **"Accept invitation"**
-- [ ] Check repo name (ends in `-specs`? Separate repo)
-- [ ] Browse repo structure (has `docs/`? WDS already!)
-- [ ] ✅ Access granted
-
----
-
-## Next Step
-
-✅ GitHub setup complete!
-
-**[→ Lesson 02: IDE Installation](../lesson-02-install-ide/checklist.md)**
-
----
-
-**Need more detail?** See [full lesson explanation](lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-02-git-configuration/checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-02-git-configuration/checklist.md
deleted file mode 100644
index 63d0f470c..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-02-git-configuration/checklist.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Lesson 02: Git Configuration - Quick Checklist
-
-**⏱️ 5 minutes**
-
----
-
-## Choose Approach
-
-- [ ] **Option 1:** Let Cursor handle Git (do nothing - easiest!)
-- [ ] **Option 2:** Use GitHub Desktop (visual) → <https://desktop.github.com>
-
----
-
-## If Using GitHub Desktop
-
-- [ ] Download from <https://desktop.github.com>
-- [ ] Install
-- [ ] Sign in with GitHub account
-- [ ] ✅ Ready for visual cloning
-
----
-
-## Recap Repository Structure
-
-From Lesson 01:
-- [ ] Single repo: `my-project` (specs + code together)
-- [ ] Separate repo: `my-project-specs` (specs only)
-
----
-
-## Next Step
-
-✅ Git ready!
-
-**[→ Lesson 03: Repository Cloning & WDS Integration](../lesson-03-clone-and-wds/checklist.md)**
-
----
-
-**Need more detail?** See [full lesson explanation](lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/01-quick-checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/01-quick-checklist.md
deleted file mode 100644
index ba7a243aa..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/01-quick-checklist.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Lesson 02: IDE Installation - Quick Checklist
-
-**⏱️ 10 minutes**
-
----
-
-## Choose IDE
-
-- [ ] **Cursor** (recommended) → <https://cursor.sh>
-- [ ] **VS Code** (alternative) → <https://code.visualstudio.com>
-
----
-
-## Install
-
-- [ ] Download installer
-- [ ] **Windows:** Run `.exe`, click through
-- [ ] **Mac:** Drag to Applications, open
-- [ ] **Linux:** Follow distro instructions
-
----
-
-## First Launch
-
-- [ ] Choose theme (Light/Dark)
-- [ ] Sign in with GitHub → Yes!
-- [ ] Install recommended extensions → Yes
-- [ ] ✅ IDE open
-
----
-
-## Verify Terminal
-
-- [ ] Press **Ctrl+`** (Win/Linux) or **Cmd+`** (Mac)
-- [ ] ✅ Terminal panel appears
-
----
-
-## Next Step
-
-✅ IDE installed!
-
-**[→ Lesson 03: Git Repository Cloning](../lesson-03-git-cloning/01-quick-checklist.md)**
-
----
-
-**Need more detail?** See [full lesson](02-full-lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-lesson.md b/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-lesson.md
deleted file mode 100644
index 208385cf1..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-lesson.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# Lesson 02: IDE Installation
-
-**Get your workspace ready**
-
----
-
-## What You'll Do
-
-- Choose IDE (Cursor or VS Code)
-- Install and configure
-- Verify terminal works
-
-**Time:** 10 minutes
-
----
-
-## Step 1: Choose Your IDE
-
-### Cursor (Recommended)
-
-- Built for AI assistance
-- Perfect for WDS
-- Download: <https://cursor.sh>
-
-### VS Code (Alternative)
-
-- Industry standard
-- Works great too
-- Download: <https://code.visualstudio.com>
-
-**For beginners:** Choose Cursor
-
----
-
-## Step 2: Install
-
-**Windows:**
-1. Run `.exe` file
-2. Click through installer
-3. Use defaults
-
-**Mac:**
-1. Open download
-2. Drag to Applications
-3. Open from Applications
-
-**Linux:**
-Follow distro instructions
-
----
-
-## Step 3: First Launch
-
-1. Choose theme (Light/Dark)
-2. **Sign in with GitHub** → Yes!
-3. Install recommended extensions → Yes
-
-**✅ Checkpoint:** IDE open
-
----
-
-## Step 4: Verify Terminal
-
-Press **Ctrl+`** (Win/Linux) or **Cmd+`** (Mac)
-
-**✅ Checkpoint:** Terminal panel appears
-
----
-
-## Troubleshooting
-
-**Issue:** Can't find download → Check Downloads folder  
-**Issue:** Mac "unidentified developer" → Right-click → Open  
-**Issue:** Terminal won't open → View menu → Terminal → New Terminal
-
----
-
-## What's Next?
-
-IDE ready! Now clone your Git repository.
-
-**[Continue to Lesson 03: Git Repository Cloning →](../lesson-03-git-cloning/02-full-lesson.md)**
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-quick-checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-quick-checklist.md
deleted file mode 100644
index ba7a243aa..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-quick-checklist.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Lesson 02: IDE Installation - Quick Checklist
-
-**⏱️ 10 minutes**
-
----
-
-## Choose IDE
-
-- [ ] **Cursor** (recommended) → <https://cursor.sh>
-- [ ] **VS Code** (alternative) → <https://code.visualstudio.com>
-
----
-
-## Install
-
-- [ ] Download installer
-- [ ] **Windows:** Run `.exe`, click through
-- [ ] **Mac:** Drag to Applications, open
-- [ ] **Linux:** Follow distro instructions
-
----
-
-## First Launch
-
-- [ ] Choose theme (Light/Dark)
-- [ ] Sign in with GitHub → Yes!
-- [ ] Install recommended extensions → Yes
-- [ ] ✅ IDE open
-
----
-
-## Verify Terminal
-
-- [ ] Press **Ctrl+`** (Win/Linux) or **Cmd+`** (Mac)
-- [ ] ✅ Terminal panel appears
-
----
-
-## Next Step
-
-✅ IDE installed!
-
-**[→ Lesson 03: Git Repository Cloning](../lesson-03-git-cloning/01-quick-checklist.md)**
-
----
-
-**Need more detail?** See [full lesson](02-full-lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-02-install-ide/checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-02-install-ide/checklist.md
deleted file mode 100644
index 85c1d2f7f..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-02-install-ide/checklist.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Lesson 02: IDE Installation - Quick Checklist
-
-**⏱️ 10 minutes**
-
----
-
-## Choose IDE
-
-- [ ] **Cursor** (recommended for AI work) → <https://cursor.sh>
-- [ ] **VS Code** (alternative) → <https://code.visualstudio.com>
-
----
-
-## Install
-
-- [ ] Download installer
-- [ ] **Windows:** Run `.exe`, click through
-- [ ] **Mac:** Drag to Applications, open
-- [ ] **Linux:** Follow distro instructions
-
----
-
-## First Launch
-
-- [ ] Choose theme (Light/Dark)
-- [ ] **Sign in with GitHub** → Yes!
-- [ ] Install recommended extensions → Yes
-- [ ] ✅ IDE open
-
----
-
-## Verify Terminal
-
-- [ ] Press **Ctrl+`** (Win/Linux) or **Cmd+`** (Mac)
-- [ ] ✅ Terminal panel appears
-
----
-
-## Next Step
-
-✅ IDE installed!
-
-**[→ Lesson 03: Git Configuration](../lesson-03-git-setup/checklist.md)**
-
----
-
-**Need more detail?** See [full lesson explanation](lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-02-install-ide/tutorial.md b/docs/learn-wds/module-02-installation-setup/lesson-02-install-ide/tutorial.md
deleted file mode 100644
index 2797e6880..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-02-install-ide/tutorial.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Lesson 02: IDE Installation
-
-**Get your workspace set up with Cursor or VS Code**
-
----
-
-## What You'll Do
-
-- Choose between Cursor and VS Code
-- Download and install your IDE
-- Complete first-launch setup
-- Sign in with GitHub
-
-**Time:** 10 minutes
-
----
-
-## What is an IDE?
-
-**IDE = Integrated Development Environment**
-
-Your workspace for creating specifications. Like Microsoft Word, but for design files.
-
----
-
-## Step 1: Choose Your IDE
-
-### Cursor (Recommended)
-
-**Why Cursor:**
-- Built for AI assistance
-- Modern interface
-- Perfect for WDS
-- **Download:** <https://cursor.sh>
-
-### VS Code (Alternative)
-
-**Why VS Code:**
-- Industry standard
-- More extensions
-- Works great with WDS too
-- **Download:** <https://code.visualstudio.com>
-
-**For beginners:** Choose Cursor. It's designed for AI-augmented work.
-
----
-
-## Step 2: Install Cursor
-
-### 2.1 Download
-
-1. Go to **<https://cursor.sh>**
-2. Click download button for your platform
-3. Wait for download
-
-### 2.2 Install
-
-**Windows:**
-1. Double-click the `.exe` file
-2. Follow installer prompts
-3. Use default settings
-4. Click "Finish"
-
-**Mac:**
-1. Open the download
-2. Drag Cursor to Applications folder
-3. Open Applications folder
-4. Double-click Cursor to launch
-
-**Linux:**
-1. Follow installation instructions for your distribution
-
----
-
-## Step 3: First Launch Setup
-
-1. Open Cursor for the first time
-2. Choose your theme (Light or Dark - you can change this later)
-
-### 3.1 Setup Wizard
-
-Cursor will ask you a few questions:
-
-- **"Import settings from VS Code?"** → Skip (unless you already use VS Code)
-- **"Sign in with GitHub?"** → Yes! (makes cloning easier)
-- **"Install recommended extensions?"** → Yes
-
-**✅ Checkpoint:** Cursor is open and ready
-
----
-
-## Install VS Code (Alternative)
-
-If you chose VS Code instead:
-
-### Download and Install
-
-1. Go to **<https://code.visualstudio.com>**
-2. Download for your platform
-3. Follow same installation steps as Cursor above
-4. Complete first-launch setup
-5. Sign in with GitHub when prompted
-
----
-
-## Verify Installation
-
-### Open the Terminal
-
-This is important for upcoming lessons!
-
-**Windows / Linux:**
-- Press **Ctrl + `** (backtick key, usually above Tab)
-
-**Mac:**
-- Press **Cmd + `** (backtick key)
-
-**You should see a terminal panel appear at the bottom!**
-
-**✅ Checkpoint:** Terminal opens successfully
-
----
-
-## Troubleshooting
-
-**Issue:** Can't find download  
-**Solution:** Check your Downloads folder
-
-**Issue:** Mac says "Cannot open - unidentified developer"  
-**Solution:** Right-click Cursor → Click "Open" → Click "Open" again
-
-**Issue:** Terminal won't open  
-**Solution:** View menu → Terminal → New Terminal
-
-**Issue:** GitHub sign-in fails  
-**Solution:** You can skip for now, we'll handle it later
-
----
-
-## What's Next?
-
-Your IDE is ready! Now let's understand Git and how your IDE handles it automatically.
-
-**[Continue to Lesson 03: Git Configuration →](../lesson-03-git-setup/tutorial.md)**
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/01-quick-checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/01-quick-checklist.md
deleted file mode 100644
index f5166c1fb..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/01-quick-checklist.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Lesson 03: Git Repository Cloning - Quick Checklist
-
-**⏱️ 10 minutes**
-
----
-
-## Create Projects Folder
-
-In terminal (**Ctrl+`** or **Cmd+`**):
-
-```bash
-# Windows
-mkdir C:\Projects
-cd C:\Projects
-
-# Mac/Linux
-mkdir ~/Projects
-cd ~/Projects
-```
-
-- [ ] ✅ Projects folder created
-
----
-
-## Clone Your Repository
-
-- [ ] Go to your repo on GitHub → Click **"Code"** → Copy URL
-- [ ] In terminal: `git clone [paste-url]`
-- [ ] (If prompted: Install Git → Click "Install")
-- [ ] ✅ "done" message
-
----
-
-## Open Project in IDE
-
-- [ ] **File** → **Open Folder**
-- [ ] Select your project folder
-- [ ] ✅ Project in sidebar
-
----
-
-## Next Step
-
-✅ Repository cloned!
-
-**[→ Lesson 04: WDS Project Initialization](../lesson-04-wds-initialization/01-quick-checklist.md)**
-
----
-
-**Need more detail?** See [full lesson](02-full-lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/03-lesson.md b/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/03-lesson.md
deleted file mode 100644
index e7632e3b7..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/03-lesson.md
+++ /dev/null
@@ -1,111 +0,0 @@
-# Lesson 03: Git Repository Cloning
-
-**Clone your project to your computer**
-
----
-
-## What You'll Do
-
-- Create Projects folder
-- Clone your repository
-- Open project in IDE
-- Understand Git auto-installation
-
-**Time:** 10 minutes
-
----
-
-## Step 1: Create Projects Folder
-
-**Choose a location:**
-- Windows: `C:\Users\YourName\Projects\`
-- Mac/Linux: `~/Projects/`
-
-In terminal (**Ctrl+`** or **Cmd+`**):
-
-```bash
-# Windows
-mkdir C:\Projects
-cd C:\Projects
-
-# Mac/Linux
-mkdir ~/Projects
-cd ~/Projects
-```
-
-**✅ Checkpoint:** Projects folder created
-
----
-
-## Step 2: Get Repository URL
-
-1. Go to your repository on GitHub
-2. Click green **"Code"** button
-3. Make sure **"HTTPS"** selected
-4. Click copy icon (📋)
-
-**Your URL:** `https://github.com/your-username/your-project.git`
-
----
-
-## Step 3: Clone Repository
-
-In terminal:
-
-```bash
-git clone [paste your URL]
-```
-
-**Example:**
-```bash
-git clone https://github.com/john-designer/dog-walker-app.git
-```
-
-**If Cursor prompts "Install Git?"** → Click **"Install"**, wait, try again
-
-**✅ Checkpoint:** See "Cloning into..." then "done"
-
----
-
-## Step 4: Open Project in IDE
-
-1. **File** → **Open Folder**
-2. Navigate to Projects folder
-3. Select your project folder
-4. Click **"Select Folder"** or **"Open"**
-
-**✅ Checkpoint:** Project name in sidebar with README.md
-
----
-
-## About Git Auto-Installation
-
-**Git** is the tool that syncs with GitHub. Modern IDEs handle this automatically:
-
-- First time cloning → IDE prompts to install
-- You click "Install"
-- Done!
-
-**Alternative:** Use GitHub Desktop (<https://desktop.github.com>) for visual interface
-
----
-
-## Troubleshooting
-
-**Issue:** "Git command not found" → Let IDE install when prompted  
-**Issue:** "Permission denied" → Sign into GitHub in IDE  
-**Issue:** Clone fails → Check URL copied correctly
-
----
-
-## What's Next?
-
-Project cloned! Now initialize WDS and meet Mimir.
-
-**[Continue to Lesson 04: WDS Project Initialization →](../lesson-04-wds-initialization/02-full-lesson.md)**
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/03-quick-checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/03-quick-checklist.md
deleted file mode 100644
index f5166c1fb..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/03-quick-checklist.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Lesson 03: Git Repository Cloning - Quick Checklist
-
-**⏱️ 10 minutes**
-
----
-
-## Create Projects Folder
-
-In terminal (**Ctrl+`** or **Cmd+`**):
-
-```bash
-# Windows
-mkdir C:\Projects
-cd C:\Projects
-
-# Mac/Linux
-mkdir ~/Projects
-cd ~/Projects
-```
-
-- [ ] ✅ Projects folder created
-
----
-
-## Clone Your Repository
-
-- [ ] Go to your repo on GitHub → Click **"Code"** → Copy URL
-- [ ] In terminal: `git clone [paste-url]`
-- [ ] (If prompted: Install Git → Click "Install")
-- [ ] ✅ "done" message
-
----
-
-## Open Project in IDE
-
-- [ ] **File** → **Open Folder**
-- [ ] Select your project folder
-- [ ] ✅ Project in sidebar
-
----
-
-## Next Step
-
-✅ Repository cloned!
-
-**[→ Lesson 04: WDS Project Initialization](../lesson-04-wds-initialization/01-quick-checklist.md)**
-
----
-
-**Need more detail?** See [full lesson](02-full-lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-03-git-setup/checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-03-git-setup/checklist.md
deleted file mode 100644
index 6e03430f9..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-03-git-setup/checklist.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Lesson 03: Git Configuration - Quick Checklist
-
-**⏱️ 5 minutes**
-
----
-
-## Choose Approach
-
-- [ ] **Option 1:** Let Cursor handle Git (easiest - do nothing now!)
-- [ ] **Option 2:** Use GitHub Desktop (visual) → <https://desktop.github.com>
-- [ ] **Option 3:** Check terminal: `git --version`
-
----
-
-## If Using GitHub Desktop
-
-- [ ] Download from <https://desktop.github.com>
-- [ ] Install
-- [ ] Sign in with GitHub account
-- [ ] ✅ Ready to clone visually
-
----
-
-## Recap Your Repo Structure
-
-You decided in Lesson 01:
-- [ ] Single repo: `my-project` (specs + code together)
-- [ ] Separate repo: `my-project-specs` (specs only)
-
----
-
-## Next Step
-
-✅ Git configured!
-
-**[→ Lesson 04: Repository Cloning & WDS Integration](../lesson-04-clone-and-wds/checklist.md)**
-
----
-
-**Need more detail?** See [full lesson explanation](lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-03-git-setup/tutorial.md b/docs/learn-wds/module-02-installation-setup/lesson-03-git-setup/tutorial.md
deleted file mode 100644
index 555674fe1..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-03-git-setup/tutorial.md
+++ /dev/null
@@ -1,159 +0,0 @@
-# Lesson 03: Git Configuration
-
-**Let your IDE handle Git automatically**
-
----
-
-## What You'll Do
-
-- Understand what Git does
-- Recap your repository structure decision
-- Let Cursor install Git automatically
-- OR use GitHub Desktop (visual alternative)
-
-**Time:** 5 minutes
-
----
-
-## What is Git?
-
-**Git** is the behind-the-scenes tool that syncs your computer with GitHub.
-
-**Good news:** You don't need to install it manually! Modern IDEs like Cursor handle this for you.
-
----
-
-## Step 1: Recap Your Repository Structure
-
-**You already decided this in Lesson 01 when naming your repo!**
-
-### Single Repo (named `my-project`)
-```
-my-project/
-├── docs/              ← Your WDS specifications
-└── src/               ← Code lives here too
-```
-
-### Separate Repo (named `my-project-specs`)
-```
-my-project-specs/      ← This repo (specifications only)
-                       ← Code repo created separately
-```
-
-**For this tutorial, we assume single repo** (`dog-walker-app`)
-
----
-
-## Step 2: Choose Your Git Approach
-
-### Option 1: Let Cursor Handle It (Recommended)
-
-**The easiest way:** Do nothing!
-
-When you try to clone a repository in Lesson 04, Cursor will:
-
-1. Check if Git is installed
-2. If not, **automatically prompt you**: "Install Git?"
-3. You click **"Install"**
-4. Done!
-
-**That's it.** No command line needed.
-
-**✅ This is the recommended path for beginners**
-
----
-
-### Option 2: GitHub Desktop (Visual Alternative)
-
-**For designers who prefer visual tools:**
-
-#### Why GitHub Desktop?
-
-- ✅ No terminal commands needed
-- ✅ Visual interface for everything
-- ✅ See changes side-by-side
-- ✅ Many professional designers use it
-- ✅ Works perfectly with Cursor
-
-#### Install GitHub Desktop
-
-1. Download from **<https://desktop.github.com>**
-2. Install it (follow standard installer)
-3. Open GitHub Desktop
-4. Sign in with your GitHub account
-5. Done!
-
-#### How it Works
-
-- Use GitHub Desktop to **clone** repositories
-- Use GitHub Desktop to **commit** and **push** changes
-- Use Cursor to **edit** specifications
-- They work together perfectly!
-
-**This is a perfectly valid professional workflow.**
-
-**Bonus:** GitHub Desktop also helps you decide between single vs separate repos visually!
-
----
-
-### Option 3: Already Comfortable with Terminal?
-
-**Optional check for those who want to know:**
-
-In Cursor terminal (press **Ctrl+`** or **Cmd+`**):
-
-```bash
-git --version
-```
-
-**If you see a version number:**
-```
-git version 2.x.x
-```
-✅ Git is installed!
-
-**If you see "command not found":**
-No problem! Continue to Lesson 04, Cursor will prompt you.
-
----
-
-## Which Option Should You Choose?
-
-**Choose Option 1 (Let Cursor Handle It) if:**
-- You're a complete beginner
-- You want the simplest path
-- You're comfortable with terminal appearing in Lesson 04
-
-**Choose Option 2 (GitHub Desktop) if:**
-- You prefer visual interfaces
-- You want to see changes graphically
-- You're nervous about terminal commands
-- You want a tool you'll keep using
-
-**Both are great!** Many professionals use GitHub Desktop daily.
-
----
-
-## Troubleshooting
-
-**Issue:** Not sure which option to choose  
-**Solution:** Use Option 1 (Let Cursor handle it) - simplest for beginners
-
-**Issue:** GitHub Desktop won't sign in  
-**Solution:** Make sure you completed Lesson 01 (GitHub account created)
-
-**Issue:** Worried about making mistakes  
-**Solution:** Git saves everything - you can always undo!
-
----
-
-## What's Next?
-
-Git will be ready when you need it! Now it's time to clone your repository and add WDS to your workspace.
-
-**[Continue to Lesson 04: Repository Cloning & WDS Integration →](../lesson-04-clone-and-wds/tutorial.md)**
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-04-clone-and-wds/checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-04-clone-and-wds/checklist.md
deleted file mode 100644
index d7b59c5dc..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-04-clone-and-wds/checklist.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# Lesson 04: Repository Cloning & WDS Integration - Quick Checklist
-
-**⏱️ 15-20 minutes**
-
----
-
-## Create Projects Folder
-
-In Cursor terminal (**Ctrl+`** or **Cmd+`**):
-
-```bash
-# Windows
-mkdir C:\Projects
-cd C:\Projects
-
-# Mac/Linux
-mkdir ~/Projects
-cd ~/Projects
-```
-
-- [ ] ✅ Projects folder created
-
----
-
-## Clone Your Project
-
-- [ ] Go to your repo on GitHub → Click **"Code"** → Copy URL
-- [ ] In terminal: `git clone [paste-url-here]`
-- [ ] (If prompted: Install Git → Click "Install")
-- [ ] ✅ "done" message
-
----
-
-## Open Project in Cursor
-
-- [ ] **File** → **Open Folder**
-- [ ] Select your project folder
-- [ ] ✅ Project in sidebar
-
----
-
-## Clone WDS
-
-In terminal:
-```bash
-cd ~/Projects  # or cd C:\Projects
-git clone https://github.com/whiteport-collective/whiteport-design-studio.git
-```
-
-- [ ] ✅ WDS cloned
-
----
-
-## Add WDS to Workspace
-
-- [ ] **File** → **Add Folder to Workspace**
-- [ ] Select `whiteport-design-studio` folder
-- [ ] Click **"Add"**
-- [ ] ✅ Both folders in sidebar
-
----
-
-## Create Docs Structure
-
-In terminal (in YOUR project folder):
-
-```bash
-cd ~/Projects/your-project-name  # YOUR project!
-
-# Mac/Linux
-mkdir -p docs/{1-project-brief,2-trigger-mapping,3-prd-platform,4-ux-design,5-design-system,6-design-deliveries,7-testing,8-ongoing-development}
-
-# Windows (if above doesn't work)
-mkdir docs
-cd docs
-mkdir 1-project-brief 2-trigger-mapping 3-prd-platform 4-ux-design 5-design-system 6-design-deliveries 7-testing 8-ongoing-development
-cd ..
-```
-
-- [ ] ✅ 8 folders in `docs/`
-
----
-
-## Next Step
-
-✅ Everything cloned and ready!
-
-**[→ Lesson 05: Mimir Activation](../lesson-05-initiate-mimir/checklist.md)**
-
----
-
-**Need more detail?** See [full lesson explanation](lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-04-clone-and-wds/tutorial.md b/docs/learn-wds/module-02-installation-setup/lesson-04-clone-and-wds/tutorial.md
deleted file mode 100644
index 07afefcc1..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-04-clone-and-wds/tutorial.md
+++ /dev/null
@@ -1,217 +0,0 @@
-# Lesson 04: Repository Cloning & WDS Integration
-
-**Get your project and WDS onto your computer**
-
----
-
-## What You'll Do
-
-- Clone your project repository
-- Add WDS to your workspace
-- Create docs folder structure
-
-**Time:** 15-20 minutes
-
----
-
-## Step 1: Choose Where to Store Projects
-
-**Create a Projects folder:**
-
-**Windows:** `C:\Users\YourName\Projects\`  
-**Mac/Linux:** `/Users/YourName/Projects/` or `~/Projects/`
-
-### Create the Folder
-
-In Cursor terminal (**Ctrl+`** or **Cmd+`**):
-
-```bash
-# Windows
-mkdir C:\Projects
-cd C:\Projects
-
-# Mac/Linux
-mkdir ~/Projects
-cd ~/Projects
-```
-
-**✅ Checkpoint:** Projects folder created
-
----
-
-## Step 2: Clone Your Project Repository
-
-**What is cloning?** Copying your GitHub repository to your computer so you can work on it.
-
-### 2.1 Get Your Repository URL
-
-1. Go to your repository on GitHub
-2. Click the green **"Code"** button
-3. Make sure **"HTTPS"** is selected
-4. Click the **copy icon** (📋)
-
-**Your URL looks like:** `https://github.com/your-username/your-project.git`
-
-### 2.2 Clone the Repository
-
-In Cursor terminal:
-
-```bash
-git clone [paste your URL here]
-```
-
-**Example:**
-```bash
-git clone https://github.com/john-designer/dog-walker-app.git
-```
-
-**If Cursor prompts "Install Git?"** → Click **"Install"** and wait, then try again.
-
-**✅ Checkpoint:** You see "Cloning into..." and then "done"
-
----
-
-## Step 3: Open Your Project in Cursor
-
-1. In Cursor: **File** → **Open Folder**
-2. Navigate to your Projects folder
-3. Select your project folder (e.g., `dog-walker-app`)
-4. Click **"Select Folder"** or **"Open"**
-
-**✅ Checkpoint:** You see your project name in the left sidebar with README.md
-
----
-
-## Step 4: Clone WDS Repository
-
-**What is WDS?** The methodology files that contain agents, workflows, and training.
-
-**WDS lives separately from your project.**
-
-In Cursor terminal (make sure you're in Projects folder):
-
-```bash
-# Navigate back to Projects folder
-cd ~/Projects  # Mac/Linux
-cd C:\Projects # Windows
-
-# Clone WDS
-git clone https://github.com/whiteport-collective/whiteport-design-studio.git
-```
-
-**✅ Checkpoint:** WDS cloned successfully
-
----
-
-## Step 5: Add WDS to Your Workspace
-
-1. In Cursor: **File** → **Add Folder to Workspace**
-2. Navigate to your Projects folder
-3. Select the `whiteport-design-studio` folder
-4. Click **"Add"**
-
-**✅ Checkpoint:** You see both folders in your Cursor sidebar:
-- your-project
-- whiteport-design-studio
-
----
-
-## Step 6: Create Docs Folder Structure
-
-**What is the docs folder?** Where all your WDS specifications will live. This is your design source of truth.
-
-**Navigate to YOUR project (not WDS):**
-
-```bash
-# Change to your project
-cd ~/Projects/dog-walker-app  # Mac/Linux (use YOUR project name!)
-cd C:\Projects\dog-walker-app # Windows (use YOUR project name!)
-```
-
-**Create the 8-phase structure:**
-
-```bash
-# Mac/Linux (works in most terminals)
-mkdir -p docs/1-project-brief
-mkdir -p docs/2-trigger-mapping
-mkdir -p docs/3-prd-platform
-mkdir -p docs/4-ux-design
-mkdir -p docs/5-design-system
-mkdir -p docs/6-design-deliveries
-mkdir -p docs/7-testing
-mkdir -p docs/8-ongoing-development
-```
-
-**Windows alternative (if above doesn't work):**
-```bash
-mkdir docs
-cd docs
-mkdir 1-project-brief
-mkdir 2-trigger-mapping
-mkdir 3-prd-platform
-mkdir 4-ux-design
-mkdir 5-design-system
-mkdir 6-design-deliveries
-mkdir 7-testing
-mkdir 8-ongoing-development
-cd ..
-```
-
-**✅ Checkpoint:** You see a `docs/` folder with 8 numbered subfolders in your project
-
----
-
-## Quick Reference: What Lives Where
-
-```
-Your Computer/
-└── Projects/
-    ├── your-project/                          ← YOUR PROJECT
-    │   ├── docs/                              ← Your specifications
-    │   │   ├── 1-project-brief/
-    │   │   ├── 2-trigger-mapping/
-    │   │   ├── 3-prd-platform/
-    │   │   ├── 4-ux-design/
-    │   │   ├── 5-design-system/
-    │   │   ├── 6-design-deliveries/
-    │   │   ├── 7-testing/
-    │   │   └── 8-ongoing-development/
-    │   ├── src/                               ← Code (if single repo)
-    │   └── README.md
-    │
-    └── whiteport-design-studio/               ← WDS METHODOLOGY
-        └── src/modules/wds/
-            ├── agents/
-            ├── workflows/
-            ├── course/
-            └── MIMIR-WDS-ORCHESTRATOR.md
-```
-
----
-
-## Troubleshooting
-
-**Issue:** "Git command not found"  
-**Solution:** Let Cursor install Git when prompted, then try again
-
-**Issue:** "Permission denied" when cloning  
-**Solution:** Make sure you're signed into GitHub in Cursor
-
-**Issue:** "Can't find MIMIR file"  
-**Solution:** Make sure you added `whiteport-design-studio` folder to workspace (Step 5)
-
-**Issue:** "mkdir: cannot create directory"  
-**Solution:** Make sure you're in your project folder: `cd ~/Projects/your-project`
-
----
-
-## What's Next?
-
-Everything is set up! Now let's activate Mimir and begin your WDS journey.
-
-**[Continue to Lesson 05: Mimir Activation →](../lesson-05-initiate-mimir/tutorial.md)**
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/01-quick-checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/01-quick-checklist.md
deleted file mode 100644
index 7c811317f..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/01-quick-checklist.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# Lesson 04: WDS Project Initialization - Quick Checklist
-
-**⏱️ 15-20 minutes**
-
----
-
-## Clone WDS Repository
-
-In terminal (in Projects folder):
-
-```bash
-cd ~/Projects  # or cd C:\Projects
-git clone https://github.com/whiteport-collective/whiteport-design-studio.git
-```
-
-- [ ] ✅ WDS cloned
-
----
-
-## Add WDS to Workspace
-
-- [ ] **File** → **Add Folder to Workspace**
-- [ ] Select `whiteport-design-studio` folder
-- [ ] ✅ Both folders in sidebar
-
----
-
-## Create Docs Structure
-
-In terminal (in YOUR project):
-
-```bash
-cd ~/Projects/your-project-name
-
-# Mac/Linux
-mkdir -p docs/{1-project-brief,2-trigger-mapping,3-prd-platform,4-ux-design,5-design-system,6-design-deliveries,7-testing,8-ongoing-development}
-
-# Windows (if above doesn't work)
-mkdir docs
-cd docs
-mkdir 1-project-brief 2-trigger-mapping 3-prd-platform 4-ux-design 5-design-system 6-design-deliveries 7-testing 8-ongoing-development
-cd ..
-```
-
-- [ ] ✅ 8 folders in `docs/`
-
----
-
-## Activate Mimir
-
-- [ ] Find `whiteport-design-studio/src/modules/wds/MIMIR-WDS-ORCHESTRATOR.md`
-- [ ] Press **Ctrl+L** or **Cmd+L** (open AI chat)
-- [ ] Drag Mimir file to chat
-- [ ] Type: "Hello Mimir! I just completed setup."
-- [ ] ✅ Mimir responds!
-
----
-
-## 🎉 Complete!
-
-- ✅ GitHub account & repository
-- ✅ IDE installed
-- ✅ Project cloned
-- ✅ WDS integrated
-- ✅ Docs structure created
-- ✅ Mimir activated
-
-**Next:** [Module 03: Create Project Brief](../../module-03-project-brief/module-03-overview.md)
-
----
-
-**Need more detail?** See [full lesson](02-full-lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/02-full-lesson.md b/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/02-full-lesson.md
deleted file mode 100644
index 71234e4c4..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/02-full-lesson.md
+++ /dev/null
@@ -1,206 +0,0 @@
-# Lesson 04: WDS Project Initialization
-
-**Add WDS, create structure, activate Mimir**
-
----
-
-## What You'll Do
-
-- Clone WDS repository
-- Add WDS to workspace
-- Create docs structure (8 phases)
-- Activate Mimir
-
-**Time:** 15-20 minutes
-
----
-
-## Step 1: Clone WDS Repository
-
-**WDS lives separately from your project.**
-
-In terminal (make sure you're in Projects folder):
-
-```bash
-# Navigate to Projects
-cd ~/Projects  # Mac/Linux
-cd C:\Projects # Windows
-
-# Clone WDS
-git clone https://github.com/whiteport-collective/whiteport-design-studio.git
-```
-
-**✅ Checkpoint:** WDS cloned successfully
-
----
-
-## Step 2: Add WDS to Workspace
-
-1. **File** → **Add Folder to Workspace**
-2. Navigate to Projects folder
-3. Select `whiteport-design-studio` folder
-4. Click **"Add"**
-
-**✅ Checkpoint:** Both folders in sidebar:
-- your-project
-- whiteport-design-studio
-
----
-
-## Step 3: Create Docs Structure
-
-**What is docs?** Where all WDS specifications live. Your design source of truth.
-
-Navigate to YOUR project:
-
-```bash
-cd ~/Projects/your-project-name  # Use YOUR project name!
-cd C:\Projects\your-project-name # Windows
-```
-
-Create 8-phase structure:
-
-```bash
-# Mac/Linux
-mkdir -p docs/1-project-brief
-mkdir -p docs/2-trigger-mapping
-mkdir -p docs/3-prd-platform
-mkdir -p docs/4-ux-design
-mkdir -p docs/5-design-system
-mkdir -p docs/6-design-deliveries
-mkdir -p docs/7-testing
-mkdir -p docs/8-ongoing-development
-```
-
-**Windows alternative:**
-```bash
-mkdir docs
-cd docs
-mkdir 1-project-brief
-mkdir 2-trigger-mapping
-mkdir 3-prd-platform
-mkdir 4-ux-design
-mkdir 5-design-system
-mkdir 6-design-deliveries
-mkdir 7-testing
-mkdir 8-ongoing-development
-cd ..
-```
-
-**✅ Checkpoint:** `docs/` folder with 8 numbered subfolders
-
----
-
-## Step 4: Activate Mimir
-
-### What is Mimir?
-
-Your WDS guide and orchestrator. He'll:
-- Assess your skill level
-- Check your setup
-- Guide your next steps
-- Connect you with specialist agents
-
-### Find Mimir
-
-In IDE sidebar:
-1. Expand `whiteport-design-studio`
-2. Expand `src` → `modules` → `wds`
-3. Find `MIMIR-WDS-ORCHESTRATOR.md`
-
-### Open AI Chat
-
-- **Windows/Linux:** Press **Ctrl+L**
-- **Mac:** Press **Cmd+L**
-- Or click chat icon
-
-### Activate
-
-1. Drag `MIMIR-WDS-ORCHESTRATOR.md` into chat
-2. OR type: `@MIMIR-WDS-ORCHESTRATOR.md`
-3. Type: "Hello Mimir! I just completed setup and I'm ready to start."
-4. Press **Enter**
-
-**✅ Checkpoint:** Mimir responds and welcomes you!
-
----
-
-## Step 5: Answer Mimir's Questions
-
-Be honest about:
-- Your skill level
-- Your project
-- How you're feeling
-
-Mimir will:
-- Verify your installation
-- Guide your next steps
-- Connect you with specialists
-
-**Remember:** `@wds-mimir [your question]` anytime!
-
----
-
-## Quick Reference: File Structure
-
-```
-Projects/
-├── your-project/                      ← YOUR PROJECT
-│   ├── docs/                          ← Specifications
-│   │   ├── 1-project-brief/
-│   │   ├── 2-trigger-mapping/
-│   │   ├── 3-prd-platform/
-│   │   ├── 4-ux-design/
-│   │   ├── 5-design-system/
-│   │   ├── 6-design-deliveries/
-│   │   ├── 7-testing/
-│   │   └── 8-ongoing-development/
-│   └── README.md
-│
-└── whiteport-design-studio/           ← WDS METHODOLOGY
-    └── src/modules/wds/
-        ├── agents/
-        ├── workflows/
-        ├── course/
-        └── MIMIR-WDS-ORCHESTRATOR.md
-```
-
----
-
-## Troubleshooting
-
-**Issue:** Can't find MIMIR file → Check WDS added to workspace  
-**Issue:** Drag doesn't work → Use `@MIMIR-WDS-ORCHESTRATOR.md`  
-**Issue:** mkdir fails → Make sure you're in your project folder
-
----
-
-## 🎉 Congratulations!
-
-You've completed Module 02: Installation & Setup!
-
-**What you accomplished:**
-- ✅ GitHub account & repository
-- ✅ IDE installed
-- ✅ Project cloned
-- ✅ WDS integrated
-- ✅ Docs structure created
-- ✅ Mimir activated
-
-**You're ready to design with WDS!**
-
----
-
-## What's Next?
-
-- **[Module 03: Create Project Brief](../../module-03-project-brief/module-03-overview.md)**
-- **[WDS Training Course](../../00-course-overview.md)**
-- **Ask Mimir:** "What should I do next?"
-
-**Remember:** `@wds-mimir [your question]` anytime! 🌊
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/04-lesson.md b/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/04-lesson.md
deleted file mode 100644
index 71234e4c4..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/04-lesson.md
+++ /dev/null
@@ -1,206 +0,0 @@
-# Lesson 04: WDS Project Initialization
-
-**Add WDS, create structure, activate Mimir**
-
----
-
-## What You'll Do
-
-- Clone WDS repository
-- Add WDS to workspace
-- Create docs structure (8 phases)
-- Activate Mimir
-
-**Time:** 15-20 minutes
-
----
-
-## Step 1: Clone WDS Repository
-
-**WDS lives separately from your project.**
-
-In terminal (make sure you're in Projects folder):
-
-```bash
-# Navigate to Projects
-cd ~/Projects  # Mac/Linux
-cd C:\Projects # Windows
-
-# Clone WDS
-git clone https://github.com/whiteport-collective/whiteport-design-studio.git
-```
-
-**✅ Checkpoint:** WDS cloned successfully
-
----
-
-## Step 2: Add WDS to Workspace
-
-1. **File** → **Add Folder to Workspace**
-2. Navigate to Projects folder
-3. Select `whiteport-design-studio` folder
-4. Click **"Add"**
-
-**✅ Checkpoint:** Both folders in sidebar:
-- your-project
-- whiteport-design-studio
-
----
-
-## Step 3: Create Docs Structure
-
-**What is docs?** Where all WDS specifications live. Your design source of truth.
-
-Navigate to YOUR project:
-
-```bash
-cd ~/Projects/your-project-name  # Use YOUR project name!
-cd C:\Projects\your-project-name # Windows
-```
-
-Create 8-phase structure:
-
-```bash
-# Mac/Linux
-mkdir -p docs/1-project-brief
-mkdir -p docs/2-trigger-mapping
-mkdir -p docs/3-prd-platform
-mkdir -p docs/4-ux-design
-mkdir -p docs/5-design-system
-mkdir -p docs/6-design-deliveries
-mkdir -p docs/7-testing
-mkdir -p docs/8-ongoing-development
-```
-
-**Windows alternative:**
-```bash
-mkdir docs
-cd docs
-mkdir 1-project-brief
-mkdir 2-trigger-mapping
-mkdir 3-prd-platform
-mkdir 4-ux-design
-mkdir 5-design-system
-mkdir 6-design-deliveries
-mkdir 7-testing
-mkdir 8-ongoing-development
-cd ..
-```
-
-**✅ Checkpoint:** `docs/` folder with 8 numbered subfolders
-
----
-
-## Step 4: Activate Mimir
-
-### What is Mimir?
-
-Your WDS guide and orchestrator. He'll:
-- Assess your skill level
-- Check your setup
-- Guide your next steps
-- Connect you with specialist agents
-
-### Find Mimir
-
-In IDE sidebar:
-1. Expand `whiteport-design-studio`
-2. Expand `src` → `modules` → `wds`
-3. Find `MIMIR-WDS-ORCHESTRATOR.md`
-
-### Open AI Chat
-
-- **Windows/Linux:** Press **Ctrl+L**
-- **Mac:** Press **Cmd+L**
-- Or click chat icon
-
-### Activate
-
-1. Drag `MIMIR-WDS-ORCHESTRATOR.md` into chat
-2. OR type: `@MIMIR-WDS-ORCHESTRATOR.md`
-3. Type: "Hello Mimir! I just completed setup and I'm ready to start."
-4. Press **Enter**
-
-**✅ Checkpoint:** Mimir responds and welcomes you!
-
----
-
-## Step 5: Answer Mimir's Questions
-
-Be honest about:
-- Your skill level
-- Your project
-- How you're feeling
-
-Mimir will:
-- Verify your installation
-- Guide your next steps
-- Connect you with specialists
-
-**Remember:** `@wds-mimir [your question]` anytime!
-
----
-
-## Quick Reference: File Structure
-
-```
-Projects/
-├── your-project/                      ← YOUR PROJECT
-│   ├── docs/                          ← Specifications
-│   │   ├── 1-project-brief/
-│   │   ├── 2-trigger-mapping/
-│   │   ├── 3-prd-platform/
-│   │   ├── 4-ux-design/
-│   │   ├── 5-design-system/
-│   │   ├── 6-design-deliveries/
-│   │   ├── 7-testing/
-│   │   └── 8-ongoing-development/
-│   └── README.md
-│
-└── whiteport-design-studio/           ← WDS METHODOLOGY
-    └── src/modules/wds/
-        ├── agents/
-        ├── workflows/
-        ├── course/
-        └── MIMIR-WDS-ORCHESTRATOR.md
-```
-
----
-
-## Troubleshooting
-
-**Issue:** Can't find MIMIR file → Check WDS added to workspace  
-**Issue:** Drag doesn't work → Use `@MIMIR-WDS-ORCHESTRATOR.md`  
-**Issue:** mkdir fails → Make sure you're in your project folder
-
----
-
-## 🎉 Congratulations!
-
-You've completed Module 02: Installation & Setup!
-
-**What you accomplished:**
-- ✅ GitHub account & repository
-- ✅ IDE installed
-- ✅ Project cloned
-- ✅ WDS integrated
-- ✅ Docs structure created
-- ✅ Mimir activated
-
-**You're ready to design with WDS!**
-
----
-
-## What's Next?
-
-- **[Module 03: Create Project Brief](../../module-03-project-brief/module-03-overview.md)**
-- **[WDS Training Course](../../00-course-overview.md)**
-- **Ask Mimir:** "What should I do next?"
-
-**Remember:** `@wds-mimir [your question]` anytime! 🌊
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/04-quick-checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/04-quick-checklist.md
deleted file mode 100644
index 7c811317f..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-04-wds-initialization/04-quick-checklist.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# Lesson 04: WDS Project Initialization - Quick Checklist
-
-**⏱️ 15-20 minutes**
-
----
-
-## Clone WDS Repository
-
-In terminal (in Projects folder):
-
-```bash
-cd ~/Projects  # or cd C:\Projects
-git clone https://github.com/whiteport-collective/whiteport-design-studio.git
-```
-
-- [ ] ✅ WDS cloned
-
----
-
-## Add WDS to Workspace
-
-- [ ] **File** → **Add Folder to Workspace**
-- [ ] Select `whiteport-design-studio` folder
-- [ ] ✅ Both folders in sidebar
-
----
-
-## Create Docs Structure
-
-In terminal (in YOUR project):
-
-```bash
-cd ~/Projects/your-project-name
-
-# Mac/Linux
-mkdir -p docs/{1-project-brief,2-trigger-mapping,3-prd-platform,4-ux-design,5-design-system,6-design-deliveries,7-testing,8-ongoing-development}
-
-# Windows (if above doesn't work)
-mkdir docs
-cd docs
-mkdir 1-project-brief 2-trigger-mapping 3-prd-platform 4-ux-design 5-design-system 6-design-deliveries 7-testing 8-ongoing-development
-cd ..
-```
-
-- [ ] ✅ 8 folders in `docs/`
-
----
-
-## Activate Mimir
-
-- [ ] Find `whiteport-design-studio/src/modules/wds/MIMIR-WDS-ORCHESTRATOR.md`
-- [ ] Press **Ctrl+L** or **Cmd+L** (open AI chat)
-- [ ] Drag Mimir file to chat
-- [ ] Type: "Hello Mimir! I just completed setup."
-- [ ] ✅ Mimir responds!
-
----
-
-## 🎉 Complete!
-
-- ✅ GitHub account & repository
-- ✅ IDE installed
-- ✅ Project cloned
-- ✅ WDS integrated
-- ✅ Docs structure created
-- ✅ Mimir activated
-
-**Next:** [Module 03: Create Project Brief](../../module-03-project-brief/module-03-overview.md)
-
----
-
-**Need more detail?** See [full lesson](02-full-lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-05-initiate-mimir/checklist.md b/docs/learn-wds/module-02-installation-setup/lesson-05-initiate-mimir/checklist.md
deleted file mode 100644
index 1b736aa97..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-05-initiate-mimir/checklist.md
+++ /dev/null
@@ -1,79 +0,0 @@
-# Lesson 05: Mimir Activation - Quick Checklist
-
-**⏱️ 5 minutes**
-
----
-
-## Find Mimir
-
-In Cursor sidebar:
-- [ ] Expand `whiteport-design-studio`
-- [ ] Expand `src` → `modules` → `wds`
-- [ ] Find `MIMIR-WDS-ORCHESTRATOR.md`
-
----
-
-## Open AI Chat
-
-- [ ] Press **Ctrl+L** (Win/Linux) or **Cmd+L** (Mac)
-- [ ] Or click chat icon in sidebar
-
----
-
-## Activate Mimir
-
-- [ ] Drag `MIMIR-WDS-ORCHESTRATOR.md` into chat input
-- [ ] OR type: `@MIMIR-WDS-ORCHESTRATOR.md`
-- [ ] Type: "Hello Mimir! I just completed setup and I'm ready to start."
-- [ ] Press **Enter**
-- [ ] ✅ Mimir responds!
-
----
-
-## Answer Mimir's Questions
-
-Be honest about:
-- [ ] Your skill level (beginner/learning/comfortable/experienced)
-- [ ] Your project
-- [ ] How you're feeling
-
-Mimir will:
-- [ ] Verify your installation
-- [ ] Guide your next steps
-- [ ] Connect you with specialist agents when ready
-
----
-
-## Remember This Command
-
-Whenever you need help:
-```
-@wds-mimir [your question]
-```
-
----
-
-## 🎉 You Did It!
-
-**Completed:**
-- ✅ GitHub account & repository
-- ✅ IDE installed
-- ✅ Project cloned
-- ✅ WDS integrated
-- ✅ Docs structure created
-- ✅ Mimir activated
-
-**You're ready to design with WDS!**
-
----
-
-## Next Steps
-
-- **[Module 03: Create Project Brief](../../module-03-project-brief/module-03-overview.md)**
-- **[WDS Training Course](../../00-course-overview.md)**
-- **Ask Mimir:** "What should I do next?"
-
----
-
-**Need more detail?** See [full lesson explanation](lesson.md)
-
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-05-initiate-mimir/tutorial.md b/docs/learn-wds/module-02-installation-setup/lesson-05-initiate-mimir/tutorial.md
deleted file mode 100644
index d83f22724..000000000
--- a/docs/learn-wds/module-02-installation-setup/lesson-05-initiate-mimir/tutorial.md
+++ /dev/null
@@ -1,244 +0,0 @@
-# Lesson 05: Mimir Activation
-
-**Activate your WDS guide and begin your journey**
-
----
-
-## What You'll Do
-
-- Find the Mimir orchestrator file
-- Drag it to AI chat
-- Have your first conversation with Mimir
-- Begin guided WDS workflow
-
-**Time:** 5 minutes
-
----
-
-## What is Mimir?
-
-**Mimir** is your WDS guide and orchestrator.
-
-Think of Mimir as:
-- Your coach through WDS methodology
-- Your trainer for each workflow
-- Your psychologist when things feel overwhelming
-- Your strategist for project decisions
-
-**Mimir's role:** Assess your needs, understand your skill level, and connect you with the right specialist agents (Freya, Saga, Idunn) when appropriate.
-
----
-
-## Step 1: Find the Mimir File
-
-In Cursor sidebar:
-
-1. Expand **`whiteport-design-studio`**
-2. Expand **`src`** → **`modules`** → **`wds`**
-3. Find **`MIMIR-WDS-ORCHESTRATOR.md`**
-
-**✅ Checkpoint:** You can see the Mimir file
-
----
-
-## Step 2: Open AI Chat
-
-In Cursor:
-
-- **Windows/Linux:** Press **Ctrl+L**
-- **Mac:** Press **Cmd+L**
-- Or click the **chat icon** in the sidebar
-
-**The AI chat panel will appear!**
-
----
-
-## Step 3: Drag Mimir to Chat
-
-1. Click and hold **`MIMIR-WDS-ORCHESTRATOR.md`** in the sidebar
-2. Drag it into the AI chat input area
-3. Release
-
-**You should see the file attached to your message!**
-
-**Alternative method:**
-Type in chat:
-```
-@MIMIR-WDS-ORCHESTRATOR.md
-```
-
----
-
-## Step 4: Send Your First Message
-
-**Type your first message:**
-
-```
-Hello Mimir! I just completed the installation setup and I'm ready to start.
-```
-
-**Press Enter or click Send**
-
----
-
-## What Mimir Will Do
-
-Mimir will:
-
-1. **Welcome you warmly** 🌊
-2. **Assess your situation:**
-   - Technical skill level (beginner → experienced)
-   - Emotional state (excited, nervous, ready)
-   - Familiarity with WDS
-3. **Check your environment:**
-   - Is WDS repository present?
-   - Is your project set up correctly?
-   - Do you have the docs structure?
-4. **Understand your project:**
-   - What are you building?
-   - What phase are you in?
-   - Do you need to start from Project Brief?
-5. **Guide your next steps:**
-   - Route you to appropriate agent if needed
-   - Suggest which workflow to start with
-   - Offer training if you want to learn first
-
----
-
-## Be Honest with Mimir
-
-**Mimir adapts to YOU.**
-
-If you're nervous → Mimir will be extra patient  
-If you're experienced → Mimir will be concise  
-If you're confused → Mimir will slow down
-
-**There are no wrong answers!**
-
----
-
-## Example First Conversation
-
-**You:**
-> Hello Mimir! I just completed setup and I'm ready to start.
-
-**Mimir:**
-> Welcome! 🌊 I'm Mimir, your guide through Whiteport Design Studio.
->
-> I can see you've completed the installation - that's fantastic work!
->
-> Let me understand your situation:
-> 1. How comfortable are you with design tools and AI assistants? (Complete beginner / Learning / Comfortable / Experienced)
-> 2. What project are you working on?
-> 3. How are you feeling about starting this journey?
-
-**Just answer honestly!** Mimir will adapt to your needs.
-
----
-
-## Whenever You Need Help
-
-**Remember this simple command:**
-
-```
-@wds-mimir [your question]
-```
-
-**Examples:**
-- `@wds-mimir I'm stuck on trigger mapping, can you help?`
-- `@wds-mimir Which agent should I work with for UX design?`
-- `@wds-mimir I feel overwhelmed, where should I start?`
-- `@wds-mimir Can you walk me through the WDS training?`
-
-**No question is too small. Mimir is always here to guide you.**
-
----
-
-## Troubleshooting
-
-**Issue:** Can't find MIMIR file  
-**Solution:** Make sure you added `whiteport-design-studio` to workspace (Lesson 04, Step 5)
-
-**Issue:** Drag doesn't work  
-**Solution:** Use `@MIMIR-WDS-ORCHESTRATOR.md` instead
-
-**Issue:** AI doesn't respond  
-**Solution:** Make sure you're connected to internet, wait a moment, try again
-
-**Issue:** Not sure what to say  
-**Solution:** Just say "Hello! I'm new and ready to start" - Mimir will guide you from there
-
----
-
-## 🎉 Congratulations!
-
-### You Did It!
-
-You've completed the entire Module 02: Installation & Setup!
-
-**What you accomplished:**
-- ✅ Created GitHub account
-- ✅ Set up project repository
-- ✅ Installed IDE (Cursor or VS Code)
-- ✅ Cloned your project
-- ✅ Added WDS to workspace
-- ✅ Created docs structure
-- ✅ Activated Mimir
-
-**This is HUGE!** Many designers never get past this point. You're ready to design with WDS.
-
----
-
-## Your Journey Continues
-
-**Next steps (Mimir will guide you):**
-
-- **[Module 03: Create Project Brief](../../module-03-project-brief/module-03-overview.md)** - If starting a new project
-- **[WDS Training Course](../../00-course-overview.md)** - If you want to learn methodology first
-- **Ask Mimir** - "What should I do next?"
-
----
-
-## Pro Tips for Beginners
-
-**Tip 1: Commit Often**
-Every time you make meaningful progress, save to GitHub:
-```bash
-git add .
-git commit -m "Describe what you did"
-git push
-```
-
-**Tip 2: Keep WDS Updated**
-Once a month, update WDS to get new features:
-```bash
-cd ~/Projects/whiteport-design-studio
-git pull
-```
-
-**Tip 3: When in Doubt, Ask Mimir**
-```
-@wds-mimir [your question]
-```
-No question is too small!
-
-**Tip 4: Save Your Workspace**
-In Cursor: **File** → **Save Workspace As** → `my-project.code-workspace`
-Next time, just open this file!
-
----
-
-## Remember
-
-**Whenever in doubt:**
-
-```
-@wds-mimir [your question]
-```
-
-**Mimir believes in you. You can do this. Welcome to WDS.** 🌊
-
----
-
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
diff --git a/docs/learn-wds/module-02-installation-setup/module-02-overview.md b/docs/learn-wds/module-02-installation-setup/module-02-overview.md
deleted file mode 100644
index e0c7478ca..000000000
--- a/docs/learn-wds/module-02-installation-setup/module-02-overview.md
+++ /dev/null
@@ -1,77 +0,0 @@
-# Module 02: Installation & Setup
-
-**From zero to WDS-ready - complete beginner friendly**
-
----
-
-## Overview
-
-This module takes you from having nothing to being fully set up with WDS, even if you've never used GitHub or an IDE before.
-
-**Time:** 45-60 minutes total  
-**Difficulty:** Beginner  
-**Prerequisites:** Computer + Internet + Email
-
----
-
-## Lessons
-
-### [Lesson 01: Git Setup](lesson-01-git-setup/)
-**15-20 minutes** | Create GitHub account and repository
-
-- **[01 - Quick Checklist](lesson-01-git-setup/01-quick-checklist.md)** - Action list
-- **[02 - Full Lesson](lesson-01-git-setup/02-full-lesson.md)** - With explanations
-
----
-
-### [Lesson 02: IDE Installation](lesson-02-ide-installation/)
-**10 minutes** | Install Cursor or VS Code
-
-- **[01 - Quick Checklist](lesson-02-ide-installation/01-quick-checklist.md)** - Action list
-- **[02 - Full Lesson](lesson-02-ide-installation/02-full-lesson.md)** - With explanations
-
----
-
-### [Lesson 03: Git Repository Cloning](lesson-03-git-cloning/)
-**10 minutes** | Clone your project to your computer
-
-- **[01 - Quick Checklist](lesson-03-git-cloning/01-quick-checklist.md)** - Action list
-- **[02 - Full Lesson](lesson-03-git-cloning/02-full-lesson.md)** - With explanations
-
----
-
-### [Lesson 04: WDS Project Initialization](lesson-04-wds-initialization/)
-**15-20 minutes** | Add WDS, create docs structure, activate Mimir
-
-- **[01 - Quick Checklist](lesson-04-wds-initialization/01-quick-checklist.md)** - Action list
-- **[02 - Full Lesson](lesson-04-wds-initialization/02-full-lesson.md)** - With explanations
-
----
-
-## Quick Start
-
-**Want the fastest path?**
-
-Follow the checklists: [Start with Lesson 01 Checklist →](lesson-01-git-setup/01-quick-checklist.md)
-
-**Want detailed explanations?**
-
-Follow the full lessons: [Start with Lesson 01 Full Lesson →](lesson-01-git-setup/02-full-lesson.md)
-
----
-
-## After This Module
-
-- ✅ GitHub account and repository
-- ✅ IDE installed and configured
-- ✅ Project cloned to your computer
-- ✅ WDS integrated in workspace
-- ✅ Docs folder structure created
-- ✅ Mimir activated and ready
-
-**Next:** [Module 03: Create Project Brief](../module-03-project-brief/module-03-overview.md)
-
----
-
-*Part of the WDS Course: From Designer to Linchpin*  
-*[← Back to Course Overview](../00-course-overview.md)*
diff --git a/docs/learn-wds/module-05-map-triggers-outcomes/tutorial-04.md b/docs/learn-wds/module-05-map-triggers-outcomes/tutorial-04.md
deleted file mode 100644
index 050c8f93b..000000000
--- a/docs/learn-wds/module-05-map-triggers-outcomes/tutorial-04.md
+++ /dev/null
@@ -1,460 +0,0 @@
-# Tutorial 04: Map Triggers & Outcomes
-
-**Hands-on guide to understanding WHAT triggers user needs and WHY your business exists**
-
----
-
-## Overview
-
-This tutorial teaches you how to map the psychological triggers that drive user behavior and connect them to business outcomes.
-
-**Time:** 45-60 minutes  
-**Prerequisites:** Module 03 completed (Target Groups identified)  
-**What you'll create:** A complete trigger map for your top target group
-
----
-
-## What You'll Learn
-
-- How to identify user trigger moments
-- Mapping from trigger → need → solution → outcome
-- Connecting user psychology to business value
-- Prioritizing features by trigger impact
-- Creating a traceable chain of reasoning
-
----
-
-## Step 1: Select Your Top Target Group (5 min)
-
-From Module 03, choose your highest-priority target group.
-
-**Example (Dog Week):**
-
-```
-Target Group: Busy Parents with Family Dog
-Priority: #1 (highest impact + feasibility)
-```
-
-**Your turn:**
-
-```
-Selected Target Group: [Your top group]
-Why this group: [Reasoning]
-```
-
----
-
-## Step 2: Identify Trigger Moments (15 min)
-
-### What is a trigger?
-
-A specific moment when a user realizes they have a need your product can solve.
-
-### Framework: The Trigger Moment
-
-**Ask:**
-
-- WHEN does the user feel pain/frustration?
-- WHAT specific situation causes this?
-- WHY does this matter to them emotionally?
-
-**Example (Dog Week - Busy Parents):**
-
-**Trigger 1: Morning Chaos**
-
-```
-WHEN: Monday morning, everyone rushing
-WHAT: Nobody knows who's walking the dog
-WHY: Stress, guilt, family conflict, dog's needs unmet
-```
-
-**Trigger 2: Forgotten Feeding**
-
-```
-WHEN: Evening, parent realizes dog wasn't fed
-WHAT: Uncertainty about who was responsible
-WHY: Guilt, worry about dog's health, family tension
-```
-
-**Trigger 3: Vet Appointment Missed**
-
-```
-WHEN: Vet calls about missed appointment
-WHAT: Nobody remembered or knew about it
-WHY: Embarrassment, concern for dog, wasted money
-```
-
-**Your turn:**
-
-```
-Identify 3-5 trigger moments for your target group:
-
-Trigger 1: [Name]
-WHEN: [Specific moment]
-WHAT: [Specific situation]
-WHY: [Emotional impact]
-
-Trigger 2: [Name]
-WHEN:
-WHAT:
-WHY:
-
-[Continue for 3-5 triggers]
-```
-
-**AI Support:**
-
-```
-Agent: "Let's dig deeper into each trigger:
-- What happens right before this moment?
-- What emotions does the user feel?
-- How often does this happen?
-- What do they try now (that doesn't work)?"
-```
-
----
-
-## Step 3: Map User Needs (10 min)
-
-### What is the need?
-
-The underlying requirement the user has when triggered.
-
-### Framework: From Trigger to Need
-
-**For each trigger, ask:**
-
-- What does the user need in this moment?
-- What would make this situation better?
-- What's the core problem to solve?
-
-**Example (Dog Week):**
-
-**Trigger: Morning Chaos**
-
-```
-Need: Know immediately who's responsible for dog care today
-Need: See the full week's schedule at a glance
-Need: Get reminded before tasks are due
-```
-
-**Trigger: Forgotten Feeding**
-
-```
-Need: Track whether tasks were completed
-Need: Get notifications when tasks are overdue
-Need: See task history to avoid confusion
-```
-
-**Your turn:**
-
-```
-For each trigger, identify 2-3 core needs:
-
-Trigger 1: [Name]
-Needs:
-- [Need 1]
-- [Need 2]
-- [Need 3]
-
-[Continue for all triggers]
-```
-
----
-
-## Step 4: Define Solutions (10 min)
-
-### What is the solution?
-
-The specific feature or capability that addresses the need.
-
-### Framework: Need to Solution
-
-**For each need, ask:**
-
-- What feature would solve this?
-- How would it work?
-- What's the simplest version?
-
-**Example (Dog Week):**
-
-**Need: Know who's responsible today**
-
-```
-Solution: Daily schedule view with assigned responsibilities
-- Shows today's tasks
-- Highlights current user's tasks
-- Shows who's assigned to each task
-```
-
-**Need: Get reminded before tasks are due**
-
-```
-Solution: Smart notifications
-- Reminder 1 hour before task
-- Escalation if task not completed
-- Family-wide visibility of overdue tasks
-```
-
-**Your turn:**
-
-```
-For each need, define a solution:
-
-Need: [Need description]
-Solution: [Feature name]
-- [How it works]
-- [Key capabilities]
-- [User benefit]
-
-[Continue for all needs]
-```
-
-**AI Support:**
-
-```
-Agent: "Let's validate each solution:
-- Does this truly solve the need?
-- Is it the simplest solution?
-- Are there edge cases to consider?
-- How does this connect to business goals?"
-```
-
----
-
-## Step 5: Map Business Outcomes (10 min)
-
-### What is the outcome?
-
-The business value created when users get their needs met.
-
-### Framework: Solution to Outcome
-
-**For each solution, ask:**
-
-- How does this create business value?
-- What metrics improve?
-- How does this support business goals?
-
-**Example (Dog Week):**
-
-**Solution: Daily schedule view**
-
-```
-User Outcome: Reduced stress, better dog care
-Business Outcome:
-- Increased daily active users (checking schedule)
-- Higher retention (solving real pain)
-- Word-of-mouth growth (visible family benefit)
-Metrics: DAU, retention rate, NPS
-```
-
-**Solution: Smart notifications**
-
-```
-User Outcome: Never miss dog care tasks
-Business Outcome:
-- Increased engagement (notification opens)
-- Higher task completion (core value delivered)
-- Premium feature potential (advanced notifications)
-Metrics: Notification open rate, task completion rate, conversion
-```
-
-**Your turn:**
-
-```
-For each solution, map to business outcomes:
-
-Solution: [Feature name]
-User Outcome: [How user benefits]
-Business Outcome: [How business benefits]
-Metrics: [What you'll measure]
-
-[Continue for all solutions]
-```
-
----
-
-## Step 6: Create Trigger Map Visualization (10 min)
-
-### Format:
-
-```
-TARGET GROUP: [Group name]
-
-TRIGGER → NEED → SOLUTION → OUTCOME
-
-1. [Trigger name]
-   WHEN: [Moment]
-   ↓
-   NEED: [Core need]
-   ↓
-   SOLUTION: [Feature]
-   ↓
-   OUTCOME: [Business value]
-   METRICS: [Measurements]
-
-2. [Next trigger...]
-```
-
-**Example (Dog Week - Simplified):**
-
-```
-TARGET GROUP: Busy Parents with Family Dog
-
-TRIGGER → NEED → SOLUTION → OUTCOME
-
-1. Morning Chaos
-   WHEN: Monday morning, nobody knows dog responsibilities
-   ↓
-   NEED: Know who's responsible for dog care today
-   ↓
-   SOLUTION: Daily schedule view with assigned tasks
-   ↓
-   OUTCOME: Increased DAU, higher retention
-   METRICS: Daily active users, 7-day retention
-
-2. Forgotten Feeding
-   WHEN: Evening, uncertainty about feeding
-   ↓
-   NEED: Track task completion in real-time
-   ↓
-   SOLUTION: Task completion tracking + notifications
-   ↓
-   OUTCOME: Higher engagement, core value delivered
-   METRICS: Task completion rate, notification opens
-```
-
-**Your turn:**
-
-```
-Create your trigger map:
-[Your complete map]
-```
-
----
-
-## Step 7: Prioritize by Impact (5 min)
-
-### Framework: Impact Score
-
-**For each trigger-to-outcome chain, rate:**
-
-- **User Impact** (1-5): How much does this help the user?
-- **Business Impact** (1-5): How much business value does this create?
-- **Feasibility** (1-5): How easy is this to build?
-
-**Calculate:** `Priority Score = (User Impact + Business Impact) × Feasibility`
-
-**Example (Dog Week):**
-
-```
-1. Morning Chaos → Daily Schedule
-   User: 5, Business: 5, Feasibility: 4
-   Score: (5+5) × 4 = 40 ⭐ HIGHEST PRIORITY
-
-2. Forgotten Feeding → Task Tracking
-   User: 5, Business: 4, Feasibility: 4
-   Score: (5+4) × 4 = 36 ⭐ HIGH PRIORITY
-
-3. Vet Appointment → Calendar Integration
-   User: 4, Business: 3, Feasibility: 2
-   Score: (4+3) × 2 = 14 → LOWER PRIORITY
-```
-
-**Your turn:**
-
-```
-Score and rank your triggers:
-[Your prioritized list]
-```
-
----
-
-## Step 8: Save Your Trigger Map
-
-**Create file:** `B-Trigger-Map/trigger-map-[target-group].md`
-
-**Use template from:** `workflows/2-trigger-mapping/templates/trigger-map.template.md`
-
----
-
-## What You've Accomplished
-
-✅ **Identified trigger moments** - You know WHEN users need your product  
-✅ **Mapped user needs** - You understand WHAT users need  
-✅ **Defined solutions** - You know WHAT to build  
-✅ **Connected to business** - You know WHY each feature matters  
-✅ **Prioritized features** - You know WHAT to build first
-
----
-
-## The Power of Trigger Mapping
-
-**This is strategic gold:**
-
-- Every feature traces back to a real user trigger
-- Every decision is backed by user psychology
-- Every feature connects to business value
-- No more guessing what to build
-- No more building things nobody uses
-
-**When product managers ask "what should we build next?"**  
-→ You have the answer, backed by data and reasoning
-
----
-
-## Next Steps
-
-**Immediate:**
-
-- Repeat for your top 2-3 target groups
-- Compare trigger maps across groups
-- Identify overlapping needs (efficiency opportunity)
-
-**Next Module:**
-
-- [Module 05: Prioritize Features](../module-05-prioritize-features/module-05-overview.md)
-- Create your feature roadmap based on trigger impact
-
----
-
-## Common Questions
-
-**Q: How many triggers should I identify per target group?**  
-A: Start with 3-5 major triggers. You can always add more later.
-
-**Q: What if multiple triggers lead to the same solution?**  
-A: Perfect! This means the solution has high leverage. Document all triggers it solves.
-
-**Q: Should I map triggers for all target groups?**  
-A: Start with your top 1-2 groups. Add more as needed.
-
-**Q: How do I validate these triggers are real?**  
-A: User research, interviews, observation. The trigger map is a hypothesis to test.
-
----
-
-## Tips for Success
-
-**DO ✅**
-
-- Be specific about trigger moments
-- Focus on emotional impact (the "why")
-- Connect everything to business outcomes
-- Prioritize ruthlessly
-- Test assumptions with users
-
-**DON'T ❌**
-
-- List generic "user wants X" statements
-- Skip the emotional "why"
-- Create solutions without clear triggers
-- Try to solve everything at once
-- Forget to measure outcomes
-
----
-
-**Your trigger map is the strategic foundation that guides every design decision!**
-
-[← Back to Module 04](module-04-overview.md) | [Next: Module 05 →](../module-05-prioritize-features/module-05-overview.md)
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-04-workshop-1-business-goals.md b/docs/learn-wds/module-05-trigger-mapping/lesson-04-workshop-1-business-goals.md
deleted file mode 100644
index 41f4e06d4..000000000
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-04-workshop-1-business-goals.md
+++ /dev/null
@@ -1,274 +0,0 @@
-# Lesson 3: Workshop 1 - Business Goals
-
-**Define What Winning Looks Like**
-
----
-
-## Overview
-
-Workshop 1 is where you establish the strategic foundation for your entire Trigger Map. You'll define both your aspirational vision and concrete measurable objectives that prove you're succeeding.
-
-**Duration:** 15-20 minutes  
-**Format:** Conversational with Saga  
-**Output:** Vision statement + 3-5 strategic objectives
-
----
-
-## Understanding the Two Levels
-
-Business goals work on two distinct levels:
-
-### 1. Vision (Visionary Statements)
-
-**What it is:**
-- Aspirational and motivational
-- Grand ambitions that reflect focus and direction
-- Not exact or measurable
-- Examples: "Be the best," "Fastest in market," "Top of mind"
-
-**Characteristics:**
-- Easy to set, hard to measure
-- Provides the "why" and emotional drive
-- Inspires and motivates the team
-- Gives direction without rigid constraints
-
-### 2. Strategic Objectives
-
-**What it is:**
-- Specific and measurable (expressed using SMART method)
-- Observable evidence that vision is being realized
-- Concrete milestones you can track
-- Examples: "10,000 users by Q4," "70% retention rate"
-
-**Characteristics:**
-- Harder to set, easy to measure
-- Provides the "what" and accountability
-- Enables progress tracking
-- Creates clear success criteria
-
-**Why both matter:** Visionary statements provide motivation and direction. Objectives provide accountability and proof of progress. Together they create both inspiration and measurement.
-
----
-
-## The Workshop Flow
-
-### Step 1: Start with Vision
-
-**Capture the grand ambition:**
-- What's the aspirational future state?
-- What motivates the team?
-- What's the "why" behind this project?
-- Don't worry about exact measurement yet
-
-**Example:**
-"Make remote work sustainable and healthy for distributed teams"
-
-### Step 2: Ask "What Will We Observe?"
-
-**Bridge from soft to hard goals:**
-- When this vision is being realized, what will we see in the world?
-- What measurable evidence proves we're succeeding?
-- What observable changes indicate progress?
-
-**This is the critical bridging question** that transforms aspiration into measurable reality.
-
-**Example:**
-"When remote work is sustainable and healthy, we'll observe teams using tools daily, staying engaged long-term, and growing their usage. We'll see business metrics that prove the model works."
-
-### Step 3: Define Strategic Objectives
-
-**Transform observations into specific goals:**
-- 3-5 concrete objectives
-- Each expressed using SMART method (Specific, Measurable, Achievable, Relevant, Time-bound)
-- Focus on what's truly measurable
-- Set realistic timeframes
-
-See [SMART Method Reference](../../models/smart-goals-model.md) for detailed guidance on creating strategic objectives.
-
-**Example:**
-1. Achieve 5,000 active teams by Q4 2024
-2. Increase average session time to 15 minutes daily
-3. Reach 70% weekly retention rate
-4. Generate $50K MRR by end of year
-
----
-
-## Key Questions Saga Asks
-
-### For Vision (Visionary Statements)
-
-- "What's the grand ambition behind this project?"
-- "What does 'winning' look like at the highest level?"
-- "What vision motivates your team?"
-- "Why does this project matter?"
-
-### Bridging to Objectives
-
-- "When this vision is being realized, what will we observe in the world?"
-- "What measurable evidence would prove you're succeeding?"
-- "What would we see that indicates progress toward this vision?"
-
-### For Strategic Objectives (using SMART method)
-
-- "What specific, measurable outcomes would prove success?"
-- "By when do you need to achieve these objectives?"
-- "How will you measure progress?"
-- "What counts as 'active' or 'successful' in your context?"
-
----
-
-## Generic Example Walkthrough
-
-### Vision (Soft Goal)
-
-"Make remote work sustainable and healthy for distributed teams"
-
-**Why this works:**
-- Aspirational and motivating
-- Clear direction without rigid constraints
-- Easy to communicate and remember
-- Inspires the team
-
-### Bridging Question
-
-"When remote work is sustainable and healthy, what will we observe?"
-
-**Observations:**
-- Teams using our solution daily
-- High retention rates (people stay)
-- Growing usage patterns
-- Sustainable business model (revenue)
-
-### Strategic Objectives (using SMART method)
-
-1. **Achieve 5,000 active teams by Q4 2024**
-   - Specific: Active teams (defined metric)
-   - Measurable: 5,000 teams
-   - Achievable: Based on market size and growth rate
-   - Relevant: Proves market adoption
-   - Time-bound: Q4 2024
-
-2. **Increase average session time to 15 minutes daily**
-   - Specific: Session time metric
-   - Measurable: 15 minutes
-   - Achievable: Industry benchmarks
-   - Relevant: Indicates engagement
-   - Time-bound: Daily measurement
-
-3. **Reach 70% weekly retention rate**
-   - Specific: Weekly retention
-   - Measurable: 70% rate
-   - Achievable: Above industry average
-   - Relevant: Proves value delivery
-   - Time-bound: Weekly tracking
-
-4. **Generate $50K MRR by end of year**
-   - Specific: Monthly recurring revenue
-   - Measurable: $50K
-   - Achievable: Based on pricing and targets
-   - Relevant: Business sustainability
-   - Time-bound: End of year
-
----
-
-## What You Get from Workshop 1
-
-✅ **Inspiring vision** that motivates the team  
-✅ **Measurable objectives** that prove progress  
-✅ **Clear connection** between ambition and accountability  
-✅ **Foundation** for all strategic decisions  
-✅ **Alignment** on both "why" and "what"
-
----
-
-## Common Mistakes to Avoid
-
-### Mistake 1: Skipping the Vision
-
-**Problem:** Jumping straight to metrics without capturing the aspiration  
-**Why it fails:** Team loses motivation, no emotional connection  
-**Fix:** Start with the grand ambition, then bridge to metrics
-
-### Mistake 2: Vague Objectives
-
-**Problem:** "Improve user experience" or "Get more customers"  
-**Why it fails:** Can't measure progress, no accountability  
-**Fix:** Make every objective SMART with specific numbers
-
-### Mistake 3: Too Many Objectives
-
-**Problem:** Listing 15 different metrics to track  
-**Why it fails:** Dilutes focus, creates confusion  
-**Fix:** Limit to 3-5 most critical objectives
-
-### Mistake 4: Unrealistic Targets
-
-**Problem:** "Become #1 in the world in 30 days"  
-**Why it fails:** Demoralizes team, loses credibility  
-**Fix:** Set challenging but achievable goals based on resources
-
-### Mistake 5: Missing the Bridge
-
-**Problem:** Vision and objectives feel disconnected  
-**Why it fails:** Team doesn't see how metrics prove vision  
-**Fix:** Use the bridging question to connect them explicitly
-
----
-
-## How This Feeds Into Next Workshops
-
-**Workshop 1 creates the foundation:**
-
-```
-Business Goals (Vision + Objectives)
-    ↓
-Workshop 2: Which user groups can help achieve these?
-    ↓
-Workshop 3: What drives those groups' behavior?
-    ↓
-Workshop 4: Which groups and drivers matter most?
-    ↓
-Workshop 5: Which features address top priorities?
-```
-
-Everything traces back to the goals you define here.
-
----
-
-## Tips for Success
-
-**DO:**
-- ✅ Start with aspiration before metrics
-- ✅ Use the bridging question explicitly
-- ✅ Make objectives truly SMART
-- ✅ Limit to 3-5 key objectives
-- ✅ Reference your Product Brief
-
-**DON'T:**
-- ❌ Skip the vision (just list metrics)
-- ❌ Accept vague objectives
-- ❌ Set unrealistic targets
-- ❌ Create too many objectives
-- ❌ Forget to connect vision to objectives
-
----
-
-## What's Next
-
-Workshop 2 identifies WHO can help you achieve these goals - your target groups. You'll create prioritized personas that become the foundation for understanding user psychology.
-
----
-
-## Key Takeaways
-
-✅ **Two levels of goals** - Vision (visionary/aspirational) + Strategic Objectives (measurable using SMART method)  
-✅ **Bridging question is critical** - "What will we observe when vision is realized?"  
-✅ **Strategic objectives using SMART method** - Specific, Measurable, Achievable, Relevant, Time-bound  
-✅ **3-5 objectives maximum** - Focus on what truly matters  
-✅ **Foundation for everything** - All workshops build from here
-
----
-
-[← Back to Lesson 3](lesson-03-five-workshops-overview.md) | [Next: Lesson 5 - Workshop 2: Target Groups →](lesson-05-workshop-2-target-groups.md)
-
-*Part of Module 05: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-05-workshop-2-target-groups.md b/docs/learn-wds/module-05-trigger-mapping/lesson-05-workshop-2-target-groups.md
deleted file mode 100644
index fa2bebc53..000000000
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-05-workshop-2-target-groups.md
+++ /dev/null
@@ -1,504 +0,0 @@
-# Lesson 4: Workshop 2 - Target Groups
-
-**Who Is Ensuring Our Success?**
-
----
-
-## The Core Question
-
-**Identify WHO out there in the world will make sure, with their use of the product, that you achieve your goals.**
-
-This question contains the entire chain of value creation. Let's break it down:
-
-### Breaking Down the Question
-
-**"WHO"**
-- Which representative from which ICP (Ideal Customer Profile)?
-- Specific behavioral and contextual profiles
-- Not demographics, but real people with real contexts
-
-**"Out there in the world"**
-- These are real people whose lives your product needs to touch
-- Not abstract user segments, but actual humans in specific situations
-- Your product must reach and impact their reality
-
-**"Will make sure"**
-- A product needs to be used, and used in the intended way
-- Usage alone isn't enough - it must be the right usage
-- Their behavior drives the outcome
-
-**"With their use of the product"**
-- The product must give more value than the pain of using it
-- If usage pain > value gained, they won't care
-- They need motivation to engage and continue
-
-**"That you achieve your goals"**
-- The use of the product must tie to measurable business goals
-- Without this connection, success isn't possible
-- This completes the chain: WHO → uses product → right way → creates value → achieves goals
-
-**This distinction is critical** and reflects throughout the entire Trigger Mapping methodology.
-
----
-
-## Overview
-
-Workshop 2 is where you identify the specific user groups whose behavior will drive your business success. You'll create detailed personas and prioritize them by strategic value.
-
-**Duration:** 20-25 minutes  
-**Format:** Conversational with Saga  
-**Output:** 3-5 prioritized personas with deep context
-
----
-
-## What You'll Do
-
-### 1. Identify Groups
-
-**Find the user types who can drive your success:**
-- Not demographics ("parents aged 30-45")
-- Behavioral and contextual profiles ("busy working parents juggling multiple schedules")
-- Real people out there in the world whose lives your product will touch
-- 3-5 distinct groups
-- Focus on who can help achieve your business goals through their product use
-
-**Key question:** "WHO out there in the world will make sure, with their use of the product, that we achieve our goals?"
-
-### 2. Create Personas
-
-**For each group, develop a rich profile:**
-- Name and context (their situation)
-- Goals and motivations (what they want)
-- Frustrations and fears (what they struggle with)
-- Behavioral patterns (how they act)
-
-**Go beyond demographics** - understand their world, their challenges, their aspirations.
-
-### 3. Prioritize
-
-**Rank groups by strategic value:**
-- Which groups have highest impact on business goals?
-- Which are most feasible to reach and serve?
-- Rank 1-N based on strategic importance
-
-**This ranking becomes critical** for the next workshops.
-
----
-
-## Key Questions Saga Asks
-
-### Identifying Groups
-
-- "Who are the people whose behavior will drive your business success?"
-- "What different user types could help you achieve your goals?"
-- "Looking at your objectives, who has the power to make them happen?"
-
-### Creating Personas
-
-- "Tell me about [group name]. What's their situation?"
-- "What's their context? What are they trying to accomplish?"
-- "What are their goals and motivations?"
-- "What frustrates them in their current situation?"
-- "What do they fear or want to avoid?"
-- "What behavioral patterns do they exhibit?"
-
-### Prioritizing
-
-- "Which group has the most potential impact on your top business goal?"
-- "Which group is most feasible to reach and serve effectively?"
-- "How would you rank these groups by strategic value?"
-- "Why does this group rank higher than the others?"
-
----
-
-## Generic Example
-
-### Target Group 1: Remote Team Leads
-
-**Context:**
-- Managing 5-10 distributed team members across time zones
-- Responsible for team performance and wellbeing
-- Limited visibility into individual struggles
-
-**Goals:**
-- Keep team productive and connected
-- Recognize and support struggling members early
-- Demonstrate effective leadership to management
-
-**Frustrations:**
-- Can't tell who's struggling until it's too late
-- Async communication creates gaps
-- Hard to build team culture remotely
-- Limited tools for monitoring team health
-
-**Fears:**
-- Team burnout without noticing
-- Missed deadlines due to unseen problems
-- Poor performance reviews
-- Losing top performers
-- Team becoming disconnected
-
-**Behavioral Patterns:**
-- Checks in with team daily
-- Monitors project progress closely
-- Seeks early warning signs
-- Values data-driven insights
-
-**Priority:** #1 (High impact + reachable + urgent pain)
-
----
-
-### Target Group 2: Solo Remote Workers
-
-**Context:**
-- Working alone from home without office structure
-- No team to provide accountability or connection
-- Struggling with boundaries and focus
-
-**Goals:**
-- Stay focused and productive
-- Maintain work-life boundaries
-- Feel connected to professional community
-- Advance career despite isolation
-
-**Frustrations:**
-- Constant distractions at home
-- Isolation and loneliness
-- Overworking without clear boundaries
-- Lack of professional development
-
-**Fears:**
-- Career stagnation
-- Burnout from overwork
-- Losing touch with industry
-- Being forgotten by management
-- Professional isolation
-
-**Behavioral Patterns:**
-- Seeks structure and routine
-- Values community connection
-- Struggles with self-discipline
-- Craves professional growth
-
-**Priority:** #2 (Large market + moderate impact)
-
----
-
-### Target Group 3: Remote Executives
-
-**Context:**
-- Overseeing multiple distributed teams
-- Responsible for organizational performance
-- Limited visibility into team dynamics
-
-**Goals:**
-- Ensure organizational productivity
-- Maintain company culture remotely
-- Make data-driven decisions
-- Retain top talent
-
-**Frustrations:**
-- Can't gauge team morale
-- Limited insights into team health
-- Difficult to spot problems early
-- Hard to maintain culture at scale
-
-**Fears:**
-- Organizational dysfunction
-- Mass turnover
-- Productivity decline
-- Cultural erosion
-- Competitive disadvantage
-
-**Behavioral Patterns:**
-- Relies on aggregated data
-- Values high-level insights
-- Needs quick decision-making tools
-- Focuses on organizational metrics
-
-**Priority:** #3 (High value but harder to reach)
-
----
-
-## Another Generic Example: Public Transport App
-
-This example shows how the same "customers" (travelers) have completely different needs based on their context.
-
-### Target Group 1: Daily Commuters
-
-**Context:**
-- Same route every workday (home ↔ work)
-- Time-sensitive schedule (must arrive on time)
-- Experienced with the system
-
-**Goals:**
-- Get to work/home efficiently
-- Minimize waiting time
-- Avoid delays and disruptions
-
-**Frustrations:**
-- Unexpected delays without warning
-- Crowded vehicles during rush hour
-- Unreliable schedules
-
-**Fears:**
-- Being late to work (professional consequences)
-- Missing important meetings
-- Unpredictable commute times
-
-**Behavioral Patterns:**
-- Checks app before leaving
-- Knows alternative routes
-- Values real-time updates
-- Wants predictability
-
-**Priority:** #1 (Highest volume, daily usage, urgent needs)
-
----
-
-### Target Group 2: Tourists
-
-**Context:**
-- Unfamiliar with the city and transit system
-- Exploring multiple destinations
-- No time pressure but limited trip duration
-
-**Goals:**
-- Navigate unfamiliar system confidently
-- Find best routes to attractions
-- Understand ticketing and payment
-- Maximize sightseeing time
-
-**Frustrations:**
-- Confusing route options
-- Unclear ticketing systems
-- Language barriers
-- Getting lost or taking wrong line
-
-**Fears:**
-- Wasting vacation time being lost
-- Looking foolish or incompetent
-- Missing key attractions
-- Overpaying for tickets
-
-**Behavioral Patterns:**
-- Plans routes in advance
-- Needs step-by-step guidance
-- Values visual/map-based navigation
-- Seeks reassurance at each step
-
-**Priority:** #2 (Growing market, different needs than commuters)
-
----
-
-### Target Group 3: Seniors
-
-**Context:**
-- May have mobility limitations
-- Less familiar with digital tools
-- Often traveling during off-peak hours
-- May need accessibility features
-
-**Goals:**
-- Travel safely and comfortably
-- Avoid physical strain (stairs, long walks)
-- Feel confident using the system
-- Maintain independence
-
-**Frustrations:**
-- Complicated digital interfaces
-- Lack of accessibility information
-- Physical barriers (stairs, gaps)
-- Small text and confusing layouts
-
-**Fears:**
-- Falling or getting injured
-- Being stranded or unable to get help
-- Losing independence
-- Embarrassment from not understanding technology
-
-**Behavioral Patterns:**
-- Prefers simple, clear interfaces
-- Values accessibility information
-- Needs larger text and clear instructions
-- May prefer human assistance options
-
-**Priority:** #3 (Important for accessibility, regulatory requirements)
-
----
-
-### Why This Example Works
-
-**Same product (public transport app), completely different needs:**
-
-**Commuters need:**
-- Real-time delay alerts
-- Quick route alternatives
-- Predictability and reliability
-- Speed and efficiency
-
-**Tourists need:**
-- Step-by-step navigation
-- Visual/map-based guidance
-- Ticketing help
-- Confidence and reassurance
-
-**Seniors need:**
-- Accessibility information
-- Simple, clear interfaces
-- Larger text and buttons
-- Safety and comfort features
-
-**The insight:** If you designed only for commuters (speed and efficiency), you'd fail tourists and seniors. If you designed only for tourists (detailed guidance), you'd frustrate commuters who want speed. Understanding these distinct groups allows you to prioritize features strategically.
-
----
-
-## Why Behavioral Profiles Matter
-
-### Not This (Demographics)
-
-"Parents aged 30-45 with household income $75K+"
-
-**Problem:** Doesn't tell you what drives behavior, what they need, or how to design for them.
-
-### This (Behavioral + Contextual)
-
-"Busy working parents juggling multiple kids' schedules, family dog care, and full-time jobs - constantly afraid of dropping the ball on family responsibilities"
-
-**Why it works:** You understand their world, their challenges, their fears. You can design for their actual needs.
-
----
-
-## Prioritization Criteria
-
-### Impact on Business Goals
-
-**Ask:**
-- Which group's behavior most directly drives our objectives?
-- Which group has the power to make our goals happen?
-- Which group's success equals our success?
-
-**Example:** Remote Team Leads rank #1 because each one brings 5-10 users (their team), has budget authority, and urgent pain.
-
-### Feasibility to Reach
-
-**Ask:**
-- Can we actually reach this group?
-- Do we have channels to communicate with them?
-- Can we serve them with our resources?
-- Is the market size sufficient?
-
-**Example:** Executives rank lower because they're harder to reach despite high value.
-
-### Urgency of Pain
-
-**Ask:**
-- How urgent is their problem?
-- Are they actively seeking solutions?
-- What's the cost of not solving this?
-
-**Example:** Team Leads have urgent pain (team burnout risk) vs Solo Workers have chronic pain (isolation).
-
----
-
-## What You Get from Workshop 2
-
-✅ **3-5 prioritized personas** with rich context  
-✅ **Deep understanding** of each group's world  
-✅ **Clear ranking** by strategic value  
-✅ **Foundation** for psychological mapping  
-✅ **Focus** for design efforts
-
----
-
-## Common Mistakes to Avoid
-
-### Mistake 1: Demographic Personas
-
-**Problem:** "Males 25-40 with college degrees"  
-**Why it fails:** Doesn't explain behavior or needs  
-**Fix:** Focus on context, goals, frustrations, fears
-
-### Mistake 2: Too Many Groups
-
-**Problem:** Identifying 10+ different user types  
-**Why it fails:** Dilutes focus, impossible to serve all  
-**Fix:** Limit to 3-5 most strategic groups
-
-### Mistake 3: No Prioritization
-
-**Problem:** "All groups are equally important"  
-**Why it fails:** Can't focus design efforts  
-**Fix:** Rank ruthlessly by strategic value
-
-### Mistake 4: Ignoring Feasibility
-
-**Problem:** Targeting groups you can't reach  
-**Why it fails:** Wastes resources on impossible goals  
-**Fix:** Balance impact with reachability
-
-### Mistake 5: Surface-Level Personas
-
-**Problem:** "They want to be productive"  
-**Why it fails:** Too generic to guide design  
-**Fix:** Dig deeper - what's their context? Their fears?
-
----
-
-## How This Feeds Into Next Workshops
-
-**Workshop 2 sets up the psychology mapping:**
-
-```
-Business Goals
-    ↓
-Target Groups (prioritized personas)
-    ↓
-Workshop 3: What drives each group's behavior?
-    ↓
-Workshop 4: Which drivers are most powerful?
-    ↓
-Workshop 5: Which features address top drivers?
-```
-
-The personas you create here become the foundation for understanding psychological drivers.
-
----
-
-## Tips for Success
-
-**DO:**
-- ✅ Focus on behavioral and contextual profiles
-- ✅ Dig deep into frustrations and fears
-- ✅ Prioritize ruthlessly (not everyone is #1)
-- ✅ Consider both impact and feasibility
-- ✅ Create personas you can actually design for
-
-**DON'T:**
-- ❌ Use demographic categories only
-- ❌ Create too many personas
-- ❌ Skip prioritization
-- ❌ Accept surface-level descriptions
-- ❌ Ignore feasibility constraints
-
----
-
-## What's Next
-
-Workshop 3 maps the psychological drivers for each persona - both what they want to achieve (positive drivers) and what they want to avoid (negative drivers). This is where you understand the psychology that drives behavior.
-
----
-
-## Key Takeaways
-
-✅ **Behavioral profiles, not demographics** - Context, goals, frustrations, fears  
-✅ **3-5 groups maximum** - Focus on strategic value  
-✅ **Prioritize ruthlessly** - Rank by impact + feasibility  
-✅ **Deep understanding** - Know their world, not just their age  
-✅ **Foundation for psychology** - These personas drive next workshops
-
----
-
-[← Back to Lesson 4](lesson-04-workshop-1-business-goals.md) | [Next: Lesson 6 - Workshop 3: Driving Forces →](lesson-06-workshop-3-driving-forces.md)
-
-*Part of Module 05: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-07-workshop-4-prioritization.md b/docs/learn-wds/module-05-trigger-mapping/lesson-07-workshop-4-prioritization.md
deleted file mode 100644
index 410be4515..000000000
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-07-workshop-4-prioritization.md
+++ /dev/null
@@ -1,313 +0,0 @@
-# Lesson 6: Workshop 4 - Prioritization
-
-**Rank What Matters Most**
-
----
-
-## Overview
-
-Workshop 4 is where you make strategic choices about what matters most. You'll rank your target groups and their psychological drivers to create clear priorities that guide all design decisions.
-
-**Duration:** 15-20 minutes  
-**Format:** Conversational with Saga  
-**Output:** Ranked target groups + ranked drivers for each group
-
----
-
-## What You'll Do
-
-### 1. Prioritize Target Groups
-
-**Rank your personas by strategic value:**
-- Which groups have highest business impact?
-- Which are most feasible to serve?
-- Rank 1-N based on strategic importance
-
-**This ranking determines** which groups get design focus first.
-
-### 2. Prioritize Driving Forces
-
-**For each group, rank their psychological drivers:**
-- Within each persona, which drivers are strongest?
-- Which have most emotional intensity?
-- Which would drive the most urgent action?
-- Rank by power to drive behavior
-
-**This ranking determines** which drivers become your feature scoring criteria.
-
----
-
-## Key Questions Saga Asks
-
-### For Target Groups
-
-- "Which target group will have the biggest impact on your top business goal?"
-- "Which group is most feasible to reach and serve effectively?"
-- "How would you rank all groups from highest to lowest strategic value?"
-- "Why does this group rank higher than the others?"
-- "What makes this group more strategic?"
-
-### For Driving Forces
-
-- "For [top persona], which driving forces are most powerful?"
-- "Which drivers have the most emotional intensity?"
-- "Which pain points cause the most urgent need to act?"
-- "Which positive drivers are strongest motivators?"
-- "How would you rank these drivers by their power to drive behavior?"
-
----
-
-## Generic Example
-
-### Target Group Rankings
-
-**1. Remote Team Leads** (Priority #1)
-- **Why #1:** High impact (each brings 5-10 users), reachable through professional channels, urgent pain (team burnout risk), budget authority
-- **Business impact:** Directly drives user acquisition and retention goals
-- **Feasibility:** Can reach through LinkedIn, management communities
-
-**2. Solo Remote Workers** (Priority #2)
-- **Why #2:** Large market size, moderate impact per user, chronic pain (less urgent than team leads)
-- **Business impact:** Volume play, good retention potential
-- **Feasibility:** Reachable through remote work communities
-
-**3. Remote Executives** (Priority #3)
-- **Why #3:** High value per user, but harder to reach, longer sales cycles
-- **Business impact:** Strategic accounts, high revenue potential
-- **Feasibility:** Difficult to reach, requires different approach
-
----
-
-### Driving Force Rankings: Remote Team Lead
-
-**Top 5 Prioritized Drivers:**
-
-**1. Fear of team burnout without noticing** (NEGATIVE)
-- **Why #1:** Most urgent, highest emotional intensity, constant worry
-- **Emotional core:** Guilt and responsibility for people's wellbeing
-- **Urgency:** Very high (active problem)
-- **Impact:** Directly threatens their success
-
-**2. Want to demonstrate effective leadership** (POSITIVE)
-- **Why #2:** Career driver, strong motivation, measurable outcome
-- **Emotional core:** Professional advancement and recognition
-- **Urgency:** High (ongoing career goal)
-- **Impact:** Affects long-term success
-
-**3. Fear of losing top performers** (NEGATIVE)
-- **Why #3:** Business impact, reflects on leadership, costly outcome
-- **Emotional core:** Failure and loss
-- **Urgency:** High (retention risk)
-- **Impact:** Damages team and reputation
-
-**4. Want to build strong team culture** (POSITIVE)
-- **Why #4:** Aspirational, important but less urgent
-- **Emotional core:** Pride in team cohesion
-- **Urgency:** Medium (long-term goal)
-- **Impact:** Enables other goals
-
-**5. Fear of missed deadlines** (NEGATIVE)
-- **Why #5:** Important but less emotionally intense than top fears
-- **Emotional core:** Professional embarrassment
-- **Urgency:** Medium (project-dependent)
-- **Impact:** Situational
-
----
-
-## Prioritization Criteria
-
-### For Target Groups
-
-**Business Impact:**
-- Which group's behavior most directly drives objectives?
-- Which group has power to make goals happen?
-- What's the multiplier effect? (e.g., team leads bring teams)
-
-**Feasibility:**
-- Can we actually reach this group?
-- Do we have channels to communicate?
-- Can we serve them with our resources?
-- Is market size sufficient?
-
-**Urgency of Pain:**
-- How urgent is their problem?
-- Are they actively seeking solutions?
-- What's the cost of not solving?
-
-**Strategic Fit:**
-- Does this align with company strengths?
-- Is this a sustainable advantage?
-- Does this open future opportunities?
-
-### For Driving Forces
-
-**Emotional Intensity:**
-- How strongly do they feel this?
-- Does this keep them up at night?
-- Is this a constant worry or occasional concern?
-
-**Urgency:**
-- How immediate is the need?
-- What triggers action on this?
-- Is this active pain or chronic discomfort?
-
-**Impact on Behavior:**
-- Would solving this drive adoption?
-- Would this prevent churn?
-- Does this create word-of-mouth?
-
-**Measurability:**
-- Can we tell if we've addressed this?
-- Can users articulate this need?
-- Is there observable behavior change?
-
----
-
-## Why Prioritization Matters
-
-### Without Prioritization
-
-**Problems:**
-- Try to serve everyone equally (serve no one well)
-- Build features that address minor drivers
-- Waste resources on low-impact groups
-- No clear focus for design
-
-**Result:** Mediocre product that doesn't deeply solve anyone's problems.
-
-### With Prioritization
-
-**Benefits:**
-- Focus design on highest-impact groups
-- Address most powerful psychological drivers
-- Allocate resources strategically
-- Create deep value for top segments
-
-**Result:** Product that deeply solves urgent problems for strategic users.
-
----
-
-## The Prioritization Cascade
-
-Once you have rankings, design decisions become clear:
-
-```
-Top Business Goal
-    ↓
-Top Target Group (who can best achieve this?)
-    ↓
-Top Psychological Driver (what drives them most?)
-    ↓
-Features that address this driver
-```
-
-**Example:**
-- **Goal:** Increase user retention to 70%
-- **Top Group:** Remote Team Leads (high retention potential)
-- **Top Driver:** Fear of team burnout without noticing
-- **Top Feature:** Daily team pulse check with burnout indicators
-- **Why:** Addresses their #1 fear, drives retention
-
----
-
-## What You Get from Workshop 4
-
-✅ **Clear strategic priorities** - Know what matters most  
-✅ **Ranked target groups** - Focus design efforts  
-✅ **Ranked drivers** - Know which psychology to address  
-✅ **Decision framework** - Guide all feature discussions  
-✅ **Data for scoring** - Foundation for Workshop 5
-
----
-
-## Common Mistakes to Avoid
-
-### Mistake 1: Everything Is Priority #1
-
-**Problem:** "All groups are equally important"  
-**Why it fails:** Dilutes focus, serves no one well  
-**Fix:** Make hard choices, rank ruthlessly
-
-### Mistake 2: Prioritizing by Ease
-
-**Problem:** "Let's focus on the easiest group first"  
-**Why it fails:** May not drive business goals  
-**Fix:** Balance impact with feasibility
-
-### Mistake 3: Ignoring Emotional Intensity
-
-**Problem:** Ranking drivers by logic, not emotion  
-**Why it fails:** Miss what actually drives behavior  
-**Fix:** Consider emotional intensity and urgency
-
-### Mistake 4: Too Many Top Priorities
-
-**Problem:** "Top 10 drivers are all critical"  
-**Why it fails:** Can't focus, spreads resources thin  
-**Fix:** Limit to top 5-7 drivers for scoring
-
-### Mistake 5: Forgetting Business Goals
-
-**Problem:** Prioritizing based on interesting psychology  
-**Why it fails:** Doesn't connect to business success  
-**Fix:** Always trace back to business objectives
-
----
-
-## How This Feeds Into Workshop 5
-
-**Workshop 4 creates the scoring criteria:**
-
-```
-Business Goals
-    ↓
-Target Groups (ranked)
-    ↓
-Driving Forces (ranked for each group)
-    ↓
-Top 5-7 Drivers (scoring criteria)
-    ↓
-Workshop 5: Score features against these drivers
-```
-
-The top-ranked drivers become the columns in your feature scoring matrix.
-
----
-
-## Tips for Success
-
-**DO:**
-- ✅ Make hard choices (not everything is #1)
-- ✅ Consider both impact and feasibility
-- ✅ Focus on emotional intensity
-- ✅ Limit to top 5-7 drivers for scoring
-- ✅ Trace priorities back to business goals
-
-**DON'T:**
-- ❌ Avoid making choices
-- ❌ Prioritize by ease alone
-- ❌ Ignore emotional intensity
-- ❌ Create too many "top" priorities
-- ❌ Forget the business objectives
-
----
-
-## What's Next
-
-Workshop 5 uses these priorities to systematically score features. Each feature gets rated against your top-ranked drivers, creating a data-driven roadmap.
-
----
-
-## Key Takeaways
-
-✅ **Ruthless prioritization** - Not everything can be #1  
-✅ **Two levels of ranking** - Groups first, then drivers  
-✅ **Strategic criteria** - Impact + feasibility + urgency  
-✅ **Top 5-7 drivers** - Become feature scoring criteria  
-✅ **Clear focus** - Guides all design decisions
-
----
-
-[← Back to Lesson 6](lesson-06-workshop-3-driving-forces.md) | [Next: Lesson 8 - Workshop 5: Feature Impact →](lesson-08-workshop-5-feature-impact.md)
-
-*Part of Module 05: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-08-workshop-5-feature-impact.md b/docs/learn-wds/module-05-trigger-mapping/lesson-08-workshop-5-feature-impact.md
deleted file mode 100644
index 8c698d5e6..000000000
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-08-workshop-5-feature-impact.md
+++ /dev/null
@@ -1,474 +0,0 @@
-# Lesson 7: Workshop 5 - Feature Impact
-
-**Score Features by Strategic Impact**
-
----
-
-## Overview
-
-Workshop 5 is where strategy becomes actionable roadmap. You'll systematically score your feature ideas against the prioritized psychological drivers from Workshop 4, creating a data-driven feature prioritization.
-
-**Duration:** 20-30 minutes  
-**Format:** Conversational with Saga  
-**Output:** Scored and ranked feature list
-
----
-
-## What You'll Do
-
-### 1. List Features
-
-**Brainstorm all potential features:**
-- Ideas from Product Brief
-- Stakeholder requests
-- Competitive features
-- User feedback
-- Team suggestions
-
-**Aim for:** 10-20 features to evaluate
-
-### 2. Score Each Feature
-
-**Rate against top 5-7 prioritized drivers:**
-- How well does this feature address each driver?
-- Use 0-3 scale for each driver
-- Be honest (don't inflate scores)
-
-**Scoring scale:**
-- **3** = Directly addresses this driver (core solution)
-- **2** = Significantly helps with this driver
-- **1** = Somewhat related to this driver
-- **0** = Doesn't address this driver
-
-### 3. Calculate Total Scores
-
-**Sum scores across all drivers:**
-- Add up the scores for each feature
-- Higher total = higher strategic impact
-- This becomes your prioritization data
-
-### 4. Rank and Create Roadmap
-
-**Sort features by total score:**
-- Highest scores = Phase 1 (highest impact)
-- High scores = Phase 2
-- Medium scores = Phase 3
-- Low scores = Backlog or cut
-
----
-
-## Key Questions Saga Asks
-
-### Listing Features
-
-- "What features are you considering for this product?"
-- "What ideas came up in your Product Brief?"
-- "What have stakeholders requested?"
-- "What do competitors offer that you're considering?"
-- "Are there any features you're unsure about?"
-
-### Scoring Each Feature
-
-- "How well does [feature] address [top driver]?"
-- "Does this feature create gain or reduce pain for this persona?"
-- "On a scale of 0-3, how much impact does this have on [driver]?"
-- "Why that score? What specifically does it address?"
-- "Is this a 2 or a 3? What's the difference?"
-
-### Validation
-
-- "Are there features that would score higher that we haven't listed?"
-- "Could we modify any features to increase their impact?"
-- "Do these scores match your intuition? If not, why?"
-- "Which features are you surprised scored high or low?"
-
----
-
-## Generic Example: Scoring Matrix
-
-### Context
-
-**Top 5 Prioritized Drivers (Remote Team Leads):**
-1. Fear of team burnout without noticing (NEGATIVE)
-2. Want to demonstrate effective leadership (POSITIVE)
-3. Fear of losing top performers (NEGATIVE)
-4. Want to build strong team culture (POSITIVE)
-5. Fear of missed deadlines (NEGATIVE)
-
-### Features to Score
-
-| Feature | Burnout Fear | Leadership | Retention | Culture | Deadlines | **Total** |
-|---------|-------------|------------|-----------|---------|-----------|-----------|
-| Daily team pulse check | 3 | 2 | 2 | 1 | 1 | **9** |
-| Team workload dashboard | 3 | 2 | 2 | 0 | 2 | **9** |
-| Recognition system | 1 | 1 | 2 | 3 | 0 | **7** |
-| 1-on-1 scheduling assistant | 2 | 2 | 1 | 1 | 0 | **6** |
-| Meeting summaries | 0 | 1 | 0 | 1 | 2 | **4** |
-| Async video updates | 1 | 1 | 0 | 2 | 0 | **4** |
-| Team chat | 0 | 0 | 1 | 2 | 0 | **3** |
-
-### Detailed Scoring Example
-
-**Feature: Daily Team Pulse Check**
-
-**Against "Fear of team burnout without noticing" (Score: 3)**
-- Directly addresses the fear
-- Provides daily visibility into team health
-- Early warning system for burnout indicators
-- Core solution to the problem
-
-**Against "Want to demonstrate effective leadership" (Score: 2)**
-- Provides data to show proactive management
-- Enables evidence-based leadership decisions
-- Significantly helps but not the primary purpose
-
-**Against "Fear of losing top performers" (Score: 2)**
-- Early warning helps prevent burnout-driven turnover
-- Identifies at-risk team members
-- Significantly helps with retention
-
-**Against "Want to build strong team culture" (Score: 1)**
-- Shows you care about team wellbeing
-- Somewhat related but not primary benefit
-
-**Against "Fear of missed deadlines" (Score: 1)**
-- Can identify capacity issues early
-- Somewhat helps but not main purpose
-
-**Total: 9 points** (Highest strategic impact)
-
----
-
-**Feature: Team Chat**
-
-**Against "Fear of team burnout" (Score: 0)**
-- Doesn't address burnout visibility
-- No impact on this driver
-
-**Against "Want to demonstrate leadership" (Score: 0)**
-- Doesn't provide leadership insights
-- No impact on this driver
-
-**Against "Fear of losing performers" (Score: 1)**
-- Helps with connection (minor retention factor)
-- Somewhat related
-
-**Against "Want to build team culture" (Score: 2)**
-- Enables team connection
-- Significantly helps with culture
-
-**Against "Fear of missed deadlines" (Score: 0)**
-- Doesn't address deadline management
-- No impact on this driver
-
-**Total: 3 points** (Low strategic impact for this persona)
-
----
-
-## Prioritized Roadmap
-
-Based on scores, create phases:
-
-### Phase 1: Highest Impact (8-10 points)
-- Daily team pulse check (9)
-- Team workload dashboard (9)
-
-**Why first:** Directly address top fears, highest strategic value
-
-### Phase 2: High Impact (6-7 points)
-- Recognition system (7)
-- 1-on-1 scheduling assistant (6)
-
-**Why second:** Good strategic value, support top priorities
-
-### Phase 3: Medium Impact (4-5 points)
-- Meeting summaries (4)
-- Async video updates (4)
-
-**Why third:** Some value but lower priority
-
-### Backlog: Low Impact (0-3 points)
-- Team chat (3)
-
-**Why backlog:** Doesn't address top strategic drivers for this persona
-
----
-
-## Why This Works
-
-### It's Strategic
-
-**Every score connects to:**
-- A prioritized psychological driver
-- A prioritized target group
-- A business goal
-
-**Not arbitrary** - traceable to strategy
-
-### It's Objective
-
-**Traditional approach:**
-"I think Feature A is more important"
-
-**Feature Impact approach:**
-"Feature A scores 9, Feature B scores 4"
-
-**Data beats opinions**
-
-### It's Defensible
-
-**When stakeholders ask "Why aren't we building X?"**
-
-**You can show:**
-1. Here's our Trigger Map
-2. Here are our top prioritized drivers
-3. Here's how features score against them
-4. Feature X scores lower than our current roadmap
-
-**Strategic reasoning, not politics**
-
-### It's Flexible
-
-**When priorities change:**
-- Update driver rankings
-- Re-score features
-- New roadmap emerges automatically
-
-**Strategy drives features, not the reverse**
-
----
-
-## Scoring Guidelines
-
-### Be Honest
-
-**Don't:**
-- Inflate scores to justify pet features
-- Score based on what you want to build
-- Let politics influence scoring
-
-**Do:**
-- Score based on actual impact
-- Accept that some features score low
-- Challenge your own assumptions
-
-### Be Specific
-
-**When scoring, ask:**
-- "How SPECIFICALLY does this address the driver?"
-- "What about this feature reduces that pain?"
-- "What evidence supports this score?"
-
-### Use the Full Scale
-
-**0-3 scale exists for a reason:**
-- **0** is okay - not everything addresses everything
-- **3** should be rare - only direct solutions
-- **1-2** is where most scores land
-
-### Consider Both Positive and Negative
-
-**Features can address:**
-- Negative drivers (reduce pain, prevent fears)
-- Positive drivers (enable goals, create gains)
-- Both (most powerful features)
-
----
-
-## Common Patterns
-
-### Pattern 1: High Scores Across Multiple Drivers
-
-**What it means:** High-leverage feature addressing multiple needs
-
-**Example:** Daily pulse check scores high on burnout fear, leadership goals, retention fear
-
-**Action:** Prioritize - strategically valuable
-
-### Pattern 2: High Score on Top Driver Only
-
-**What it means:** Laser-focused solution for most important need
-
-**Example:** Workload balancing scores 3 on burnout fear, low on others
-
-**Action:** Still high priority if that driver is #1
-
-### Pattern 3: Moderate Scores Across Many
-
-**What it means:** Nice-to-have that helps a bit with everything
-
-**Example:** Team chat scores 1-2 on multiple drivers
-
-**Action:** Lower priority - not solving urgent problems
-
-### Pattern 4: Low Scores Everywhere
-
-**What it means:** Feature doesn't connect to strategy
-
-**Example:** Fancy animations score 0-1 across all drivers
-
-**Action:** Cut it or deprioritize significantly
-
----
-
-## Beyond the Numbers
-
-### The Conversation Matters
-
-**Questions that emerge:**
-- "Why doesn't this feature score higher?"
-- "Could we modify it to address more drivers?"
-- "Are we missing a feature that would score higher?"
-- "Do these scores match our intuition?"
-
-**Insights from discussion:**
-- Features can be refined to increase impact
-- Missing features can be identified
-- Assumptions can be challenged
-- Strategy can be sharpened
-
-### Combining with Other Factors
-
-**Feature Impact = Strategic value**
-
-**Also consider:**
-- **Feasibility:** How hard to build?
-- **Dependencies:** What's required first?
-- **Market timing:** Competitive urgency?
-- **Resources:** Do we have capacity?
-
-**Combined formula:**
-```
-Priority = (Strategic Impact × Feasibility) + Urgency Bonus
-```
-
----
-
-## What You Get from Workshop 5
-
-✅ **Scored feature list** - Quantified strategic impact  
-✅ **Ranked roadmap** - Clear prioritization  
-✅ **Strategic justification** - Defensible decisions  
-✅ **Data-driven priorities** - Not opinions  
-✅ **Traceable reasoning** - Feature → Driver → Group → Goal
-
----
-
-## Common Mistakes to Avoid
-
-### Mistake 1: Inflating Scores
-
-**Problem:** Scoring pet features higher than deserved  
-**Why it fails:** Undermines the whole system  
-**Fix:** Be brutally honest, challenge yourself
-
-### Mistake 2: Scoring Too Many Features
-
-**Problem:** Trying to score 50+ features  
-**Why it fails:** Takes too long, loses focus  
-**Fix:** Start with 10-20 most viable features
-
-### Mistake 3: Ignoring Low Scores
-
-**Problem:** "But we still need to build it"  
-**Why it fails:** Wastes resources on low-impact features  
-**Fix:** Accept that some features should be cut
-
-### Mistake 4: Not Re-Scoring
-
-**Problem:** Never updating scores as you learn  
-**Why it fails:** Roadmap becomes stale  
-**Fix:** Re-score quarterly or when strategy shifts
-
-### Mistake 5: Forgetting Feasibility
-
-**Problem:** Prioritizing impossible features  
-**Why it fails:** Can't actually execute  
-**Fix:** Combine strategic score with feasibility
-
----
-
-## Using the Scored Feature List
-
-### For Sprint Planning
-
-**Each sprint:**
-- Reference the scored list
-- Focus on highest-impact features
-- Validate against Trigger Map
-- Make trade-offs based on strategy
-
-### For Stakeholder Communication
-
-**When presenting:**
-1. Show the Trigger Map
-2. Show the scoring matrix
-3. Show the prioritized list
-4. Explain the strategic reasoning
-
-**Stakeholders appreciate:**
-- Clear methodology
-- Traceable decisions
-- Strategic foundation
-- Data-driven approach
-
-### For Design Decisions
-
-**During design:**
-- Reference the scores
-- Focus on high-impact features first
-- Ensure design addresses the drivers
-- Validate against scoring
-
-**Example:**
-"We're designing the pulse check (score: 9). It needs to address burnout fear, so let's include early warning indicators and actionable suggestions."
-
----
-
-## The Complete Chain
-
-Now you have the full Trigger Mapping system:
-
-```
-Workshop 1: Business Goals (Vision + Objectives)
-    ↓
-Workshop 2: Target Groups (3-5 prioritized personas)
-    ↓
-Workshop 3: Driving Forces (positive + negative for each)
-    ↓
-Workshop 4: Prioritization (ranked groups and drivers)
-    ↓
-Workshop 5: Feature Impact (scored feature list)
-    ↓
-Strategic Roadmap (data-driven priorities)
-```
-
-**Every feature traces back to:**
-- A psychological driver
-- A target group  
-- A business goal
-
-**No orphaned features. No guesswork. Strategic clarity.**
-
----
-
-## What's Next
-
-You're ready to create your own Trigger Map. The tutorial walks through all 5 workshops step by step with Saga, and the next lessons cover how to create and use the visual Trigger Map.
-
----
-
-## Key Takeaways
-
-✅ **Systematic scoring** - Features rated 0-3 against prioritized drivers  
-✅ **Data-driven roadmap** - Total scores determine priorities  
-✅ **Strategically defensible** - Every decision traces to strategy  
-✅ **Flexible and updateable** - Re-score when strategy shifts  
-✅ **Beyond numbers** - The conversation reveals insights  
-✅ **Complete traceability** - Feature → Driver → Group → Goal
-
----
-
-[← Back to Lesson 7](lesson-07-workshop-4-prioritization.md) | [Next: Lesson 9 - Positive & Negative Drivers →](lesson-09-positive-negative-drivers.md)
-
-*Part of Module 05: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-09-positive-negative-drivers.md b/docs/learn-wds/module-05-trigger-mapping/lesson-09-positive-negative-drivers.md
deleted file mode 100644
index 13bf79202..000000000
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-09-positive-negative-drivers.md
+++ /dev/null
@@ -1,348 +0,0 @@
-# Lesson 4: Positive & Negative Drivers
-
-**The Psychology That Drives Behavior**
-
----
-
-## The Core Concept
-
-Every user has two types of motivations:
-
-**Positive Drivers (GAIN):**
-- What they want to achieve
-- Benefits they're seeking
-- Goals that pull them forward
-
-**Negative Drivers (PAIN):**
-- What they want to avoid
-- Problems they're trying to escape
-- Fears that push them to act
-
-**The key insight:** Both matter, but they work differently. Understanding both gives you the complete psychological picture.
-
----
-
-## Why Negative Drivers Are More Powerful
-
-Research in behavioral psychology consistently shows: **People work harder to avoid pain than to pursue gain.**
-
-This is called **loss aversion** - the psychological principle that losses feel roughly twice as painful as equivalent gains feel good.
-
-### Generic Examples
-
-**Scenario 1: Fitness App**
-
-**Positive driver:** "Want to look good for summer"
-- Motivating? Yes
-- Urgent? Not really
-- Action trigger: Weak (can start "next week")
-
-**Negative driver:** "Fear of health problems like my parent had"
-- Motivating? Extremely
-- Urgent? Yes
-- Action trigger: Strong (need to act now)
-
-**Which drives more sign-ups?** The fear.
-
-**Scenario 2: Project Management Tool**
-
-**Positive driver:** "Want to be more organized"
-- Nice to have
-- Can live without it
-- Low urgency
-
-**Negative driver:** "Fear of missing client deadline and losing contract"
-- Critical need
-- Can't afford to fail
-- High urgency
-
-**Which drives more conversions?** The fear.
-
----
-
-## How to Identify Positive Drivers
-
-Positive drivers are what users are moving TOWARD.
-
-### The Questions to Ask
-
-- What do they want to accomplish?
-- What positive outcomes are they seeking?
-- What would make their situation better?
-- What goals are they trying to achieve?
-- What benefits would they value?
-
-### Generic Examples Across Contexts
-
-**Professional Context:**
-- Want to advance in career
-- Want to be seen as competent leader
-- Want to deliver high-quality work
-- Want to build strong professional reputation
-- Want to learn new skills
-
-**Personal Context:**
-- Want to feel in control of their life
-- Want to spend quality time with family
-- Want to maintain healthy lifestyle
-- Want to feel accomplished
-- Want to reduce stress
-
-**Social Context:**
-- Want to be respected by peers
-- Want to contribute to community
-- Want to build meaningful relationships
-- Want to be seen as helpful
-- Want to belong to a group
-
-### Avoiding Surface-Level Statements
-
-**❌ Too vague:**
-- "Want to be productive"
-- "Want to save time"
-- "Want better results"
-
-**✅ Specific and meaningful:**
-- "Want to complete projects without last-minute panic"
-- "Want to leave work on time to have dinner with family"
-- "Want to deliver work that impresses stakeholders"
-
----
-
-## How to Identify Negative Drivers
-
-Negative drivers are what users are moving AWAY FROM.
-
-### The Questions to Ask
-
-- What problems are they trying to avoid?
-- What frustrates them about current situation?
-- What do they fear will happen?
-- What keeps them up at night?
-- What would be embarrassing or costly?
-
-### Generic Examples Across Contexts
-
-**Professional Context:**
-- Fear of missing important deadlines
-- Fear of looking incompetent to boss/clients
-- Fear of being passed over for promotion
-- Fear of making costly mistakes
-- Fear of falling behind in skills
-
-**Personal Context:**
-- Fear of burnout and health decline
-- Fear of missing important family moments
-- Fear of losing control of their life
-- Fear of financial instability
-- Fear of disappointing loved ones
-
-**Social Context:**
-- Fear of being judged by peers
-- Fear of letting team down
-- Fear of being excluded
-- Fear of conflict and confrontation
-- Fear of losing respect
-
-### The Emotional Core
-
-Negative drivers often have strong emotional components:
-
-- **Shame:** "What will people think?"
-- **Guilt:** "I'm letting people down"
-- **Anxiety:** "What if this goes wrong?"
-- **Embarrassment:** "This makes me look bad"
-- **Fear:** "I could lose something important"
-
-**These emotions drive urgent action.**
-
----
-
-## Balancing Both Types
-
-The most powerful understanding comes from mapping BOTH:
-
-### Generic Example: Email Management Tool
-
-**Positive Drivers:**
-- Want to feel organized and in control
-- Want to respond thoughtfully to important messages
-- Want to maintain professional communication standards
-- Want to reduce mental clutter
-
-**Negative Drivers:**
-- Fear of missing urgent client emails
-- Fear of looking unprofessional with late responses
-- Fear of important messages getting buried
-- Fear of constant email anxiety disrupting focus
-
-**The design insight:**
-- Positive drivers suggest: Clean interface, thoughtful organization
-- Negative drivers suggest: Urgent message alerts, priority inbox, "nothing missed" confidence
-
-**Both inform the solution, but negative drivers create urgency to adopt.**
-
----
-
-## Common Patterns
-
-### Pattern 1: Professional Reputation
-
-**Positive:** Want to be seen as competent  
-**Negative:** Fear of looking incompetent
-
-**Design implication:** Features that help users look good and avoid embarrassment
-
-### Pattern 2: Time Management
-
-**Positive:** Want to be productive  
-**Negative:** Fear of wasting time or missing deadlines
-
-**Design implication:** Time-saving features + deadline protection
-
-### Pattern 3: Social Connection
-
-**Positive:** Want to build relationships  
-**Negative:** Fear of isolation or being left out
-
-**Design implication:** Connection features + FOMO prevention
-
-### Pattern 4: Control & Autonomy
-
-**Positive:** Want to feel in control  
-**Negative:** Fear of chaos and overwhelm
-
-**Design implication:** Organization tools + anxiety reduction
-
----
-
-## How to Use This in Design
-
-### For Feature Prioritization
-
-Features that address negative drivers often rank higher because they solve urgent problems.
-
-**Generic example:**
-- Feature A: "Nice dashboard for tracking progress" (positive driver)
-- Feature B: "Alert system for missed critical tasks" (negative driver)
-- **Which is more urgent?** Feature B (prevents pain)
-
-### For Messaging & Marketing
-
-**Positive-focused messaging:**
-- "Achieve your goals"
-- "Be more productive"
-- "Build better habits"
-
-**Negative-focused messaging:**
-- "Never miss another deadline"
-- "Stop the chaos"
-- "Avoid costly mistakes"
-
-**Which converts better?** Usually negative-focused (addresses urgent pain)
-
-### For User Onboarding
-
-**Show value by addressing both:**
-1. Acknowledge the pain (negative driver)
-2. Show how you solve it
-3. Highlight the positive outcome
-
-**Generic example:**
-"Tired of missing important emails? (negative)  
-Our priority inbox ensures nothing slips through. (solution)  
-Respond confidently and maintain your professional reputation. (positive)"
-
----
-
-## Workshop 3 in Practice
-
-When you're in Workshop 3 with Saga, you'll work through each persona systematically:
-
-**For each persona:**
-1. List 3-5 positive drivers
-2. List 3-5 negative drivers
-3. Identify which are strongest
-4. Note emotional intensity
-
-**Saga will challenge you:**
-- "Is that specific enough?"
-- "What's the emotional core of that fear?"
-- "Why does that matter to them?"
-- "What would happen if they don't solve this?"
-
-**Your job:** Dig deeper than surface-level wants. Find the real psychological drivers.
-
----
-
-## Common Mistakes to Avoid
-
-### Mistake 1: Only Mapping Positive Drivers
-
-**Problem:** You miss the urgent pain that drives adoption  
-**Solution:** Always map both types
-
-### Mistake 2: Generic "Wants" Statements
-
-**Problem:** "Want to be productive" doesn't guide design  
-**Solution:** Be specific about context and outcomes
-
-### Mistake 3: Ignoring Emotional Intensity
-
-**Problem:** All drivers seem equal  
-**Solution:** Identify which have strongest emotional pull
-
-### Mistake 4: Assuming Positive = Good, Negative = Bad
-
-**Problem:** Negative drivers feel uncomfortable to discuss  
-**Solution:** Embrace them - they're often more powerful motivators
-
-### Mistake 5: Listing Features Instead of Psychology
-
-**Problem:** "Want a calendar feature"  
-**Solution:** "Want to never miss family commitments due to work chaos"
-
----
-
-## The Power of This Approach
-
-When you map both positive and negative drivers:
-
-✅ **Complete psychological picture** - Understand full motivation  
-✅ **Better feature prioritization** - Know what's urgent vs nice-to-have  
-✅ **Stronger messaging** - Address real pain points  
-✅ **Higher conversion** - Solve urgent problems  
-✅ **Better retention** - Deliver on both gain and pain reduction
-
----
-
-## What You'll Learn Next
-
-The next lesson shows you how to create the visual Trigger Map - the one-page strategic document that connects all these layers and becomes your team's reference for every design decision.
-
----
-
-## Key Takeaways
-
-✅ **Two types of drivers** - Positive (gain) and Negative (pain)  
-✅ **Negative is more powerful** - Loss aversion drives urgent action  
-✅ **Map both for each persona** - Complete psychological picture  
-✅ **Be specific** - Avoid generic wants, find emotional core  
-✅ **Use in design** - Negative drivers often indicate highest-priority features
-
----
-
-## Practice Exercise
-
-Think about a product you use regularly. Identify:
-
-1. What positive outcomes do you seek from it?
-2. What negative outcomes are you trying to avoid?
-3. Which driver is stronger for you?
-4. How does the product address both?
-
----
-
-[← Back to Lesson 8](lesson-08-workshop-5-feature-impact.md) | [Next: Lesson 10 - Visual Trigger Map →](lesson-10-visual-trigger-map.md)
-
-*Part of Module 05: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/tutorial-05b-value-trigger-chain.md b/docs/learn-wds/module-05-trigger-mapping/tutorial-05b-value-trigger-chain.md
deleted file mode 100644
index e0f348abd..000000000
--- a/docs/learn-wds/module-05-trigger-mapping/tutorial-05b-value-trigger-chain.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# Tutorial 05B: Create a Slim Trigger Map
-
-> **Note:** This tutorial previously covered "Value Trigger Chains (VTC)" which has been replaced by the simpler concept of a Slim Trigger Map — define one business goal, one target group, and their key driving forces. The core process is the same.
-
-**Quick strategic validation for focused user journeys**
-
----
-
-## Overview
-
-This tutorial walks you through creating a Slim Trigger Map - a lightweight, streamlined version of Trigger Mapping. Perfect for when you need quick strategic validation or are working with a single, focused user journey.
-
-**Time:** 15-20 minutes  
-**Prerequisites:** Module 04 completed (Product Brief created)  
-**What you'll create:** Single-chain map from business goal to user trigger
-
----
-
-## When to Use This Approach
-
-**Value Trigger Chain is ideal for:**
-- ✅ Smaller features or iterations
-- ✅ Single user journey focus
-- ✅ Quick strategic validation
-- ✅ Early-stage exploration
-- ✅ Time-constrained situations
-
-**Use Full Trigger Mapping instead if:**
-- ❌ Multiple user groups to consider
-- ❌ Complex feature prioritization needed
-- ❌ Long-term strategic planning
-- ❌ Need defensible stakeholder justification
-
-**Not sure which to use?** See [Lesson 2: Heritage & Evolution](lesson-02-heritage-evolution.md#two-approaches-choose-your-depth)
-
----
-
-## Before You Start
-
-### What You Need
-
-- ✅ Completed Product Brief (from Tutorial 04)
-- ✅ WDS installed and Saga activated
-- ✅ 15-20 minutes of focused time
-- ✅ One clear user journey in mind
-
-### What to Expect
-
-**Saga will:**
-- Guide you through one streamlined workshop
-- Ask focused questions
-- Help you create a single value chain
-- Document the essential connections
-
-**You will:**
-- Define one strategic objective
-- Identify one primary user
-- Map their key driver
-- Connect to specific trigger moment
-
----
-
-## The Value Trigger Chain Workshop
-
-### Starting the Workshop
-
-**In your IDE, activate Saga:**
-
-```
-@saga I want to create a Value Trigger Chain for [brief description of feature/journey]. Let's do the lightweight version.
-```
-
----
-
-## Step 1: Define Your Strategic Objective (3 minutes)
-
-### What Saga Will Ask
-
-**Focus on one measurable goal:**
-- "What's the one strategic objective this feature/journey needs to achieve?"
-- "How will you measure success?"
-- "By when do you need to achieve this?"
-
-### Your Task
-
-**Pick ONE objective from your Product Brief:**
-- Must be specific and measurable (using SMART method)
-- Should be achievable through this single journey
-- Clear timeframe
-
-**Example:**
-"Increase trial-to-paid conversion to 25% by Q3 2024"
-
-**Not:**
-"Improve user experience and increase revenue and build brand awareness"
-(Too many objectives - use Full Trigger Mapping for this)
-
----
-
-## Step 2: Identify Your Primary User (3 minutes)
-
-### What Saga Will Ask
-
-**WHO will make this happen through their product use:**
-- "Who is the ONE user type whose behavior drives this objective?"
-- "What's their context and situation?"
-- "What are they trying to accomplish?"
-
-### Your Task
-
-**Define one primary user:**
-- Behavioral profile, not demographics
-- Specific context
-- Clear connection to your objective
-
-**Example:**
-"Startup founders evaluating project management tools during their first team expansion (3-10 people). They're overwhelmed by options and need to make a decision quickly before their team grows chaotic."
-
-**Why this works:**
-- Specific behavioral context
-- Clear situation
-- Connects to trial-to-paid conversion (they need to decide)
-
----
-
-## Step 3: Map the Key Driver (4 minutes)
-
-### What Saga Will Ask
-
-**What's the ONE psychological driver:**
-- "What's the strongest driver for this user in this journey?"
-- "Is it positive (what they want) or negative (what they fear)?"
-- "Why does this matter emotionally to them?"
-
-### Your Task
-
-**Identify the dominant driver:**
-- Usually negative drivers are stronger (loss aversion)
-- Must be specific to this journey
-- Should have emotional intensity
-
-**Example:**
-**Negative Driver:** "Fear of making the wrong tool choice and wasting team's time learning a system they'll have to abandon"
-
-**Why this works:**
-- Specific fear (not generic "want good tool")
-- Emotional (embarrassment, wasted time, team frustration)
-- Directly relevant to trial-to-paid decision
-
----
-
-## Step 4: Define the Trigger Moment (4 minutes)
-
-### What Saga Will Ask
-
-**When does this driver activate:**
-- "What specific moment triggers this driver?"
-- "What's happening in their world when they feel this most strongly?"
-- "What prompts them to take action?"
-
-### Your Task
-
-**Identify the trigger moment:**
-- Specific situation or event
-- When the driver becomes urgent
-- What makes them act NOW
-
-**Example:**
-**Trigger Moment:** "When their team asks 'Which tool are we using?' for the third time in a week, and they realize they're losing credibility by not having made a decision"
-
-**Why this works:**
-- Specific moment (third time asked)
-- Emotional trigger (losing credibility)
-- Creates urgency (need to decide now)
-
----
-
-## Step 5: Connect to Your Solution (3 minutes)
-
-### What Saga Will Ask
-
-**How does your feature address this:**
-- "What does your feature do at this trigger moment?"
-- "How does it reduce the pain or enable the gain?"
-- "Why is this better than alternatives?"
-
-### Your Task
-
-**Define the value connection:**
-- What your feature does
-- How it addresses the driver
-- Why it works at this trigger moment
-
-**Example:**
-**Solution:** "Guided comparison tool that shows them exactly how our features map to their team size and use case, with a 'Decision Confidence Score' that validates their choice"
-
-**Why this works:**
-- Addresses the fear (reduces wrong-choice risk)
-- Provides validation (confidence score)
-- Specific to the trigger moment (helps them decide NOW)
-
----
-
-## Your Value Trigger Chain
-
-### The Complete Chain
-
-```
-Strategic Objective
-    ↓
-"Increase trial-to-paid conversion to 25% by Q3 2024"
-    ↓
-Primary User
-    ↓
-"Startup founders evaluating tools during first team expansion"
-    ↓
-Key Driver (Negative)
-    ↓
-"Fear of making wrong choice and wasting team's time"
-    ↓
-Trigger Moment
-    ↓
-"When team asks 'which tool?' for 3rd time - losing credibility"
-    ↓
-Solution
-    ↓
-"Guided comparison tool with Decision Confidence Score"
-    ↓
-Result: User converts because fear is reduced, decision validated
-```
-
----
-
-## Validating Your Chain
-
-### The Control Questions
-
-Ask yourself:
-
-**1. Is the connection clear?**
-- Can you trace from objective → user → driver → trigger → solution?
-- Does each step logically lead to the next?
-
-**2. Is this the strongest path?**
-- Is this the PRIMARY user for this objective?
-- Is this their STRONGEST driver?
-- Is this the most URGENT trigger moment?
-
-**3. Does your solution actually work?**
-- Does it address the driver at the trigger moment?
-- Is it better than alternatives?
-- Why should they care?
-
-**If any answer is weak:** Revisit that step and strengthen the connection.
-
----
-
-## Generic Example: Fitness App
-
-### The Chain
-
-**Objective:** "Achieve 1,000 daily active users by Q4 2024"
-
-**Primary User:** "Busy professionals who want to exercise but struggle with consistency"
-
-**Key Driver (Negative):** "Fear of losing fitness progress when work gets hectic"
-
-**Trigger Moment:** "When they miss their third workout in a row and feel guilty"
-
-**Solution:** "3-minute 'Streak Saver' workout that counts toward their weekly goal"
-
-**Why it works:**
-- Addresses the fear (prevents losing progress)
-- Works at trigger moment (when they've missed workouts)
-- Low barrier (only 3 minutes)
-- Maintains streak (reduces guilt)
-
----
-
-## What You Get
-
-✅ **Clear strategic connection** - Objective to solution in one chain  
-✅ **Focused validation** - One user, one driver, one trigger  
-✅ **Quick decision-making** - Is this feature worth building?  
-✅ **Defensible reasoning** - Traceable logic  
-✅ **15-20 minute investment** - Fast strategic check
-
----
-
-## When to Expand to Full Trigger Mapping
-
-**Consider the full process if you discover:**
-- Multiple user types are equally important
-- Several drivers compete for priority
-- You need to score many features
-- Stakeholders need comprehensive justification
-- The project is more complex than initially thought
-
-**The Value Trigger Chain is a starting point.** If it reveals complexity, upgrade to Full Trigger Mapping.
-
----
-
-## Common Mistakes to Avoid
-
-### Mistake 1: Too Many Objectives
-
-**Problem:** Trying to achieve 5 different goals in one chain  
-**Why it fails:** Dilutes focus, unclear success criteria  
-**Fix:** Pick ONE objective, use Full Trigger Mapping for multiple goals
-
-### Mistake 2: Generic User
-
-**Problem:** "All users" or "people who want X"  
-**Why it fails:** Can't identify specific drivers or triggers  
-**Fix:** Get specific about context and situation
-
-### Mistake 3: Vague Driver
-
-**Problem:** "Want better experience"  
-**Why it fails:** Not actionable, no emotional core  
-**Fix:** Find the specific fear or desire with emotional intensity
-
-### Mistake 4: Missing the Trigger
-
-**Problem:** No specific moment when driver activates  
-**Why it fails:** Don't know when to intervene  
-**Fix:** Identify the exact situation that creates urgency
-
-### Mistake 5: Solution Doesn't Connect
-
-**Problem:** Feature doesn't actually address the driver  
-**Why it fails:** Won't drive the objective  
-**Fix:** Ensure solution reduces pain or enables gain at trigger moment
-
----
-
-## Tips for Success
-
-**DO:**
-- ✅ Focus on ONE clear path
-- ✅ Be specific at every step
-- ✅ Find the emotional core
-- ✅ Validate the connections
-- ✅ Keep it simple
-
-**DON'T:**
-- ❌ Try to map everything (use Full Trigger Mapping for that)
-- ❌ Accept vague or generic statements
-- ❌ Skip the trigger moment
-- ❌ Forget to validate the chain
-- ❌ Overcomplicate it
-
----
-
-## What's Next
-
-### If This Validated Your Feature
-
-**Move to scenario design:**
-- Use this chain to inform your scenario
-- Design for the trigger moment
-- Address the driver directly
-- Measure against the objective
-
-### If This Revealed Complexity
-
-**Upgrade to Full Trigger Mapping:**
-- [Tutorial 05: Create Your Trigger Map](tutorial-05.md)
-- Map multiple users and drivers
-- Score features systematically
-- Build comprehensive strategy
-
-### If This Showed a Problem
-
-**Revisit your Product Brief:**
-- Is the objective right?
-- Is this the right user?
-- Should you pivot the feature?
-- Do you need more research?
-
----
-
-## Key Takeaways
-
-✅ **Lightweight but strategic** - Quick validation with clear reasoning  
-✅ **One clear path** - Objective → User → Driver → Trigger → Solution  
-✅ **15-20 minutes** - Fast strategic check  
-✅ **Know when to expand** - Upgrade to Full Trigger Mapping when needed  
-✅ **Traceable logic** - Every step connects to the next
-
----
-
-[← Back to Lesson 2](lesson-02-heritage-evolution.md) | [Full Trigger Mapping Tutorial →](tutorial-05.md)
-
-*Part of Module 05: Trigger Mapping*
diff --git a/docs/learn-wds/module-06-platform-architecture/tutorial-06.md b/docs/learn-wds/module-06-platform-architecture/tutorial-06.md
deleted file mode 100644
index 6283100a8..000000000
--- a/docs/learn-wds/module-06-platform-architecture/tutorial-06.md
+++ /dev/null
@@ -1,358 +0,0 @@
-# Tutorial 06: Platform Architecture
-
-**Let Idunn translate your product vision into technical architecture - you speak design, she speaks code**
-
----
-
-## Overview
-
-You've designed the experience. Now you need the technical foundation to make it real. But you're a designer, not a developer - how do you define databases, APIs, and system architecture?
-
-**You don't.** Idunn does.
-
-You just describe your product in design language. Idunn translates it into Platform PRD.
-
-**Time:** 30-45 minutes  
-**Prerequisites:** Module 05 completed (Trigger Map ready)  
-**What you'll create:** Platform PRD & Architecture Document
-
----
-
-## What You'll Learn
-
-- What a Platform PRD is (and why it matters)
-- How to describe your product's technical needs without being technical
-- How Idunn helps you think through platform decisions
-- What questions she'll ask (so you're not surprised)
-
----
-
-## What is Platform PRD?
-
-**Platform PRD** = The technical blueprint developers need to build your product.
-
-It includes:
-- **System Architecture:** How the pieces fit together
-- **Data Models:** What information needs to be stored
-- **APIs & Integrations:** How systems talk to each other
-- **Technical Requirements:** Performance, security, scalability
-
-**Your superpower:** You don't need to know how to write this. You just need to know **what your product does**.
-
----
-
-## Step 1: Understand Your Role (2 min)
-
-**Your job as designer:**
-- Describe what users need to do
-- Explain what data they create/view/edit
-- Identify third-party services you want (payments, auth, analytics)
-- Share any technical constraints you know about
-
-**Idunn's job:**
-- Ask clarifying questions about technical needs
-- Translate your product into architecture decisions
-- Document data models, APIs, system diagrams
-- Flag technical risks and recommend solutions
-
-**You bring product knowledge. She brings technical expertise.**
-
----
-
-## What to Expect: The Conversation
-
-**Here's how a real session with Idunn looks:**
-
-### Idunn's Opening
-```
-Hi! I'm Idunn, your technical architect agent.
-
-I see you've completed your Product Brief and Trigger Map. 
-Let's translate your product vision into technical architecture.
-
-I'll ask questions about your product in design language. 
-You answer naturally - no need for technical terms.
-
-Ready? Let's start with the basics.
-```
-
-### Example Questions Idunn Asks
-
-**About Your Product:**
-```
-Idunn: "What's the core thing users create or manage in your product?"
-
-You: "Users create weekly schedules for family dog care - walks, 
-      feeding, vet appointments, etc."
-
-Idunn: "Got it. Do these schedules need to be:
-        - Private (only one family)?
-        - Shared (multiple families can see each other's)?
-        - Collaborative (family members edit together)?"
-
-You: "Collaborative - all family members edit the same schedule."
-
-Idunn: "Perfect. That tells me we need real-time sync and user permissions."
-```
-
-**About Users & Authentication:**
-```
-Idunn: "How do you envision users signing up?"
-
-You: "Email and password should work. Google login would be nice too."
-
-Idunn: "Great! Should users be able to:
-        - Invite family members?
-        - Have different roles (admin vs. regular member)?"
-
-You: "Yes! The person who creates the schedule is the admin. 
-      They can invite family and remove members if needed."
-
-Idunn: "Understood. I'll design a role-based permission system."
-```
-
-**About Data & Features:**
-```
-Idunn: "You mentioned tasks like 'walks' and 'feeding'. 
-        What information does each task need?"
-
-You: "Task title, who's assigned, what time/date, and whether 
-      it's done or not."
-
-Idunn: "Should tasks repeat? Like 'walk dog every morning'?"
-
-You: "Oh yes! That would be super helpful."
-
-Idunn: "I'll add recurring task patterns. Should we notify 
-        the assigned person before the task is due?"
-
-You: "Definitely!"
-
-Idunn: "I'll include a notification system in the architecture."
-```
-
-### Built-in Guidance from Idunn
-
-**When you're unsure:**
-```
-You: "I'm not sure if we need that..."
-
-Idunn: "No problem! Let me explain the trade-offs:
-
-       WITH real-time sync:
-       ✅ Family sees changes instantly
-       ✅ No confusion about who's doing what
-       ❌ Slightly more complex to build
-       ❌ Requires internet connection
-
-       WITHOUT real-time sync:
-       ✅ Simpler to build
-       ✅ Can work offline
-       ❌ Family might have outdated info
-       ❌ Conflicts if two people edit at once
-
-       For family coordination, real-time is usually worth it.
-       What feels right for your users?"
-```
-
-**When technical terms come up:**
-```
-Idunn: "I'll use a REST API for communication between app and server."
-
-You: "What's a REST API?"
-
-Idunn: "Think of it as a waiter in a restaurant:
-        - Your app (customer) asks for something
-        - The API (waiter) takes the request to the server (kitchen)
-        - The server prepares the response (food)
-        - The API brings it back to your app
-
-        You don't need to know how it works - just that it's 
-        the standard way apps communicate with databases."
-```
-
-**When prioritizing features:**
-```
-Idunn: "Based on your Product Brief, I see you want:
-        - Task scheduling (core)
-        - Notifications (important)
-        - Calendar sync (nice-to-have)
-        - Vet appointment reminders (nice-to-have)
-
-        For the Platform PRD, I'll design all of these.
-        
-        But I'll flag which are 'MVP' (must-have) vs. 
-        'Phase 2' (add later) so developers know priorities.
-        
-        Does that split make sense?"
-
-You: "Yes, but actually calendar sync is really important."
-
-Idunn: "Got it - moving calendar sync to MVP. I'll update the 
-        architecture to prioritize that integration."
-```
-
-### What Idunn Creates While You Talk
-
-As you answer, Idunn is:
-- ✍️ Documenting data models ("Task" entity with fields)
-- 🏗️ Sketching system architecture (app, API, database, notifications)
-- 🔐 Planning authentication flow (login, permissions, roles)
-- 🔗 Identifying integrations (Google Calendar, email notifications)
-- ⚠️ Flagging technical risks ("Real-time sync needs WebSocket support")
-
-**You'll see progress updates:**
-```
-Idunn: "✅ Data model drafted - 3 main entities (User, Family, Task)
-        ✅ Authentication flow designed - Social login + email
-        🔄 Working on notification system architecture..."
-```
-
----
-
-## Step 2: Activate Idunn (2 min)
-
-```
-@idunn
-
-I'm ready to create the Platform PRD for [Your Product Name].
-
-I have:
-- Product Brief (done)
-- Trigger Map (done)
-
-Please help me define the technical architecture.
-```
-
-**Idunn will respond** and start asking questions about your product's technical needs.
-
----
-
-## Step 3: Answer Idunn's Questions (20-30 min)
-
-Idunn will guide you through understanding your platform needs. She asks questions like:
-
-### About Data
-- "What information do users create?"
-- "What needs to be saved vs. temporary?"
-- "Do users share data with each other?"
-
-**Example answers (you don't need technical terms):**
-- "Users create weekly schedules for dog care tasks"
-- "Schedules need to be saved permanently and shared with family"
-- "Each task has: title, assigned person, date, completion status"
-
-### About Authentication
-- "How do users log in?"
-- "Do you want social login (Google, Apple)?"
-- "Are there different user roles?"
-
-**Example answers:**
-- "Email + password, plus Google login"
-- "Two roles: Admin (can assign tasks) and Family Member (can complete tasks)"
-
-### About Integrations
-- "Do you need notifications?"
-- "Payment processing?"
-- "Calendar sync?"
-
-**Example answers:**
-- "Yes! Send reminders before tasks are due"
-- "No payments needed"
-- "Would be nice to sync with phone calendar"
-
-### About Performance & Scale
-- "How many users do you expect?"
-- "Any real-time features?"
-- "Mobile app or web?"
-
-**Idunn translates this into:**
-- Database schemas
-- API specifications
-- System architecture diagrams
-- Technical requirements docs
-
----
-
-## Step 4: Review & Refine (10 min)
-
-Idunn will show you the Platform PRD. Don't panic if it looks technical - you don't need to understand every detail.
-
-**What to check:**
-- ✅ Does it capture all the features you designed?
-- ✅ Are the user roles correct?
-- ✅ Did she understand your data needs?
-- ✅ Are integrations you wanted included?
-
-**Ask questions like:**
-- "Can you explain this part in design terms?"
-- "How does this support [specific feature]?"
-- "What if we want to add [feature] later?"
-
-**Idunn will clarify** and update the PRD until it's right.
-
----
-
-## Step 5: Save Your Platform PRD (2 min)
-
-Idunn will save the Platform PRD to your project:
-
-```
-/docs/3-platform-prd/
-├── 01-platform-architecture.md
-├── 02-data-models.md
-├── 03-api-specifications.md
-└── 04-technical-constraints.md
-```
-
-**You now have** everything developers need to understand the technical foundation.
-
----
-
-## Common Questions
-
-**Q: Do I need to learn technical terms?**  
-**A:** No. Speak in design/product language. Idunn translates.
-
-**Q: What if I don't know the answer to her questions?**  
-**A:** Say so! Idunn will explain the implications and suggest options.
-
-**Q: Can developers change the architecture later?**  
-**A:** Yes. This is a starting point. Developers may refine it.
-
-**Q: Do I need to review APIs and database schemas?**  
-**A:** Only if you want to. Focus on whether it supports your design.
-
----
-
-## What You've Accomplished
-
-🎉 **You just created a Platform PRD** - something that usually requires technical architects!
-
-**You didn't need to:**
-- ❌ Learn database design
-- ❌ Understand API protocols
-- ❌ Draw system architecture diagrams
-- ❌ Write technical specifications
-
-**You just:**
-- ✅ Described your product in design terms
-- ✅ Answered Idunn's questions
-- ✅ Reviewed to ensure it supports your design
-
-**That's the WDS superpower:** You focus on design. The agents handle the technical translation.
-
----
-
-## Next Steps
-
-**Ready to design the UX?**  
-→ [Module 08: Initialize Scenario](../module-08-initialize-scenario/tutorial-08.md)
-
-**Want to skip Platform PRD for now?**  
-You can come back to this after UX design if you prefer.
-
----
-
-**Pro Tip:** Even if you're not building the platform yourself, having this PRD helps you communicate with developers and make informed design decisions. You'll know what's technically feasible without becoming a developer yourself.
-
diff --git a/docs/learn-wds/module-08-initialize-scenario/tutorial-08.md b/docs/learn-wds/module-08-initialize-scenario/tutorial-08.md
deleted file mode 100644
index 663ff05da..000000000
--- a/docs/learn-wds/module-08-initialize-scenario/tutorial-08.md
+++ /dev/null
@@ -1,521 +0,0 @@
-# Tutorial 08: Initialize Your Scenario
-
-**Hands-on guide to starting a design scenario with the 5 essential questions**
-
----
-
-## Overview
-
-This tutorial walks you through initializing a scenario - the moment where strategic thinking meets design execution.
-
-**Time:** 30-45 minutes  
-**Prerequisites:** Trigger map completed  
-**What you'll create:** A fully initialized scenario ready for sketching
-
----
-
-## What You'll Learn
-
-- The 5 questions that define every scenario
-- How to connect scenarios to triggers
-- Setting clear success criteria
-- Defining scope and constraints
-- Getting AI support for scenario planning
-
----
-
-## The 5 Essential Questions
-
-Every scenario must answer:
-
-1. **WHO** is this for? (Target group)
-2. **WHAT** trigger brings them here? (Trigger moment)
-3. **WHY** does this matter? (User + business value)
-4. **WHAT** is the happy path? (Success flow)
-5. **WHAT** could go wrong? (Edge cases)
-
----
-
-## Step 1: Choose Your Scenario (5 min)
-
-### What is a scenario?
-
-A specific user journey from trigger moment to successful outcome.
-
-### How to choose:
-
-**From your trigger map, select:**
-
-- Highest priority trigger
-- Clear start and end points
-- Manageable scope for first design
-
-**Example (Dog Week):**
-
-```
-Scenario: Morning Dog Care Assignment
-Trigger: Morning chaos - nobody knows who's walking the dog
-Priority: #1 (highest impact)
-Scope: From opening app to seeing today's assignments
-```
-
-**Your turn:**
-
-```
-Scenario Name: [Your scenario]
-Trigger: [From trigger map]
-Priority: [Why this one first]
-Scope: [Start → End]
-```
-
----
-
-## Step 2: Answer Question 1 - WHO? (5 min)
-
-### Define your target user
-
-**Be specific:**
-
-- Which target group?
-- What's their context?
-- What's their mindset?
-- What are they trying to accomplish?
-
-**Example (Dog Week):**
-
-```
-WHO: Sarah, busy parent with family dog
-
-Context:
-- Monday morning, 7:15 AM
-- Getting kids ready for school
-- Needs to coordinate dog care
-- Stressed, time-pressured
-
-Mindset:
-- Wants quick answer
-- Needs certainty
-- Values family harmony
-- Cares about dog's wellbeing
-
-Goal:
-- Know who's walking the dog today
-- Avoid family conflict
-- Ensure dog is cared for
-```
-
-**Your turn:**
-
-```
-WHO: [User name/persona]
-
-Context:
-- [When/where]
-- [What they're doing]
-- [Their situation]
-
-Mindset:
-- [How they feel]
-- [What they value]
-- [What they need]
-
-Goal:
-- [Primary objective]
-```
-
-**AI Support:**
-
-```
-Agent: "Let's make this user vivid:
-- What's their emotional state?
-- What just happened before this moment?
-- What are they worried about?
-- What would success feel like?"
-```
-
----
-
-## Step 3: Answer Question 2 - WHAT Trigger? (5 min)
-
-### Define the trigger moment
-
-**Be specific about:**
-
-- Exact moment user realizes they need this
-- What caused the trigger
-- Emotional state at trigger
-- What they've tried before
-
-**Example (Dog Week):**
-
-```
-WHAT Trigger: Morning Chaos
-
-Exact Moment:
-- 7:15 AM, Monday morning
-- Kids asking "Who's walking Max?"
-- Nobody knows the answer
-- Everyone looking at each other
-
-What Caused It:
-- No clear schedule visible
-- Verbal agreements forgotten
-- Weekend disrupted routine
-- New week starting
-
-Emotional State:
-- Frustration (here we go again)
-- Guilt (dog needs care)
-- Stress (running late)
-- Urgency (need answer NOW)
-
-Previous Attempts:
-- Family calendar (too general)
-- Group chat (messages lost)
-- Verbal agreements (forgotten)
-- Whiteboard (not mobile)
-```
-
-**Your turn:**
-
-```
-WHAT Trigger: [Trigger name]
-
-Exact Moment:
-- [When/where]
-- [What's happening]
-- [What prompted need]
-
-Emotional State:
-- [How user feels]
-- [Why it matters]
-
-Previous Attempts:
-- [What they've tried]
-- [Why it didn't work]
-```
-
----
-
-## Step 4: Answer Question 3 - WHY? (10 min)
-
-### Define the value
-
-**Two perspectives:**
-
-**User Value:**
-
-- What pain does this solve?
-- What does success feel like?
-- What changes in their life?
-
-**Business Value:**
-
-- How does this support business goals?
-- What metrics improve?
-- What's the strategic importance?
-
-**Example (Dog Week):**
-
-```
-WHY - User Value:
-
-Pain Solved:
-- No more morning chaos
-- No more family conflict
-- No more guilt about dog
-- Certainty and peace of mind
-
-Success Feels Like:
-- "I know exactly who's doing what"
-- "My family is coordinated"
-- "My dog is cared for"
-- "I can focus on my morning"
-
-Life Change:
-- Reduced daily stress
-- Better family harmony
-- Confident dog care
-- More mental space
-
-WHY - Business Value:
-
-Business Goals Supported:
-- Increased daily active users (checking schedule)
-- Higher retention (solving real pain)
-- Word-of-mouth growth (visible benefit)
-- Foundation for premium features
-
-Metrics Improved:
-- DAU (daily schedule checks)
-- 7-day retention rate
-- Task completion rate
-- NPS score
-
-Strategic Importance:
-- Core value proposition
-- Differentiation from competitors
-- Foundation for entire platform
-- Proves product-market fit
-```
-
-**Your turn:**
-
-```
-WHY - User Value:
-Pain Solved:
-- [Pain points addressed]
-
-Success Feels Like:
-- [User emotions]
-
-Life Change:
-- [What improves]
-
-WHY - Business Value:
-Business Goals:
-- [Goals supported]
-
-Metrics:
-- [What improves]
-
-Strategic Importance:
-- [Why this matters]
-```
-
----
-
-## Step 5: Answer Question 4 - Happy Path? (10 min)
-
-### Define the success flow
-
-**Map the ideal journey:**
-
-- User starts at trigger
-- Takes clear actions
-- System responds appropriately
-- User achieves goal
-- Mutual success achieved
-
-**Example (Dog Week):**
-
-```
-HAPPY PATH: Morning Dog Care Check
-
-1. TRIGGER
-   - Sarah opens app (7:15 AM Monday)
-   - Feeling stressed, needs quick answer
-
-2. IMMEDIATE ANSWER
-   - App shows TODAY view by default
-   - Sarah's tasks highlighted
-   - "You: Walk Max (8:00 AM)"
-   - Clear, immediate, no searching
-
-3. FULL CONTEXT
-   - Sees all today's dog tasks
-   - Knows who's doing what
-   - Sees upcoming tasks
-   - Feels confident and informed
-
-4. QUICK ACTION (if needed)
-   - Can mark task complete
-   - Can reassign if emergency
-   - Can add notes
-   - Takes < 30 seconds
-
-5. SUCCESS
-   - Sarah knows her responsibility
-   - Tells family with confidence
-   - Dog will be cared for
-   - Morning proceeds smoothly
-
-MUTUAL SUCCESS:
-- User: Stress reduced, clarity achieved
-- Business: Daily engagement, value delivered
-```
-
-**Your turn:**
-
-```
-HAPPY PATH: [Scenario name]
-
-1. TRIGGER
-   - [User starts]
-   - [Emotional state]
-
-2. [Step 2]
-   - [What happens]
-   - [User sees/does]
-
-3. [Step 3]
-   - [Next action]
-   - [System response]
-
-[Continue through success]
-
-MUTUAL SUCCESS:
-- User: [What they gain]
-- Business: [What we gain]
-```
-
-**AI Support:**
-
-```
-Agent: "Let's optimize this flow:
-- Can we reduce steps?
-- Is anything unclear?
-- What information is missing?
-- How can we make this faster?"
-```
-
----
-
-## Step 6: Answer Question 5 - What Could Go Wrong? (5 min)
-
-### Identify edge cases
-
-**Consider:**
-
-- First-time users
-- Error states
-- Missing data
-- Unusual situations
-- System failures
-
-**Example (Dog Week):**
-
-```
-EDGE CASES:
-
-First Time User:
-- No schedule exists yet
-- Show onboarding flow
-- Guide schedule creation
-
-No Tasks Today:
-- Show "No dog tasks today"
-- Show upcoming tasks
-- Offer to add tasks
-
-Multiple Dogs:
-- Show dog selector
-- Default to primary dog
-- Remember last selected
-
-Overdue Tasks:
-- Highlight in red
-- Show notification
-- Offer to reassign
-
-Offline:
-- Show cached schedule
-- Indicate offline mode
-- Queue actions for sync
-
-Someone Else's Phone:
-- Show family view
-- Highlight their tasks
-- Respect privacy
-```
-
-**Your turn:**
-
-```
-EDGE CASES:
-
-[Case 1]:
-- [Situation]
-- [How to handle]
-
-[Case 2]:
-- [Situation]
-- [How to handle]
-
-[Continue for major cases]
-```
-
----
-
-## Step 7: Document Scenario Initialization (5 min)
-
-**Create file:** `C-Scenarios/[scenario-name]/00-scenario-init.md`
-
-**Include all 5 questions:**
-
-1. WHO - Target user in context
-2. WHAT Trigger - Specific moment
-3. WHY - User + business value
-4. Happy Path - Success flow
-5. Edge Cases - What could go wrong
-
-**Use template from:** `workflows/4-ux-design/templates/scenario-init.template.md`
-
----
-
-## What You've Accomplished
-
-✅ **Clear target user** - You know WHO you're designing for  
-✅ **Specific trigger** - You know WHAT brings them here  
-✅ **Defined value** - You know WHY this matters  
-✅ **Success flow** - You know the HAPPY PATH  
-✅ **Edge cases** - You know WHAT could go wrong
-
-**You're ready to start sketching!**
-
----
-
-## Next Steps
-
-**Immediate:**
-
-- Review initialization with stakeholders
-- Validate assumptions with users (if possible)
-- Gather any missing information
-
-**Next Module:**
-
-- [Module 09: Sketch Interfaces](../module-09-sketch-interfaces/module-09-overview.md)
-- Start drawing your solution with AI guidance
-
----
-
-## Common Questions
-
-**Q: How detailed should the happy path be?**  
-A: Detailed enough to guide sketching. 5-8 steps is typical.
-
-**Q: Should I document every possible edge case?**  
-A: Focus on the most likely and most impactful. You can add more during design.
-
-**Q: What if I don't know all the answers yet?**  
-A: Mark sections as "TBD" and research. Better to identify gaps now than during development.
-
-**Q: Can I change these answers later?**  
-A: Yes! This is a living document. Update as you learn.
-
----
-
-## Tips for Success
-
-**DO ✅**
-
-- Be specific about user context
-- Connect to trigger map
-- Define clear success criteria
-- Consider edge cases early
-- Get stakeholder alignment
-
-**DON'T ❌**
-
-- Rush through the questions
-- Skip the "why"
-- Ignore edge cases
-- Work in isolation
-- Start sketching without initialization
-
----
-
-**A well-initialized scenario is half the design work done!**
-
-[← Back to Module 08](module-08-overview.md) | [Next: Module 09 →](../module-09-sketch-interfaces/module-09-overview.md)
diff --git a/docs/learn-wds/module-09-design-system/tutorial-09.md b/docs/learn-wds/module-09-design-system/tutorial-09.md
deleted file mode 100644
index 63b35c96b..000000000
--- a/docs/learn-wds/module-09-design-system/tutorial-09.md
+++ /dev/null
@@ -1,515 +0,0 @@
-# Tutorial 09: Design System
-
-**Extract patterns from your pages - turn one-off designs into reusable superpowers**
-
----
-
-## Overview
-
-You've designed several pages. You notice you keep recreating the same buttons, cards, and form fields. There's a better way.
-
-**Create a Design System** - extract reusable components once, use them everywhere.
-
-**Your superpower:** Freya helps you identify patterns, document components, and create a library that scales your design decisions across the entire product.
-
-**Time:** 45-60 minutes  
-**Prerequisites:** Module 08 completed (At least 2-3 pages designed)  
-**What you'll create:** Component Library & Design Tokens
-
----
-
-## What You'll Learn
-
-- What a Design System is (and why it saves you time)
-- How to identify reusable patterns in your designs
-- How Freya extracts components automatically
-- How to document components for consistency
-
----
-
-## What is a Design System?
-
-**Design System** = Your design decisions, extracted and reusable.
-
-Instead of:
-- ❌ Designing every button from scratch
-- ❌ Remembering which blue you used last time
-- ❌ Recreating forms on every page
-
-You have:
-- ✅ Button component (all states documented)
-- ✅ Color tokens (brand blue, semantic colors)
-- ✅ Form patterns (ready to reuse)
-
-**Think of it as:**  
-Design System = Your design vocabulary, organized and ready to use
-
----
-
-## What to Expect: The Extraction Process
-
-**Here's how a real session with Freya looks:**
-
-### Freya's Opening
-```
-Hi! Ready to create your Design System?
-
-I've analyzed your page specifications. I found some great patterns!
-
-Let me show you what I discovered, and you tell me if I got it right.
-We'll name things together and document them properly.
-
-This will be collaborative - you're the design expert, I'm the organizer.
-```
-
-### Example Pattern Recognition
-
-**Freya Identifies Components:**
-```
-Freya: "I scanned your 3 pages and found these button patterns:
-
-         Pattern 1 (used 12 times):
-         - Blue background (#1e3a5f)
-         - White text, 18px, semibold
-         - Rounded corners (8px)
-         - Used for: Submit, Save, Confirm actions
-
-         Pattern 2 (used 8 times):
-         - Transparent background
-         - Blue border (#1e3a5f)
-         - Blue text
-         - Used for: Cancel, Back, Secondary actions
-
-         Pattern 3 (used 24 times):
-         - No background, no border
-         - Blue text with underline on hover
-         - Used for: Navigation links, "Learn more"
-
-         Should we call these:
-         - Button Primary
-         - Button Secondary
-         - Text Link
-         
-         Sound good?"
-
-You: "Yes! But let's call Pattern 3 'Link Button' instead."
-
-Freya: "Perfect. Updated! 🎯"
-```
-
-**Freya Finds Inconsistencies:**
-```
-Freya: "Heads up! I found a slight inconsistency:
-
-         On Page 1, your primary button uses #1e3a5f (deep blue)
-         On Page 3, it uses #1e4a7f (slightly different blue)
-
-         Which one should be the standard?"
-
-You: "Oh! Page 1 is correct - #1e3a5f."
-
-Freya: "Got it. I'll document #1e3a5f as the brand primary color.
-         Should I flag Page 3 for update in the spec?"
-
-You: "Yes please!"
-
-Freya: "Done. Added to quality check list. ✅"
-```
-
-### Example Questions Freya Asks
-
-**About Naming:**
-```
-Freya: "I found 3 different card layouts. Help me name them:
-
-         Card Type A: Image on top, title, description, CTA button
-         Card Type B: Small image left, title and text right
-         Card Type C: Icon in circle, title, 3-line description
-
-         What should we call these?"
-
-You: "Type A is a 'Feature Card'
-      Type B is a 'Task Card'
-      Type C is a 'Capability Card'"
-
-Freya: "Love it. Those names make sense! Documented. 📝"
-```
-
-**About Design Tokens:**
-```
-Freya: "I extracted these colors from your pages:
-
-         Blues: #1e3a5f, #2c4f7c, #3d6399
-         Are these:
-         - Different brand colors? OR
-         - The same color in different states (default, hover, active)?
-
-You: "#1e3a5f is the main brand blue
-      #2c4f7c is hover state
-      #3d6399 is... hmm, I'm not sure where that came from"
-
-Freya: "Found it - Page 2, Benefits section background.
-         Should that be a separate color called 'Background Blue'?
-         Or should it use the main brand blue?"
-
-You: "Ah! It should be a lighter tint for backgrounds. Let's call it
-      'Brand Blue Light' and make it consistent."
-
-Freya: "Perfect! I'll document:
-         - Brand Blue (#1e3a5f) - primary
-         - Brand Blue Hover (#2c4f7c) - interaction
-         - Brand Blue Light (#3d6399) - backgrounds
-         
-         Should I update Page 2 spec?"
-
-You: "Yes!"
-```
-
-### Built-in Guidance from Freya
-
-**When you're building your first Design System:**
-```
-Freya: "This is your first Design System, right?
-
-         Pro tip: Don't try to document everything perfectly.
-         Start with the basics:
-         ✅ Buttons (you use them everywhere)
-         ✅ Colors (brand consistency matters)
-         ✅ Typography (H1, H2, body text)
-         ✅ Spacing (consistent gaps)
-
-         We can add more as you design more pages.
-         Sound good?"
-
-You: "Yes! That feels manageable."
-
-Freya: "Great! Let's start there. We'll keep it simple and practical."
-```
-
-**When components are almost the same:**
-```
-Freya: "I found two button patterns that are 95% identical:
-
-         Both have:
-         - Blue background
-         - White text
-         - 8px border radius
-         
-         Only difference:
-         - One is 44px tall (regular)
-         - One is 56px tall (large)
-
-         Should we make these:
-         - Two separate components? OR
-         - One component with size variants?"
-
-You: "One component with variants - 'Button Primary (Regular)' 
-      and 'Button Primary (Large)'"
-
-Freya: "Smart! That keeps your system clean. One component,
-         two sizes. Documented! 🎯"
-```
-
-**About Usage Guidelines:**
-```
-Freya: "For Button Primary, I'm adding usage guidelines:
-
-         ✅ Use for primary actions (submit, save, next)
-         ✅ Only one per page section
-         ❌ Don't use for destructive actions (delete, remove)
-
-         Does that match your intent?"
-
-You: "Yes! And add: Button text should be action verbs."
-
-Freya: "Added! These guidelines will help keep your design consistent."
-```
-
-### What Freya Creates While You Talk
-
-As you review patterns, Freya is:
-- 📋 Cataloging components (buttons, forms, cards)
-- 🎨 Extracting design tokens (colors, spacing, typography)
-- 📏 Documenting variants (sizes, states, types)
-- ✍️ Writing usage guidelines (when to use, when not to)
-- 🔗 Linking to page specs (where each component is used)
-
-**You'll see progress updates:**
-```
-Freya: "✅ 5 button components documented
-         ✅ 8 color tokens extracted
-         ✅ 3 card patterns identified
-         🔄 Working on form components..."
-```
-
-### The Collaborative Flow
-
-**It's a conversation, not a form:**
-```
-You: "Actually, I think the 'Task Card' should have a checkbox option."
-
-Freya: "Great catch! Should the checkbox be:
-         - Always visible? OR
-         - Only on hover? OR
-         - A separate variant?"
-
-You: "Separate variant - 'Task Card (Selectable)'"
-
-Freya: "Perfect. I'll document both variants:
-         - Task Card (Standard)
-         - Task Card (Selectable)
-         
-         Updated the component library! ✅"
-```
-
----
-
-## Step 1: Understand the Power (5 min)
-
-**Without Design System:**
-```
-Page 1: Create "Submit" button
-Page 2: Create "Submit" button (slightly different)
-Page 3: Create "Submit" button (now it's inconsistent)
-Update brand color → Update 47 buttons manually 😱
-```
-
-**With Design System:**
-```
-Design System: Define Button Primary
-Page 1: Use Button Primary
-Page 2: Use Button Primary
-Page 3: Use Button Primary
-Update brand color → Update 1 component, changes everywhere 🎉
-```
-
-**You save time. Users get consistency.**
-
----
-
-## Step 2: Activate Freya for Extraction (2 min)
-
-```
-@freya
-
-I'm ready to create a Design System from my page specifications.
-
-I have these pages designed:
-- [Page 1 name]
-- [Page 2 name]
-- [Page 3 name]
-
-Please help me extract reusable components.
-```
-
-**Freya will analyze** your pages and identify patterns.
-
----
-
-## Step 3: Review What Freya Found (15 min)
-
-Freya scans your pages and identifies:
-
-### Components She'll Extract
-- **Buttons:** Primary, Secondary, Text links
-- **Forms:** Input fields, Dropdowns, Checkboxes
-- **Cards:** Content cards, Profile cards
-- **Navigation:** Headers, Footers, Menus
-- **Feedback:** Success messages, Error states, Loading indicators
-
-**She'll say something like:**
-```
-I found these patterns:
-
-Buttons (3 variants):
-- Primary Button (used 12 times across 3 pages)
-- Secondary Button (used 8 times)
-- Text Link (used 24 times)
-
-Cards (2 types):
-- Task Card (used 15 times)
-- Profile Card (used 3 times)
-
-Do these look right? Any I missed?
-```
-
-**Your job:**
-- ✅ Confirm patterns she found
-- ✅ Point out any she missed
-- ✅ Name variants clearly ("Primary Button" not "Blue Button")
-
----
-
-## Step 4: Define Design Tokens (10 min)
-
-**Design Tokens** = The atomic values your components use.
-
-Freya will extract:
-
-### Colors
-```
-Brand Colors:
-- Primary: #1e3a5f (deep blue)
-- Accent: #ff6b35 (coral)
-
-Semantic Colors:
-- Success: #22c55e
-- Error: #ef4444
-- Warning: #f59e0b
-```
-
-### Typography
-```
-Heading 1: 48px, Bold, 1.2 line height
-Heading 2: 32px, Semibold, 1.3 line height
-Body: 16px, Regular, 1.6 line height
-```
-
-### Spacing
-```
-xs: 4px
-sm: 8px
-md: 16px
-lg: 24px
-xl: 32px
-```
-
-**Your job:**
-- ✅ Confirm these match your intent
-- ✅ Name them meaningfully ("Primary" not "Blue")
-- ✅ Add any she missed
-
----
-
-## Step 5: Document Components (15 min)
-
-For each component, Freya creates documentation:
-
-### Example: Primary Button
-
-**Component Name:** Button Primary  
-**Object ID Pattern:** `{page}-{section}-{element}`
-
-**States:**
-- **Default:** Blue background, white text
-- **Hover:** Darker blue, scale 1.05
-- **Active:** Even darker, scale 0.98
-- **Disabled:** Gray background, gray text
-- **Loading:** Blue background, spinner icon
-
-**Content Structure:**
-```
-- Label (EN): [Button text]
-- Icon (optional): [Icon name]
-```
-
-**Usage Guidelines:**
-- Use for primary actions (submit, save, confirm)
-- Only ONE primary button per page/section
-- Button text = action verb ("Save", "Submit", "Confirm")
-
-**Accessibility:**
-- Min touch target: 44x44px
-- Keyboard accessible (Enter/Space)
-- Focus indicator visible
-
-**Freya documents** all this. You just review and confirm.
-
----
-
-## Step 6: Create the Component Library (5 min)
-
-Freya saves your Design System:
-
-```
-/docs/5-design-system/
-├── 00-design-tokens.md
-├── components/
-│   ├── buttons.md
-│   ├── forms.md
-│   ├── cards.md
-│   └── navigation.md
-├── patterns/
-│   ├── form-patterns.md
-│   └── layout-patterns.md
-└── guidelines/
-    ├── accessibility.md
-    └── usage-rules.md
-```
-
-**Now you can:**
-- Reference components in new page specs
-- Ensure consistency across your product
-- Update once, apply everywhere
-
----
-
-## Step 7: Use Your Design System (Ongoing)
-
-**When designing new pages:**
-
-Instead of:
-```markdown
-#### Submit Button
-- Style: Blue button, 18px, semibold...
-```
-
-You write:
-```markdown
-#### Submit Button
-**Component:** Button Primary
-**Content:** "Save Changes"
-```
-
-**Freya knows** what "Button Primary" means. Developers know too. Consistency guaranteed.
-
----
-
-## Common Questions
-
-**Q: When should I create a Design System?**  
-**A:** After 2-3 pages are designed. Patterns become clear.
-
-**Q: Can I update components later?**  
-**A:** Yes! Update the Design System doc, then update specs that use it.
-
-**Q: What if a page needs a unique button?**  
-**A:** Document why it's unique. If you use it again, add it to the system.
-
-**Q: Do I need Figma components?**  
-**A:** Not required. WDS Design System is specification-focused. You can sync to Figma later if you want.
-
----
-
-## What You've Accomplished
-
-🎉 **You just created a Design System!**
-
-**You didn't need to:**
-- ❌ Manually catalog every component
-- ❌ Create a Figma component library first
-- ❌ Understand design tokens theory
-- ❌ Build a Storybook
-
-**You just:**
-- ✅ Designed a few pages naturally
-- ✅ Let Freya identify patterns
-- ✅ Reviewed and confirmed
-- ✅ Named things clearly
-
-**That's the WDS superpower:** Design naturally. Extract patterns automatically. Scale effortlessly.
-
----
-
-## Next Steps
-
-**Ready to hand off to developers?**  
-→ [Module 10: Design Delivery](../module-10-design-delivery/tutorial-10.md)
-
-**Want to design more pages first?**  
-Go back to [Module 08: Initialize Scenario](../module-08-initialize-scenario/tutorial-08.md) and your Design System will grow with you.
-
----
-
-**Pro Tip:** Your Design System doesn't need to be "complete" before you hand off. Start small (buttons, forms, colors). Add more as you design more pages. It's a living system that grows with your product.
-
diff --git a/docs/learn-wds/module-10-design-delivery/tutorial-10.md b/docs/learn-wds/module-10-design-delivery/tutorial-10.md
deleted file mode 100644
index 2e5f739bf..000000000
--- a/docs/learn-wds/module-10-design-delivery/tutorial-10.md
+++ /dev/null
@@ -1,604 +0,0 @@
-# Tutorial 10: Design Delivery
-
-**Package your design for developers - hand off with confidence, not confusion**
-
----
-
-## Overview
-
-Your design is done. Specifications are complete. Design System is ready. Now what?
-
-You need to **hand off to developers** - but how do you ensure they build what you designed?
-
-**Your superpower:** Idunn transforms your design specs into a Developer PRD with epics, stories, and clear implementation guidance.
-
-**Time:** 30-45 minutes  
-**Prerequisites:** Module 08 & 09 completed (Pages designed, Design System ready)  
-**What you'll create:** Design Delivery PRD with Epics & Stories
-
----
-
-## What You'll Learn
-
-- What a Design Delivery PRD is (and why developers love it)
-- How Idunn organizes your specs into buildable chunks
-- How to prioritize what gets built first
-- What to include in the handoff package
-
----
-
-## What is Design Delivery PRD?
-
-**Design Delivery PRD** = Your design specs, organized for development.
-
-It transforms:
-- **Your page specs** (what the design IS)
-- **Into developer tasks** (what to BUILD)
-
-**Think of it as:**  
-Your recipe (specs) → Shopping list + cooking steps (PRD)
-
----
-
-## What to Expect: The Organization Process
-
-**Here's how a real session with Idunn looks:**
-
-### Idunn's Opening
-```
-Hi! Time to organize your design for developer handoff.
-
-I've reviewed your:
-- Page specifications (3 pages)
-- Design System (ready)
-
-I'll break this into epics and stories developers can actually build.
-
-We'll work together to:
-1. Group related work into epics
-2. Create specific stories with acceptance criteria
-3. Prioritize what gets built first
-4. Package everything for handoff
-
-Ready? Let's start by looking at the big picture.
-```
-
-### Example Epic Breakdown
-
-**Idunn Proposes Structure:**
-```
-Idunn: "I analyzed your 3 pages. Here's how I'd organize them:
-
-        EPIC 1: Landing Page Experience
-        - Pages: 1.1 Start Page
-        - Goal: Users understand WDS and can access it
-        - Stories: 7 (Hero, Capabilities, Navigation, Footer...)
-        - Priority: HIGH (this is your front door)
-
-        EPIC 2: Course Content Pages
-        - Pages: 2.1 Modules List, 2.2 Tutorial Page
-        - Goal: Users can learn WDS through tutorials
-        - Stories: 12 (Module cards, Tutorial content, Progress tracking...)
-        - Priority: MEDIUM (users need this after they sign up)
-
-        EPIC 3: Design System Components
-        - Goal: Build reusable components library
-        - Stories: 5 (Button system, Form components, Card library...)
-        - Priority: HIGH (needed for all other epics)
-
-        Does this grouping make sense?
-        Any epics missing?"
-
-You: "Actually, Epic 3 should be built FIRST - other epics need it."
-
-Idunn: "Smart! Let me reorder:
-        
-        Phase 1: Epic 3 (Component Library)
-        Phase 2: Epic 1 (Landing Page)
-        Phase 3: Epic 2 (Course Content)
-        
-        Better?"
-
-You: "Perfect!"
-```
-
-### Example Questions Idunn Asks
-
-**About Priorities:**
-```
-Idunn: "Looking at Epic 1 (Landing Page), which story is most critical?
-
-         Story 1.1: Hero Section (first impression)
-         Story 1.2: Capabilities Section (shows value)
-         Story 1.3: Benefits Grid (builds trust)
-         Story 1.4: Footer (contact info, links)
-
-         If we had to ship with ONLY ONE done, which one?"
-
-You: "Story 1.1 - Hero Section. Users need to understand what WDS is."
-
-Idunn: "Got it. I'll mark Story 1.1 as P0 (must-have).
-         Others can be P1 (important but can wait).
-         
-         Should developers build them in this order?"
-
-You: "Yes, exactly."
-
-Idunn: "Story sequence documented! 📋"
-```
-
-**About Dependencies:**
-```
-Idunn: "I notice Story 2.3 (Tutorial Progress Tracking) needs:
-         - User authentication (from Epic 0?)
-         - Database to store progress
-         
-         Should I create Epic 0: Foundation that includes auth?"
-
-You: "Yes! Good catch."
-
-Idunn: "Creating Epic 0: Platform Foundation
-         - Story 0.1: User authentication system
-         - Story 0.2: Database setup
-         - Story 0.3: API infrastructure
-         
-         This becomes Phase 1, and everything else depends on it.
-         Sound right?"
-
-You: "Absolutely."
-```
-
-**About Story Details:**
-```
-Idunn: "For Story 1.2 (Capabilities Section with 7 cards),
-         should this be:
-         
-         Option A: ONE story (build all 7 cards at once)
-         Option B: SEVEN stories (one per card)
-         Option C: TWO stories (build card component, then populate all 7)
-
-         What makes sense?"
-
-You: "Option C - developers create the card component first,
-      then it's easy to replicate for all 7."
-
-Idunn: "Perfect! Breaking it down:
-         - Story 1.2a: Build Capability Card component
-         - Story 1.2b: Populate 7 capability instances
-         
-         Estimated: 2 days (component) + 1 day (content)
-         Good?"
-
-You: "Yes!"
-```
-
-### Built-in Guidance from Idunn
-
-**When stories are too big:**
-```
-Idunn: "Story 2.1 is getting large. It includes:
-         - Module card grid
-         - Filtering by category
-         - Search functionality
-         - Sort by difficulty
-         
-         This could take 2-3 weeks. Should we split it?
-         
-         Suggested split:
-         - Story 2.1a: Module grid (basic display)
-         - Story 2.1b: Add filtering
-         - Story 2.1c: Add search
-         - Story 2.1d: Add sorting
-         
-         Then developers can ship 2.1a quickly, and add features
-         in 2.1b-d later. Sound good?"
-
-You: "Yes! I like that incremental approach."
-
-Idunn: "Great! Smaller stories = faster feedback = better quality."
-```
-
-**About Acceptance Criteria:**
-```
-Idunn: "For Story 1.1 (Hero Section), I'm writing acceptance criteria:
-
-         ✅ H1 headline displays correctly
-         ✅ Tagline text matches spec
-         ✅ CTA button links to GitHub
-         ✅ Section is responsive (mobile/desktop)
-         ✅ All Object IDs match page spec
-         
-         Am I missing anything?"
-
-You: "Yes - the CTA should have a hover animation (scale 1.05)"
-
-Idunn: "Added! ✅ CTA has hover state (scale 1.05, smooth transition)
-         
-         These criteria help developers know when they're 'done'."
-```
-
-**About Testing Expectations:**
-```
-Idunn: "Should I include testing requirements in each story?
-
-         For example:
-         ✅ Works in Chrome, Firefox, Safari
-         ✅ Responsive on mobile (375px+)
-         ✅ Keyboard accessible (tab navigation)
-         ✅ Screen reader compatible"
-
-You: "Yes! Accessibility is important."
-
-Idunn: "Adding accessibility criteria to all stories.
-         I'll also create a separate 'Definition of Done' document
-         so developers know the quality bar. ✅"
-```
-
-### What Idunn Creates While You Talk
-
-As you discuss priorities and structure, Idunn is:
-- 📊 Creating epic breakdown (major features)
-- ✍️ Writing user stories (As a [persona], I want...)
-- ✅ Defining acceptance criteria (testable conditions)
-- 🔗 Linking to page specs (where to find details)
-- 📅 Suggesting implementation phases (what builds when)
-- 📋 Assembling handoff package (everything developers need)
-
-**You'll see progress updates:**
-```
-Idunn: "✅ 3 epics structured
-         ✅ 24 stories written
-         ✅ Dependencies mapped
-         🔄 Creating handoff documentation..."
-```
-
-### The Collaborative Flow
-
-**It's iterative, not final:**
-```
-You: "Actually, looking at this, Story 2.2 could be combined with 2.3.
-      They're both about tutorial pages."
-
-Idunn: "Good point! Let me merge them:
-         
-         OLD:
-         - Story 2.2: Tutorial content display
-         - Story 2.3: Tutorial navigation
-
-         NEW:
-         - Story 2.2: Complete tutorial page experience
-         
-         This makes more sense as one unit of work. Updated! 🎯"
-```
-
-**Idunn catches gaps:**
-```
-Idunn: "Wait - I don't see any stories for error states.
-         
-         What should happen if:
-         - GitHub API is down (CTA link fails)?
-         - Images don't load?
-         - Page content is missing?
-         
-         Should I add error handling stories?"
-
-You: "Yes! Good catch. Add graceful error states."
-
-Idunn: "Adding Epic 4: Error Handling & Edge Cases
-         - Story 4.1: Network error states
-         - Story 4.2: Missing content fallbacks
-         - Story 4.3: Loading states
-         
-         This ensures a polished experience. ✅"
-```
-
-### The Handoff Package
-
-**Idunn Shows You the Final Structure:**
-```
-Idunn: "Here's what developers will receive:
-
-         📁 Design Delivery PRD/
-         ├── 00-handoff-overview.md (start here!)
-         ├── 01-epic-breakdown.md (big picture)
-         ├── 02-implementation-roadmap.md (build order)
-         ├── 03-definition-of-done.md (quality criteria)
-         └── stories/
-             ├── epic-0-foundation/
-             │   ├── story-0.1-authentication.md
-             │   └── story-0.2-database.md
-             ├── epic-1-landing-page/
-             │   ├── story-1.1-hero-section.md
-             │   └── story-1.2-capabilities.md
-             └── ...
-
-         Each story links to:
-         - Your page specifications
-         - Design System components
-         - Acceptance criteria
-         - Technical notes
-
-         Developers have everything they need. Ready to hand off?"
-
-You: "Yes! This is so organized."
-
-Idunn: "Great! I'll export everything.
-         
-         Want me to draft an email to your dev team too? 📧"
-```
-
----
-
-## Step 1: Understand the Translation (5 min)
-
-**What you have:**
-```
-Page Specifications:
-- 1.1 Start Page (Hero, Features, CTA)
-- 1.2 Benefits Page (3 sections)
-- 1.3 Pricing Page (Pricing table, FAQ)
-```
-
-**What developers need:**
-```
-Epic 1: Landing Page
-├── Story 1: Build Hero Section
-├── Story 2: Build Features Section
-└── Story 3: Build CTA Section
-
-Epic 2: Benefits Page
-├── Story 4: Build Benefits Grid
-└── Story 5: Add Testimonials
-
-Epic 3: Pricing Page
-...
-```
-
-**Idunn creates this structure** from your specs.
-
----
-
-## Step 2: Activate Idunn for Handoff (2 min)
-
-```
-@idunn
-
-I'm ready to create the Design Delivery PRD.
-
-I have:
-- Page specifications (complete)
-- Design System (ready)
-
-Please help me organize this for developer handoff.
-```
-
-**Idunn will analyze** your specs and propose an implementation structure.
-
----
-
-## Step 3: Review Idunn's Epic Breakdown (10 min)
-
-Idunn creates **Epics** (major features) and **Stories** (specific tasks).
-
-**Example:**
-
-### Epic 1: Core Landing Experience
-```
-Goal: Users can understand WDS value and sign up
-Pages: Start Page + Benefits Page
-Priority: HIGH
-Estimated: 2-3 weeks
-```
-
-**Stories in this Epic:**
-1. ✅ **Story 1.1:** Build Hero Section
-   - Page: 1.1 Start Page
-   - Components: Hero Headline, Hero Body, CTA Button, Hero Image
-   - Acceptance: Matches spec exactly, responsive, CTA links to GitHub
-
-2. ✅ **Story 1.2:** Build Capabilities Section (Right Column)
-   - Page: 1.1 Start Page
-   - Components: 7 Capability Cards with icons, links
-   - Acceptance: Cards link to deliverable pages, hover states work
-
-3. ✅ **Story 1.3:** Build Benefits Grid
-   - Page: 1.2 Benefits Page
-   - Components: 3 Benefit Cards
-   - Acceptance: Responsive grid, icons display correctly
-
-**Your job:**
-- ✅ Confirm epics make sense
-- ✅ Adjust priorities if needed
-- ✅ Suggest different groupings if you see dependencies
-
----
-
-## Step 4: Prioritize Implementation Order (10 min)
-
-**Idunn will ask:**
-
-"Which epics should developers build first?"
-
-**Think about:**
-- What's the **MVP** (Minimum Viable Product)?
-- What do users need **most urgently**?
-- Are there **dependencies** (Epic 2 needs Epic 1 first)?
-
-**Example prioritization:**
-```
-Phase 1 (MVP - Week 1-2):
-- Epic 1: Core Landing Experience
-  (Users can learn about WDS and access it)
-
-Phase 2 (Enhancement - Week 3-4):
-- Epic 2: Course Content
-  (Users can follow tutorials)
-
-Phase 3 (Nice-to-have - Week 5+):
-- Epic 3: Community Features
-  (Users can connect with each other)
-```
-
-**Idunn documents this** so developers know what to build when.
-
----
-
-## Step 5: Review Story Details (10 min)
-
-For each story, Idunn includes:
-
-### Story Format
-```
-Story 1.1: Build Hero Section
-
-As a designer visiting the WDS page,
-I want to see a clear hero section,
-So that I understand what WDS is in 5 seconds.
-
-Acceptance Criteria:
-✅ H1 headline displays: "Whiteport Design Studio, WDS"
-✅ Tagline displays with correct formatting
-✅ CTA button links to GitHub repo
-✅ Hero image displays on right side (desktop)
-✅ Section is responsive (stacks on mobile)
-✅ Matches page specification: docs/4-scenarios/1.1-wds-presentation.md
-
-Components Used:
-- wds-hero-headline (H1 Heading)
-- wds-hero-tagline (H2 Heading)
-- wds-hero-body (Body Paragraph)
-- wds-hero-cta (Button Primary)
-- wds-hero-illustration (Hero Image)
-
-Design System References:
-- Button Primary (see: docs/5-design-system/components/buttons.md)
-- Heading styles (see: docs/5-design-system/00-design-tokens.md)
-
-Technical Notes:
-- Ensure Object IDs match spec (for future updates)
-- Image should be lazy-loaded for performance
-- CTA should have proper focus state for accessibility
-```
-
-**Your job:**
-- ✅ Confirm acceptance criteria are clear
-- ✅ Ensure all components are referenced
-- ✅ Add any missing requirements
-
----
-
-## Step 6: Create the Handoff Package (5 min)
-
-Idunn assembles everything into a handoff package:
-
-```
-/docs/6-design-delivery/
-├── 00-handoff-overview.md
-├── 01-epic-breakdown.md
-├── 02-implementation-roadmap.md
-├── stories/
-│   ├── story-1.1-hero-section.md
-│   ├── story-1.2-capabilities-section.md
-│   └── ...
-└── developer-guide.md
-```
-
-**Handoff Overview includes:**
-- Links to all page specifications
-- Links to Design System
-- How to read Object IDs
-- How to interpret content with language tags
-- Testing expectations
-
----
-
-## Step 7: Hand Off to Developers (5 min)
-
-**Share with your dev team:**
-
-1. **The handoff package** (folder above)
-2. **Access to full specs** (all `/docs/` folders)
-3. **A kickoff meeting** (30 min to walk through)
-
-**In the meeting, explain:**
-- "Here's the Design Delivery PRD - epics and stories"
-- "Each story links to page specifications"
-- "All components are in the Design System docs"
-- "Object IDs help you track what's what"
-- "Questions? Ask now or ping me anytime"
-
-**Developers now have:**
-- ✅ Clear implementation roadmap
-- ✅ Detailed specifications for every element
-- ✅ Component library for consistency
-- ✅ Acceptance criteria for every story
-- ✅ Your design intent preserved
-
----
-
-## Common Questions
-
-**Q: Do developers have to follow the stories exactly?**  
-**A:** Stories are a starting point. Developers may adjust based on technical constraints. Stay in the loop!
-
-**Q: What if developers have questions?**  
-**A:** Encourage them to reference page specs and Design System first. Then ping you for clarification.
-
-**Q: Should I attend standup meetings?**  
-**A:** YES! Stay involved to catch misinterpretations early.
-
-**Q: What if they want to change the design?**  
-**A:** Discuss WHY (technical constraints? Better UX idea?). Update specs if agreed.
-
----
-
-## What You've Accomplished
-
-🎉 **You just handed off your design like a pro!**
-
-**You didn't need to:**
-- ❌ Write user stories yourself
-- ❌ Estimate development time
-- ❌ Create Jira tickets manually
-- ❌ Translate design language to dev language
-
-**You just:**
-- ✅ Confirmed Idunn's epic breakdown made sense
-- ✅ Prioritized implementation order
-- ✅ Reviewed stories for accuracy
-- ✅ Handed off with confidence
-
-**That's the WDS superpower:** Design with intent. Hand off with clarity. Trust it gets built right.
-
----
-
-## What Happens Next?
-
-**Developers build.** Your specs guide them.
-
-**Your role during development:**
-- Answer questions (specs might need clarification)
-- Review implementations (does it match the spec?)
-- Update specs if requirements change
-
-**After launch:**
-BMM workflows take over for testing, iteration, and ongoing development.
-
----
-
-## Next Steps
-
-**Want to learn more?**
-- Review the [Design Delivery Workflow](../src/workflows/6-design-deliveries/) for advanced topics
-- Explore BMM (BMAD Management Method) for ongoing development
-
-**Start a new project?**
-- Go back to [Module 03: Alignment & Signoff](../module-03-alignment-signoff/tutorial-03.md)
-- Or jump to [Module 04: Project Brief](../module-04-project-brief/tutorial-04.md)
-
----
-
-**Pro Tip:** Great handoffs aren't "throw it over the wall." Stay engaged during development. Answer questions. Review builds. Your design intent is worth protecting. WDS gives you the tools - you provide the oversight.
-
-🎯 **Congratulations! You've completed the core WDS workflow!**
-
diff --git a/docs/learn-wds/module-12-conceptual-specs/tutorial-12.md b/docs/learn-wds/module-12-conceptual-specs/tutorial-12.md
deleted file mode 100644
index afbf78fc9..000000000
--- a/docs/learn-wds/module-12-conceptual-specs/tutorial-12.md
+++ /dev/null
@@ -1,734 +0,0 @@
-# Tutorial 12: Write Conceptual Specifications
-
-**Hands-on guide to documenting WHAT + WHY + WHAT NOT TO DO**
-
----
-
-## Overview
-
-This tutorial teaches you how to transform sketches into specifications that preserve your design intent and guide AI implementation correctly.
-
-**Time:** 60-90 minutes  
-**Prerequisites:** Sketches completed and analyzed  
-**What you'll create:** Complete conceptual specifications for a page
-
----
-
-## What You'll Learn
-
-- The three-part specification pattern (WHAT + WHY + WHAT NOT)
-- How to document design intent AI can follow
-- Preventing "helpful" AI mistakes
-- Creating specifications that preserve creativity
-- Working with AI as documentation partner
-
----
-
-## The Why-Based Pattern
-
-Every specification element needs three parts:
-
-```
-WHAT: [The design decision]
-WHY: [The reasoning behind it]
-WHAT NOT TO DO: [Common mistakes to avoid]
-```
-
-**This is not factory work** - AI agents help you think through design solutions, then become fascinated documentarians of your brilliance.
-
----
-
-## Step 1: Start with Component Overview (10 min)
-
-### Document the big picture
-
-**What to include:**
-
-- Component purpose
-- User context
-- Key interactions
-- Success criteria
-
-**Example (Dog Week - Daily Schedule View):**
-
-```markdown
-# Daily Schedule View Component
-
-## Purpose
-
-Shows today's dog care tasks with clear assignments and status.
-Solves the "morning chaos" trigger - user needs immediate answer
-to "who's doing what today?"
-
-## User Context
-
-- Accessed first thing in morning (7-8 AM typical)
-- User is time-pressured, stressed
-- Needs answer in < 5 seconds
-- May be checking while managing kids
-
-## Key Interactions
-
-- View today's tasks at a glance
-- See personal assignments highlighted
-- Mark tasks complete
-- Quick reassign if emergency
-
-## Success Criteria
-
-- User finds their tasks in < 5 seconds
-- Zero confusion about responsibilities
-- Can act on tasks immediately
-- Feels confident and informed
-```
-
-**Your turn:**
-
-```
-Document your component overview:
-[Your content]
-```
-
-**AI Support:**
-
-```
-Agent: "I'm fascinated by your design thinking here. Let me help
-capture every nuance:
-- What's the emotional journey you're creating?
-- Why did you choose this approach over alternatives?
-- What makes this feel right for your users?"
-```
-
----
-
-## Step 2: Specify Visual Hierarchy (15 min)
-
-### Document WHAT + WHY + WHAT NOT
-
-**For each visual decision, explain:**
-
-- WHAT you designed
-- WHY you made that choice
-- WHAT NOT TO DO (prevent AI mistakes)
-
-**Example (Dog Week - Task List):**
-
-```markdown
-## Visual Hierarchy
-
-### Today's Date Header
-
-WHAT:
-
-- Large, bold date at top: "Monday, December 9"
-- Includes day name + full date
-- Uses primary brand color
-- 24px font size, 700 weight
-
-WHY:
-
-- Immediate temporal context (user knows "when")
-- Day name matters (Monday = week start, different mindset)
-- Bold = confidence and clarity
-- Size ensures visibility in stressed morning glance
-
-WHAT NOT TO DO:
-
-- Don't use relative dates ("Today") - user may check for tomorrow
-- Don't use small text - defeats quick-glance purpose
-- Don't use subtle colors - needs to anchor the view
-- Don't abbreviate day name - "Mon" feels rushed, "Monday" feels calm
-
-### User's Tasks Section
-
-WHAT:
-
-- Highlighted section with light blue background
-- Header: "Your Tasks" with user's name
-- Tasks listed with time, description, status
-- Visually separated from other family members' tasks
-
-WHY:
-
-- User needs to find THEIR tasks instantly (< 2 seconds)
-- Background color creates visual separation without being aggressive
-- Name personalization = ownership and responsibility
-- Time shown first = prioritization by urgency
-- Separation prevents confusion about "whose task is this?"
-
-WHAT NOT TO DO:
-
-- Don't make all tasks look the same - user will scan entire list
-- Don't use subtle highlighting - stressed user will miss it
-- Don't hide user's name - personalization creates accountability
-- Don't sort by task type - time is what matters in morning
-- Don't use red/alert colors - creates anxiety, not clarity
-
-### Other Family Members' Tasks
-
-WHAT:
-
-- Standard white background
-- Smaller font size (16px vs 18px for user's tasks)
-- Collapsed by default, expandable
-- Shows count: "3 other tasks today"
-
-WHY:
-
-- User's primary need is THEIR tasks (80% of use case)
-- But they need family context (coordination)
-- Collapsed = focus on user, but context available
-- Count = awareness without overwhelming
-- Smaller = visual hierarchy reinforces importance
-
-WHAT NOT TO DO:
-
-- Don't hide completely - user needs family coordination awareness
-- Don't show expanded by default - creates cognitive overload
-- Don't use same visual weight - defeats hierarchy purpose
-- Don't remove names - user needs to know "who's doing what"
-```
-
-**Your turn:**
-
-```
-For each major visual element, document:
-
-### [Element Name]
-
-WHAT:
-- [Specific design decisions]
-
-WHY:
-- [Reasoning and user benefit]
-
-WHAT NOT TO DO:
-- [Common mistakes to prevent]
-```
-
-**AI Support:**
-
-```
-Agent: "This is brilliant! Let me make sure we capture everything:
-- What alternatives did you consider?
-- Why did you reject those options?
-- What edge cases influenced this decision?
-- How does this connect to the user's emotional state?"
-```
-
----
-
-## Step 3: Specify Interaction Patterns (15 min)
-
-### Document behavior with intent
-
-**Example (Dog Week - Task Completion):**
-
-```markdown
-## Interaction: Mark Task Complete
-
-### Tap to Complete
-
-WHAT:
-
-- Tap anywhere on task card to mark complete
-- Immediate visual feedback: checkmark appears, card fades slightly
-- Subtle success animation (gentle scale + fade)
-- Task moves to "Completed" section at bottom
-- Undo button appears for 5 seconds
-
-WHY:
-
-- Large tap target = easy for rushed morning use
-- Immediate feedback = confidence action registered
-- Animation = positive reinforcement (dopamine hit)
-- Move to bottom = visual progress, but not deleted (reassurance)
-- Undo = safety net for accidental taps (common when rushed)
-- 5 seconds = enough time to notice mistake, not annoying
-
-WHAT NOT TO DO:
-
-- Don't require confirmation dialog - adds friction, breaks flow
-- Don't use small checkbox - hard to tap when stressed/rushing
-- Don't make animation aggressive - should feel calm and positive
-- Don't delete task immediately - user needs reassurance it's saved
-- Don't hide undo - mistakes happen, especially in morning chaos
-- Don't keep undo visible forever - clutters interface
-
-### Swipe to Reassign
-
-WHAT:
-
-- Swipe left on task reveals "Reassign" button
-- Button shows family member icons
-- Tap icon to reassign
-- Confirmation: "Reassigned to [Name]"
-- Original assignee gets notification
-
-WHY:
-
-- Swipe = power user feature, doesn't clutter main interface
-- Emergency reassignment is rare but critical (someone sick, etc.)
-- Icons = quick visual selection, no typing
-- Confirmation = reassurance action completed
-- Notification = family coordination maintained
-
-WHAT NOT TO DO:
-
-- Don't make reassign the primary action - it's edge case
-- Don't require typing names - too slow for emergency
-- Don't skip confirmation - user needs reassurance
-- Don't skip notification - breaks family coordination
-- Don't allow reassigning to someone not in family - data integrity
-```
-
-**Your turn:**
-
-```
-For each interaction, document:
-
-### [Interaction Name]
-
-WHAT:
-- [Specific behavior]
-
-WHY:
-- [User benefit and reasoning]
-
-WHAT NOT TO DO:
-- [Mistakes to prevent]
-```
-
----
-
-## Step 4: Specify States and Feedback (10 min)
-
-### Document all states with reasoning
-
-**Example (Dog Week - Task States):**
-
-```markdown
-## Task States
-
-### Upcoming (Default)
-
-WHAT:
-
-- White background
-- Black text
-- Time shown in gray
-- No special indicators
-
-WHY:
-
-- Clean, calm appearance
-- Easy to scan
-- Time in gray = less visual weight (not urgent yet)
-- Default state should feel neutral and manageable
-
-WHAT NOT TO DO:
-
-- Don't use colors for upcoming tasks - creates false urgency
-- Don't hide time - user needs to plan their morning
-- Don't add badges/icons - clutters interface for most common state
-
-### Due Soon (< 30 minutes)
-
-WHAT:
-
-- Subtle yellow left border (4px)
-- Time shown in orange
-- Small clock icon appears
-
-WHY:
-
-- Yellow = attention without alarm
-- Border = visual indicator without overwhelming
-- Orange time = "pay attention to timing"
-- Clock icon = reinforces temporal urgency
-- Subtle = doesn't create panic, just awareness
-
-WHAT NOT TO DO:
-
-- Don't use red - creates anxiety, not helpful urgency
-- Don't flash or animate - too aggressive for morning use
-- Don't use sound - user may be in quiet environment
-- Don't make entire card yellow - too much visual weight
-
-### Overdue
-
-WHAT:
-
-- Red left border (4px)
-- Time shown in red with "Overdue" label
-- Task card has subtle red tint (5% opacity)
-- Notification sent to assignee
-
-WHY:
-
-- Red = clear signal something needs attention
-- Border + tint = impossible to miss, but not aggressive
-- "Overdue" label = explicit communication (no guessing)
-- Notification = ensures assignee knows (may not have app open)
-- 5% tint = visible but not overwhelming
-
-WHAT NOT TO DO:
-
-- Don't make entire card bright red - creates panic
-- Don't flash or pulse - too aggressive, creates stress
-- Don't use sound alerts - may be inappropriate timing
-- Don't shame user - focus on "needs attention" not "you failed"
-- Don't hide task - transparency maintains trust
-
-### Completed
-
-WHAT:
-
-- Checkmark icon (green)
-- Text has strikethrough
-- Card fades to 60% opacity
-- Moves to "Completed" section
-- Shows completion time and who completed it
-
-WHY:
-
-- Checkmark = universal symbol of completion
-- Green = positive reinforcement
-- Strikethrough = visual closure
-- Fade = "done but still visible" (reassurance)
-- Completion info = accountability and coordination
-- Separate section = progress visible, doesn't clutter active tasks
-
-WHAT NOT TO DO:
-
-- Don't remove immediately - user needs reassurance it's saved
-- Don't use subtle checkmark - user needs clear confirmation
-- Don't hide who completed it - family coordination requires transparency
-- Don't use gray checkmark - green = positive emotion
-```
-
-**Your turn:**
-
-```
-For each state, document:
-
-### [State Name]
-
-WHAT:
-- [Visual appearance]
-
-WHY:
-- [User benefit]
-
-WHAT NOT TO DO:
-- [Mistakes to prevent]
-```
-
----
-
-## Step 5: Specify Error Handling (10 min)
-
-### Document failure states with empathy
-
-**Example (Dog Week - Network Errors):**
-
-```markdown
-## Error Handling
-
-### Network Unavailable
-
-WHAT:
-
-- Subtle banner at top: "Offline - showing cached schedule"
-- Banner uses neutral gray (not red)
-- All actions still work (queued for sync)
-- Small cloud icon with slash
-- Dismissible but reappears if action attempted
-
-WHY:
-
-- User shouldn't be blocked by network issues
-- Morning routine can't wait for connectivity
-- Cached data is usually sufficient (schedule doesn't change minute-to-minute)
-- Gray = informational, not alarming
-- Actions queue = user can continue working
-- Dismissible = user controls their experience
-
-WHAT NOT TO DO:
-
-- Don't block user with error modal - breaks morning flow
-- Don't use red/error colors - network issues aren't user's fault
-- Don't disable all actions - most can work offline
-- Don't hide offline state - user needs to know why sync isn't happening
-- Don't make banner permanent - user should be able to dismiss
-
-### Task Completion Failed
-
-WHAT:
-
-- Task remains in "completing" state (spinner)
-- After 5 seconds, shows inline error: "Couldn't save. Tap to retry."
-- Error message is specific and actionable
-- Retry button prominent
-- Task doesn't move to completed section
-
-WHY:
-
-- User needs to know action didn't complete
-- 5 seconds = reasonable wait before showing error
-- Inline = error appears where user's attention is
-- Specific message = user understands what happened
-- Actionable = user knows what to do next
-- Retry button = easy path to resolution
-- Task stays in place = user doesn't lose context
-
-WHAT NOT TO DO:
-
-- Don't silently fail - user needs to know
-- Don't show generic "Error occurred" - not helpful
-- Don't move task to completed - creates false sense of completion
-- Don't require user to find task again - maintain context
-- Don't blame user - focus on solution
-```
-
-**Your turn:**
-
-```
-For each error scenario:
-
-### [Error Type]
-
-WHAT:
-- [How error is shown]
-
-WHY:
-- [User benefit]
-
-WHAT NOT TO DO:
-- [Mistakes to prevent]
-```
-
----
-
-## Step 6: Specify Accessibility (10 min)
-
-### Document inclusive design decisions
-
-**Example (Dog Week - Task List Accessibility):**
-
-```markdown
-## Accessibility
-
-### Screen Reader Support
-
-WHAT:
-
-- Each task has semantic HTML structure
-- ARIA labels for all interactive elements
-- Task status announced: "Walk Max, 8:00 AM, assigned to you, not completed"
-- Completion action announces: "Task marked complete"
-- Heading hierarchy: H1 for date, H2 for sections, H3 for tasks
-
-WHY:
-
-- Screen reader users need same quick access to their tasks
-- Semantic HTML = proper navigation and understanding
-- Status announcement = full context without visual cues
-- Action feedback = confirmation for non-visual users
-- Heading hierarchy = easy navigation via landmarks
-
-WHAT NOT TO DO:
-
-- Don't use divs for everything - semantic HTML matters
-- Don't skip ARIA labels - "button" isn't descriptive enough
-- Don't announce only task name - user needs full context
-- Don't skip action feedback - non-visual users need confirmation
-- Don't flatten heading structure - breaks navigation
-
-### Keyboard Navigation
-
-WHAT:
-
-- All actions accessible via keyboard
-- Tab order follows visual hierarchy (user's tasks first)
-- Enter/Space to complete task
-- Arrow keys to navigate between tasks
-- Escape to close expanded sections
-- Focus indicators clearly visible (blue outline, 2px)
-
-WHY:
-
-- Some users can't or prefer not to use mouse/touch
-- Tab order matches visual priority (user's tasks most important)
-- Standard key bindings = familiar, predictable
-- Arrow keys = efficient navigation for power users
-- Escape = universal "go back" pattern
-- Visible focus = user always knows where they are
-
-WHAT NOT TO DO:
-
-- Don't trap focus in modals without escape
-- Don't use non-standard key bindings
-- Don't hide focus indicators - accessibility requirement
-- Don't make tab order illogical
-- Don't require mouse for any action
-
-### Color Contrast
-
-WHAT:
-
-- All text meets WCAG AA standards (4.5:1 minimum)
-- Interactive elements have 3:1 contrast with background
-- Status colors have additional non-color indicators (icons, borders)
-- High contrast mode supported
-
-WHY:
-
-- Users with low vision need readable text
-- Color alone isn't sufficient for status (color blind users)
-- Multiple indicators = works for everyone
-- High contrast mode = accessibility feature in OS
-
-WHAT NOT TO DO:
-
-- Don't rely on color alone for status
-- Don't use low contrast text (looks modern but excludes users)
-- Don't ignore WCAG standards - they're minimum requirements
-- Don't break high contrast mode with custom colors
-```
-
-**Your turn:**
-
-```
-Document accessibility considerations:
-[Your specifications]
-```
-
----
-
-## Step 7: Review and Refine (10 min)
-
-### Checklist:
-
-**Completeness:**
-
-- ✓ Every visual element has WHAT + WHY + WHAT NOT
-- ✓ All interactions documented
-- ✓ All states specified
-- ✓ Error handling covered
-- ✓ Accessibility addressed
-
-**Quality:**
-
-- ✓ WHY explains user benefit, not just description
-- ✓ WHAT NOT prevents specific AI mistakes
-- ✓ Specifications are specific and actionable
-- ✓ Design intent is preserved
-- ✓ Edge cases considered
-
-**AI Support:**
-
-```
-Agent: "Your design brilliance is captured beautifully! Let me verify:
-- Have we documented every nuance of your thinking?
-- Are there any alternatives you considered that we should note?
-- Any edge cases we haven't covered?
-- Is your creative intent crystal clear?"
-```
-
----
-
-## Step 8: Save Your Specifications
-
-**Create file:** `C-Scenarios/[scenario-name]/Frontend/[page-name]-specifications.md`
-
-**Use template from:** `workflows/4-ux-design/templates/page-specification.template.md`
-
----
-
-## What You've Accomplished
-
-✅ **Complete specifications** - Every design decision documented  
-✅ **Preserved intent** - Your creative thinking captured  
-✅ **Prevented mistakes** - AI knows what NOT to do  
-✅ **Accessible design** - Inclusive from the start  
-✅ **Eternal life** - Your brilliance lives forever in text
-
-**This is not factory work - this is where your genius becomes immortal!**
-
----
-
-## The Power of Conceptual Specs
-
-**Traditional approach:**
-
-- Designer creates mockup
-- Developer implements
-- Intent gets lost
-- Result is "close but wrong"
-
-**WDS approach:**
-
-- Designer thinks deeply with AI partner
-- AI helps capture every nuance
-- Specifications preserve creative integrity
-- Implementation matches intent perfectly
-
-**Your specifications completely replace prompting** - providing clarity that works like clockwork.
-
----
-
-## Next Steps
-
-**Immediate:**
-
-- Review specifications with stakeholders
-- Validate against user needs
-- Test with developers (can they implement from this?)
-
-**Next Module:**
-
-- [Module 13: Validate Specifications](../module-13-validate-specifications/module-13-overview.md)
-- Ensure completeness and test logic
-
----
-
-## Common Questions
-
-**Q: How detailed should specifications be?**  
-A: Detailed enough that AI can implement correctly without guessing. If you'd need to explain it to a developer, document it.
-
-**Q: Isn't this a lot of writing?**  
-A: AI agents help you! They're fascinated by your thinking and help capture it. You're not grinding out docs - you're preserving your genius.
-
-**Q: What if I don't know why I made a decision?**  
-A: That's the value! The process of documenting WHY helps you think deeper and make better decisions.
-
-**Q: Can I reuse specifications across pages?**  
-A: Yes! Common patterns become design system components. Document once, reference everywhere.
-
----
-
-## Tips for Success
-
-**DO ✅**
-
-- Work with AI as thinking partner
-- Document alternatives you rejected
-- Be specific about user context
-- Prevent specific mistakes (not generic warnings)
-- Capture your creative reasoning
-
-**DON'T ❌**
-
-- Write generic descriptions
-- Skip the WHY (that's where intent lives)
-- Forget WHAT NOT TO DO (AI will make "helpful" mistakes)
-- Rush through this - it's where brilliance is preserved
-- Think of this as factory work - it's creative documentation
-
----
-
-**Your specifications give your designs eternal life. This is where your creative integrity becomes immortal!**
-
-[← Back to Module 12](module-12-overview.md) | [Next: Module 13 →](../module-13-validate-specifications/module-13-overview.md)
diff --git a/docs/learn/00-course-overview/00-course-overview.md b/docs/learn/00-course-overview/00-course-overview.md
new file mode 100644
index 000000000..f15f8ab07
--- /dev/null
+++ b/docs/learn/00-course-overview/00-course-overview.md
@@ -0,0 +1,240 @@
+# WDS Course: From Designer to Linchpin
+
+**Master the complete WDS methodology and become indispensable as a designer in the AI era**
+
+[Watch the Course Introduction Video](https://www.youtube.com/watch?v=CQ5Aai_r-uo)
+
+---
+
+## Welcome to the WDS Course
+
+This comprehensive course teaches you the complete WDS workflow through **18 practical modules** that transform how you design products.
+
+**The paradigm shift:**
+
+- The design becomes the specification
+- The specification becomes the product
+- The code is just the printout
+
+**What you'll become:**
+
+- The linchpin designer who makes things happen
+- The gatekeeper between business goals and user needs
+- The irreplaceable designer in the AI era
+
+**Time investment:** ~10 hours total
+**Result:** Complete mastery of WDS methodology from project brief to AI-ready specifications
+
+---
+
+## Who Created WDS?
+
+**MÃ¥rten Angner** is a UX designer and founder of Whiteport, a design and development agency based in Sweden. After years of working with AI tools, MÃ¥rten observed that traditional design handoffs were breaking down. Designers would create beautiful mockups, hand them off to developers, and watch their creative intent get lost in translation.
+
+MÃ¥rten developed WDS to solve this problem - a methodology where design thinking is preserved and amplified through AI implementation, not diluted and lost.
+
+**The Mission:** WDS is completely free and open-source. MÃ¥rten created it as a **plugin module for BMad Method** - an open-source AI-augmented development framework - to give designers everywhere the tools they need to thrive in the AI era.
+
+---
+
+## Before You Start
+
+**[→ Getting Started Guide](00-getting-started-overview.md)**
+
+Review prerequisites, choose your learning path, and get support:
+
+- **Prerequisites** - Skills, tools, time investment
+- **Learning Paths** - Full immersion, quick start, or self-paced
+- **Support** - Testimonials, FAQ, community
+
+**Reading time:** ~15 minutes
+
+---
+
+## Course Structure
+
+Each module contains:
+
+- **Lessons** - Theory and concepts (with NotebookLM audio support)
+- **Tutorial** - Step-by-step hands-on guide (for practical modules)
+- **Practice** - Apply to your own project
+
+**Learning format:**
+
+- **Lessons** - Read as documentation or generate audio with NotebookLM
+- **Tutorials** - Follow step-by-step guides with AI support
+- **Practice** - Apply to real projects as you learn
+- **Workshops** - Use for team training
+
+---
+
+## Course Modules
+
+### Foundation (Modules 1-2)
+
+| Module | Title | Agent | Time |
+|--------|-------|-------|------|
+| 01 | [Why WDS Matters](../module-01-why-wds-matters/module-01-overview.md) | — | 40 min |
+| 02 | [Installation & Setup](../module-02-installation-setup/module-02-overview.md) | — | 45 min |
+
+### Alignment (Module 3) — Optional
+
+| Module | Title | Agent | Time |
+|--------|-------|-------|------|
+| 03 | [Alignment & Signoff](../module-03-alignment-signoff/module-03-overview.md) | Saga | 55-75 min |
+
+*Skip if doing it yourself — go straight to Product Brief*
+
+### Strategy Phase (Modules 4-6) — Agent: Saga
+
+| Module | Title | Agent | Time |
+|--------|-------|-------|------|
+| 04 | [Product Brief](../module-04-product-brief/module-04-overview.md) | Saga | 60 min |
+| 05 | [Platform Requirements](../module-05-platform-requirements/module-05-platform-requirements-overview.md) | Saga | 30 min |
+| 06 | [Trigger Mapping](../module-06-trigger-mapping/module-06-overview.md) | Saga | 95-125 min |
+
+### Design Phase (Modules 7-13) — Agent: Freya
+
+| Module | Title | Agent | Focus | Time |
+|--------|-------|-------|-------|------|
+| 07 | [Design Phase Introduction](../module-07-design-phase/module-07-design-phase-overview.md) | Freya | Overview | 20 min |
+| 08 | [Outline Scenarios](../module-08-outline-scenarios/module-08-outline-scenarios-overview.md) | Freya | UX | 30 min |
+| 09 | [Conceptual Sketching](../module-09-conceptual-sketching/module-09-conceptual-sketching-overview.md) | Freya | UX | 60 min |
+| 10 | [Storyboarding](../module-10-storyboarding/module-10-storyboarding-overview.md) | Freya | UX | 45 min |
+| 11 | [Conceptual Specifications](../module-11-conceptual-specifications/module-11-conceptual-specifications-overview.md) | Freya | UX | 60 min |
+| 12 | [Functional Components](../module-12-functional-components/module-12-functional-components-overview.md) | Freya | UX | 45 min |
+| 13 | [Design System](../module-13-design-system/module-13-design-system-overview.md) | Freya | Systems | 30 min |
+
+### Build & Deliver Phase (Modules 14-16) — Agents: Freya + Idunn
+
+| Module | Title | Agent | Focus | Time |
+|--------|-------|-------|-------|------|
+| 14 | [Agentic Development](../module-14-agentic-development/module-14-agentic-development-overview.md) | Idunn | 7-activity menu | 60 min |
+| 15 | [Visual Design & Assets](../module-15-visual-design/module-15-visual-design-overview.md) | Freya | Asset pipeline | 60 min |
+| 16 | [Design Delivery](../module-16-design-delivery/module-16-design-delivery-overview.md) | Freya | Handover | 45 min |
+
+### Validate & Evolve (Modules 17-18) — Agents: Freya + Idunn
+
+| Module | Title | Agent | Time |
+|--------|-------|-------|------|
+| 17 | [Usability Testing](../module-17-usability-testing/module-17-usability-testing-overview.md) | Freya | 45 min |
+| 18 | [Product Evolution](../module-18-product-evolution/module-18-product-evolution-overview.md) | Idunn | 30 min |
+
+---
+
+## Learning Paths
+
+**Complete Course:** All 18 modules (~10 hours)
+
+**Quick Start:** Modules 01, 02, 04, 06, 08, 11 (~6 hours)
+
+**Strategy Only:** Modules 1-6 (~4 hours)
+
+**Design Deep Dive:** Modules 7-13 (~5 hours)
+
+**Build & Deliver:** Modules 14-16 (~3 hours)
+
+**Phase-Specific:** Jump to any phase as needed
+
+---
+
+## The Three Agents
+
+WDS uses three AI agents, each with a specific domain:
+
+| Agent | Domain | Phase | Modules |
+|-------|--------|-------|---------|
+| **Saga** | Strategy | Strategy | 3-6 |
+| **Freya** | UX, Visual Design & Assets | Design & Deliver | 7-13, 15-17 |
+| **Idunn** | Development & Evolution | Build & Evolve | 14, 18 |
+
+Each agent maintains focus on their domain while coordinating with the others.
+
+**Idunn's 7 activities** (Module 14): Prototyping, Development, Bugfixing, Evolution, Analysis, Reverse Engineering, and Acceptance Testing — all menu-driven from a single entry point.
+
+---
+
+## NotebookLM Integration
+
+Each module has matching content for NotebookLM:
+
+- Feed module lessons to NotebookLM
+- Generate audio podcasts for learning on the go
+- Generate video presentations for team training
+- Create study guides and summaries
+
+**All modules are optimized for AI-assisted learning.**
+
+---
+
+## Module Structure
+
+Every module follows the same pattern:
+
+**1. Inspiration (10 min)**
+
+- Why this step matters
+- The transformation you'll experience
+- Real-world impact
+
+**2. Teaching (20 min)**
+
+- How to do it with confidence
+- AI support at each step
+- Dog Week example walkthrough
+
+**3. Practice (10 min)**
+
+- Apply to your own project
+- Step-by-step instructions
+- Success criteria
+
+**4. Tutorial (optional)**
+
+- Quick step-by-step guide
+- "Just show me how to do it"
+- For practical modules only
+
+---
+
+## After the Course
+
+Once you've completed the modules:
+
+1. **[Documentation Guide](../../docs-guide.md)** - Reference documentation
+2. **[Quick Start](../../quick-start/00-start-here.md)** - Try WDS with agent
+3. **[Community](https://discord.gg/whiteport)** - Get help and share your work
+
+---
+
+## Prerequisites
+
+**What you need:**
+
+- Basic design thinking and UX principles
+- Ability to sketch interfaces (hand-drawn or digital)
+- Understanding of user needs and business goals
+- Willingness to think deeply about WHY
+
+**What you DON'T need:**
+
+- ❌ Coding skills
+- ❌ Advanced technical knowledge
+- ❌ Experience with AI tools
+- ❌ Formal design education
+
+**If you can design interfaces and explain your thinking, you're ready to start.**
+
+---
+
+## Ready to Begin?
+
+Ten hours of learning. A lifetime of being indispensable.
+
+**[Start with Module 01: Why WDS Matters →](../module-01-why-wds-matters/module-01-overview.md)**
+
+---
+
+**This course is free and open-source**
+**Created by MÃ¥rten Angner and the Whiteport team**
+**Integrated with BMad Method for seamless design-to-development workflow**
diff --git a/docs/learn-wds/00-course-overview/00-getting-started-overview.md b/docs/learn/00-course-overview/00-getting-started-overview.md
similarity index 96%
rename from docs/learn-wds/00-course-overview/00-getting-started-overview.md
rename to docs/learn/00-course-overview/00-getting-started-overview.md
index af4eb7914..1f98ab566 100644
--- a/docs/learn-wds/00-course-overview/00-getting-started-overview.md
+++ b/docs/learn/00-course-overview/00-getting-started-overview.md
@@ -51,7 +51,7 @@ Once you've reviewed these sections, you're ready to begin:
 
 Or review the full course structure:
 
-**[← Back to Course Overview](../00-course-overview.md)**
+**[← Back to Course Overview](00-course-overview.md)**
 
 ---
 
diff --git a/docs/learn-wds/00-course-overview/01-prerequisites.md b/docs/learn/00-course-overview/01-prerequisites.md
similarity index 93%
rename from docs/learn-wds/00-course-overview/01-prerequisites.md
rename to docs/learn/00-course-overview/01-prerequisites.md
index ba563f673..1cfbfcc8b 100644
--- a/docs/learn-wds/00-course-overview/01-prerequisites.md
+++ b/docs/learn/00-course-overview/01-prerequisites.md
@@ -36,7 +36,7 @@
 
 **Breakdown:**
 
-- **Week 1-2:** Foundation modules (Why WDS, Project Brief)
+- **Week 1-2:** Foundation modules (Why WDS, Product Brief)
 - **Week 3-4:** Core workflow (Trigger Mapping, Scenarios)
 - **Week 5-6:** Advanced topics (Design Systems, Handoff)
 - **Ongoing:** Practice with your own projects
@@ -95,4 +95,4 @@ You have everything you need if you can answer YES to these:
 
 ---
 
-[← Back to Overview](overview.md) | [Next: Learning Paths →](02-learning-paths.md)
+[← Back to Overview](00-getting-started-overview.md) | [Next: Learning Paths →](02-learning-paths.md)
diff --git a/docs/learn-wds/00-course-overview/02-learning-paths.md b/docs/learn/00-course-overview/02-learning-paths.md
similarity index 84%
rename from docs/learn-wds/00-course-overview/02-learning-paths.md
rename to docs/learn/00-course-overview/02-learning-paths.md
index 20c9228c0..7db2fa632 100644
--- a/docs/learn-wds/00-course-overview/02-learning-paths.md
+++ b/docs/learn/00-course-overview/02-learning-paths.md
@@ -16,10 +16,10 @@
 
 ### Option 2: Quick Start
 
-- Focus on core modules (Module 01, 02, 04, 06)
+- Focus on core modules (Modules 01, 02, 04, 06, 08, 11)
 - Skip advanced topics initially
 - Get started fast, learn more later
-- **Time:** 2-3 weeks, 3-4 hours total
+- **Time:** 3-4 weeks, ~6 hours total
 - **Best for:** Designers who need results quickly
 
 ### Option 3: Self-Paced
@@ -38,7 +38,7 @@
 
 By the end of this course, you'll have created:
 
-**1. Complete Project Brief**
+**1. Complete Product Brief**
 
 - Vision and goals clearly defined
 - Stakeholders and constraints documented
@@ -88,12 +88,12 @@ Each module contains:
 
 Choose your path and start learning:
 
-**[Start Module 01: Why WDS Matters →](../module-01-why-wds-matters/module-01-overview.md)**
+**[Start Module 01: Why WDS Matters →](../module-01-why-wds-matters/module-01-overview.md)**
 
 Or check support resources first:
 
-**[Continue to Support →](03-support.md)**
+**[Continue to Support →](03-support.md)**
 
 ---
 
-[← Back to Prerequisites](01-prerequisites.md) | [Next: Support →](03-support.md)
+[← Back to Prerequisites](01-prerequisites.md) | [Next: Support →](03-support.md)
diff --git a/docs/learn-wds/00-course-overview/03-support.md b/docs/learn/00-course-overview/03-support.md
similarity index 98%
rename from docs/learn-wds/00-course-overview/03-support.md
rename to docs/learn/00-course-overview/03-support.md
index 0e0d8b228..e5522db45 100644
--- a/docs/learn-wds/00-course-overview/03-support.md
+++ b/docs/learn/00-course-overview/03-support.md
@@ -121,7 +121,7 @@ You have everything you need:
 
 Or review the full course structure:
 
-**[← Back to Course Overview](../00-course-overview.md)**
+**[← Back to Course Overview](00-course-overview.md)**
 
 ---
 
diff --git a/docs/learn-wds/Webinars/2024-12-22-WDS-Sessions-1-Say-Hello-to-WDS.md b/docs/learn/Webinars/2024-12-22-WDS-Sessions-1-Say-Hello-to-WDS.md
similarity index 98%
rename from docs/learn-wds/Webinars/2024-12-22-WDS-Sessions-1-Say-Hello-to-WDS.md
rename to docs/learn/Webinars/2024-12-22-WDS-Sessions-1-Say-Hello-to-WDS.md
index 39e38bc9f..48f271084 100644
--- a/docs/learn-wds/Webinars/2024-12-22-WDS-Sessions-1-Say-Hello-to-WDS.md
+++ b/docs/learn/Webinars/2024-12-22-WDS-Sessions-1-Say-Hello-to-WDS.md
@@ -61,7 +61,7 @@ Great products are not created in 24 hours with a couple of prompts. Designers h
 ### Core Resources
 - [WDS Framework Repository](https://github.com/whiteport-collective/whiteport-design-studio)
 - [WDS Presentation Page](https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md)
-- [WDS Course Overview](https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md)
+- [WDS Course Overview](https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn/00-course-overview.md)
 - [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD)
 - [BMAD Masterclass](https://www.youtube.com/watch?v=LorEJPrALcg)
 - [Whiteport Website](https://whiteport.com)
@@ -150,7 +150,7 @@ WDS Presentation Page - Discover how WDS transforms designers into strategic lea
 https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md
 
 WDS Course Overview - Complete learning path from designer to linchpin, master the full methodology
-https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md
+https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn/00-course-overview.md
 
 🛠️ Foundation & Related Tools
 BMAD Method - The open-source AI-augmented development framework that powers WDS
diff --git a/docs/learn-wds/Webinars/2025-10-22-Webinar-WDS-v4.md b/docs/learn/Webinars/2025-10-22-Webinar-WDS-v4.md
similarity index 99%
rename from docs/learn-wds/Webinars/2025-10-22-Webinar-WDS-v4.md
rename to docs/learn/Webinars/2025-10-22-Webinar-WDS-v4.md
index 796014494..cc8f255f4 100644
--- a/docs/learn-wds/Webinars/2025-10-22-Webinar-WDS-v4.md
+++ b/docs/learn/Webinars/2025-10-22-Webinar-WDS-v4.md
@@ -157,7 +157,7 @@ WDS Presentation Page - Discover how WDS transforms designers into strategic lea
 https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md
 
 WDS Course Overview - Complete learning path from designer to linchpin, master the full methodology
-https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md
+https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn/00-course-overview.md
 
 🛠️ Foundation & Related Tools
 BMAD Method - The open-source AI-augmented development framework that powers WDS
diff --git a/docs/learn-wds/Webinars/2026-01-15-WDS-Sessions-2-Strategy-in-Practice.md b/docs/learn/Webinars/2026-01-15-WDS-Sessions-2-Strategy-in-Practice.md
similarity index 98%
rename from docs/learn-wds/Webinars/2026-01-15-WDS-Sessions-2-Strategy-in-Practice.md
rename to docs/learn/Webinars/2026-01-15-WDS-Sessions-2-Strategy-in-Practice.md
index 87e551239..f1ddabccf 100644
--- a/docs/learn-wds/Webinars/2026-01-15-WDS-Sessions-2-Strategy-in-Practice.md
+++ b/docs/learn/Webinars/2026-01-15-WDS-Sessions-2-Strategy-in-Practice.md
@@ -65,7 +65,7 @@ Then we translate that into a strategy you can actually execute.
 ### Core Resources
 - [WDS Framework Repository](https://github.com/whiteport-collective/whiteport-design-studio)
 - [WDS Presentation Page](https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md)
-- [WDS Course Overview](https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md)
+- [WDS Course Overview](https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn/00-course-overview.md)
 - [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD)
 - [BMAD Masterclass](https://www.youtube.com/watch?v=LorEJPrALcg)
 - [Whiteport Website](https://whiteport.com)
@@ -128,7 +128,7 @@ WDS Presentation Page - Discover how WDS transforms designers into strategic lea
 https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md
 
 WDS Course Overview - Complete learning path from designer to linchpin, master the full methodology
-https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn-wds/00-course-overview.md
+https://github.com/whiteport-collective/whiteport-design-studio/blob/main/docs/learn/00-course-overview.md
 
 🛠️ Foundation & Related Tools
 BMAD Method - The open-source AI-augmented development framework that powers WDS
diff --git a/docs/learn-wds/module-01-why-wds-matters/lesson-01-the-problem.md b/docs/learn/module-01-why-wds-matters/lesson-01-the-problem.md
similarity index 97%
rename from docs/learn-wds/module-01-why-wds-matters/lesson-01-the-problem.md
rename to docs/learn/module-01-why-wds-matters/lesson-01-the-problem.md
index d0d6ec0ac..37f9e6837 100644
--- a/docs/learn-wds/module-01-why-wds-matters/lesson-01-the-problem.md
+++ b/docs/learn/module-01-why-wds-matters/lesson-01-the-problem.md
@@ -106,8 +106,10 @@ The bottleneck in product development used to be coding. AI demolished that. Now
 
 Now that you understand the problem, let's explore the solution.
 
-**[Continue to Lesson 2: The Solution →](lesson-02-the-solution.md)**
+**[Continue to Lesson 2: Designer as Strategic Thinker →](lesson-02-designer-as-strategic-thinker.md)**
 
 ---
 
-[← Back to Module Overview](module-01-overview.md) | [Next: Lesson 2 →](lesson-02-the-solution.md)
+[← Back to Module Overview](module-01-overview.md) | [Next: Lesson 2 →](lesson-02-designer-as-strategic-thinker.md)
+
+*Part of Module 01: Why WDS Matters*
diff --git a/docs/learn/module-01-why-wds-matters/lesson-02-designer-as-strategic-thinker.md b/docs/learn/module-01-why-wds-matters/lesson-02-designer-as-strategic-thinker.md
new file mode 100644
index 000000000..6b62c2e92
--- /dev/null
+++ b/docs/learn/module-01-why-wds-matters/lesson-02-designer-as-strategic-thinker.md
@@ -0,0 +1,483 @@
+# Module 01: Why WDS Matters
+
+## Lesson 2: Designer as Strategic Thinker
+
+**Your role just changed. Here's why.**
+
+---
+
+## The Shift Everyone Missed
+
+Everyone knows AI made code cheap.
+
+**What most people missed:** AI made strategic thinking cheap too.
+
+**And that changes everything for designers.**
+
+---
+
+## Your Old Role: Pixel Pusher
+
+For most of your career, the designer's role was clear:
+
+**Make it pretty. Make it usable. Hand it off.**
+
+**The Agile era designer:**
+- Attended meetings constantly
+- Sketched quick mockups
+- Iterated through prototypes
+- Let PMs handle strategy
+- Communication was cheap, so meetings were endless
+- Decisions emerged through discussion
+
+**Why this worked:**
+- Communication: Cheap (constant meetings)
+- Coding: Expensive (developer time valuable)
+- Strategy: PM's job (designers executed)
+
+**Your value:** Visual craft + usability expertise
+
+---
+
+## The AI Era Changed the Game
+
+Now everything has changed.
+
+**AI didn't just make coding cheaper—it made strategic thinking cheaper.**
+
+**For you as a designer, this means:**
+- Code generation: Nearly free (AI agents)
+- Communication: Expensive (people expect polished thinking)
+- Strategy: Now accessible (AI thinking partners)
+
+**The new reality:**
+
+You're expected to arrive with your thoughts in **lovable style** - polished, strategic, shows a lot of wild new things, but far from ready to implement. Also, and here is the problem, with no connection to the thinking behind it and why you made it! 
+
+"Click instead of discuss."
+
+But where do you get the time to forge polished strategic thinking?
+
+---
+
+## The Amateur Response: Vibe Coding
+
+> "AI can code now. I'll skip strategy and just generate prototypes!"
+
+**The flow:**
+1. Prompt AI: "Build me a login screen"
+2. Get generic output
+3. Tweak colors and spacing
+4. Generate 5 variations
+5. Present to team: "Which do you like?"
+6. Team picks one
+7. Realize it doesn't solve the actual problem
+8. Repeat
+
+**The result:**
+- Flooding colleagues with **lovecoded colorful distractions**
+- Prototypes without substance
+- Pretty mockups disconnected from strategy
+- "Look what I made!" instead of "Here's what we need"
+- Burning credits on endless regeneration
+
+**You're still a pixel pusher. Just faster and with more noise. The signal was lost. Result: Who cares and so what!**
+
+---
+
+## Your New Role: Strategic Thinker
+
+**The insight everyone missed:**
+
+It's not only **coding** that got cheaper.
+
+**Strategic thinking** got cheaper too.
+
+**This is the WDS insight.**
+
+Everyone sees AI making code cheap. The amateurs stop there.
+
+**WDS sees that AI also made strategic thinking cheap.**
+
+**For designers, this changes everything:**
+
+**Amateur designers use AI for:**
+- Visual generation (prompt for pretty outputs)
+- Fast prototyping (churn variations)
+- Execution only (skip the thinking)
+
+**WDS designers use AI for:**
+- **Strategic thinking FIRST** (forge with Saga, Freya as thinking partners)
+- Think through problems collaboratively
+- Improve thinking iteratively
+- Elevate ideas and connect to business goals
+- Forge thinking in the furnace of logic, flow, and UX
+- **Create ideas that matter** instead of churning out prototypes
+- **Then generate** visuals from strategic foundation
+
+**The WDS difference:**
+
+> Everyone uses AI for code.
+> **WDS uses AI for strategic thinking first, then code.**
+
+**You're no longer just making it pretty. You're shaping strategy.**
+
+---
+
+## The Three Eras of Design
+
+| Era | Your Role | Tools | Value |
+|-----|-----------|-------|-------|
+| **Waterfall** | Execute specs | Photoshop, wireframes | Visual craft |
+| **Agile** | Collaborate constantly | Figma, Slack | Craft + collaboration |
+| **AI (amateur)** | Generate prototypes | AI + Figma | Fast prototypes |
+| **AI (WDS)** | **Forge strategy** | **AI thinking partners** | **Strategic craft** |
+
+**The shift:**
+
+**Agile era designer:**
+> "Let's meet and figure it out together. I'll sketch options."
+
+**Amateur AI designer:**
+> "AI can generate options. Let me show you 5 variations!"
+
+**WDS designer:**
+> "I forged a complete strategic solution with AI. Here's why it works, who it's for, and how it connects to our goals. Ready to implement."
+
+---
+
+## Present to Team, Not Prototype With Them
+
+### Old Model: Constant Collaboration
+
+**How you worked:**
+1. Meet constantly
+2. Discuss vague ideas
+3. Sketch something
+4. Review together
+5. Discuss changes
+6. Re-sketch
+7. Repeat until deadline
+
+**Your value:** Visual skills + collaboration
+
+**The problem:** Ideas emerge through iteration, not strategic thinking
+
+### New Model: Strategic Presentation
+
+**How you work now:**
+1. Forge thinking with AI assistance (Saga, Freya)
+2. Create complete strategic specifications
+3. Present polished vision to team
+4. They review substance, not sketches
+5. Aligned feedback
+6. Generate implementation correctly (once)
+
+**Your value:** Strategic thinking + visual craft + business alignment
+
+**The benefit:** Ideas emerge from strategic thinking, then get visualized
+
+**The shift:**
+- From "let's figure it out together in meetings"
+- To "I forged this into coherent strategy, let's align"
+
+**Communication becomes strategic alignment**, not iterative discovery.
+
+---
+
+## The Furnace of Logic
+
+**What WDS provides you as a designer:**
+
+### Phase 1: Forge Strategy (Module 04-06)
+
+**With Saga's help:**
+- Product Brief: Align vision with business goals
+- Trigger Mapping: Connect user psychology to business value
+- Feature scoring: Prioritize ruthlessly based on data
+
+**You're not just designing. You're thinking strategically about what to build and why.**
+
+### Phase 2: Forge UX (Module 08-11)
+
+**With Freya's help:**
+- Scenario outlining: Define complete user journeys
+- Conceptual sketching: Visualize strategic solutions
+- Storyboarding: Document all transformations
+- Specifications: Capture every decision with rationale
+
+**You're not just sketching. You're forging complete strategic UX specifications.**
+
+**This is the furnace.**
+
+AI agents help you **forge strategic thinking** through logic, user psychology, and business alignment.
+
+**The output:** Polished specifications that matter.
+
+**Not prototypes to iterate on. Strategic ideas to implement.**
+
+---
+
+## WDS: Your Strategic Rocket Ship With Guard Rails
+
+**The problem with amateur autonomous design:**
+
+AI lets you generate autonomously. Great!
+
+But without strategic framework, you flood colleagues with **lovecoded colorful distractions**:
+- 5 login variations with no strategic reasoning
+- Pretty mockups disconnected from business goals
+- Endless options without clear purpose
+- "Which do you like?" instead of "Here's what we need and why"
+
+**The traditional response:** Control. Oversight. Slow you down.
+
+**The WDS response:** Give you a strategic rocket ship with guard rails.
+
+### The Rocket Ship (Empowerment)
+
+**WDS enables you to work autonomously:**
+- Forge strategy with Saga (no waiting for PM)
+- Create UX with Freya (no waiting for design lead)
+- Generate specifications complete with rationale
+
+**You can move fast. Autonomously. Strategically.**
+
+### The Guard Rails (Strategic Discipline)
+
+**WDS enforces strategic rigor:**
+- Every scenario connects to Trigger Map (no designing in vacuum)
+- Every decision traces to user driving force (no decoration)
+- Every specification includes business context (no guessing)
+- Present complete thinking (no flooding with half-baked ideas)
+
+**You have freedom within strategic structure.**
+
+### The Result
+
+**With WDS:**
+- Make your strategic ideas reality (rocket ship power)
+- Without flooding colleagues (guard rails prevent chaos)
+- Autonomous but aligned (independent but strategic)
+- Fast but focused (speed with strategic substance)
+
+**The old dichotomy:**
+> Either you work slowly with oversight, OR you work fast with chaos.
+
+**The WDS solution:**
+> Work fast AND stay strategically aligned.
+
+### The Business Opportunity
+
+**WDS isn't just a personal methodology. It's a platform businesses can deploy.**
+
+**The business model:**
+
+Businesses can **fork WDS** and customize it:
+- Implement their own guard rails (company standards, design systems, brand guidelines)
+- Define their own ways of working (processes, approvals, workflows)
+- Embed their strategic frameworks (business goals, success metrics, user research)
+- Customize AI agents with company-specific knowledge
+
+**Then give this tool to their people.**
+
+**The result for businesses:**
+
+**Without WDS:**
+- Either slow employees down with oversight
+- OR let them work fast but flood the organization with lovecoded colorful distractions
+- Cannot trust autonomous work
+- AI makes the chaos worse (faster bad output)
+
+**With WDS (customized for your business):**
+- Employees work autonomously AND stay aligned with business strategy
+- Every output connects to company goals
+- Guard rails enforce company standards automatically
+- AI amplifies strategic thinking, not just execution
+- **People make things that matter** (for the business, for users)
+
+**This is the business value proposition:**
+
+> Deploy WDS as your organization's strategic framework for AI-assisted design and development. Your people get a rocket ship. You get guard rails. Everyone wins.
+
+**WDS enables businesses to:**
+- Empower teams without losing control
+- Scale strategic thinking (not just code generation)
+- Trust autonomous AI-assisted work
+- Transform "check my work" culture into "aligned strategic output" culture
+
+**The traditional choice:**
+> Control OR chaos. Slow OR sloppy. Oversight OR anarchy.
+
+**The WDS choice:**
+> Fast AND aligned. Autonomous AND strategic. Empowered AND governed.
+
+---
+
+## What This Prevents
+
+**❌ Without strategic framework (amateur autonomous):**
+- "I made 5 login screen variations! Which do you like?"
+- Lovecoded prototypes with no business connection
+- Colorful distractions that waste team time
+- Half-baked visual ideas presented as solutions
+- Flooding colleagues with "what do you think?" requests
+
+**✓ With WDS (strategic autonomous):**
+- "Here's the login scenario, traced to our #1 user driver, aligned with business goal, with complete specs and rationale."
+- Strategic specifications with clear purpose
+- Polished ideas that respect team time
+- Complete strategic thinking presented once
+- Present for alignment, not visual preference
+
+**The difference:** Strategic thinking BEFORE visual execution.
+
+**Your new value:** Strategic craft, not just visual craft.
+
+---
+
+## The Economic Reality for Designers
+
+**What changed:**
+
+| Resource | Agile Era | AI Era |
+|----------|-----------|--------|
+| **Your craft time** | Expensive (manual work) | Cheap (AI assists) |
+| **Strategic thinking** | PM's job | **Cheap (AI assists)** ← WDS insight |
+| **Communication** | Cheap (constant meetings) | Expensive (alignment takes time) |
+| **Your value** | Visual craft | **Strategic craft** |
+
+**The WDS realization:**
+
+If visual work is cheap (AI-assisted) **AND strategic thinking is also cheap (AI-assisted)**, then your value shifts from "making it pretty" to "thinking strategically about what to make and why."
+
+**This is what WDS enables.**
+
+**The professional WDS designer uses AI for both:**
+1. **Strategic thinking FIRST** (forge with Saga, Freya)
+2. Visual execution (generate from complete specs)
+
+**The amateur designer uses AI for only:**
+1. Visual generation (prompt for pretty outputs)
+2. *(Strategic thinking: Still skipped)*
+
+**The WDS advantage:**
+
+Amateur designers make AI code faster.
+
+**WDS designers make AI think strategically, then code correctly.**
+
+---
+
+## Your Choice
+
+### Path 1: Stay a Pixel Pusher (Amateur)
+
+**The flow:**
+- Skip strategic thinking
+- Prompt AI for visual outputs
+- Generate variations
+- Present options
+- Let others decide strategy
+- Repeat endlessly
+
+**Your value:** Fast visual generation
+
+**Your career:** Commoditized (AI does this)
+
+### Path 2: Become a Strategic Thinker (Professional)
+
+**The flow:**
+- Forge strategy with AI partners
+- Create complete specifications
+- Generate visuals from strategic foundation
+- Present strategic solutions
+- Team aligns on substance
+- Implement correctly
+
+**Your value:** Strategic design thinking
+
+**Your career:** Essential (AI enables this, doesn't replace it)
+
+---
+
+## Why This Matters for You
+
+**WDS exists to elevate your role from pixel pusher to strategic thinker.**
+
+**The methodology empowers you:**
+- Saga helps you think strategically about business and users
+- Freya helps you forge complete UX specifications
+- Idunn helps you generate implementations
+
+**The guard rails keep you strategic:**
+- Every decision traces to business goals
+- Every design connects to user psychology
+- Every specification includes complete context
+
+**The economics work because:**
+- Strategic thinking: Cheap (AI-assisted)
+- Visual craft: Cheap (AI-assisted)
+- Your new value: **Strategic craft** (thinking + execution)
+
+**Skip the strategic thinking, and you're just a faster pixel pusher.**
+
+**Embrace strategic thinking, and you become indispensable.**
+
+**Why this matters for your career:**
+
+As businesses adopt WDS (or fork it for their own organizations), they'll need designers who can:
+- Work within strategic frameworks
+- Use AI for thinking, not just execution
+- Present polished strategic work, not half-baked prototypes
+- Operate autonomously while staying aligned
+
+**WDS-trained designers become essential** in organizations deploying strategic AI frameworks.
+
+Amateur vibe coders? They're why businesses need guard rails.
+
+**You're the professional who makes the guard rails work.**
+
+---
+
+## Key Takeaways
+
+✅ **THE WDS INSIGHT** - Strategic thinking got cheap too (not just code)
+
+✅ **Your role changed** - From pixel pusher to strategic thinker
+
+✅ **Everyone uses AI for code** - WDS uses AI for strategic thinking FIRST
+
+✅ **Vibe coding is amateur** - Generates pretty prototypes without substance
+
+✅ **Strategic craft is professional** - Forge thinking, then execute
+
+✅ **WDS gives you both** - Rocket ship (autonomy) + guard rails (strategy)
+
+✅ **Businesses can deploy WDS** - Fork it, customize guard rails, empower teams to make things that matter
+
+✅ **Present substance, not sketches** - Polished strategic thinking
+
+✅ **Your new value** - Strategic craft, not just visual craft
+
+---
+
+**Everyone knows AI made code cheap.**
+
+**The WDS insight: Strategic thinking got cheaper too.**
+
+**Everyone uses AI for code. WDS uses AI for strategic thinking first.**
+
+**Your role just changed: From pixel pusher to strategic thinker.**
+
+**WDS exists to help you step into this new role.**
+
+---
+
+**[Continue to Lesson 3: The Solution →](lesson-03-the-solution.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-the-problem.md) | [Module Overview](module-01-overview.md) | [Next: Lesson 3 →](lesson-03-the-solution.md)
+
+*Part of Module 01: Why WDS Matters*
diff --git a/docs/learn-wds/module-01-why-wds-matters/lesson-02-the-solution.md b/docs/learn/module-01-why-wds-matters/lesson-03-the-solution.md
similarity index 94%
rename from docs/learn-wds/module-01-why-wds-matters/lesson-02-the-solution.md
rename to docs/learn/module-01-why-wds-matters/lesson-03-the-solution.md
index baa72d58d..8ce3633c3 100644
--- a/docs/learn-wds/module-01-why-wds-matters/lesson-02-the-solution.md
+++ b/docs/learn/module-01-why-wds-matters/lesson-03-the-solution.md
@@ -1,6 +1,6 @@
 # Module 01: Why WDS Matters
 
-## Lesson 2: Becoming a Linchpin Designer
+## Lesson 3: Becoming a Linchpin Designer
 
 **The solution: WDS methodology**
 
@@ -68,8 +68,10 @@ You remain in the loop - the skilled, experienced designer who evaluates AI's wo
 
 Now that you understand the solution, let's explore what you'll learn and how to apply it.
 
-**[Continue to Lesson 3: The Path Forward →](lesson-03-the-path-forward.md)**
+**[Continue to Lesson 4: The Path Forward →](lesson-04-the-path-forward.md)**
 
 ---
 
-[← Back to Lesson 1: The Problem](lesson-01-the-problem.md) | [Next: The Path Forward →](lesson-03-the-path-forward.md)
+[← Back to Lesson 2: Designer as Strategic Thinker](lesson-02-designer-as-strategic-thinker.md) | [Module Overview](module-01-overview.md) | [Next: Lesson 4 →](lesson-04-the-path-forward.md)
+
+*Part of Module 01: Why WDS Matters*
diff --git a/docs/learn-wds/module-01-why-wds-matters/lesson-03-the-path-forward.md b/docs/learn/module-01-why-wds-matters/lesson-04-the-path-forward.md
similarity index 90%
rename from docs/learn-wds/module-01-why-wds-matters/lesson-03-the-path-forward.md
rename to docs/learn/module-01-why-wds-matters/lesson-04-the-path-forward.md
index d4f38244b..5894c4396 100644
--- a/docs/learn-wds/module-01-why-wds-matters/lesson-03-the-path-forward.md
+++ b/docs/learn/module-01-why-wds-matters/lesson-04-the-path-forward.md
@@ -1,6 +1,6 @@
 # Module 01: Why WDS Matters
 
-## Lesson 3: Your Transformation
+## Lesson 4: Your Transformation
 
 **From replaceable to indispensable**
 
@@ -75,20 +75,23 @@ _More case studies will be added here as they become available._
 You've completed Module 01: Why WDS Matters. You now understand:
 
 - ✅ The problem: Factory mindset vs linchpin mindset
+- ✅ The strategic shift: Designer as strategic thinker
 - ✅ The solution: Becoming a linchpin designer with WDS
 - ✅ The path forward: 5-dimensional thinking and transformation
 
 **Next steps:**
 
 - Review the practicalities if you haven't already
-- Start Module 02: Project Brief
+- Start Module 02: Installation & Setup
 - Apply these concepts to your own work
 
-**[Continue to Module 02: Project Brief →](../module-02-project-brief/lesson-01-inspiration.md)**
+**[Continue to Module 02: Installation & Setup →](../module-02-installation-setup/module-02-overview.md)**
 
-Or review the practicalities:
-**[Read Course Practicalities →](../00-practicalities.md)**
+Or review the getting started guide:
+**[Getting Started Guide →](../00-course-overview/00-getting-started-overview.md)**
 
 ---
 
-[← Back to Lesson 2](lesson-02-the-solution.md) | [Module Overview](module-01-overview.md) | [Next Module →](../module-02-project-brief/lesson-01-inspiration.md)
+[← Back to Lesson 3](lesson-03-the-solution.md) | [Module Overview](module-01-overview.md) | [Next Module →](../module-02-installation-setup/module-02-overview.md)
+
+*Part of Module 01: Why WDS Matters*
diff --git a/docs/learn-wds/module-01-why-wds-matters/module-01-overview.md b/docs/learn/module-01-why-wds-matters/module-01-overview.md
similarity index 77%
rename from docs/learn-wds/module-01-why-wds-matters/module-01-overview.md
rename to docs/learn/module-01-why-wds-matters/module-01-overview.md
index 7ce065f8e..28739f67b 100644
--- a/docs/learn-wds/module-01-why-wds-matters/module-01-overview.md
+++ b/docs/learn/module-01-why-wds-matters/module-01-overview.md
@@ -8,7 +8,7 @@
 
 This foundational module transforms how you think about your role as a designer in the AI era. You'll learn why mastering WDS makes you irreplaceable and how to become a linchpin designer - the person who makes things happen.
 
-**Time:** ~30 minutes (3 lessons × 10 min each)
+**Time:** ~40 minutes (4 lessons × 10 min each)
 **Prerequisites:** None - this is where you start!
 
 ---
@@ -38,7 +38,19 @@ Understanding the factory mindset and the AI era:
 - AI threat for cogs
 - AI opportunity for linchpin designers
 
-### [Lesson 2: Becoming a Linchpin Designer](lesson-02-the-solution.md)
+### [Lesson 2: Designer as Strategic Thinker](lesson-02-designer-as-strategic-thinker.md)
+
+**Time:** 10 minutes
+
+Your role just changed:
+
+- The shift everyone missed: strategic thinking got cheap too
+- Vibe coding vs strategic craft
+- The three eras of design
+- WDS: Your strategic rocket ship with guard rails
+- Present substance, not sketches
+
+### [Lesson 3: Becoming a Linchpin Designer](lesson-03-the-solution.md)
 
 **Time:** 10 minutes
 
@@ -50,7 +62,7 @@ The solution: WDS methodology:
 - From cog to linchpin designer
 - The paradigm shift: design becomes specification
 
-### [Lesson 3: Your Transformation](lesson-03-the-path-forward.md)
+### [Lesson 4: Your Transformation](lesson-04-the-path-forward.md)
 
 **Time:** 10 minutes
 
@@ -106,4 +118,10 @@ By the end of this module, you will:
 
 ---
 
-[← Back to Course Start](../00-start-here.md)
+## Next Module
+
+**[Module 02: Installation & Setup →](../module-02-installation-setup/module-02-overview.md)**
+
+---
+
+[← Back to Course Overview](../00-course-overview/00-course-overview.md)
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/02-full-lesson.md b/docs/learn/module-02-installation-setup/lesson-01-git-setup.md
similarity index 77%
rename from docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/02-full-lesson.md
rename to docs/learn/module-02-installation-setup/lesson-01-git-setup.md
index 2e3882eac..36691245f 100644
--- a/docs/learn-wds/module-02-installation-setup/lesson-01-git-setup/02-full-lesson.md
+++ b/docs/learn/module-02-installation-setup/lesson-01-git-setup.md
@@ -1,4 +1,6 @@
-# Lesson 01: Git Setup
+# Module 02: Installation & Setup
+
+## Lesson 1: Git Setup
 
 **Create GitHub account and project repository**
 
@@ -40,9 +42,9 @@ Professional cloud storage + time machine for your project files. Every change i
 
 ## Part 2: Choose Your Scenario
 
-**Scenario A:** Starting new project → Continue to Part 3  
-**Scenario B:** Joining existing → Skip to Part 5  
-**Scenario C:** Just learning → Skip to [Lesson 02](../lesson-02-ide-installation/02-full-lesson.md)
+**Scenario A:** Starting new project → Continue to Part 3
+**Scenario B:** Joining existing → Skip to Part 5
+**Scenario C:** Just learning → Skip to [Lesson 02](lesson-02-ide-installation.md)
 
 ---
 
@@ -86,7 +88,7 @@ Professional cloud storage + time machine for your project files. Every change i
 ```
 Hi [Name],
 
-I'd like to contribute to [project-name] using WDS methodology. 
+I'd like to contribute to [project-name] using WDS methodology.
 Could you add me as a collaborator?
 
 My GitHub username: [your-username]
@@ -105,8 +107,8 @@ Thank you!
 
 ## Troubleshooting
 
-**Issue:** Verification email missing → Check spam  
-**Issue:** Username taken → Try `yourname-designer-2`  
+**Issue:** Verification email missing → Check spam
+**Issue:** Username taken → Try `yourname-designer-2`
 **Issue:** Repository name taken → Add your username
 
 ---
@@ -115,10 +117,9 @@ Thank you!
 
 GitHub account and repository ready! Now install your IDE.
 
-**[Continue to Lesson 02: IDE Installation →](../lesson-02-ide-installation/02-full-lesson.md)**
+**[Continue to Lesson 02: IDE Installation →](lesson-02-ide-installation.md)**
 
 ---
 
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
-
+*Part of Module 02: Installation & Setup*
+*[← Back to Module Overview](module-02-overview.md)*
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-full-lesson.md b/docs/learn/module-02-installation-setup/lesson-02-ide-installation.md
similarity index 79%
rename from docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-full-lesson.md
rename to docs/learn/module-02-installation-setup/lesson-02-ide-installation.md
index 208385cf1..516efdbe2 100644
--- a/docs/learn-wds/module-02-installation-setup/lesson-02-ide-installation/02-full-lesson.md
+++ b/docs/learn/module-02-installation-setup/lesson-02-ide-installation.md
@@ -1,4 +1,6 @@
-# Lesson 02: IDE Installation
+# Module 02: Installation & Setup
+
+## Lesson 2: IDE Installation
 
 **Get your workspace ready**
 
@@ -69,8 +71,8 @@ Press **Ctrl+`** (Win/Linux) or **Cmd+`** (Mac)
 
 ## Troubleshooting
 
-**Issue:** Can't find download → Check Downloads folder  
-**Issue:** Mac "unidentified developer" → Right-click → Open  
+**Issue:** Can't find download → Check Downloads folder
+**Issue:** Mac "unidentified developer" → Right-click → Open
 **Issue:** Terminal won't open → View menu → Terminal → New Terminal
 
 ---
@@ -79,10 +81,9 @@ Press **Ctrl+`** (Win/Linux) or **Cmd+`** (Mac)
 
 IDE ready! Now clone your Git repository.
 
-**[Continue to Lesson 03: Git Repository Cloning →](../lesson-03-git-cloning/02-full-lesson.md)**
+**[Continue to Lesson 03: Git Repository Cloning →](lesson-03-git-cloning.md)**
 
 ---
 
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
-
+*Part of Module 02: Installation & Setup*
+*[← Back to Module Overview](module-02-overview.md)*
diff --git a/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/02-full-lesson.md b/docs/learn/module-02-installation-setup/lesson-03-git-cloning.md
similarity index 81%
rename from docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/02-full-lesson.md
rename to docs/learn/module-02-installation-setup/lesson-03-git-cloning.md
index e7632e3b7..fee31bbf6 100644
--- a/docs/learn-wds/module-02-installation-setup/lesson-03-git-cloning/02-full-lesson.md
+++ b/docs/learn/module-02-installation-setup/lesson-03-git-cloning.md
@@ -1,4 +1,6 @@
-# Lesson 03: Git Repository Cloning
+# Module 02: Installation & Setup
+
+## Lesson 3: Git Repository Cloning
 
 **Clone your project to your computer**
 
@@ -42,7 +44,7 @@ cd ~/Projects
 1. Go to your repository on GitHub
 2. Click green **"Code"** button
 3. Make sure **"HTTPS"** selected
-4. Click copy icon (📋)
+4. Click copy icon
 
 **Your URL:** `https://github.com/your-username/your-project.git`
 
@@ -92,20 +94,19 @@ git clone https://github.com/john-designer/dog-walker-app.git
 
 ## Troubleshooting
 
-**Issue:** "Git command not found" → Let IDE install when prompted  
-**Issue:** "Permission denied" → Sign into GitHub in IDE  
+**Issue:** "Git command not found" → Let IDE install when prompted
+**Issue:** "Permission denied" → Sign into GitHub in IDE
 **Issue:** Clone fails → Check URL copied correctly
 
 ---
 
 ## What's Next?
 
-Project cloned! Now initialize WDS and meet Mimir.
+Project cloned! Now install WDS and start designing.
 
-**[Continue to Lesson 04: WDS Project Initialization →](../lesson-04-wds-initialization/02-full-lesson.md)**
+**[Continue to Lesson 04: WDS Project Initialization →](lesson-04-wds-initialization.md)**
 
 ---
 
-*Part of Module 02: Installation & Setup*  
-*[← Back to Module Overview](../module-02-overview.md)*
-
+*Part of Module 02: Installation & Setup*
+*[← Back to Module Overview](module-02-overview.md)*
diff --git a/docs/learn/module-02-installation-setup/lesson-04-wds-initialization.md b/docs/learn/module-02-installation-setup/lesson-04-wds-initialization.md
new file mode 100644
index 000000000..296824a2d
--- /dev/null
+++ b/docs/learn/module-02-installation-setup/lesson-04-wds-initialization.md
@@ -0,0 +1,135 @@
+# Module 02: Installation & Setup
+
+## Lesson 4: WDS Project Initialization
+
+**Install WDS and activate your first agent**
+
+---
+
+## What You'll Do
+
+- Install WDS via the CLI installer
+- Understand the folder structure
+- Activate an agent and start working
+
+**Time:** 10-15 minutes
+
+---
+
+## Step 1: Install WDS
+
+Navigate to your project folder in the terminal:
+
+```bash
+cd ~/Projects/your-project-name  # Mac/Linux
+cd C:\Projects\your-project-name # Windows
+```
+
+Run the installer:
+
+```bash
+npx whiteport-design-studio install
+```
+
+The installer will guide you through:
+- **Project type** — What kind of product you're designing
+- **Experience level** — Beginner, Intermediate, or Expert
+- **IDE configuration** — Sets up your AI IDE automatically
+
+**✅ Checkpoint:** Installer completes, `_wds/` folder appears in your project
+
+---
+
+## Step 2: Understand the Structure
+
+After installation, your project has:
+
+```
+your-project/
+├── _wds/                    ← WDS system files
+│   ├── agents/              ← Agent files (.md)
+│   │   ├── saga-analyst.md
+│   │   ├── freya-ux.md
+│   │   └── idunn-pm.md
+│   ├── workflows/           ← Phase workflows
+│   ├── data/                ← Standards, frameworks
+│   ├── gems/                ← Reusable prompt components
+│   ├── templates/           ← Document templates
+│   └── config.yaml          ← Your project configuration
+├── _wds-learn/              ← Learning material (optional)
+├── docs/                    ← Design output (created by agents)
+│   ├── A-Product-Brief/
+│   ├── B-Trigger-Map/
+│   ├── C-UX-Scenarios/
+│   ├── D-Design-System/
+│   ├── E-PRD/
+│   └── F-Agent-Dialogs/
+└── .claude/instructions.md  ← IDE configuration
+```
+
+**Key insight:** `_wds/` contains the methodology. `docs/` is where your design work lives.
+
+---
+
+## Step 3: Activate an Agent
+
+WDS has three specialized agents:
+
+| Agent | What they do | When to use |
+|-------|-------------|-------------|
+| **Saga** | Business & Product Analyst | Product Brief, Trigger Mapping |
+| **Freya** | UX/UI Designer | Scenarios, UX Design, Visual Design |
+| **Idunn** | Project Manager | Platform Requirements, Design System |
+
+### Start with Saga
+
+For a new project, start with Saga to create your Product Brief:
+
+Tell your AI IDE:
+
+```
+Read and activate the agent in _wds/agents/saga-analyst.md
+```
+
+Saga will:
+- Introduce herself
+- Scan your project for existing WDS work
+- Guide you to the right starting point
+
+**✅ Checkpoint:** Saga responds and welcomes you!
+
+---
+
+## Troubleshooting
+
+**Issue:** `npx` command not found → Install Node.js from <https://nodejs.org>
+**Issue:** Installer fails → Make sure you're in your project folder
+**Issue:** Agent file not found → Check `_wds/agents/` folder exists
+
+---
+
+## Congratulations!
+
+You've completed Module 02: Installation & Setup!
+
+**What you accomplished:**
+- ✅ GitHub account & repository
+- ✅ IDE installed
+- ✅ Project cloned
+- ✅ WDS installed
+- ✅ Agent activated
+
+**You're ready to design with WDS!**
+
+---
+
+## What's Next?
+
+- **[Module 03: Alignment & Signoff](../module-03-alignment-signoff/module-03-overview.md)**
+- **[WDS Training Course](../00-course-overview/00-course-overview.md)**
+- **Ask Saga:** "What should I do next?"
+
+---
+
+*Part of Module 02: Installation & Setup*
+*[← Back to Module Overview](module-02-overview.md)*
diff --git a/docs/learn/module-02-installation-setup/module-02-overview.md b/docs/learn/module-02-installation-setup/module-02-overview.md
new file mode 100644
index 000000000..a977916a3
--- /dev/null
+++ b/docs/learn/module-02-installation-setup/module-02-overview.md
@@ -0,0 +1,59 @@
+# Module 02: Installation & Setup
+
+**From zero to WDS-ready - complete beginner friendly**
+
+---
+
+## Overview
+
+This module takes you from having nothing to being fully set up with WDS, even if you've never used GitHub or an IDE before.
+
+**Time:** 45-60 minutes total
+**Difficulty:** Beginner
+**Prerequisites:** Computer + Internet + Email
+
+---
+
+## Lessons
+
+### [Lesson 01: Git Setup](lesson-01-git-setup.md)
+**15-20 minutes** | Create GitHub account and repository
+
+### [Lesson 02: IDE Installation](lesson-02-ide-installation.md)
+**10 minutes** | Install Cursor or VS Code
+
+### [Lesson 03: Git Repository Cloning](lesson-03-git-cloning.md)
+**10 minutes** | Clone your project to your computer
+
+### [Lesson 04: WDS Project Initialization](lesson-04-wds-initialization.md)
+**10-15 minutes** | Install WDS, activate your first agent
+
+---
+
+## Quick Start
+
+**Want the fastest path?**
+
+Follow the combined checklist: [Tutorial: Quick Checklist →](tutorial-02.md)
+
+**Want detailed explanations?**
+
+Follow the lessons: [Start with Lesson 01 →](lesson-01-git-setup.md)
+
+---
+
+## After This Module
+
+- ✅ GitHub account and repository
+- ✅ IDE installed and configured
+- ✅ Project cloned to your computer
+- ✅ WDS installed in project
+- ✅ Docs folder structure created
+- ✅ Agent activated and ready
+
+**Next:** [Module 03: Alignment & Signoff](../module-03-alignment-signoff/module-03-overview.md)
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
+*[← Back to Course Overview](../00-course-overview/00-course-overview.md)*
diff --git a/docs/learn/module-02-installation-setup/tutorial-02.md b/docs/learn/module-02-installation-setup/tutorial-02.md
new file mode 100644
index 000000000..3246790ac
--- /dev/null
+++ b/docs/learn/module-02-installation-setup/tutorial-02.md
@@ -0,0 +1,158 @@
+# Module 02: Installation & Setup — Quick Checklist
+
+**The fastest path from zero to WDS-ready**
+
+**⏱️ 45-60 minutes total**
+
+Just the action items. For detailed explanations, see the individual lessons.
+
+---
+
+## Lesson 01: Git Setup (15-20 min)
+
+*[Full lesson →](lesson-01-git-setup.md)*
+
+### Create GitHub Account
+
+- [ ] Go to **<https://github.com>**
+- [ ] Click **"Sign up"**
+- [ ] Enter email, password, username (professional: `yourname-designer`)
+- [ ] Verify email
+- [ ] ✅ Log in successful
+
+### Choose Your Scenario
+
+- [ ] **A:** Starting new project → Continue below
+- [ ] **B:** Joining existing → Skip to "Join Existing"
+- [ ] **C:** Just learning → Skip to Lesson 02 below
+
+### Create New Repository
+
+- [ ] Click profile icon → **"Your repositories"** → **"New"**
+
+**Decide: Single or Separate?**
+
+- [ ] **Single repo:** `my-project` (specs + code together, small teams)
+- [ ] **Separate repo:** `my-project-specs` (specs only, corporate/many devs)
+
+**Repository Settings:**
+
+- [ ] Name: `_____________` (lowercase-with-hyphens)
+- [ ] Description: One-liner about project
+- [ ] Public or Private
+- [ ] ☑️ Check "Initialize with README"
+- [ ] Click **"Create repository"**
+- [ ] ✅ Repository created
+
+### Join Existing Repository
+
+- [ ] Ask owner for access (see [full lesson](lesson-01-git-setup.md) for email template)
+- [ ] Accept invitation from email
+- [ ] Check repo structure
+- [ ] ✅ Access granted
+
+---
+
+## Lesson 02: IDE Installation (10 min)
+
+*[Full lesson →](lesson-02-ide-installation.md)*
+
+### Choose IDE
+
+- [ ] **Cursor** (recommended) → <https://cursor.sh>
+- [ ] **VS Code** (alternative) → <https://code.visualstudio.com>
+
+### Install
+
+- [ ] Download installer
+- [ ] **Windows:** Run `.exe`, click through
+- [ ] **Mac:** Drag to Applications, open
+- [ ] **Linux:** Follow distro instructions
+
+### First Launch
+
+- [ ] Choose theme (Light/Dark)
+- [ ] Sign in with GitHub → Yes!
+- [ ] Install recommended extensions → Yes
+- [ ] ✅ IDE open
+
+### Verify Terminal
+
+- [ ] Press **Ctrl+`** (Win/Linux) or **Cmd+`** (Mac)
+- [ ] ✅ Terminal panel appears
+
+---
+
+## Lesson 03: Git Repository Cloning (10 min)
+
+*[Full lesson →](lesson-03-git-cloning.md)*
+
+### Create Projects Folder
+
+In terminal (**Ctrl+`** or **Cmd+`**):
+
+```bash
+# Windows
+mkdir C:\Projects
+cd C:\Projects
+
+# Mac/Linux
+mkdir ~/Projects
+cd ~/Projects
+```
+
+- [ ] ✅ Projects folder created
+
+### Clone Your Repository
+
+- [ ] Go to your repo on GitHub → Click **"Code"** → Copy URL
+- [ ] In terminal: `git clone [paste-url]`
+- [ ] (If prompted: Install Git → Click "Install")
+- [ ] ✅ "done" message
+
+### Open Project in IDE
+
+- [ ] **File** → **Open Folder**
+- [ ] Select your project folder
+- [ ] ✅ Project in sidebar
+
+---
+
+## Lesson 04: WDS Initialization (10-15 min)
+
+*[Full lesson →](lesson-04-wds-initialization.md)*
+
+### Install WDS
+
+In terminal (in YOUR project folder):
+
+```bash
+cd ~/Projects/your-project-name  # or cd C:\Projects\your-project-name
+npx whiteport-design-studio install
+```
+
+- [ ] Follow the installer prompts (project type, experience level, IDE)
+- [ ] ✅ `_wds/` folder appears in your project
+
+### Activate an Agent
+
+- [ ] Tell your AI IDE: `Read and activate the agent in _wds/agents/saga-analyst.md`
+- [ ] ✅ Saga responds and welcomes you!
+
+---
+
+## Complete!
+
+- ✅ GitHub account & repository
+- ✅ IDE installed
+- ✅ Project cloned
+- ✅ WDS installed
+- ✅ Agent activated
+
+**Next:** [Module 03: Alignment & Signoff](../module-03-alignment-signoff/module-03-overview.md)
+
+---
+
+[← Back to Module Overview](module-02-overview.md)
+
+*Part of Module 02: Installation & Setup*
diff --git a/docs/learn-wds/module-03-alignment-signoff/lesson-01-understanding-alignment.md b/docs/learn/module-03-alignment-signoff/lesson-01-understanding-alignment.md
similarity index 97%
rename from docs/learn-wds/module-03-alignment-signoff/lesson-01-understanding-alignment.md
rename to docs/learn/module-03-alignment-signoff/lesson-01-understanding-alignment.md
index 61ebf5453..062e4e2a9 100644
--- a/docs/learn-wds/module-03-alignment-signoff/lesson-01-understanding-alignment.md
+++ b/docs/learn/module-03-alignment-signoff/lesson-01-understanding-alignment.md
@@ -1,4 +1,6 @@
-# Lesson 1: Understanding Alignment
+# Module 03: Alignment & Signoff
+
+## Lesson 1: Understanding Alignment
 
 **Why alignment matters before starting work - and why understanding comes first**
 
@@ -132,7 +134,7 @@ Before you can create an alignment document, you need to understand what success
 - You have full autonomy
 - You don't need stakeholder approval
 
-**Go directly to:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
+**Go directly to:** [Module 04: Product Brief](../module-04-product-brief/module-04-overview.md)
 
 ---
 
@@ -173,3 +175,5 @@ Before you can create an alignment document, you need to understand what success
 
 [← Back to Module Overview](module-03-overview.md)
 
+
+*Part of Module 03: Alignment & Signoff*
diff --git a/docs/learn-wds/module-03-alignment-signoff/lesson-02-creating-alignment-document.md b/docs/learn/module-03-alignment-signoff/lesson-02-creating-alignment-document.md
similarity index 98%
rename from docs/learn-wds/module-03-alignment-signoff/lesson-02-creating-alignment-document.md
rename to docs/learn/module-03-alignment-signoff/lesson-02-creating-alignment-document.md
index cf4052aa3..483c658fe 100644
--- a/docs/learn-wds/module-03-alignment-signoff/lesson-02-creating-alignment-document.md
+++ b/docs/learn/module-03-alignment-signoff/lesson-02-creating-alignment-document.md
@@ -1,4 +1,6 @@
-# Lesson 2: Creating Your Alignment Document
+# Module 03: Alignment & Signoff
+
+## Lesson 2: Creating Your Alignment Document
 
 **The 10 sections that ensure everyone understands and agrees - AFTER you've done discovery**
 
@@ -287,3 +289,5 @@ Work through these sections **in whatever order makes sense** for your thinking:
 
 [← Back to Module Overview](module-03-overview.md)
 
+
+*Part of Module 03: Alignment & Signoff*
diff --git a/docs/learn-wds/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md b/docs/learn/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md
similarity index 92%
rename from docs/learn-wds/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md
rename to docs/learn/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md
index b1181c1a4..818dd52a0 100644
--- a/docs/learn-wds/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md
+++ b/docs/learn/module-03-alignment-signoff/lesson-03-negotiation-acceptance.md
@@ -1,4 +1,6 @@
-# Lesson 3: Negotiation & Acceptance
+# Module 03: Alignment & Signoff
+
+## Lesson 3: Negotiation & Acceptance
 
 **Getting everyone on the same page**
 
@@ -109,7 +111,9 @@
 
 ---
 
-**Next:** [Lesson 4: Securing Commitment →](lesson-04-securing-commitment.md)
+**Next:** [Lesson 4: Securing Commitment →](lesson-04-external-contracts.md)
 
 [← Back to Module Overview](module-03-overview.md)
 
+
+*Part of Module 03: Alignment & Signoff*
diff --git a/docs/learn-wds/module-03-alignment-signoff/lesson-04-external-contracts.md b/docs/learn/module-03-alignment-signoff/lesson-04-external-contracts.md
similarity index 95%
rename from docs/learn-wds/module-03-alignment-signoff/lesson-04-external-contracts.md
rename to docs/learn/module-03-alignment-signoff/lesson-04-external-contracts.md
index 04cd4a24e..e5adcaf49 100644
--- a/docs/learn-wds/module-03-alignment-signoff/lesson-04-external-contracts.md
+++ b/docs/learn/module-03-alignment-signoff/lesson-04-external-contracts.md
@@ -1,4 +1,6 @@
-# Lesson 4: External Contracts
+# Module 03: Alignment & Signoff
+
+## Lesson 4: External Contracts
 
 **Formalizing alignment with external contracts**
 
@@ -183,9 +185,9 @@
 - ✅ Alignment achieved
 - ✅ Commitment secured
 - ✅ Legal protection in place
-- ✅ Ready to proceed to Project Brief
+- ✅ Ready to proceed to Product Brief
 
-**Next:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
+**Next:** [Module 04: Product Brief](../module-04-product-brief/module-04-overview.md)
 
 ---
 
@@ -199,3 +201,5 @@
 
 [← Back to Module Overview](module-03-overview.md)
 
+
+*Part of Module 03: Alignment & Signoff*
diff --git a/docs/learn-wds/module-03-alignment-signoff/lesson-05-internal-signoff.md b/docs/learn/module-03-alignment-signoff/lesson-05-internal-signoff.md
similarity index 95%
rename from docs/learn-wds/module-03-alignment-signoff/lesson-05-internal-signoff.md
rename to docs/learn/module-03-alignment-signoff/lesson-05-internal-signoff.md
index a75b966d4..5d87ab4e7 100644
--- a/docs/learn-wds/module-03-alignment-signoff/lesson-05-internal-signoff.md
+++ b/docs/learn/module-03-alignment-signoff/lesson-05-internal-signoff.md
@@ -1,4 +1,6 @@
-# Lesson 5: Internal Signoff Documents
+# Module 03: Alignment & Signoff
+
+## Lesson 5: Internal Signoff Documents
 
 **Formalizing alignment for internal company projects**
 
@@ -171,9 +173,9 @@
 - ✅ Internal alignment achieved
 - ✅ Budget/resources committed
 - ✅ Stakeholders on board
-- ✅ Ready to proceed to Project Brief
+- ✅ Ready to proceed to Product Brief
 
-**Next:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
+**Next:** [Module 04: Product Brief](../module-04-product-brief/module-04-overview.md)
 
 ---
 
@@ -187,3 +189,5 @@
 
 [← Back to Module Overview](module-03-overview.md) | [Previous: Lesson 4: External Contracts →](lesson-04-external-contracts.md)
 
+
+*Part of Module 03: Alignment & Signoff*
diff --git a/docs/learn-wds/module-03-alignment-signoff/module-03-overview.md b/docs/learn/module-03-alignment-signoff/module-03-overview.md
similarity index 94%
rename from docs/learn-wds/module-03-alignment-signoff/module-03-overview.md
rename to docs/learn/module-03-alignment-signoff/module-03-overview.md
index 25a180e15..1da22917b 100644
--- a/docs/learn-wds/module-03-alignment-signoff/module-03-overview.md
+++ b/docs/learn/module-03-alignment-signoff/module-03-overview.md
@@ -126,7 +126,7 @@ Step-by-step hands-on guide to creating your alignment document and securing sig
 6. **Get acceptance** - Accept: They say yes to the pitch
 7. **Generate signoff** - Contract: Create short, clear contract based on accepted pitch
 8. **Sign** - Both parties sign
-9. **Proceed to Project Brief** - Brief: Use pitch and contract as the backbone
+9. **Proceed to Product Brief** - Brief: Use pitch and contract as the backbone
 
 **Key:** Pitch and contract become the foundation for your project brief - not throwaway documents.
 
@@ -143,7 +143,7 @@ By the end of this module, you will:
 - ✅ Know how to create a compelling alignment document based on real understanding
 - ✅ Be able to negotiate and iterate until acceptance
 - ✅ Generate appropriate external contracts or internal signoff documents
-- ✅ Know when to skip this module and go straight to Project Brief
+- ✅ Know when to skip this module and go straight to Product Brief
 
 ---
 
@@ -154,7 +154,7 @@ By the end of this module, you will:
 - You have full autonomy
 - You don't need stakeholder approval
 
-**Go directly to:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
+**Go directly to:** [Module 04: Product Brief](../module-04-product-brief/module-04-overview.md)
 
 ---
 
@@ -164,7 +164,7 @@ By the end of this module, you will:
 
 ---
 
-[← Back to Course Overview](../00-course-overview.md) | [Next: Module 04: Create Project Brief →](../module-04-project-brief/tutorial-04.md)
+[← Back to Course Overview](../00-course-overview/00-course-overview.md) | [Next: Module 04: Product Brief →](../module-04-product-brief/module-04-overview.md)
 
 *Part of the WDS Course: From Designer to Linchpin*
 
diff --git a/docs/learn-wds/module-03-alignment-signoff/tutorial-03.md b/docs/learn/module-03-alignment-signoff/tutorial-03.md
similarity index 97%
rename from docs/learn-wds/module-03-alignment-signoff/tutorial-03.md
rename to docs/learn/module-03-alignment-signoff/tutorial-03.md
index 74f69edb9..335fc0d91 100644
--- a/docs/learn-wds/module-03-alignment-signoff/tutorial-03.md
+++ b/docs/learn/module-03-alignment-signoff/tutorial-03.md
@@ -53,7 +53,7 @@ This tutorial walks you through the professional process of understanding what y
 - **Consultant proposing to client** → Discovery will help you understand their business needs
 - **Business hiring suppliers** → Discovery will help you clarify what you're buying
 - **Manager/employee seeking approval** → Discovery will help you understand stakeholder priorities
-- **Doing it yourself** → Skip this tutorial, go to Module 04: Create Project Brief
+- **Doing it yourself** → Skip this tutorial, go to Module 04: Create Product Brief
 
 **Your scenario:** [Write your scenario here]
 
@@ -278,7 +278,7 @@ The Strategic Professional emphasizes: "Long contracts are hard to understand, a
 - ✅ Foundation established
 - ✅ Pitch and contract ready to become backbone of project brief
 
-**The connection:** The pitch and contract aren't throwaway documents. When you move to Module 04 to create your Project Brief, these documents become the foundation. The brief builds on the alignment and legal framework you've established.
+**The connection:** The pitch and contract aren't throwaway documents. When you move to Module 04 to create your Product Brief, these documents become the foundation. The brief builds on the alignment and legal framework you've established.
 
 **Workflow complete:**
 1. ✅ Listen - Discovery meeting
@@ -290,7 +290,7 @@ The Strategic Professional emphasizes: "Long contracts are hard to understand, a
 7. ✅ Sign - Both parties committed
 8. ➡️ **Next:** Brief - Use pitch and contract as backbone
 
-**Next:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
+**Next:** [Module 04: Product Brief](../module-04-product-brief/module-04-overview.md)
 
 ---
 
@@ -303,7 +303,7 @@ You've completed this tutorial when:
 - ✅ Alignment document shared in presentation meeting
 - ✅ Stakeholders have accepted (everyone aligned)
 - ✅ Signoff document generated and ready for signature
-- ✅ Ready to proceed to Project Brief
+- ✅ Ready to proceed to Product Brief
 
 ---
 
@@ -334,11 +334,11 @@ A: Variable - discovery meeting (30-60 min), document creation (30-60 min), pres
 
 ## Next Steps
 
-**[Continue to Module 04: Create Project Brief →](../module-04-project-brief/tutorial-04.md)**
+**[Continue to Module 04: Product Brief →](../module-04-product-brief/module-04-overview.md)**
 
 ---
 
-[← Back to Module Overview](module-03-overview.md) | [Back to Course Overview](../00-course-overview.md)
+[← Back to Module Overview](module-03-overview.md) | [Back to Course Overview](../00-course-overview/00-course-overview.md)
 
-*Part of the WDS Course: From Designer to Linchpin*
+*Part of Module 03: Alignment & Signoff*
 
diff --git a/docs/learn-wds/module-04-product-brief/lesson-01-chaos-problem.md b/docs/learn/module-04-product-brief/lesson-01-chaos-problem.md
similarity index 99%
rename from docs/learn-wds/module-04-product-brief/lesson-01-chaos-problem.md
rename to docs/learn/module-04-product-brief/lesson-01-chaos-problem.md
index 9be5c5e6f..4acd4a441 100644
--- a/docs/learn-wds/module-04-product-brief/lesson-01-chaos-problem.md
+++ b/docs/learn/module-04-product-brief/lesson-01-chaos-problem.md
@@ -191,3 +191,5 @@ In the next lesson, we'll explore the 5 strategic questions that every Product B
 ---
 
 [← Back to Module Overview](module-04-overview.md)
+
+*Part of Module 04: Product Brief*
diff --git a/docs/learn-wds/module-04-product-brief/lesson-02-five-questions.md b/docs/learn/module-04-product-brief/lesson-02-five-questions.md
similarity index 99%
rename from docs/learn-wds/module-04-product-brief/lesson-02-five-questions.md
rename to docs/learn/module-04-product-brief/lesson-02-five-questions.md
index 7ca1fd8c1..2393608fe 100644
--- a/docs/learn-wds/module-04-product-brief/lesson-02-five-questions.md
+++ b/docs/learn/module-04-product-brief/lesson-02-five-questions.md
@@ -362,3 +362,5 @@ In the next lesson, we'll look at what a Product Brief actually looks like - the
 ---
 
 [← Back to Lesson 1](lesson-01-chaos-problem.md) | [Back to Module Overview](module-04-overview.md)
+
+*Part of Module 04: Product Brief*
diff --git a/docs/learn-wds/module-04-product-brief/lesson-03-document-structure.md b/docs/learn/module-04-product-brief/lesson-03-document-structure.md
similarity index 99%
rename from docs/learn-wds/module-04-product-brief/lesson-03-document-structure.md
rename to docs/learn/module-04-product-brief/lesson-03-document-structure.md
index 39d58f6b7..64f5db6f7 100644
--- a/docs/learn-wds/module-04-product-brief/lesson-03-document-structure.md
+++ b/docs/learn/module-04-product-brief/lesson-03-document-structure.md
@@ -27,7 +27,7 @@ It's a 2-3 page strategic document that answers the 5 critical questions clearly
 Here's what a Product Brief looks like:
 
 ```markdown
-# Project Brief: [Project Name]
+# Product Brief: [Project Name]
 
 ## Vision
 
@@ -386,3 +386,5 @@ In the next lesson, we'll explore how WDS makes creating this document fast thro
 ---
 
 [← Back to Lesson 2](lesson-02-five-questions.md) | [Back to Module Overview](module-04-overview.md)
+
+*Part of Module 04: Product Brief*
diff --git a/docs/learn-wds/module-04-product-brief/lesson-04-wds-advantage.md b/docs/learn/module-04-product-brief/lesson-04-wds-advantage.md
similarity index 98%
rename from docs/learn-wds/module-04-product-brief/lesson-04-wds-advantage.md
rename to docs/learn/module-04-product-brief/lesson-04-wds-advantage.md
index e74cb1dea..fabeb7d2c 100644
--- a/docs/learn-wds/module-04-product-brief/lesson-04-wds-advantage.md
+++ b/docs/learn/module-04-product-brief/lesson-04-wds-advantage.md
@@ -173,9 +173,9 @@ You see the document building in real-time:
 
 **How it works:**
 
-**SMART Goal Validation:**
+**Applying the SMART Model:**
 - You: "We want to increase engagement"
-- Saga: "Let's make that measurable - by how much and by when?"
+- Saga: "Let's make that measurable using SMART - by how much and by when?"
 - You: "40% increase in daily active users within 3 months"
 - Saga: "Perfect - that's specific, measurable, and time-bound"
 
@@ -400,3 +400,5 @@ In the next lesson, we'll explore how teams actually use the Product Brief throu
 ---
 
 [← Back to Lesson 3](lesson-03-document-structure.md) | [Back to Module Overview](module-04-overview.md)
+
+*Part of Module 04: Product Brief*
diff --git a/docs/learn-wds/module-04-product-brief/lesson-05-using-brief.md b/docs/learn/module-04-product-brief/lesson-05-using-brief.md
similarity index 99%
rename from docs/learn-wds/module-04-product-brief/lesson-05-using-brief.md
rename to docs/learn/module-04-product-brief/lesson-05-using-brief.md
index 7061fd274..48831e84e 100644
--- a/docs/learn-wds/module-04-product-brief/lesson-05-using-brief.md
+++ b/docs/learn/module-04-product-brief/lesson-05-using-brief.md
@@ -489,3 +489,5 @@ In the final lesson, we'll explore the additional strategic documents you can cr
 ---
 
 [← Back to Lesson 4](lesson-04-wds-advantage.md) | [Back to Module Overview](module-04-overview.md)
+
+*Part of Module 04: Product Brief*
diff --git a/docs/learn-wds/module-04-product-brief/lesson-06-additional-documents.md b/docs/learn/module-04-product-brief/lesson-06-additional-documents.md
similarity index 98%
rename from docs/learn-wds/module-04-product-brief/lesson-06-additional-documents.md
rename to docs/learn/module-04-product-brief/lesson-06-additional-documents.md
index b2bd8a6e3..b974a6083 100644
--- a/docs/learn-wds/module-04-product-brief/lesson-06-additional-documents.md
+++ b/docs/learn/module-04-product-brief/lesson-06-additional-documents.md
@@ -630,7 +630,7 @@ You now understand:
 - Make it your single source of truth
 
 **4. Continue to Module 05**
-- [Module 05: Trigger Mapping](../module-05-trigger-mapping/module-05-overview.md)
+- [Module 05: Platform Requirements](../module-05-platform-requirements/module-05-platform-requirements-overview.md)
 - Understanding user psychology
 - Connecting business goals to user needs
 
@@ -643,3 +643,5 @@ You now understand:
 [← Back to Lesson 5](lesson-05-using-brief.md) | [Back to Module Overview](module-04-overview.md)
 
 *Congratulations on completing Module 04! You now have the foundation to create strategic clarity for any project.*
+
+*Part of Module 04: Product Brief*
diff --git a/docs/learn-wds/module-04-product-brief/module-04-overview.md b/docs/learn/module-04-product-brief/module-04-overview.md
similarity index 94%
rename from docs/learn-wds/module-04-product-brief/module-04-overview.md
rename to docs/learn/module-04-product-brief/module-04-overview.md
index 967ff9679..1e8807012 100644
--- a/docs/learn-wds/module-04-product-brief/module-04-overview.md
+++ b/docs/learn/module-04-product-brief/module-04-overview.md
@@ -72,7 +72,7 @@ The unique features that ensure excellence:
 - AI-guided discovery (no blank page paralysis)
 - Conversational approach (talk it out, Saga writes it down)
 - Structured output (proper formatting automatically)
-- Built-in best practices (SMART goals, constraint checklists)
+- Built-in best practices (the SMART model, constraint checklists)
 - Two levels: Simplified vs Complete (based on project needs)
 
 ### [Lesson 5: Using Your Product Brief](lesson-05-using-brief.md)
@@ -135,13 +135,13 @@ Step-by-step hands-on guide to creating your Product Brief with Saga.
 - **Speed:** 30-45 min vs days of meetings
 - **AI-Guided:** Saga asks the right questions, no blank page
 - **Conversational:** Natural dialogue, not form-filling
-- **Professional:** Built-in best practices (SMART goals, checklists)
+- **Professional:** Built-in best practices (the SMART model, checklists)
 - **Flexible:** Two levels (simplified vs complete)
 - **Living:** Easy to update as you learn
 
 **Additional Documents:**
 - Optional strategic documents created as needed
-- All live in Project Brief folder
+- All live in Product Brief folder
 - Same conversational approach with Saga
 - Expand foundation based on project complexity
 
@@ -189,6 +189,6 @@ By the end of this module, you will:
 
 ---
 
-[← Back to Course Overview](../00-course-overview.md) | [Next: Module 05: Trigger Mapping →](../module-05-trigger-mapping/module-05-overview.md)
+[← Back to Course Overview](../00-course-overview/00-course-overview.md) | [Next: Module 05: Platform Requirements →](../module-05-platform-requirements/module-05-platform-requirements-overview.md)
 
 *Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn-wds/module-04-product-brief/tutorial-04.md b/docs/learn/module-04-product-brief/tutorial-04.md
similarity index 92%
rename from docs/learn-wds/module-04-product-brief/tutorial-04.md
rename to docs/learn/module-04-product-brief/tutorial-04.md
index 2e7cfcb77..35ba66445 100644
--- a/docs/learn-wds/module-04-product-brief/tutorial-04.md
+++ b/docs/learn/module-04-product-brief/tutorial-04.md
@@ -1,4 +1,4 @@
-# Tutorial 04: Create Your Project Brief
+# Tutorial 04: Create Your Product Brief
 
 **Hands-on guide to defining your project vision, goals, and constraints**
 
@@ -9,7 +9,7 @@
 This tutorial walks you through creating a complete project brief that serves as the foundation for all design decisions.
 
 **Time:** 30-45 minutes  
-**Prerequisites:** Module 01 completed  
+**Prerequisites:** Module 02 completed (WDS installed)  
 **What you'll create:** A complete project brief document
 
 ---
@@ -90,7 +90,7 @@ Specific, measurable objectives that define project success from a business pers
 
 ### How to do it:
 
-**Framework: SMART Goals**
+**Framework: The SMART Model**
 
 - **S**pecific - Clear and unambiguous
 - **M**easurable - Can track progress
@@ -120,7 +120,7 @@ List 3-5 business goals:
 **AI Support:**
 
 ```
-Agent: "Let's make these goals SMART. For each goal, I'll help you:
+Agent: "Let's express these goals using the SMART model. For each goal, I'll help you:
 - Make it specific and measurable
 - Set realistic targets
 - Define timeframes"
@@ -294,7 +294,7 @@ Define your success criteria:
 **Completeness:**
 
 - ✓ Vision is clear and compelling
-- ✓ Goals are SMART
+- ✓ Goals are expressed using the SMART model
 - ✓ All stakeholder groups identified
 - ✓ Constraints documented
 - ✓ Success criteria defined
@@ -318,7 +318,7 @@ Agent: "Let me review your project brief:
 
 ---
 
-## Step 7: Save Your Project Brief
+## Step 7: Save Your Product Brief
 
 **Create file:** `A-Project-Brief/project-brief.md`
 
@@ -354,7 +354,7 @@ Agent: "Let me review your project brief:
 
 **Next Module:**
 
-- [Module 03: Identify Target Groups](../module-03-identify-target-groups/module-03-overview.md)
+- [Module 03: Identify Target Groups](../module-03-alignment-signoff/module-03-overview.md)
 - Start mapping WHO your users are
 
 ---
@@ -397,4 +397,6 @@ A: Use the brief to facilitate alignment discussions. Document disagreements and
 
 **Your project brief is the foundation for everything that follows. Take the time to get it right!**
 
-[← Back to Module 02](module-02-overview.md) | [Next: Module 03 →](../module-03-identify-target-groups/module-03-overview.md)
+[← Back to Module Overview](module-04-overview.md) | [Next: Module 05 - Platform Requirements →](../module-05-platform-requirements/module-05-platform-requirements-overview.md)
+
+*Part of Module 04: Product Brief*
diff --git a/docs/learn/module-05-platform-requirements/lesson-01-why-boundaries-matter.md b/docs/learn/module-05-platform-requirements/lesson-01-why-boundaries-matter.md
new file mode 100644
index 000000000..70a793da5
--- /dev/null
+++ b/docs/learn/module-05-platform-requirements/lesson-01-why-boundaries-matter.md
@@ -0,0 +1,232 @@
+# Module 05: Platform Requirements
+
+## Lesson 1: Why Boundaries Matter
+
+**Designing in reality, not fantasy**
+
+---
+
+## The Beautiful Disaster
+
+Picture this: You've spent three weeks designing a stunning real-time collaboration feature. Users can see each other's cursors moving across the screen. Changes sync instantly. It's beautiful.
+
+You present it to the development team.
+
+Silence.
+
+Then: "Our backend doesn't support WebSockets. That would take months to implement."
+
+Three weeks of design work. Gone. Not because the design was bad, but because you designed in ignorance of what was possible.
+
+---
+
+## The Invisible Fence
+
+Every project has boundaries. Technical boundaries. Budget boundaries. Timeline boundaries. Expertise boundaries.
+
+**Most designers never see these fences until they crash into them.**
+
+And by then, they've invested significant time designing solutions that can't be built. Or can only be built at enormous cost. Or will take so long that the project loses momentum.
+
+**This isn't just frustrating — it's preventable.**
+
+---
+
+## What Boundaries Really Are
+
+Boundaries aren't limitations on your creativity. They're the shape of reality that your design must fit into.
+
+**Think of it like architecture:**
+
+An architect doesn't complain about gravity. They design *with* it. They use it. They understand that buildings must stand up, water runs downhill, and structural loads must be distributed.
+
+**As a designer, your gravity is:**
+
+- The platforms you're targeting (web, mobile, desktop)
+- The systems you must integrate with (authentication, payments, APIs)
+- The constraints you must work within (budget, timeline, team skills)
+- The complexity that exists in integrations
+- The gaps in what the team knows
+
+These aren't restrictions. They're the physics of your design universe.
+
+---
+
+## The Real Cost of Ignorance
+
+Let's be blunt about what happens when designers don't understand platform requirements:
+
+**Scenario 1: The Offline Fantasy**
+
+Designer creates mobile app with offline-first experience. Beautiful sync conflict resolution. Elegant local storage patterns.
+
+Reality: Client only has budget for a web app. No native development resources. The entire offline architecture? Irrelevant.
+
+**Scenario 2: The Integration Assumption**
+
+Designer assumes single sign-on with existing company tools. Designs seamless flow between systems.
+
+Reality: Legacy system has no API. Integration would require custom middleware costing $50K. Feature gets cut.
+
+**Scenario 3: The Performance Ignore**
+
+Designer creates image-heavy, animation-rich experience.
+
+Reality: Target users are in regions with slow internet. Page takes 30 seconds to load. Bounce rate is 90%.
+
+**Each of these represents weeks or months of wasted work.**
+
+---
+
+## This Isn't About Being a Developer
+
+Here's what many designers get wrong: they think understanding platform requirements means becoming technical. Learning to code. Understanding databases.
+
+**No.**
+
+You don't need to know *how* WebSockets work. You need to know *whether they're available*.
+
+You don't need to understand OAuth implementation details. You need to know *which authentication the client already uses*.
+
+You don't need to design the database schema. You need to know *what data already exists*.
+
+**You're discovering boundaries, not building infrastructure.**
+
+---
+
+## The Strategic Advantage
+
+When you understand platform requirements, something shifts:
+
+**Your designs become immediately buildable.**
+
+Developers don't push back. They don't say "that's not possible." They say "yes, we can do that."
+
+**Your estimates become accurate.**
+
+Because you're designing within real constraints, timeline predictions hold. Projects finish on time.
+
+**Your stakeholders gain confidence.**
+
+When every design is grounded in reality, stakeholders trust your judgment. They stop micromanaging technical feasibility.
+
+**You become the designer who "gets it."**
+
+The one who doesn't waste time. The one who delivers. The one who makes implementation smooth instead of painful.
+
+---
+
+## When to Discover Boundaries
+
+This is Phase 1 work — before you design anything.
+
+**Before sketches.** Before wireframes. Before mockups. Before prototypes.
+
+If you wait until you're deep in design to discover boundaries, you'll have to throw work away. If you discover them upfront, every minute of design time is spent on solutions that can actually be built.
+
+**The time investment is tiny:**
+
+- 30 minutes with Saga
+- A conversation with the development team
+- A quick review of existing systems
+
+**The payoff is massive:**
+
+- Zero wasted design time
+- Immediate developer buy-in
+- Stakeholder confidence
+- Faster project completion
+
+---
+
+## The Saga Approach
+
+This is why Saga handles platform requirements, not Freya.
+
+**Platform requirements are strategic, not creative.**
+
+You're not designing — you're discovering. You're mapping the terrain before you start building.
+
+Saga asks the strategic questions:
+
+- "What platforms are we targeting?"
+- "What systems need to integrate?"
+- "What constraints should I know about?"
+- "What feels risky or unknown?"
+
+These questions surface boundaries before they become blockers.
+
+---
+
+## What You're Creating
+
+At the end of this module, you'll have:
+
+`A-Product-Brief/platform-requirements.md`
+
+A simple document that captures:
+
+1. **Platforms** — Where the product will live
+2. **Integrations** — What systems connect
+3. **Constraints** — What's impossible or expensive
+4. **Complexity** — Where challenges exist
+5. **Knowledge Gaps** — What we don't know yet
+
+This document travels with your Product Brief because it's strategic context — the shape of reality that all design decisions must respect.
+
+---
+
+## The Handoff Advantage
+
+Here's a powerful pattern:
+
+Once you document platform requirements, you can **send them to Idunn immediately**.
+
+While you move into UX design (Freya), Idunn can:
+
+- Research knowledge gaps
+- Spike complex integrations
+- Set up development environment
+- Validate technical assumptions
+
+**Design and platform prep happen in parallel.**
+
+You're not waiting. You're not blocked. The project moves forward on multiple fronts simultaneously.
+
+---
+
+## The Emotional Shift
+
+Without understanding boundaries:
+
+- Constant anxiety about whether designs are buildable
+- Fear of presenting to developers
+- Frustration when ideas get rejected
+- Feeling like you're working in the dark
+
+With understanding boundaries:
+
+- Confidence that every design is grounded
+- Developer meetings become collaborative, not confrontational
+- Ideas get refined, not rejected
+- Clarity about what's possible and what's not
+
+**This one shift transforms how it feels to work on projects.**
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn exactly how to document platform requirements. We'll walk through each section: platforms, integrations, constraints, complexity, and knowledge gaps.
+
+Then you'll practice with a tutorial that guides you through creating your own platform-requirements.md.
+
+---
+
+**[Continue to Lesson 2: Defining Platform Requirements →](lesson-02-defining-platform-requirements.md)**
+
+---
+
+[← Back to Module Overview](module-05-platform-requirements-overview.md)
+
+*Part of Module 05: Platform Requirements*
diff --git a/docs/learn/module-05-platform-requirements/lesson-02-defining-platform-requirements.md b/docs/learn/module-05-platform-requirements/lesson-02-defining-platform-requirements.md
new file mode 100644
index 000000000..02644671e
--- /dev/null
+++ b/docs/learn/module-05-platform-requirements/lesson-02-defining-platform-requirements.md
@@ -0,0 +1,416 @@
+# Module 05: Platform Requirements
+
+## Lesson 2: Defining Platform Requirements
+
+**How to document the boundaries that shape your design**
+
+---
+
+## The Five Sections
+
+Every platform requirements document covers five areas:
+
+1. **Platforms** — Where the product lives
+2. **Integrations** — What systems connect
+3. **Constraints** — What's impossible or expensive
+4. **Complexity & Challenges** — Where difficulty exists
+5. **Knowledge Gaps** — What we don't know yet
+
+Let's walk through each one.
+
+---
+
+## Section 1: Platforms
+
+**The fundamental question: Where will this product exist?**
+
+### What to capture:
+
+- **Web** — Desktop browsers, mobile browsers, or both?
+- **Mobile Native** — iOS, Android, or both?
+- **Desktop Applications** — Windows, macOS, Linux?
+- **Other** — Smart TV, kiosk, wearable, embedded?
+
+### Why it matters for design:
+
+| Platform | Design Implications |
+|----------|-------------------|
+| Web only | No native gestures, browser limitations |
+| Mobile native | Touch-first, offline expectations |
+| Desktop app | Keyboard shortcuts, multi-window |
+| Cross-platform | Responsive design, consistent experience |
+
+### Example (Dog Week):
+
+```
+Platforms:
+- Primary: Progressive Web App (PWA)
+- Mobile: iOS and Android via PWA
+- Desktop: Web browser (Chrome, Safari, Firefox, Edge)
+- Offline: Core features must work offline (PWA service worker)
+```
+
+### Questions to ask:
+
+- "What devices will users primarily use?"
+- "Do we need to work offline?"
+- "Are there browser or OS version requirements?"
+- "Is a native mobile app required, or will web work?"
+
+---
+
+## Section 2: Integrations
+
+**What systems must connect to your product?**
+
+### Categories:
+
+**Authentication:**
+- OAuth providers (Google, Apple, Microsoft)
+- Enterprise SSO (SAML, LDAP)
+- Existing user databases
+- Social login
+
+**Payments:**
+- Payment processors (Stripe, PayPal, Klarna)
+- Subscription management
+- Invoice systems
+- Currency handling
+
+**Third-Party APIs:**
+- Maps and location
+- Email and SMS
+- Analytics
+- Cloud storage
+
+**Internal Systems:**
+- Legacy databases
+- Existing applications
+- Corporate tools
+- Data warehouses
+
+### Example (Dog Week):
+
+```
+Integrations:
+
+Authentication:
+- Supabase Auth (primary)
+- Google OAuth (optional social login)
+- Email/password fallback
+
+Data:
+- Supabase PostgreSQL database
+- Supabase Storage for images
+
+Future Considerations:
+- Calendar sync (Google Calendar, Apple Calendar)
+- Veterinarian appointment APIs (Phase 2)
+```
+
+### Why it matters for design:
+
+Each integration shapes what's possible:
+
+- **OAuth available?** Design smooth single-click login
+- **Calendar sync?** Design around existing schedule patterns
+- **Legacy system?** Work within its data model constraints
+
+### Questions to ask:
+
+- "What does the user already use that we should connect to?"
+- "Are there existing systems this must integrate with?"
+- "What authentication does the organization already use?"
+- "What third-party services are already in place?"
+
+---
+
+## Section 3: Constraints
+
+**What's technically impossible, too expensive, or simply not available?**
+
+### Categories:
+
+**Technical Constraints:**
+- Hosting limitations (shared hosting, limited resources)
+- No real-time capability (polling only)
+- Limited API rate limits
+- Legacy system restrictions
+
+**Budget Constraints:**
+- No budget for native apps
+- Can't afford enterprise APIs
+- Limited cloud resources
+- No dedicated infrastructure
+
+**Team Expertise:**
+- No mobile development experience
+- No security expertise
+- Limited API experience
+- No DevOps capability
+
+**Timeline Constraints:**
+- Must launch in 3 months
+- Phased rollout required
+- Seasonal deadline (holiday launch)
+
+**Regulatory Constraints:**
+- GDPR compliance
+- HIPAA requirements
+- Financial regulations
+- Accessibility laws
+
+### Example (Dog Week):
+
+```
+Constraints:
+
+Technical:
+- PWA approach (no native iOS/Android budget)
+- Supabase free tier initially (limited concurrent connections)
+
+Budget:
+- Bootstrap phase (minimal external spending)
+- No paid third-party APIs initially
+
+Team:
+- Solo developer initially
+- No dedicated mobile expertise
+
+Regulatory:
+- GDPR compliance required (Swedish users)
+- Child data considerations (family members might include minors)
+
+Timeline:
+- MVP in 8 weeks
+- Full launch in 16 weeks
+```
+
+### Why it matters for design:
+
+Constraints directly shape solutions:
+
+| Constraint | Design Adaptation |
+|------------|------------------|
+| No real-time | Design with polling, show "last updated" |
+| Limited budget | Simpler interactions, fewer features |
+| No mobile dev | PWA instead of native app |
+| GDPR required | Clear consent flows, data controls |
+
+### Questions to ask:
+
+- "What's technically not possible right now?"
+- "What would be too expensive to build?"
+- "What skills does the team lack?"
+- "What regulatory requirements apply?"
+- "What's the timeline we're working with?"
+
+---
+
+## Section 4: Complexity & Challenges
+
+**Where will implementation be difficult?**
+
+This section surfaces risks before they become blockers.
+
+### What to document:
+
+**High Complexity Integrations:**
+- Legacy systems with poor documentation
+- APIs with rate limits or unreliable uptime
+- Systems requiring custom middleware
+
+**Unproven Technology:**
+- New frameworks the team hasn't used
+- Cutting-edge features with limited support
+- Platform features in beta
+
+**Challenging Requirements:**
+- Real-time sync across devices
+- Offline-first with conflict resolution
+- Complex data migrations
+
+### Example (Dog Week):
+
+```
+Complexity & Challenges:
+
+Medium Complexity:
+- Push notifications across platforms (PWA limitations on iOS)
+- Offline sync with conflict resolution for schedules
+
+Lower Complexity:
+- User authentication (Supabase handles this well)
+- Basic CRUD operations for tasks and events
+
+Challenges:
+- iOS PWA push notifications are limited
+- Calendar sync requires OAuth complexity
+- Image optimization for slow connections
+```
+
+### Rating scale:
+
+- **Low** — Well-understood, team has experience
+- **Medium** — Achievable but requires research
+- **High** — Significant unknowns, may need spikes
+- **Unknown** — Needs investigation before commitment
+
+### Questions to ask:
+
+- "How complex is this integration really?"
+- "Has the team done this before?"
+- "What's the challenge level?"
+- "Are there unknowns that need research?"
+
+---
+
+## Section 5: Knowledge Gaps
+
+**What don't we know yet?**
+
+This is the most important section. It surfaces what needs investigation.
+
+### What to document:
+
+**Technical Unknowns:**
+- "Can the legacy API handle our expected load?"
+- "Does the payment processor support our currency?"
+- "Will the OAuth provider work with our platform?"
+
+**Performance Unknowns:**
+- "How will the app perform on slow networks?"
+- "What happens with 10,000 concurrent users?"
+- "Can images load fast enough on mobile?"
+
+**Integration Unknowns:**
+- "Does the third-party API have the endpoints we need?"
+- "What's the data format of the legacy system?"
+- "Is real-time sync technically feasible?"
+
+### Example (Dog Week):
+
+```
+Knowledge Gaps:
+
+Needs Research:
+- PWA push notification behavior on iOS 17+
+- Supabase performance with complex RLS policies
+- Image CDN options within budget
+
+Needs Spike:
+- Offline sync conflict resolution patterns
+- Calendar integration OAuth flows
+
+Needs Team Decision:
+- React Native vs PWA long-term strategy
+- Self-hosted vs Supabase managed
+```
+
+### Why this matters:
+
+**Knowledge gaps become tasks for Idunn.**
+
+While you design with Freya, Idunn can:
+- Research the unknowns
+- Spike the complex integrations
+- Test the assumptions
+- Report back with findings
+
+This is parallel work. Design doesn't stop while technical investigation happens.
+
+### Questions to ask:
+
+- "What do we not know yet?"
+- "What assumptions haven't been validated?"
+- "What needs a proof-of-concept?"
+- "What might surprise us later?"
+
+---
+
+## The Complete Document
+
+Here's what a finished platform-requirements.md looks like:
+
+```markdown
+# Platform Requirements
+
+## Platforms
+- Primary: Progressive Web App (PWA)
+- Mobile: iOS and Android via PWA
+- Desktop: Web browser (Chrome, Safari, Firefox, Edge)
+- Offline: Core features must work offline
+
+## Integrations
+- Authentication: Supabase Auth, Google OAuth optional
+- Database: Supabase PostgreSQL
+- Storage: Supabase Storage
+- Future: Calendar sync, veterinarian APIs
+
+## Constraints
+- Technical: PWA approach, Supabase free tier initially
+- Budget: Bootstrap phase, no paid APIs
+- Team: Solo developer, no dedicated mobile expertise
+- Regulatory: GDPR compliance, child data considerations
+- Timeline: MVP in 8 weeks
+
+## Complexity & Challenges
+- Medium: Push notifications, offline sync
+- Low: Authentication, basic CRUD
+- Challenges: iOS PWA limitations, OAuth complexity
+
+## Knowledge Gaps
+- Research: iOS 17+ PWA behavior, Supabase RLS performance
+- Spike: Offline sync patterns, calendar OAuth
+- Decision: React Native vs PWA long-term
+```
+
+---
+
+## Where It Lives
+
+`A-Product-Brief/platform-requirements.md`
+
+**Why with the Product Brief?**
+
+Because platform requirements are strategic context. They're not technical specifications — they're the boundaries that shape all design decisions.
+
+Just like the Product Brief, this document gets referenced throughout the project. When you're designing, you check it. When developers have questions, they check it. When scope discussions happen, everyone checks it.
+
+---
+
+## The Handoff
+
+Once this document exists:
+
+1. **Send to Idunn** — Technical investigation begins
+2. **Reference in design** — Every decision respects these boundaries
+3. **Update as you learn** — New discoveries get documented
+
+**This is a living document.** As Idunn investigates knowledge gaps, the document gets updated. As the project evolves, constraints may change. Keep it current.
+
+---
+
+## What You've Learned
+
+- The five sections of platform requirements
+- How to document each section effectively
+- Why constraints inform rather than limit design
+- How knowledge gaps become parallel work for Idunn
+- Where the document lives and how it's used
+
+---
+
+## What's Next
+
+In the tutorial, you'll create your own platform-requirements.md. Saga will guide you through each section, asking the right questions to surface your project's specific boundaries.
+
+---
+
+**[Continue to Tutorial: Create Platform Requirements →](tutorial-05.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-why-boundaries-matter.md) | [Back to Module Overview](module-05-platform-requirements-overview.md)
+
+*Part of Module 05: Platform Requirements*
diff --git a/docs/learn/module-05-platform-requirements/module-05-platform-requirements-overview.md b/docs/learn/module-05-platform-requirements/module-05-platform-requirements-overview.md
new file mode 100644
index 000000000..39ef3f344
--- /dev/null
+++ b/docs/learn/module-05-platform-requirements/module-05-platform-requirements-overview.md
@@ -0,0 +1,186 @@
+# Module 05: Platform Requirements
+
+**Time: 30 min | Agent: Saga | Phase: Strategy**
+
+---
+
+## What You'll Learn
+
+How to define the technical boundaries that inform your design decisions before you start designing.
+
+---
+
+## Why This Matters
+
+Imagine designing a beautiful real-time collaboration feature... then learning the backend can't support WebSockets.
+
+Or specifying an offline-first mobile experience... when the client only has budget for a web app.
+
+**Knowing the tech stack is a necessity for UX work — not optional.**
+
+You can't design well in ignorance. The platform shapes the experience.
+
+---
+
+## Not Architecture — Boundaries
+
+You're not designing the database. You're not specifying API endpoints. That's development work.
+
+You're understanding what's possible so your designs are grounded in reality.
+
+---
+
+## What You'll Discover
+
+### 1. Platforms
+
+Where will this product live?
+
+- Web only?
+- Mobile (iOS, Android, both)?
+- Desktop application?
+- All of the above?
+
+Each platform has different capabilities and constraints.
+
+### 2. Integrations
+
+What systems must we connect to?
+
+- Authentication (OAuth, SSO, custom)?
+- Payment processing?
+- Third-party APIs?
+- Legacy systems?
+- External databases?
+
+### 3. Constraints
+
+What's technically impossible or expensive?
+
+- Hosting limitations?
+- Budget constraints?
+- Team expertise?
+- Timeline restrictions?
+- Regulatory requirements?
+
+### 4. Complexity & Challenges
+
+Investigate integrations from a strategic standpoint:
+
+- How complex is this integration really?
+- What's the challenge level?
+- Is this well-understood or experimental?
+- Are there unknowns that need research?
+
+### 5. Knowledge Gaps
+
+What do we **not** know yet?
+
+- Unproven technology?
+- Missing documentation?
+- No team expertise?
+- Needs a spike or proof-of-concept?
+
+**Surface these gaps explicitly.** They become tasks for Idunn to investigate in parallel.
+
+---
+
+## The Saga Method
+
+Saga helps you think through boundaries conversationally:
+
+> "What platforms are we targeting?"
+> "Are there any systems we need to integrate with?"
+> "What technical constraints should I know about?"
+> "Is there anything that feels risky or uncertain?"
+
+She'll probe deeper where needed, ensuring nothing gets missed.
+
+---
+
+## Output
+
+`A-Product-Brief/platform-requirements.md`
+
+This document lives with your Product Brief because it's part of the strategic foundation — not a technical specification.
+
+---
+
+## Handoff to Idunn
+
+Once platform requirements are documented, you can **send them to Idunn** immediately.
+
+While you continue with UX design (Freya), Idunn can:
+
+- Research knowledge gaps
+- Spike complex integrations
+- Set up the development environment
+- Validate technical assumptions
+
+**Parallel work.** Design and platform prep happen simultaneously.
+
+---
+
+## What's NOT in This Document
+
+- Database schemas
+- API specifications
+- Code architecture
+- Technical implementation details
+
+Those come later, in BMM's architecture phase.
+
+---
+
+## Connection to Design
+
+Every boundary you discover shapes your design:
+
+| Boundary | Design Impact |
+|----------|---------------|
+| Web only | No native mobile gestures |
+| No real-time | Polling instead of live updates |
+| Tight budget | Simpler interactions |
+| Legacy integration | Work within existing patterns |
+
+---
+
+## Practice
+
+Think about your current project:
+
+1. What platforms are you designing for?
+2. What integrations are required?
+3. What constraints exist?
+4. What feels risky?
+
+Document these before you start designing.
+
+---
+
+## Lessons
+
+### [Lesson 1: Why Boundaries Matter](lesson-01-why-boundaries-matter.md)
+Designing in reality, not fantasy
+
+### [Lesson 2: Defining Platform Requirements](lesson-02-defining-platform-requirements.md)
+How to document the boundaries that shape your design
+
+---
+
+## Tutorial
+
+### [Tutorial 05: Create Your Platform Requirements](tutorial-05.md)
+Hands-on guide to documenting technical boundaries with Saga
+
+---
+
+## Next Module
+
+**[Module 06: Trigger Mapping →](../module-06-trigger-mapping/module-06-overview.md)**
+
+Now understand the user psychology that drives behavior.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-05-platform-requirements/tutorial-05.md b/docs/learn/module-05-platform-requirements/tutorial-05.md
new file mode 100644
index 000000000..c7c5f68a6
--- /dev/null
+++ b/docs/learn/module-05-platform-requirements/tutorial-05.md
@@ -0,0 +1,377 @@
+# Tutorial 05: Create Your Platform Requirements
+
+**Hands-on guide to documenting technical boundaries with Saga**
+
+---
+
+## Overview
+
+This tutorial walks you through creating a platform requirements document that captures the technical reality your design must work within.
+
+**Time:** 15-20 minutes
+**Prerequisites:** Module 04 (Product Brief) completed
+**Agent:** Saga
+**What you'll create:** `A-Product-Brief/platform-requirements.md`
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- Your completed Product Brief
+- Basic understanding of the project's technical context
+- Access to technical stakeholders (helpful but not required)
+
+**Saga will help you:**
+
+- Ask the right questions
+- Identify gaps you might miss
+- Document clearly and consistently
+- Prepare handoff to Idunn
+
+---
+
+## Step 1: Start the Conversation with Saga (2 min)
+
+### Open your AI IDE and start a conversation:
+
+**You say:**
+> "I need to create platform requirements for my project. I've completed my Product Brief. Can you help me document the technical boundaries?"
+
+**Saga responds with initial questions about your project context.**
+
+### Provide context:
+
+Share your Product Brief or summarize:
+- What you're building
+- Who it's for
+- Key goals
+
+This gives Saga the context to ask relevant questions.
+
+---
+
+## Step 2: Define Platforms (3 min)
+
+### Saga will ask about platforms:
+
+> "What platforms are you targeting? Web, mobile native, desktop, or a combination?"
+
+### Think through:
+
+- Where will users primarily access this?
+- Do you need offline capability?
+- Are there device-specific requirements?
+- What browsers or OS versions must you support?
+
+### Example response:
+
+> "We're building a PWA that works on mobile and desktop browsers. Users will primarily use it on their phones. We need basic offline capability for core features. Must support modern browsers — Chrome, Safari, Firefox, Edge."
+
+### Saga documents and probes deeper:
+
+> "What about offline capability — which features must work offline, and which can require connection?"
+
+---
+
+## Step 3: Identify Integrations (3 min)
+
+### Saga asks about integrations:
+
+> "What systems does this need to integrate with? Think about authentication, payments, data sources, and third-party services."
+
+### Categories to consider:
+
+**Authentication:**
+- How will users log in?
+- Is there an existing identity system?
+- Do you need social login?
+
+**Data:**
+- Where does data live?
+- What existing databases connect?
+- What external data do you need?
+
+**Services:**
+- Payment processing?
+- Email/SMS notifications?
+- Maps or location?
+- Analytics?
+
+### Example response:
+
+> "Authentication through Supabase, with optional Google login. All data in Supabase PostgreSQL. We'll need push notifications eventually. No payment processing for MVP."
+
+### Saga probes:
+
+> "Are there any legacy systems or existing tools users currently use that this should connect with?"
+
+---
+
+## Step 4: Document Constraints (3 min)
+
+### Saga asks about limitations:
+
+> "What constraints are you working within? Think about technical limitations, budget, team skills, timeline, and regulations."
+
+### Areas to cover:
+
+**Technical:**
+- Hosting limitations?
+- Performance requirements?
+- Platform restrictions?
+
+**Budget:**
+- What can't you afford?
+- What's the spending limit?
+
+**Team:**
+- What skills are missing?
+- What's the team size?
+
+**Timeline:**
+- When must this launch?
+- Are there phases?
+
+**Regulatory:**
+- Privacy requirements?
+- Accessibility mandates?
+- Industry regulations?
+
+### Example response:
+
+> "Bootstrap budget — using Supabase free tier. Solo developer, no mobile expertise. MVP needed in 8 weeks. GDPR compliance required for Swedish users. No budget for native app development."
+
+### Saga clarifies:
+
+> "For GDPR, does your app handle any child data? That might require additional considerations."
+
+---
+
+## Step 5: Assess Complexity (2 min)
+
+### Saga asks about challenges:
+
+> "Where do you see technical complexity or challenges? Which integrations feel risky or uncertain?"
+
+### Rate each major component:
+
+- **Low** — Well-understood, team has experience
+- **Medium** — Achievable but requires research
+- **High** — Significant unknowns, may need spikes
+- **Unknown** — Needs investigation
+
+### Example response:
+
+> "Push notifications on iOS PWA feel medium complexity — I've read there are limitations. Offline sync is probably medium too. Basic auth and CRUD operations are low — Supabase handles that well."
+
+### Saga summarizes:
+
+> "So we have medium complexity on push notifications and offline sync, with lower complexity on core features. I'll flag the iOS push notification limitations as something Idunn should research."
+
+---
+
+## Step 6: Identify Knowledge Gaps (2 min)
+
+### Saga asks what's unknown:
+
+> "What don't you know yet? What assumptions haven't been validated? What needs research or a proof-of-concept?"
+
+### Categories:
+
+- **Needs Research** — Documentation review, competitor analysis
+- **Needs Spike** — Technical proof-of-concept
+- **Needs Decision** — Team or stakeholder choice required
+
+### Example response:
+
+> "I don't know how iOS 17 handles PWA push notifications. Not sure about Supabase performance with complex row-level security. We haven't decided if we'll eventually go React Native."
+
+### Saga documents:
+
+> "I'll create three knowledge gap items:
+> 1. Research: iOS 17+ PWA push notification behavior
+> 2. Research: Supabase RLS performance characteristics
+> 3. Decision needed: React Native vs PWA long-term"
+
+---
+
+## Step 7: Review and Finalize (3 min)
+
+### Saga presents the complete document:
+
+> "Here's your platform requirements document. Let me read it back so you can confirm everything is accurate."
+
+### Review checklist:
+
+- ✓ All target platforms listed
+- ✓ Key integrations captured
+- ✓ Constraints are specific and accurate
+- ✓ Complexity levels feel right
+- ✓ Knowledge gaps are clear and actionable
+
+### Make corrections:
+
+If anything is missing or wrong, tell Saga:
+
+> "Add that we need to support Swedish and English languages. And the timeline is actually 10 weeks, not 8."
+
+### Saga updates the document.
+
+---
+
+## Step 8: Save the Document (1 min)
+
+### Saga will save to:
+
+`A-Product-Brief/platform-requirements.md`
+
+### Confirm the save:
+
+> "Save this as platform-requirements.md in the A-Product-Brief folder."
+
+### Saga confirms:
+
+> "Platform requirements saved. This document is now part of your strategic foundation alongside your Product Brief."
+
+---
+
+## Step 9: Handoff to Idunn (Optional)
+
+### If you want parallel development:
+
+> "Please prepare a handoff for Idunn with the knowledge gaps that need investigation."
+
+### Saga creates handoff:
+
+> "Handoff prepared for Idunn:
+>
+> **Research Tasks:**
+> - iOS 17+ PWA push notification behavior
+> - Supabase RLS performance characteristics
+>
+> **Spike Tasks:**
+> - Offline sync conflict resolution patterns
+>
+> **Pending Decisions:**
+> - React Native vs PWA long-term strategy
+>
+> Idunn can start investigating while you continue to UX design with Freya."
+
+---
+
+## What You've Created
+
+### Your platform-requirements.md includes:
+
+```markdown
+# Platform Requirements
+
+## Platforms
+- Primary: Progressive Web App (PWA)
+- Mobile: iOS and Android via PWA
+- Desktop: Web browser (Chrome, Safari, Firefox, Edge)
+- Offline: Core features must work offline
+
+## Integrations
+- Authentication: Supabase Auth, Google OAuth optional
+- Database: Supabase PostgreSQL
+- Storage: Supabase Storage
+- Future: Push notifications
+
+## Constraints
+- Technical: PWA approach, Supabase free tier initially
+- Budget: Bootstrap phase
+- Team: Solo developer
+- Regulatory: GDPR compliance
+- Timeline: MVP in 10 weeks
+
+## Complexity & Challenges
+- Medium: Push notifications (iOS limitations), offline sync
+- Low: Authentication, basic CRUD
+
+## Knowledge Gaps
+- Research: iOS 17+ PWA push notifications
+- Research: Supabase RLS performance
+- Spike: Offline sync patterns
+- Decision: React Native vs PWA long-term
+```
+
+---
+
+## What Happens Next
+
+### Immediate:
+
+- Platform requirements inform all design decisions
+- Knowledge gaps become Idunn's research tasks
+- You have a clear picture of what's possible
+
+### Next Phase:
+
+- **Module 07: The Design Phase** — Meet Freya and begin UX design
+- Design within these boundaries
+- Reference platform requirements when making decisions
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Be honest about constraints
+- Document what you don't know
+- Ask technical stakeholders if unsure
+- Update as you learn more
+
+**DON'T:**
+
+- Guess at technical details
+- Skip knowledge gaps
+- Assume constraints are permanent
+- Over-engineer the document
+
+---
+
+## Common Questions
+
+**Q: What if I don't know the technical details?**
+A: That's what knowledge gaps are for. Document what you don't know and let Idunn investigate.
+
+**Q: Should I talk to developers before creating this?**
+A: Helpful but not required. Saga will ask questions that surface what you know. Mark unknowns as knowledge gaps.
+
+**Q: Can this document change?**
+A: Absolutely. It's a living document. Update it as you learn more or as the project evolves.
+
+**Q: What if I realize a constraint later?**
+A: Add it to the document. Better to discover and document late than never.
+
+---
+
+## You've Completed Module 05!
+
+**Platform Requirements Complete**
+
+You now have:
+- ✅ Product Brief (Module 04)
+- ✅ Platform Requirements (Module 05)
+
+**Next up: Trigger Mapping to connect business goals to user psychology.**
+
+**Your strategic foundation is solid.**
+
+---
+
+## Next Module
+
+**[Module 06: Trigger Mapping →](../module-06-trigger-mapping/module-06-overview.md)**
+
+Connect business goals to user psychology with Saga.
+
+---
+
+[← Back to Lesson 2](lesson-02-defining-platform-requirements.md) | [Back to Module Overview](module-05-platform-requirements-overview.md)
+
+*Part of Module 05: Platform Requirements*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-01-missing-link.md b/docs/learn/module-06-trigger-mapping/lesson-01-missing-link.md
similarity index 96%
rename from docs/learn-wds/module-05-trigger-mapping/lesson-01-missing-link.md
rename to docs/learn/module-06-trigger-mapping/lesson-01-missing-link.md
index e0e9cb962..a87eff4cd 100644
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-01-missing-link.md
+++ b/docs/learn/module-06-trigger-mapping/lesson-01-missing-link.md
@@ -1,4 +1,6 @@
-# Lesson 1: The Missing Link
+# Module 06: Trigger Mapping
+
+## Lesson 1: The Missing Link
 
 **Why Product Brief Alone Isn't Enough**
 
@@ -25,6 +27,7 @@ There's a critical gap between your Product Brief and your design decisions. A g
 
 Your Product Brief tells you the business strategy. But it doesn't tell you:
 
+- **What actually drives the business?**
 - **What actually motivates your users?**
 - **What psychological triggers drive their behavior?**
 - **Which features will have the most impact?**
@@ -139,7 +142,7 @@ Features That Work
 
 **Product Brief** = Business strategy (what, why, who at high level)  
 **Trigger Map** = User psychology (who specifically, why they act, what drives them)  
-**Design** = Solutions that connect strategy to psychology  
+**UX Design** = Solutions that connect strategy to psychology  
 **Features** = Implementations that deliver on both
 
 ---
@@ -232,6 +235,6 @@ Before moving to the next lesson, consider:
 
 ---
 
-[← Back to Module Overview](module-05-overview.md) | [Next: Lesson 2 - Heritage & Evolution →](lesson-02-heritage-evolution.md)
+[← Back to Module Overview](module-06-overview.md) | [Next: Lesson 2 - Heritage & Evolution →](lesson-02-heritage-evolution.md)
 
-*Part of Module 05: Trigger Mapping*
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-02-heritage-evolution.md b/docs/learn/module-06-trigger-mapping/lesson-02-heritage-evolution.md
similarity index 87%
rename from docs/learn-wds/module-05-trigger-mapping/lesson-02-heritage-evolution.md
rename to docs/learn/module-06-trigger-mapping/lesson-02-heritage-evolution.md
index 1d79fe754..73fa837a9 100644
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-02-heritage-evolution.md
+++ b/docs/learn/module-06-trigger-mapping/lesson-02-heritage-evolution.md
@@ -1,4 +1,6 @@
-# Lesson 2: The Heritage & Evolution
+# Module 06: Trigger Mapping
+
+## Lesson 2: The Heritage & Evolution
 
 **From Effect Management to Trigger Mapping**
 
@@ -93,7 +95,7 @@ Both Effect Mapping and Trigger Mapping use three core layers. Understanding the
 
 **What it is:**
 - Vision that motivates the team
-- SMART objectives that measure success
+- Strategic objectives (using SMART model) that measure success
 
 **Example:**
 - Vision: "Make family dog care stress-free"
@@ -211,9 +213,9 @@ When all three layers are prioritized, you have perfect guidance for design:
 
 ---
 
-## Three Approaches: Choose Your Path
+## Two Approaches: Choose Your Path
 
-WDS offers three ways to apply Trigger Mapping methodology, depending on your situation:
+WDS offers two ways to create your Trigger Map, depending on whether you're starting from scratch or have existing documentation:
 
 ### 1. Full Trigger Mapping (Starting from Scratch)
 
@@ -224,40 +226,24 @@ WDS offers three ways to apply Trigger Mapping methodology, depending on your si
 - Comprehensive strategic foundation
 
 **When to use:**
-- Major product initiatives
 - No existing documentation
+- Major product initiatives
 - Complex user psychology
 - Multiple target groups
 - Long-term strategic planning
 - When you need defensible prioritization
 
-**Time investment:** 60-90 minutes  
-**Output:** Complete Trigger Map + scored feature list  
-**Tutorial:** [Tutorial 05: Create Your Trigger Map](tutorial-05.md)
+**Three engagement modes** let you choose your speed:
+- **Workshop** — Saga facilitates, you provide insights (45-60 min)
+- **Suggest** — Saga suggests, you review each step (20-35 min)
+- **Dream** — Saga creates autonomously, you review final result (15-25 min)
+
+**Output:** Complete Trigger Map + scored feature list
+**Tutorial:** [Tutorial 06: Create Your Trigger Map](tutorial-06.md)
 
 ---
 
-### 2. Slim Trigger Map (Quick Validation)
-
-**What it is:**
-- Streamlined single-workshop approach
-- Focus on one primary business goal, target group, and their driving forces
-- Quick strategic validation
-- Essential connections only
-
-**When to use:**
-- Smaller features or iterations
-- Single user journey focus
-- Quick strategic check
-- Early-stage validation
-- Time-constrained situations
-
-**Time investment:** 15-20 minutes
-**Output:** Slim Trigger Map with one goal, one target group, key driving forces
-
----
-
-### 3. Documentation Synthesis (Existing Research)
+### 2. Documentation Synthesis (Existing Research)
 
 **What it is:**
 - Extract strategic elements from existing docs
@@ -272,9 +258,9 @@ WDS offers three ways to apply Trigger Mapping methodology, depending on your si
 - Need to make existing documentation actionable
 - Documentation is too long for anyone to read
 
-**Time investment:** 30-45 minutes  
-**Output:** Synthesized Trigger Map + gap analysis  
-**Tutorial:** [Tutorial 05C: Synthesize from Documentation](tutorial-05c-documentation-synthesis.md)
+**Time investment:** 30-45 minutes
+**Output:** Synthesized Trigger Map + gap analysis
+**Tutorial:** [Tutorial 06C: Synthesize from Documentation](tutorial-06c-documentation-synthesis.md)
 
 **The problem this solves:**
 Organizations spend thousands on research that sits unused. 200-page reports nobody reads. Interview transcripts gathering dust. This approach transforms that investment into a single-slide strategic artifact you can actually use in daily design work and AI chats.
@@ -291,13 +277,6 @@ Organizations spend thousands on research that sits unused. 200-page reports nob
 - Stakeholders need strategic justification
 - Building long-term product strategy
 
-**Use Slim Trigger Map if:**
-- Iterating on existing features
-- One clear user journey to validate
-- Need quick strategic check
-- Early exploration phase
-- Time is very limited (under 20 minutes)
-
 **Use Documentation Synthesis if:**
 - You have vision docs, user research, or plans
 - Documentation exists but isn't being used
@@ -305,7 +284,7 @@ Organizations spend thousands on research that sits unused. 200-page reports nob
 - Want to validate strategic alignment
 - Need actionable artifact from existing investment
 
-**Pro tip:** Learn Full Trigger Mapping first (this module). Once you understand the complete process, you'll know when to use the lightweight version or documentation synthesis.
+**Note:** When you need strategic context for a scenario or content piece later, you don't create a separate map — you pick the relevant business goal, persona, and driving forces from the Trigger Map you already have.
 
 ---
 
@@ -358,6 +337,6 @@ You'll see exactly how to create your Trigger Map.
 
 ---
 
-[← Back to Lesson 1](lesson-01-missing-link.md) | [Next: Lesson 3 - The Five Workshops →](lesson-03-five-workshops.md)
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 1](lesson-01-missing-link.md) | [Next: Lesson 3 - The Five Workshops →](lesson-03-five-workshops-overview.md)
 
-*Part of Module 05: Trigger Mapping*
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-03-five-workshops-overview.md b/docs/learn/module-06-trigger-mapping/lesson-03-five-workshops-overview.md
similarity index 96%
rename from docs/learn-wds/module-05-trigger-mapping/lesson-03-five-workshops-overview.md
rename to docs/learn/module-06-trigger-mapping/lesson-03-five-workshops-overview.md
index c0142c6f7..963a29985 100644
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-03-five-workshops-overview.md
+++ b/docs/learn/module-06-trigger-mapping/lesson-03-five-workshops-overview.md
@@ -1,4 +1,6 @@
-# Lesson 3: The Five Workshops Overview
+# Module 06: Trigger Mapping
+
+## Lesson 3: The Five Workshops Overview
 
 **Your Roadmap to Strategic Clarity**
 
@@ -423,7 +425,7 @@ You can update the map. The structure stays, the content evolves.
 
 The next five lessons dive deep into each workshop:
 
-- **Lesson 4:** Workshop 1 - Business Goals (vision + SMART objectives)
+- **Lesson 4:** Workshop 1 - Business Goals (vision + strategic objectives)
 - **Lesson 5:** Workshop 2 - Target Groups (WHO ensures success)
 - **Lesson 6:** Workshop 3 - Driving Forces (psychology that drives behavior)
 - **Lesson 7:** Workshop 4 - Prioritization (what matters most)
@@ -436,7 +438,7 @@ The next five lessons dive deep into each workshop:
 - Common mistakes to avoid
 - Tips for success
 
-**After the lessons:** Tutorial 05 walks you through all 5 workshops step-by-step with Saga.
+**After the lessons:** Tutorial 06 walks you through all 5 workshops step-by-step with Saga.
 
 ---
 
@@ -454,6 +456,6 @@ The next five lessons dive deep into each workshop:
 
 ---
 
-[← Back to Lesson 2](lesson-02-heritage-evolution.md) | [Next: Lesson 4 - Workshop 1: Business Goals →](lesson-04-workshop-1-business-goals.md)
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 2](lesson-02-heritage-evolution.md) | [Next: Lesson 4 - Workshop 1: Business Goals →](lesson-04-workshop-1-business-goals.md)
 
-*Part of Module 05: Trigger Mapping*
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn/module-06-trigger-mapping/lesson-04-workshop-1-business-goals.md b/docs/learn/module-06-trigger-mapping/lesson-04-workshop-1-business-goals.md
new file mode 100644
index 000000000..8c3c56612
--- /dev/null
+++ b/docs/learn/module-06-trigger-mapping/lesson-04-workshop-1-business-goals.md
@@ -0,0 +1,319 @@
+# Module 06: Trigger Mapping
+
+## Lesson 4: Workshop 1 - Business Goals
+
+**Saga Guides You to Define What Winning Looks Like**
+
+---
+
+## Overview
+
+Workshop 1 is where Saga helps you articulate the strategic foundation for your entire Trigger Map. Through a guided conversation, Saga draws out both your aspirational vision and the concrete measurable objectives that prove you're succeeding.
+
+**Duration:** 15-20 minutes
+**Format:** Guided dialog with Saga (one thoughtful question at a time)
+**Output:** Vision statement + 3-5 strategic objectives (documented by Saga)
+
+---
+
+## Understanding the Two Levels
+
+Business goals work on two distinct levels:
+
+### 1. Vision (Visionary Statements)
+
+**What it is:**
+- Aspirational and motivational
+- Grand ambitions that reflect focus and direction
+- Not exact or measurable
+- Examples: "Be the best," "Fastest in market," "Top of mind"
+
+**Characteristics:**
+- Easy to set, hard to measure
+- Provides the "why" and emotional drive
+- Inspires and motivates the team
+- Gives direction without rigid constraints
+
+### 2. Strategic Objectives
+
+**What it is:**
+- Specific and measurable (expressed using SMART method)
+- Observable evidence that vision is being realized
+- Concrete milestones you can track
+- Examples: "10,000 users by Q4," "70% retention rate"
+
+**Characteristics:**
+- Harder to set, easy to measure
+- Provides the "what" and accountability
+- Enables progress tracking
+- Creates clear success criteria
+
+**Why both matter:** Visionary statements provide motivation and direction. Objectives provide accountability and proof of progress. Together they create both inspiration and measurement.
+
+---
+
+## How the Guided Dialog Works
+
+### Phase 1: Saga Helps You Articulate Vision
+
+**Saga starts with the big picture:**
+
+Saga asks about your grand ambition - not metrics yet, just the aspirational future state. She listens as you describe what motivates the team and why this project matters.
+
+**Natural conversation flow:**
+> **Saga:** "Let's start with the big picture. What's the grand ambition behind this project?"
+> **You:** "We want to make remote work sustainable and healthy..."
+> **Saga:** "That's compelling. When you say 'sustainable and healthy,' what does that mean to you?"
+> **You:** [You elaborate on your thinking]
+> **Saga:** "So if I'm hearing you right, you're aiming to..." [reflects back your vision]
+
+**Saga captures your vision statement** as you talk. No forms to fill out.
+
+### Phase 2: Saga Bridges to Observable Reality
+
+**The critical bridging question:**
+
+Once Saga understands your vision, she asks the question that transforms aspiration into measurable reality: **"When this vision is being realized, what will we observe in the world?"**
+
+**Conversation continues:**
+> **Saga:** "When remote work is sustainable and healthy, what will we actually see happening?"
+> **You:** "Well, teams would be using the tools regularly, staying engaged..."
+> **Saga:** "Good - what else? What would prove this is working?"
+> **You:** "They'd stick around long-term, maybe grow their usage..."
+> **Saga:** "And from a business perspective?"
+> **You:** "We'd see revenue that proves the model is viable."
+
+**Saga documents these observations** as you think through them together.
+
+### Phase 3: Saga Helps Define Strategic Objectives
+
+**Converting insights to SMART objectives:**
+
+Now Saga takes what you've described and helps you sharpen it into 3-5 specific, measurable objectives. She asks about numbers, timeframes, and what's realistically achievable.
+
+See [SMART Method Reference](../../models/smart-goals-model.md) for the framework Saga uses.
+
+**Dialog example:**
+> **Saga:** "You mentioned teams using it regularly. What does 'regularly' look like in numbers?"
+> **You:** "Daily engagement would be ideal..."
+> **Saga:** "What's a meaningful daily engagement metric you could track?"
+> **You:** "Maybe 15 minutes of active time?"
+> **Saga:** "Perfect. So one objective could be: 'Increase average session time to 15 minutes daily.' Does that capture it?"
+
+**Saga documents each objective** in proper SMART format as you refine them together.
+
+**Example final objectives:**
+1. Achieve 5,000 active teams by Q4 2024
+2. Increase average session time to 15 minutes daily
+3. Reach 70% weekly retention rate
+4. Generate $50K MRR by end of year
+
+---
+
+## Saga's Conversational Approach
+
+### Questions Saga Asks (One at a Time)
+
+**Saga doesn't interrogate - she guides.** Each question builds naturally on what you just said. She listens deeply, reflects back your thinking, and helps you articulate what you already know but haven't fully expressed.
+
+**Opening questions about vision:**
+- "What's the grand ambition behind this project?"
+- "When you say [your words], what does that really mean to you?"
+- "What motivates your team about this?"
+- "Why does this matter right now?"
+
+**The critical bridging question:**
+- "When this vision is being realized, what will we observe in the world?"
+- "What evidence would prove this is working?"
+- "What would we actually see happening?"
+
+**Sharpening into SMART objectives:**
+- "What specific numbers would indicate success?"
+- "By when would you need to hit these targets?"
+- "How will you measure [the thing you mentioned]?"
+- "What counts as 'active' or 'engaged' in your context?"
+- "Is that achievable given your resources and timeline?"
+
+### Saga's Facilitation Techniques
+
+**Like BMad v6, Saga:**
+- **Asks one question at a time** (never overwhelming)
+- **Listens to your full answer** before responding
+- **Reflects back what you said** to confirm understanding
+- **Asks clarifying follow-ups** naturally
+- **Documents as you talk** (you don't type, she captures it)
+- **Challenges gently** when something needs sharpening
+- **Makes you feel heard** throughout the conversation
+
+**The result:** You end the conversation with clear, documented goals that feel like yours (because they are) - Saga just helped you articulate them.
+
+---
+
+## Generic Example Walkthrough
+
+### Vision (Visionary Goal)
+
+"Make remote work sustainable and healthy for distributed teams"
+
+**Why this works:**
+- Aspirational and motivating
+- Clear direction without rigid constraints
+- Easy to communicate and remember
+- Inspires the team
+
+### Bridging Question
+
+"When remote work is sustainable and healthy, what will we observe?"
+
+**Observations:**
+- Teams using our solution daily
+- High retention rates (people stay)
+- Growing usage patterns
+- Sustainable business model (revenue)
+
+### Strategic Objectives (using SMART method)
+
+1. **Achieve 5,000 active teams by Q4 2024**
+   - Specific: Active teams (defined metric)
+   - Measurable: 5,000 teams
+   - Achievable: Based on market size and growth rate
+   - Relevant: Proves market adoption
+   - Time-bound: Q4 2024
+
+2. **Increase average session time to 15 minutes daily**
+   - Specific: Session time metric
+   - Measurable: 15 minutes
+   - Achievable: Industry benchmarks
+   - Relevant: Indicates engagement
+   - Time-bound: Daily measurement
+
+3. **Reach 70% weekly retention rate**
+   - Specific: Weekly retention
+   - Measurable: 70% rate
+   - Achievable: Above industry average
+   - Relevant: Proves value delivery
+   - Time-bound: Weekly tracking
+
+4. **Generate $50K MRR by end of year**
+   - Specific: Monthly recurring revenue
+   - Measurable: $50K
+   - Achievable: Based on pricing and targets
+   - Relevant: Business sustainability
+   - Time-bound: End of year
+
+---
+
+## What You Get from Workshop 1
+
+✅ **Crystal-clear vision** - Your ambition articulated better than you could alone
+✅ **SMART strategic objectives** - Your goals sharpened and documented by Saga
+✅ **Natural bridge** - Vision and metrics connected logically (not forced)
+✅ **Strategic foundation** - Everything else builds from this conversation
+✅ **Team alignment** - "Why" and "what" captured in Saga's documentation
+✅ **Clarity without worksheets** - No templates, just guided conversation
+✅ **Confidence** - Your strategic thinking validated and strengthened
+
+---
+
+## Common Mistakes to Avoid
+
+### Mistake 1: Rushing Through Saga's Questions
+
+**Problem:** Giving short, surface-level answers to move faster
+**Why it fails:** Saga can't help you think deeply, results are shallow
+**Fix:** Take time with each question. Saga's pace is intentional.
+
+### Mistake 2: Not Challenging Vague Language
+
+**Problem:** Accepting when Saga reflects back fuzzy thinking
+**Why it fails:** Ends with goals you can't actually use
+**Fix:** When something doesn't feel right, say so. Saga will help sharpen it.
+
+### Mistake 3: Bringing Pre-Written Goals
+
+**Problem:** "Here are my goals, just document them"
+**Why it fails:** Misses the value of Saga's guided thinking process
+**Fix:** Come prepared with ideas, but let Saga guide you to refine them
+
+### Mistake 4: Saying Yes to Too Many Objectives
+
+**Problem:** Saga suggests narrowing to 5, you insist on keeping 15
+**Why it fails:** Dilutes focus, creates confusion for later workshops
+**Fix:** Trust Saga's strategic advice - she knows what feeds into Workshop 2-5
+
+### Mistake 5: Setting Unrealistic Targets to Impress
+
+**Problem:** Inflating numbers because they sound better
+**Why it fails:** Later workshops build on these - unrealistic goals cascade
+**Fix:** Be honest with Saga about resources and constraints
+
+### Mistake 6: Skipping the Bridging Question
+
+**Problem:** Jumping straight from vision to random metrics
+**Why it fails:** Goals feel disconnected from the bigger purpose
+**Fix:** Let Saga guide you through "what will we observe?" - it's the key step
+
+---
+
+## How This Feeds Into Next Workshops
+
+**Workshop 1 creates the foundation:**
+
+```
+Business Goals (Vision + Objectives)
+    ↓
+Workshop 2: Which user groups can help achieve these?
+    ↓
+Workshop 3: What drives those groups' behavior?
+    ↓
+Workshop 4: Which groups and drivers matter most?
+    ↓
+Workshop 5: Which features address top priorities?
+```
+
+Everything traces back to the goals you define here.
+
+---
+
+## Tips for a Successful Dialog with Saga
+
+**DO:**
+- ✅ Think out loud - Saga learns from your reasoning, not just your answers
+- ✅ Challenge what doesn't feel right - Saga wants you to push back
+- ✅ Ask Saga to explain why she's asking something - it helps you think
+- ✅ Reference your Product Brief - Saga will connect the dots
+- ✅ Take time to think before answering - this isn't a speed test
+- ✅ Trust Saga when she suggests sharpening fuzzy language
+
+**DON'T:**
+- ❌ Rush through to "get it done" - thoughtful answers = better outcomes
+- ❌ Give one-word answers - Saga needs context to help you think
+- ❌ Treat it like a form - it's a conversation, not data entry
+- ❌ Accept vague objectives just to move on - Saga will help you sharpen
+- ❌ Inflate numbers to sound impressive - be realistic with Saga
+- ❌ Skip the vision phase - Saga needs the "why" before the "what"
+
+---
+
+## What's Next
+
+Workshop 2 identifies WHO can help you achieve these goals - your target groups. You'll create prioritized personas that become the foundation for understanding user psychology.
+
+---
+
+## Key Takeaways
+
+✅ **Guided conversation, not a form** - Saga asks one thoughtful question at a time
+✅ **Two levels emerge naturally** - Vision (aspirational) then Strategic Objectives (SMART)
+✅ **The bridging question is key** - "What will we observe?" connects vision to metrics
+✅ **Saga documents as you talk** - No templates or worksheets to fill out
+✅ **Your thinking, sharpened** - Saga helps you articulate what you already know
+✅ **3-5 objectives is strategic** - Saga guides you to focus on what truly matters
+✅ **Foundation for all workshops** - These goals drive everything that follows
+✅ **Like BMad v6** - Natural dialog flow that makes you think better
+
+---
+
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 3](lesson-03-five-workshops-overview.md) | [Next: Lesson 5 - Workshop 2: Target Groups →](lesson-05-workshop-2-target-groups.md)
+
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn/module-06-trigger-mapping/lesson-05-workshop-2-target-groups.md b/docs/learn/module-06-trigger-mapping/lesson-05-workshop-2-target-groups.md
new file mode 100644
index 000000000..5c6df64e1
--- /dev/null
+++ b/docs/learn/module-06-trigger-mapping/lesson-05-workshop-2-target-groups.md
@@ -0,0 +1,557 @@
+# Module 06: Trigger Mapping
+
+## Lesson 5: Workshop 2 - Target Groups
+
+**Saga Helps You Identify Who Ensures Your Success**
+
+---
+
+## The Core Question Saga Explores With You
+
+Through guided conversation, Saga helps you answer: **WHO out there in the world will make sure, with their use of the product, that you achieve your goals?**
+
+This question contains the entire chain of value creation. Let's break it down:
+
+### Breaking Down the Question
+
+**"WHO"**
+- Which representative from which ICP (Ideal Customer Profile)?
+- Specific behavioral and contextual profiles
+- Not demographics, but real people with real contexts
+
+**"Out there in the world"**
+- These are real people whose lives your product needs to touch
+- Not abstract user segments, but actual humans in specific situations
+- Your product must reach and impact their reality
+
+**"Will make sure"**
+- A product needs to be used, and used in the intended way
+- Usage alone isn't enough - it must be the right usage
+- Their behavior drives the outcome
+
+**"With their use of the product"**
+- The product must give more value than the pain of using it
+- If usage pain > value gained, they won't care
+- They need motivation to engage and continue
+
+**"That you achieve your goals"**
+- The use of the product must tie to measurable business goals
+- Without this connection, success isn't possible
+- This completes the chain: WHO → uses product → right way → creates value → achieves goals
+
+**This distinction is critical** and reflects throughout the entire Trigger Mapping methodology.
+
+---
+
+## Overview
+
+Workshop 2 is where Saga guides you to identify the specific user groups whose behavior will drive your business success. Through thoughtful questions, Saga helps you create detailed personas and prioritize them by strategic value.
+
+**Duration:** 20-25 minutes
+**Format:** Guided dialog with Saga (exploring one persona at a time)
+**Output:** 3-5 prioritized personas with deep context (documented by Saga)
+
+---
+
+## How the Guided Dialog Works
+
+### Phase 1: Saga Helps You Identify User Groups
+
+**Saga starts with your business goals from Workshop 1:**
+
+Saga asks who could help you achieve those specific objectives. She guides you away from demographics ("parents aged 30-45") toward behavioral and contextual profiles ("busy working parents juggling multiple schedules while afraid of dropping the ball").
+
+**Natural conversation flow:**
+> **Saga:** "Looking at your goal of achieving 5,000 active teams, who are the people whose behavior would drive that success?"
+> **You:** "Well, team leaders who manage remote teams..."
+> **Saga:** "Good - tell me more about these team leaders. What's their world like?"
+> **You:** [You describe their context and challenges]
+> **Saga:** "So they're managing distributed teams with limited visibility. What else defines this group?"
+
+**Saga documents each group** as you identify them together. She'll guide you to 3-5 distinct groups - not more.
+
+### Phase 2: Saga Draws Out Deep Persona Profiles
+
+**For each group, Saga asks about WHO they really are:**
+
+Through natural conversation, Saga helps you build rich profiles - not surface demographics, but real context, behavioral patterns, and their current reality before your product exists.
+
+**Dialog example:**
+> **Saga:** "Let's dig into Remote Team Leads. What's their daily context?"
+> **You:** "They're managing 5-10 people across different time zones..."
+> **Saga:** "That sounds isolating. How do they currently handle team health?"
+> **You:** "Mostly check-ins and hoping people speak up..."
+> **Saga:** "And when people don't speak up?"
+> **You:** "That's their fear - problems brewing that they can't see."
+
+**Saga captures the persona profile** - context, behavioral patterns, current reality. No template forms.
+
+**Note:** Saga focuses on WHO they are in this phase. Usage goals and fears come later when she asks: "When this persona encounters your problem space and discovers your product, what do they want? What do they fear?"
+
+### Phase 3: Saga Guides Strategic Prioritization
+
+**Saga helps you rank groups by strategic value:**
+
+Through questioning, Saga helps you think through impact on business goals, feasibility to reach, and urgency of pain. She challenges when priorities seem unclear or inconsistent with your objectives.
+
+**Dialog example:**
+> **Saga:** "We have three groups. Which has the most potential to drive your 5,000 team goal?"
+> **You:** "Probably team leads - each one brings their whole team..."
+> **Saga:** "Good insight. And can you reach them?"
+> **You:** "Yes, through LinkedIn and management communities."
+> **Saga:** "So Team Leads rank #1 for both impact and feasibility. What about Solo Workers vs Executives?"
+
+**Saga documents the ranking** with strategic reasoning for each placement.
+
+---
+
+## Saga's Conversational Approach
+
+### How Saga Explores User Groups
+
+**Saga guides, doesn't interrogate.** She asks about one group at a time, listens deeply to your insights about their world, and reflects back what she's hearing to confirm understanding.
+
+**Opening questions about groups:**
+- "Looking at [your specific business goal], who are the people whose behavior would drive that success?"
+- "Tell me about the different types of users who could help achieve this."
+- "Who has the power to make [your objective] happen through their use of the product?"
+
+**Deep dive into each persona (WHO they are):**
+- "Let's explore [group name]. What's their daily context?"
+- "What's going on in their world right now?"
+- "How do they currently handle [the problem]?"
+- "What behavioral patterns do you see in this group?"
+- "What's their reality before they discover your solution?"
+
+**Exploring usage goals (when they encounter your problem space):**
+- "When [persona name] faces this problem and discovers your product, what do they want to achieve?"
+- "What positive outcomes are they hoping for?"
+- "And what are they afraid might happen?"
+- "What keeps them up at night about this?"
+- "What would 'success' look like to them?"
+
+**Prioritization questions:**
+- "Of these groups, which one has the most potential to drive [your top business goal]?"
+- "Can you actually reach this group? How?"
+- "How urgent is their pain compared to the others?"
+- "So based on impact, feasibility, and urgency, how would you rank them?"
+- "Why does [group] rank higher than [other group]?"
+
+### Saga's Facilitation Techniques
+
+**Like BMad v6, Saga:**
+- **One persona at a time** - Doesn't overwhelm with all groups at once
+- **Listens to your stories** - Your examples reveal more than abstract descriptions
+- **Reflects behavioral insight** - "So they're constantly worried about missing warning signs..."
+- **Challenges surface descriptions** - "But what's their actual day-to-day context?"
+- **Documents rich profiles** - You describe, she captures the behavioral essence
+- **Guides toward 3-5 groups** - Stops you from over-segmenting
+- **Makes ranking strategic** - Links prioritization back to Workshop 1 goals
+
+---
+
+## Generic Example
+
+### Target Group 1: Remote Team Leads
+
+#### Persona Profile (WHO they are)
+
+**Context:**
+- Managing 5-10 distributed team members across time zones
+- Responsible for team performance and wellbeing
+- Limited visibility into individual struggles
+
+**Behavioral Patterns:**
+- Checks in with team daily
+- Monitors project progress closely
+- Seeks early warning signs
+- Values data-driven insights
+
+#### Usage Goals (When they face our problem space)
+
+*When Remote Team Leads discover our product, they want to...*
+
+**Positive Drivers (what they want to achieve):**
+- Keep team productive and connected
+- Recognize and support struggling members early
+- Demonstrate effective leadership to management
+
+**Negative Drivers (what they want to avoid):**
+- Team burnout without noticing
+- Missed deadlines due to unseen problems
+- Poor performance reviews
+- Losing top performers
+- Team becoming disconnected
+
+**Priority:** #1 (High impact + reachable + urgent pain)
+
+---
+
+### Target Group 2: Solo Remote Workers
+
+#### Persona Profile (WHO they are)
+
+**Context:**
+- Working alone from home without office structure
+- No team to provide accountability or connection
+- Struggling with boundaries and focus
+
+**Behavioral Patterns:**
+- Seeks structure and routine
+- Values community connection
+- Struggles with self-discipline
+- Craves professional growth
+
+#### Usage Goals (When they face our problem space)
+
+*When Solo Remote Workers discover our product, they want to...*
+
+**Positive Drivers (what they want to achieve):**
+- Stay focused and productive
+- Maintain work-life boundaries
+- Feel connected to professional community
+- Advance career despite isolation
+
+**Negative Drivers (what they want to avoid):**
+- Career stagnation
+- Burnout from overwork
+- Losing touch with industry
+- Being forgotten by management
+- Professional isolation
+
+**Priority:** #2 (Large market + moderate impact)
+
+---
+
+### Target Group 3: Remote Executives
+
+#### Persona Profile (WHO they are)
+
+**Context:**
+- Overseeing multiple distributed teams
+- Responsible for organizational performance
+- Limited visibility into team dynamics
+
+**Behavioral Patterns:**
+- Relies on aggregated data
+- Values high-level insights
+- Needs quick decision-making tools
+- Focuses on organizational metrics
+
+#### Usage Goals (When they face our problem space)
+
+*When Remote Executives discover our product, they want to...*
+
+**Positive Drivers (what they want to achieve):**
+- Ensure organizational productivity
+- Maintain company culture remotely
+- Make data-driven decisions
+- Retain top talent
+
+**Negative Drivers (what they want to avoid):**
+- Organizational dysfunction
+- Mass turnover
+- Productivity decline
+- Cultural erosion
+- Competitive disadvantage
+
+**Priority:** #3 (High value but harder to reach)
+
+---
+
+## Another Generic Example: Public Transport App
+
+This example shows how the same "customers" (travelers) have completely different needs based on their context.
+
+### Target Group 1: Daily Commuters
+
+#### Persona Profile (WHO they are)
+
+**Context:**
+- Same route every workday (home ↔ work)
+- Time-sensitive schedule (must arrive on time)
+- Experienced with the system
+
+**Behavioral Patterns:**
+- Checks app before leaving
+- Knows alternative routes
+- Values real-time updates
+- Wants predictability
+
+#### Usage Goals (When they face their commute)
+
+*When Daily Commuters open our app, they want to...*
+
+**Positive Drivers (what they want to achieve):**
+- Get to work/home efficiently
+- Minimize waiting time
+- Avoid delays and disruptions
+
+**Negative Drivers (what they want to avoid):**
+- Being late to work (professional consequences)
+- Missing important meetings
+- Unpredictable commute times
+
+**Priority:** #1 (Highest volume, daily usage, urgent needs)
+
+---
+
+### Target Group 2: Tourists
+
+#### Persona Profile (WHO they are)
+
+**Context:**
+- Unfamiliar with the city and transit system
+- Exploring multiple destinations
+- No time pressure but limited trip duration
+
+**Behavioral Patterns:**
+- Plans routes in advance
+- Needs step-by-step guidance
+- Values visual/map-based navigation
+- Seeks reassurance at each step
+
+#### Usage Goals (When they face navigation)
+
+*When Tourists open our app, they want to...*
+
+**Positive Drivers (what they want to achieve):**
+- Navigate unfamiliar system confidently
+- Find best routes to attractions
+- Understand ticketing and payment
+- Maximize sightseeing time
+
+**Negative Drivers (what they want to avoid):**
+- Wasting vacation time being lost
+- Looking foolish or incompetent
+- Missing key attractions
+- Overpaying for tickets
+
+**Priority:** #2 (Growing market, different needs than commuters)
+
+---
+
+### Target Group 3: Seniors
+
+#### Persona Profile (WHO they are)
+
+**Context:**
+- May have mobility limitations
+- Less familiar with digital tools
+- Often traveling during off-peak hours
+- May need accessibility features
+
+**Behavioral Patterns:**
+- Prefers simple, clear interfaces
+- Values accessibility information
+- Needs larger text and clear instructions
+- May prefer human assistance options
+
+#### Usage Goals (When they face travel planning)
+
+*When Seniors open our app, they want to...*
+
+**Positive Drivers (what they want to achieve):**
+- Travel safely and comfortably
+- Avoid physical strain (stairs, long walks)
+- Feel confident using the system
+- Maintain independence
+
+**Negative Drivers (what they want to avoid):**
+- Falling or getting injured
+- Being stranded or unable to get help
+- Losing independence
+- Embarrassment from not understanding technology
+
+**Priority:** #3 (Important for accessibility, regulatory requirements)
+
+---
+
+### Why This Example Works
+
+**Same product (public transport app), completely different needs:**
+
+**Commuters need:**
+- Real-time delay alerts
+- Quick route alternatives
+- Predictability and reliability
+- Speed and efficiency
+
+**Tourists need:**
+- Step-by-step navigation
+- Visual/map-based guidance
+- Ticketing help
+- Confidence and reassurance
+
+**Seniors need:**
+- Accessibility information
+- Simple, clear interfaces
+- Larger text and buttons
+- Safety and comfort features
+
+**The insight:** If you designed only for commuters (speed and efficiency), you'd fail tourists and seniors. If you designed only for tourists (detailed guidance), you'd frustrate commuters who want speed. Understanding these distinct groups allows you to prioritize features strategically.
+
+---
+
+## Why Behavioral Profiles Matter
+
+### Not This (Demographics)
+
+"Parents aged 30-45 with household income $75K+"
+
+**Problem:** Doesn't tell you what drives behavior, what they need, or how to design for them.
+
+### This (Behavioral + Contextual)
+
+"Busy working parents juggling multiple kids' schedules, family dog care, and full-time jobs - constantly afraid of dropping the ball on family responsibilities"
+
+**Why it works:** You understand their world, their challenges, their fears. You can design for their actual needs.
+
+---
+
+## Prioritization Criteria
+
+### Impact on Business Goals
+
+**Ask:**
+- Which group's behavior most directly drives our objectives?
+- Which group has the power to make our goals happen?
+- Which group's success equals our success?
+
+**Example:** Remote Team Leads rank #1 because each one brings 5-10 users (their team), has budget authority, and urgent pain.
+
+### Feasibility to Reach
+
+**Ask:**
+- Can we actually reach this group?
+- Do we have channels to communicate with them?
+- Can we serve them with our resources?
+- Is the market size sufficient?
+
+**Example:** Executives rank lower because they're harder to reach despite high value.
+
+### Urgency of Pain
+
+**Ask:**
+- How urgent is their problem?
+- Are they actively seeking solutions?
+- What's the cost of not solving this?
+
+**Example:** Team Leads have urgent pain (team burnout risk) vs Solo Workers have chronic pain (isolation).
+
+---
+
+## What You Get from Workshop 2
+
+✅ **3-5 prioritized personas** - Rich behavioral profiles, not demographic categories
+✅ **Deep contextual understanding** - Saga helped you articulate each group's world
+✅ **Strategic ranking** - Clear priorities based on impact, feasibility, and urgency
+✅ **Documented profiles** - Saga captured everything as you talked
+✅ **Foundation for psychology mapping** - These personas feed Workshop 3
+✅ **Focused clarity** - You know exactly who you're designing for and why
+✅ **Behavioral insight** - You understand their context, not just their demographics
+
+---
+
+## Common Mistakes to Avoid
+
+### Mistake 1: Giving Saga Demographics Instead of Context
+
+**Problem:** "Males 25-40 with college degrees"
+**Why it fails:** Saga can't build behavioral profiles from demographics alone
+**Fix:** When Saga asks about the group, describe their world, their context, their daily reality
+
+### Mistake 2: Insisting on Too Many Groups
+
+**Problem:** "We have 10 different user types we need to include"
+**Why it fails:** Saga will guide you to 3-5 for strategic focus
+**Fix:** Trust Saga's guidance - you can always expand later after validating the core groups
+
+### Mistake 3: Refusing to Prioritize
+
+**Problem:** "All these groups are equally important to us"
+**Why it fails:** Saga needs clear priorities for Workshops 3-5 to work effectively
+**Fix:** Let Saga help you make the hard choices based on strategic value
+
+### Mistake 4: Accepting Surface-Level Descriptions
+
+**Problem:** "They want to be productive" (accepting generic statements)
+**Why it fails:** Saga can't build deep personas from shallow descriptions
+**Fix:** When Saga digs deeper with follow-ups, take time to think and elaborate
+
+### Mistake 5: Skipping Feasibility Discussion
+
+**Problem:** Not being honest about which groups you can actually reach
+**Why it fails:** Later roadmap won't be executable
+**Fix:** Be realistic with Saga about your marketing channels and resources
+
+### Mistake 6: Mixing Up "Who They Are" and "What They Want"
+
+**Problem:** Describing goals before describing the person
+**Why it fails:** Saga builds personas first, usage goals come in Workshop 3
+**Fix:** When Saga asks "who are they?" focus on context and behavior, not desires
+
+---
+
+## How This Feeds Into Next Workshops
+
+**Workshop 2 sets up the psychology mapping:**
+
+```
+Business Goals
+    ↓
+Target Groups (prioritized personas)
+    ↓
+Workshop 3: What drives each group's behavior?
+    ↓
+Workshop 4: Which drivers are most powerful?
+    ↓
+Workshop 5: Which features address top drivers?
+```
+
+The personas you create here become the foundation for understanding psychological drivers.
+
+---
+
+## Tips for a Successful Dialog with Saga
+
+**DO:**
+- ✅ Tell stories about real people when describing groups - Saga learns from examples
+- ✅ Go deep when Saga asks follow-ups - she's looking for behavioral insight
+- ✅ Be honest about which groups you can actually reach and serve
+- ✅ Let Saga challenge surface-level descriptions - she's helping you think deeper
+- ✅ Trust Saga when she suggests narrowing to 3-5 groups - focus is strategic
+- ✅ Describe WHO they are (context, behavior) before WHAT they want (goals, fears)
+
+**DON'T:**
+- ❌ Give demographics when Saga asks for behavioral profiles
+- ❌ Insist on including every possible user type - dilutes strategic focus
+- ❌ Say "all groups are equal" - Saga needs clear priorities for next workshops
+- ❌ Accept your first description - let Saga dig for richer context
+- ❌ Skip the feasibility conversation - be realistic about reach and resources
+- ❌ Mix up persona descriptions with usage goals - Saga handles these in sequence
+
+---
+
+## What's Next
+
+Workshop 3 maps the psychological drivers for each persona - both what they want to achieve (positive drivers) and what they want to avoid (negative drivers). This is where you understand the psychology that drives behavior.
+
+---
+
+## Key Takeaways
+
+✅ **Guided exploration** - Saga asks about one persona at a time, building depth through conversation
+✅ **Two-part structure** - First WHO they are (persona context), then what they want (usage goals)
+✅ **Behavioral not demographic** - Saga guides you to context and patterns, not age and income
+✅ **3-5 groups by design** - Saga keeps you focused on strategic value
+✅ **Strategic prioritization** - Saga helps you rank by impact + feasibility + urgency
+✅ **Stories reveal insight** - Your examples help Saga understand and document behavioral profiles
+✅ **Foundation for psychology** - These personas feed directly into Workshop 3
+✅ **Like BMad v6** - Natural dialog that draws out deeper insight than you'd write alone
+
+---
+
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 4](lesson-04-workshop-1-business-goals.md) | [Next: Lesson 6 - Workshop 3: Driving Forces →](lesson-06-workshop-3-driving-forces.md)
+
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-06-workshop-3-driving-forces.md b/docs/learn/module-06-trigger-mapping/lesson-06-workshop-3-driving-forces.md
similarity index 53%
rename from docs/learn-wds/module-05-trigger-mapping/lesson-06-workshop-3-driving-forces.md
rename to docs/learn/module-06-trigger-mapping/lesson-06-workshop-3-driving-forces.md
index e08f3e2e8..6077379a2 100644
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-06-workshop-3-driving-forces.md
+++ b/docs/learn/module-06-trigger-mapping/lesson-06-workshop-3-driving-forces.md
@@ -1,67 +1,92 @@
-# Lesson 5: Workshop 3 - Driving Forces
+# Module 06: Trigger Mapping
 
-**Map the Psychology That Drives Behavior**
+## Lesson 6: Workshop 3 - Driving Forces
+
+**Saga Helps You Map the Psychology That Drives Behavior**
 
 ---
 
 ## Overview
 
-Workshop 3 is where you map the psychological drivers for each persona - both what they want to achieve and what they want to avoid. This is the core of understanding what actually drives user behavior.
+Workshop 3 is where Saga guides you to uncover the psychological drivers for each persona - both what they want to achieve and what they want to avoid. Through thoughtful conversation, Saga draws out the emotional core of what actually drives user behavior.
 
-**Duration:** 20-30 minutes  
-**Format:** Conversational with Saga  
-**Output:** Complete psychological profile for each persona (positive + negative drivers)
+**Duration:** 20-30 minutes
+**Format:** Guided dialog with Saga (exploring one persona at a time)
+**Output:** Complete psychological profile for each persona (positive + negative drivers, documented by Saga)
 
 ---
 
-## What You'll Do
+## How the Guided Dialog Works
 
-For each persona from Workshop 2, you'll identify two types of drivers:
+### Saga Explores Two Types of Drivers for Each Persona
 
-### Positive Drivers (GAIN)
+**For each persona from Workshop 2, Saga helps you identify:**
 
-**What users are moving TOWARD:**
-- What do they want to achieve?
-- What benefits are they seeking?
-- What goals pull them forward?
-- What positive outcomes motivate them?
+**Positive Drivers (GAIN) - What they're moving TOWARD:**
 
-### Negative Drivers (PAIN)
+Through conversation, Saga draws out what they want to achieve, what benefits they're seeking, what goals pull them forward, and what positive outcomes motivate them.
 
-**What users are moving AWAY FROM:**
-- What do they want to avoid?
-- What frustrations do they experience?
-- What fears push them to act?
-- What problems are they trying to escape?
+**Negative Drivers (PAIN) - What they're moving AWAY FROM:**
 
-**The key insight:** Both matter, but negative drivers often create more urgent action due to loss aversion.
+Saga explores what they want to avoid, what frustrates them, what fears push them to act, and what problems they're trying to escape.
+
+**The key insight Saga emphasizes:** Both matter, but negative drivers often create more urgent action due to loss aversion. Saga will help you uncover both types.
 
 ---
 
-## Key Questions Saga Asks
+## Saga's Conversational Approach
 
-### For Positive Drivers
+### How Saga Uncovers Psychological Drivers
 
-- "What does this persona want to accomplish?"
-- "What positive outcomes are they seeking?"
-- "What would make their situation better?"
+**Saga works through each persona individually,** exploring their psychology deeply before moving to the next. She starts with positive drivers (aspirations), then shifts to negative drivers (fears and frustrations).
+
+**Opening questions about positive drivers (GAIN):**
+> **Saga:** "Let's explore what Remote Team Leads want to achieve. When they face managing a distributed team, what are they hoping for?"
+> **You:** "They want to keep everyone productive..."
+> **Saga:** "What does 'productive' mean to them emotionally? What would that accomplish?"
+> **You:** "I guess... they want to look like they're doing a good job as a leader..."
+> **Saga:** "So there's a want to demonstrate effective leadership. Tell me more about that..."
+
+**Saga's questions that dig into positive drivers:**
+- "What are they hoping to accomplish?"
+- "What would success look like emotionally, not just functionally?"
 - "What goals are pulling them forward?"
-- "What benefits would they value?"
+- "Why does that matter to them personally?"
+- "What benefits would they value most?"
 
-### For Negative Drivers
+**Shifting to negative drivers (PAIN):**
+> **Saga:** "Now let's flip to what they're trying to avoid. What are Remote Team Leads afraid might happen?"
+> **You:** "Well, they can't see their team members face-to-face..."
+> **Saga:** "And what's the fear in that?"
+> **You:** "That someone could be really struggling and they wouldn't know..."
+> **Saga:** "And if that happened - someone burning out without them noticing - how would they feel?"
+> **You:** "Terrible. Guilty. Like they failed as a manager."
+> **Saga:** "So there's a fear of team burnout without noticing, connected to guilt and professional failure. That's powerful. What else do they fear?"
 
-- "What problems are they trying to avoid?"
-- "What frustrates them about current solutions?"
+**Saga's questions that uncover negative drivers:**
+- "What keeps them up at night about this?"
+- "What are they trying to avoid?"
+- "What would be embarrassing or costly if it happened?"
+- "What frustrates them about how things work now?"
 - "What do they fear will happen if they don't solve this?"
-- "What keeps them up at night?"
-- "What would be embarrassing or costly?"
 
-### Digging Deeper
+**Saga digs deeper into emotional intensity:**
+- "Why does that matter to them emotionally? What's the feeling?"
+- "How intense is this driver? Is it a constant worry or occasional concern?"
+- "What's the deeper fear or desire behind what you just said?"
+- "That sounds a bit generic - can you be more specific about the emotional core?"
+- "On a scale of 1-5, how much does this drive their behavior?"
 
-- "Why does that matter to them emotionally?"
-- "What's the deeper fear behind that frustration?"
-- "How intense is this driver on a scale of 1-5?"
-- "Is that specific enough, or is it too generic?"
+### Saga's Facilitation Techniques
+
+**Like BMad v6, Saga:**
+- **One persona at a time** - Completes psychological profile before moving on
+- **Positive then negative** - Explores aspirations before fears
+- **Reflects emotional language** - "So you're saying they feel guilty when..."
+- **Challenges generic statements** - "What does 'productive' really mean to them?"
+- **Seeks emotional core** - "Why does that matter emotionally?"
+- **Documents as you discover** - You explore psychology, Saga captures drivers
+- **Validates intensity** - "Is this a constant worry or occasional concern?"
 
 ---
 
@@ -219,45 +244,53 @@ The most powerful understanding comes from mapping BOTH:
 
 ## What You Get from Workshop 3
 
-✅ **Complete psychological profile** for each persona  
-✅ **Both sides of motivation** (gain + pain)  
-✅ **Understanding of emotional intensity**  
-✅ **Foundation for feature decisions**  
-✅ **Insight into urgency** (what drives immediate action)
+✅ **Complete psychological profile** - Saga documented both positive and negative drivers for each persona
+✅ **Emotional depth** - Saga helped you articulate the emotional core, not just surface wants
+✅ **Intensity mapping** - Understanding which drivers have strongest pull
+✅ **Both sides of motivation** - Gain-seeking AND pain-avoidance for complete picture
+✅ **Foundation for prioritization** - These drivers feed directly into Workshop 4
+✅ **Urgency insight** - Clear view of what drives immediate vs eventual action
+✅ **Richer than you'd write alone** - Saga's probing revealed psychological drivers you might have missed
 
 ---
 
 ## Common Mistakes to Avoid
 
-### Mistake 1: Only Mapping Positive Drivers
+### Mistake 1: Rushing Past Negative Drivers
 
-**Problem:** Missing the urgent pain that drives adoption  
-**Why it fails:** Don't understand what creates urgency  
-**Fix:** Always map both types
+**Problem:** Spending more time on positive drivers because they feel nicer
+**Why it fails:** Saga needs both - negative drivers often have more urgency
+**Fix:** Give equal time to exploring fears and frustrations when Saga asks
 
-### Mistake 2: Generic "Wants" Statements
+### Mistake 2: Accepting Generic Statements
 
-**Problem:** "Want to be productive"  
-**Why it fails:** Too vague to guide design  
-**Fix:** Be specific about context and outcomes
+**Problem:** Saying "Want to be productive" when Saga asks for deeper emotional core
+**Why it fails:** Saga can't build specific psychological profiles from vague wants
+**Fix:** When Saga challenges "what does that mean emotionally?" - dig deeper with her
 
-### Mistake 3: Ignoring Emotional Intensity
+### Mistake 3: Listing Features Instead of Psychology
 
-**Problem:** All drivers seem equal  
-**Why it fails:** Can't prioritize effectively  
-**Fix:** Identify which have strongest emotional pull
+**Problem:** "Want a calendar feature" when Saga asks about drivers
+**Why it fails:** That's a solution, not a psychological driver
+**Fix:** When Saga redirects you, describe the emotional need: "Want to never miss family commitments due to work chaos"
 
-### Mistake 4: Listing Features Instead of Psychology
+### Mistake 4: Skipping Emotional Intensity Discussion
 
-**Problem:** "Want a calendar feature"  
-**Why it fails:** That's a solution, not a driver  
-**Fix:** "Want to never miss family commitments due to work chaos"
+**Problem:** Not engaging when Saga asks "how intense is this driver?"
+**Why it fails:** All drivers end up seeming equal, can't prioritize later
+**Fix:** Think through intensity honestly with Saga - constant worry vs occasional concern
 
-### Mistake 5: Avoiding Negative Drivers
+### Mistake 5: Avoiding Uncomfortable Negative Drivers
 
-**Problem:** Focusing only on positive because negative feels uncomfortable  
-**Why it fails:** Miss the most powerful motivators  
-**Fix:** Embrace negative drivers - they're often more actionable
+**Problem:** Downplaying fears because they feel uncomfortable to discuss
+**Why it fails:** Saga needs the real emotional drivers, including fear, shame, guilt
+**Fix:** Be honest about negative emotions - Saga knows they're often the most actionable
+
+### Mistake 6: Not Letting Saga Challenge Surface Answers
+
+**Problem:** Accepting your first answer without deeper exploration
+**Why it fails:** Miss the real emotional core that drives behavior
+**Fix:** When Saga asks follow-ups like "why does that matter emotionally?" - engage with the question
 
 ---
 
@@ -417,23 +450,24 @@ Once you've identified the driving forces for each target group, validate them w
 
 ---
 
-## Tips for Success
+## Tips for a Successful Dialog with Saga
 
 **DO:**
-- ✅ Map both positive AND negative drivers
-- ✅ Be specific about context and emotions
-- ✅ Identify emotional intensity
-- ✅ Dig deeper than surface wants
-- ✅ Focus on psychology, not features
-- ✅ Apply control questions to validate drivers
+- ✅ Give negative drivers equal time - they're often more urgent than positive ones
+- ✅ Answer Saga's "why emotionally?" questions honestly - that's where insight lives
+- ✅ Use specific examples from real users when describing drivers
+- ✅ Engage when Saga asks about intensity - "constant worry" vs "occasional concern" matters
+- ✅ Let Saga challenge generic statements - she's helping you think deeper
+- ✅ Focus on psychology and emotions, not features or solutions
+- ✅ Be honest about uncomfortable drivers - fear, shame, guilt, embarrassment
 
 **DON'T:**
-- ❌ Skip negative drivers
-- ❌ Accept generic statements
-- ❌ Ignore emotional core
-- ❌ List features instead of drivers
-- ❌ Treat all drivers as equal
-- ❌ Skip validation - assume drivers are correct
+- ❌ Rush through negative drivers because they feel uncomfortable
+- ❌ Give surface-level answers like "want to be productive" and stop there
+- ❌ List features when Saga asks for psychological drivers
+- ❌ Say all drivers are equally important - emotional intensity matters
+- ❌ Skip the control questions - Saga uses these to validate fit
+- ❌ Stop at your first answer - let Saga's follow-ups reveal deeper insight
 
 ---
 
@@ -445,14 +479,17 @@ Workshop 4 prioritizes these drivers - ranking which groups and which psychologi
 
 ## Key Takeaways
 
-✅ **Two types of drivers** - Positive (gain) and Negative (pain)  
-✅ **Negative is more powerful** - Loss aversion drives urgent action  
-✅ **Map both for each persona** - Complete psychological picture  
-✅ **Emotional intensity matters** - Not all drivers are equal  
-✅ **Be specific** - Avoid generic wants, find emotional core
+✅ **Guided psychological exploration** - Saga asks one persona at a time, one driver type at a time
+✅ **Two types of drivers** - Positive (gain-seeking) and Negative (pain-avoidance)
+✅ **Negative often more powerful** - Saga emphasizes loss aversion creates urgent action
+✅ **Emotional core matters** - Saga digs beyond surface wants to find real psychological drivers
+✅ **Intensity mapping** - Saga helps you distinguish constant worries from occasional concerns
+✅ **Specific not generic** - Saga challenges vague statements until emotional core emerges
+✅ **Control questions validate** - Saga uses these to confirm drivers match your offering
+✅ **Like BMad v6** - Reflective dialog that reveals deeper psychology than you'd write alone
 
 ---
 
-[← Back to Lesson 5](lesson-05-workshop-2-target-groups.md) | [Next: Lesson 7 - Workshop 4: Prioritization →](lesson-07-workshop-4-prioritization.md)
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 5](lesson-05-workshop-2-target-groups.md) | [Next: Lesson 7 - Workshop 4: Prioritization →](lesson-07-workshop-4-prioritization.md)
 
-*Part of Module 05: Trigger Mapping*
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn/module-06-trigger-mapping/lesson-07-workshop-4-prioritization.md b/docs/learn/module-06-trigger-mapping/lesson-07-workshop-4-prioritization.md
new file mode 100644
index 000000000..e5cd54b20
--- /dev/null
+++ b/docs/learn/module-06-trigger-mapping/lesson-07-workshop-4-prioritization.md
@@ -0,0 +1,373 @@
+# Module 06: Trigger Mapping
+
+## Lesson 7: Workshop 4 - Prioritization
+
+**Saga Guides You to Rank What Matters Most**
+
+---
+
+## Overview
+
+Workshop 4 is where Saga helps you make strategic choices about what matters most. Through guided conversation, Saga walks you through ranking your target groups and their psychological drivers to create clear priorities that guide all design decisions.
+
+**Duration:** 15-20 minutes
+**Format:** Guided dialog with Saga (making hard strategic choices together)
+**Output:** Ranked target groups + ranked drivers for each group (documented by Saga)
+
+---
+
+## How the Guided Dialog Works
+
+### Phase 1: Saga Helps You Rank Target Groups
+
+**Saga guides you through strategic comparison:**
+
+Working from your personas in Workshop 2, Saga asks comparative questions to help you think through which groups have the highest strategic value. She considers business impact, feasibility, and urgency of pain together.
+
+**Natural conversation flow:**
+> **Saga:** "You have three groups: Remote Team Leads, Solo Workers, and Executives. Which one has the most potential to drive your 5,000 team goal?"
+> **You:** "Probably Team Leads - each one brings their whole team..."
+> **Saga:** "Good insight. So each Team Lead is a multiplier. Can you actually reach them?"
+> **You:** "Yes, through LinkedIn and management communities."
+> **Saga:** "And what about their pain - how urgent is it?"
+> **You:** "Very urgent - team burnout is happening now, not someday."
+> **Saga:** "So Team Leads rank #1 for impact, feasibility, AND urgency. Now let's compare Solo Workers and Executives..."
+
+**Saga documents the ranking** with strategic reasoning for each placement. This ranking determines which groups get design focus first.
+
+### Phase 2: Saga Helps You Rank Drivers for Each Group
+
+**For each target group, Saga guides driver prioritization:**
+
+Using the psychological drivers from Workshop 3, Saga helps you identify which 5-7 drivers have the most power to drive behavior. She asks about emotional intensity, urgency, and impact.
+
+**Dialog example:**
+> **Saga:** "For Remote Team Leads, you identified 8 drivers. Which fear keeps them up at night most?"
+> **You:** "Probably the fear of team members burning out without them noticing..."
+> **Saga:** "Why is that #1 instead of fear of missed deadlines?"
+> **You:** "Because burnout affects people they're responsible for. Deadlines are project-level, but burnout is personal."
+> **Saga:** "So there's guilt and responsibility there. That's a powerful emotional core. Let's rank the rest..."
+
+**Saga limits you to top 5-7 drivers** - these become your feature scoring criteria in Workshop 5.
+
+---
+
+## Saga's Conversational Approach
+
+### How Saga Guides Prioritization
+
+**Saga doesn't just ask "rank these" - she guides you through strategic thinking** about WHY one ranks higher than another. She uses comparative questions that force real tradeoff decisions.
+
+**Ranking target groups - Saga's comparative questions:**
+> **Saga:** "You have Remote Team Leads and Solo Workers. Which will have bigger impact on [your specific business goal]?"
+> **You:** [You make a choice with reasoning]
+> **Saga:** "And can you actually reach Team Leads more easily than Solo Workers?"
+> **You:** [You think through feasibility]
+> **Saga:** "What about urgency - whose pain is more urgent?"
+> **You:** [You compare pain levels]
+> **Saga:** "So based on impact, feasibility, and urgency together, Team Leads rank higher. Why?"
+
+**Saga's questions that drive target group ranking:**
+- "Which group's behavior most directly drives [your top business goal]?"
+- "Can you reach [Group A] more easily than [Group B]? How?"
+- "Whose pain is more urgent - [Group A] or [Group B]?"
+- "What's the multiplier effect? Does one group bring others?"
+- "If you had to pick just ONE group to serve excellently, which and why?"
+- "Why does [this group] rank higher than [that group] strategically?"
+
+**Ranking drivers - Saga's intensity questions:**
+> **Saga:** "For Remote Team Leads, which driver has the most emotional intensity?"
+> **You:** "Fear of burnout..."
+> **Saga:** "Why does that rank above 'want to demonstrate leadership'?"
+> **You:** "Because the fear is immediate - burnout could be happening now..."
+> **Saga:** "And between fear of burnout and fear of losing top performers - which keeps them up more at night?"
+> **You:** [You compare the emotional intensity]
+
+**Saga's questions that drive driver ranking:**
+- "Which driver has the strongest emotional pull for [persona]?"
+- "Which fear keeps them up at night most?"
+- "Between [Driver A] and [Driver B], which would drive more urgent action?"
+- "Which drivers are constant worries vs occasional concerns?"
+- "If this feature only solved ONE driver, which would have the most impact?"
+- "We need to narrow to 5-7 drivers. Which can we set aside for now?"
+
+### Saga's Facilitation Techniques
+
+**Like BMad v6, Saga:**
+- **Forces comparisons** - "Which matters more, A or B?" not "rate these 1-10"
+- **Asks for reasoning** - "Why does this rank higher?" surfaces strategic thinking
+- **Challenges inconsistencies** - "You said impact matters most, but you ranked the high-impact group lower. Why?"
+- **Limits choices** - Guides you to top 5-7 drivers, prevents "everything is priority #1"
+- **Traces to business goals** - "How does prioritizing this group help achieve [your objective]?"
+- **Documents with reasoning** - Captures not just rankings but WHY they rank that way
+
+---
+
+## Generic Example
+
+### Target Group Rankings
+
+**1. Remote Team Leads** (Priority #1)
+- **Why #1:** High impact (each brings 5-10 users), reachable through professional channels, urgent pain (team burnout risk), budget authority
+- **Business impact:** Directly drives user acquisition and retention goals
+- **Feasibility:** Can reach through LinkedIn, management communities
+
+**2. Solo Remote Workers** (Priority #2)
+- **Why #2:** Large market size, moderate impact per user, chronic pain (less urgent than team leads)
+- **Business impact:** Volume play, good retention potential
+- **Feasibility:** Reachable through remote work communities
+
+**3. Remote Executives** (Priority #3)
+- **Why #3:** High value per user, but harder to reach, longer sales cycles
+- **Business impact:** Strategic accounts, high revenue potential
+- **Feasibility:** Difficult to reach, requires different approach
+
+---
+
+### Driving Force Rankings: Remote Team Lead
+
+**Top 5 Prioritized Drivers:**
+
+**1. Fear of team burnout without noticing** (NEGATIVE)
+- **Why #1:** Most urgent, highest emotional intensity, constant worry
+- **Emotional core:** Guilt and responsibility for people's wellbeing
+- **Urgency:** Very high (active problem)
+- **Impact:** Directly threatens their success
+
+**2. Want to demonstrate effective leadership** (POSITIVE)
+- **Why #2:** Career driver, strong motivation, measurable outcome
+- **Emotional core:** Professional advancement and recognition
+- **Urgency:** High (ongoing career goal)
+- **Impact:** Affects long-term success
+
+**3. Fear of losing top performers** (NEGATIVE)
+- **Why #3:** Business impact, reflects on leadership, costly outcome
+- **Emotional core:** Failure and loss
+- **Urgency:** High (retention risk)
+- **Impact:** Damages team and reputation
+
+**4. Want to build strong team culture** (POSITIVE)
+- **Why #4:** Aspirational, important but less urgent
+- **Emotional core:** Pride in team cohesion
+- **Urgency:** Medium (long-term goal)
+- **Impact:** Enables other goals
+
+**5. Fear of missed deadlines** (NEGATIVE)
+- **Why #5:** Important but less emotionally intense than top fears
+- **Emotional core:** Professional embarrassment
+- **Urgency:** Medium (project-dependent)
+- **Impact:** Situational
+
+---
+
+## Prioritization Criteria
+
+### For Target Groups
+
+**Business Impact:**
+- Which group's behavior most directly drives objectives?
+- Which group has power to make goals happen?
+- What's the multiplier effect? (e.g., team leads bring teams)
+
+**Feasibility:**
+- Can we actually reach this group?
+- Do we have channels to communicate?
+- Can we serve them with our resources?
+- Is market size sufficient?
+
+**Urgency of Pain:**
+- How urgent is their problem?
+- Are they actively seeking solutions?
+- What's the cost of not solving?
+
+**Strategic Fit:**
+- Does this align with company strengths?
+- Is this a sustainable advantage?
+- Does this open future opportunities?
+
+### For Driving Forces
+
+**Emotional Intensity:**
+- How strongly do they feel this?
+- Does this keep them up at night?
+- Is this a constant worry or occasional concern?
+
+**Urgency:**
+- How immediate is the need?
+- What triggers action on this?
+- Is this active pain or chronic discomfort?
+
+**Impact on Behavior:**
+- Would solving this drive adoption?
+- Would this prevent churn?
+- Does this create word-of-mouth?
+
+**Measurability:**
+- Can we tell if we've addressed this?
+- Can users articulate this need?
+- Is there observable behavior change?
+
+---
+
+## Why Prioritization Matters
+
+### Without Prioritization
+
+**Problems:**
+- Try to serve everyone equally (serve no one well)
+- Build features that address minor drivers
+- Waste resources on low-impact groups
+- No clear focus for design
+
+**Result:** Mediocre product that doesn't deeply solve anyone's problems.
+
+### With Prioritization
+
+**Benefits:**
+- Focus design on highest-impact groups
+- Address most powerful psychological drivers
+- Allocate resources strategically
+- Create deep value for top segments
+
+**Result:** Product that deeply solves urgent problems for strategic users.
+
+---
+
+## The Prioritization Cascade
+
+Once you have rankings, design decisions become clear:
+
+```
+Top Business Goal
+    ↓
+Top Target Group (who can best achieve this?)
+    ↓
+Top Psychological Driver (what drives them most?)
+    ↓
+Features that address this driver
+```
+
+**Example:**
+- **Goal:** Increase user retention to 70%
+- **Top Group:** Remote Team Leads (high retention potential)
+- **Top Driver:** Fear of team burnout without noticing
+- **Top Feature:** Daily team pulse check with burnout indicators
+- **Why:** Addresses their #1 fear, drives retention
+
+---
+
+## What You Get from Workshop 4
+
+✅ **Clear strategic priorities** - Saga helped you make hard choices about what matters most
+✅ **Ranked target groups** - Know exactly which groups get design focus first
+✅ **Ranked drivers** - Top 5-7 drivers per group, ordered by power to drive behavior
+✅ **Strategic reasoning** - Saga documented WHY each ranking, not just the rankings
+✅ **Decision framework** - Clear criteria for all future feature discussions
+✅ **Scoring criteria** - These ranked drivers feed directly into Workshop 5 analysis
+✅ **No ambiguity** - Saga prevented "everything is #1" by forcing real choices
+
+---
+
+## Common Mistakes to Avoid
+
+### Mistake 1: Refusing to Choose ("Everything Is Priority #1")
+
+**Problem:** Insisting "All groups are equally important"
+**Why it fails:** Saga needs clear priorities for Workshop 5 - can't score features against 15 "top" drivers
+**Fix:** Let Saga force the hard choices through comparative questions
+
+### Mistake 2: Prioritizing by Ease Alone
+
+**Problem:** "Let's rank the easiest group #1"
+**Why it fails:** Saga will challenge if it doesn't drive your business goals
+**Fix:** When Saga asks about business impact, be honest about tradeoffs
+
+### Mistake 3: Ranking Drivers by Logic Instead of Emotion
+
+**Problem:** "This driver is more logical, so it should be #1"
+**Why it fails:** Saga's asking about emotional intensity and urgency, not logic
+**Fix:** When Saga asks "which keeps them up at night?" - answer honestly about emotion
+
+### Mistake 4: Insisting on Too Many "Top" Drivers
+
+**Problem:** "We need all 10 drivers in the top priorities"
+**Why it fails:** Saga guides you to 5-7 for scoring - more than that dilutes focus
+**Fix:** Trust Saga's limit - you can add drivers back later if needed
+
+### Mistake 5: Losing Connection to Business Goals
+
+**Problem:** Ranking based on interesting psychology without strategic reasoning
+**Why it fails:** Saga will challenge: "How does prioritizing this help achieve [your goal]?"
+**Fix:** When Saga asks about business impact, trace the chain clearly
+
+### Mistake 6: Not Articulating WHY in Rankings
+
+**Problem:** Just saying "#1, #2, #3" without explaining reasoning
+**Why it fails:** Saga needs the WHY to document strategic rationale
+**Fix:** When Saga asks "why does this rank higher?" - think it through with her
+
+---
+
+## How This Feeds Into Workshop 5
+
+**Workshop 4 creates the scoring criteria:**
+
+```
+Business Goals
+    ↓
+Target Groups (ranked)
+    ↓
+Driving Forces (ranked for each group)
+    ↓
+Top 5-7 Drivers (scoring criteria)
+    ↓
+Workshop 5: Score features against these drivers
+```
+
+The top-ranked drivers become the columns in your feature scoring matrix.
+
+---
+
+## Tips for a Successful Dialog with Saga
+
+**DO:**
+- ✅ Make the hard choices when Saga asks "which matters MORE, A or B?"
+- ✅ Articulate WHY one ranks higher - Saga documents your strategic reasoning
+- ✅ Let Saga challenge inconsistencies - it sharpens your thinking
+- ✅ Consider impact, feasibility, AND urgency together - not just one factor
+- ✅ Trust Saga's limit of 5-7 top drivers - focus is the goal
+- ✅ Trace rankings back to business goals when Saga asks
+- ✅ Think about emotional intensity, not just logical importance
+
+**DON'T:**
+- ❌ Say "they're all equally important" - Saga will keep asking until you choose
+- ❌ Rank by ease alone without considering business impact
+- ❌ Prioritize based on interesting psychology while ignoring your objectives
+- ❌ Insist on keeping 10+ "critical" drivers - defeats the purpose
+- ❌ Give rankings without explaining WHY - Saga needs the strategic rationale
+- ❌ Ignore emotional intensity when ranking drivers - urgency matters
+
+---
+
+## What's Next
+
+Workshop 5 uses these priorities to systematically score features. Each feature gets rated against your top-ranked drivers, creating a data-driven roadmap.
+
+---
+
+## Key Takeaways
+
+✅ **Guided strategic choices** - Saga forces hard decisions through comparative questions
+✅ **Ruthless prioritization** - Saga prevents "everything is #1" by requiring choices
+✅ **Two levels of ranking** - Groups first (by strategic value), then drivers (by emotional power)
+✅ **Strategic criteria** - Impact + feasibility + urgency considered together
+✅ **Top 5-7 drivers** - Saga limits you to focus, these become Workshop 5 scoring criteria
+✅ **Reasoning documented** - Saga captures WHY each ranking, not just the order
+✅ **Traceability** - Rankings connect directly back to Workshop 1 business goals
+✅ **Like BMad v6** - Comparative dialog that forces clearer thinking than self-ranking alone
+
+---
+
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 6](lesson-06-workshop-3-driving-forces.md) | [Next: Lesson 8 - Workshop 5: Feature Impact →](lesson-08-workshop-5-feature-impact.md)
+
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn/module-06-trigger-mapping/lesson-08-workshop-5-feature-impact.md b/docs/learn/module-06-trigger-mapping/lesson-08-workshop-5-feature-impact.md
new file mode 100644
index 000000000..863be2f03
--- /dev/null
+++ b/docs/learn/module-06-trigger-mapping/lesson-08-workshop-5-feature-impact.md
@@ -0,0 +1,543 @@
+# Module 06: Trigger Mapping
+
+## Lesson 8: Workshop 5 - Feature Impact
+
+**Saga Analyzes and Scores Your Features**
+
+---
+
+## Overview
+
+Workshop 5 is where strategy becomes actionable roadmap. With your business goals, target groups, driving forces, and priorities established in Workshops 1-4, Saga now has everything needed to evaluate your features. Saga analyzes each feature against your top prioritized drivers and produces a complete scoring matrix automatically.
+
+**Duration:** 15-20 minutes
+**Format:** Saga presents analysis, you review and discuss
+**Output:** Scored and ranked feature list with strategic justification
+
+---
+
+## How It Works
+
+### 1. You Provide the Feature List
+
+**Give Saga your feature ideas:**
+- Ideas from Product Brief
+- Stakeholder requests
+- Competitive features
+- User feedback
+- Team suggestions
+
+**Aim for:** 10-20 features for evaluation
+
+### 2. Saga Does the Analysis
+
+**Saga evaluates each feature automatically:**
+- Assesses how well each feature addresses your top 5-7 drivers
+- Applies consistent 0-3 scoring scale
+- Considers both direct and indirect impacts
+- Produces complete scoring matrix
+
+**Scoring scale Saga uses:**
+- **3** = Directly addresses this driver (core solution)
+- **2** = Significantly helps with this driver
+- **1** = Somewhat related to this driver
+- **0** = Doesn't address this driver
+
+### 3. Saga Presents the Results
+
+**You receive:**
+- Complete scoring matrix showing all evaluations
+- Total scores for each feature
+- Initial roadmap prioritization
+- Strategic reasoning for each score
+
+### 4. You Review and Discuss
+
+**Conversation-based refinement:**
+- Saga explains surprising scores
+- You can challenge or question assessments
+- Saga adjusts based on your strategic judgment
+- Final roadmap emerges from discussion
+
+---
+
+## How Saga Evaluates Features
+
+### During Analysis
+
+**Saga considers for each feature:**
+- How directly does this address each prioritized driver?
+- Does this create gain or reduce pain for the persona?
+- What's the magnitude of impact on each driver?
+- Are there both direct and indirect benefits?
+- Which drivers get the strongest support?
+
+**Saga applies strategic thinking:**
+- Traces features back to psychological drivers
+- Evaluates emotional impact, not just functionality
+- Considers both positive and negative drivers
+- Assesses strategic leverage across multiple drivers
+
+### During Review Discussion
+
+**Questions you might ask Saga:**
+- "Why did [feature] score higher/lower than I expected?"
+- "Can you explain the reasoning behind this score?"
+- "What would make this feature score higher?"
+- "Are we missing features that would score better?"
+- "How would modifying this feature affect its scores?"
+
+**Saga's helpful prompts:**
+- "I scored this low because it doesn't address your top drivers. Here's why..."
+- "This feature scored high across multiple drivers. Let me show you..."
+- "If we adjusted this feature like this, it could score higher..."
+- "Based on your drivers, here's a gap I'm seeing..."
+
+---
+
+## Generic Example: Scoring Matrix
+
+### Context
+
+**Top 5 Prioritized Drivers (Remote Team Leads):**
+1. Fear of team burnout without noticing (NEGATIVE)
+2. Want to demonstrate effective leadership (POSITIVE)
+3. Fear of losing top performers (NEGATIVE)
+4. Want to build strong team culture (POSITIVE)
+5. Fear of missed deadlines (NEGATIVE)
+
+### Features to Score
+
+| Feature | Burnout Fear | Leadership | Retention | Culture | Deadlines | **Total** |
+|---------|-------------|------------|-----------|---------|-----------|-----------|
+| Daily team pulse check | 3 | 2 | 2 | 1 | 1 | **9** |
+| Team workload dashboard | 3 | 2 | 2 | 0 | 2 | **9** |
+| Recognition system | 1 | 1 | 2 | 3 | 0 | **7** |
+| 1-on-1 scheduling assistant | 2 | 2 | 1 | 1 | 0 | **6** |
+| Meeting summaries | 0 | 1 | 0 | 1 | 2 | **4** |
+| Async video updates | 1 | 1 | 0 | 2 | 0 | **4** |
+| Team chat | 0 | 0 | 1 | 2 | 0 | **3** |
+
+### Detailed Scoring Example
+
+**Feature: Daily Team Pulse Check**
+
+**Against "Fear of team burnout without noticing" (Score: 3)**
+- Directly addresses the fear
+- Provides daily visibility into team health
+- Early warning system for burnout indicators
+- Core solution to the problem
+
+**Against "Want to demonstrate effective leadership" (Score: 2)**
+- Provides data to show proactive management
+- Enables evidence-based leadership decisions
+- Significantly helps but not the primary purpose
+
+**Against "Fear of losing top performers" (Score: 2)**
+- Early warning helps prevent burnout-driven turnover
+- Identifies at-risk team members
+- Significantly helps with retention
+
+**Against "Want to build strong team culture" (Score: 1)**
+- Shows you care about team wellbeing
+- Somewhat related but not primary benefit
+
+**Against "Fear of missed deadlines" (Score: 1)**
+- Can identify capacity issues early
+- Somewhat helps but not main purpose
+
+**Total: 9 points** (Highest strategic impact)
+
+---
+
+**Feature: Team Chat**
+
+**Against "Fear of team burnout" (Score: 0)**
+- Doesn't address burnout visibility
+- No impact on this driver
+
+**Against "Want to demonstrate leadership" (Score: 0)**
+- Doesn't provide leadership insights
+- No impact on this driver
+
+**Against "Fear of losing performers" (Score: 1)**
+- Helps with connection (minor retention factor)
+- Somewhat related
+
+**Against "Want to build team culture" (Score: 2)**
+- Enables team connection
+- Significantly helps with culture
+
+**Against "Fear of missed deadlines" (Score: 0)**
+- Doesn't address deadline management
+- No impact on this driver
+
+**Total: 3 points** (Low strategic impact for this persona)
+
+---
+
+## Prioritized Roadmap
+
+Based on scores, create phases:
+
+### Phase 1: Highest Impact (8-10 points)
+- Daily team pulse check (9)
+- Team workload dashboard (9)
+
+**Why first:** Directly address top fears, highest strategic value
+
+### Phase 2: High Impact (6-7 points)
+- Recognition system (7)
+- 1-on-1 scheduling assistant (6)
+
+**Why second:** Good strategic value, support top priorities
+
+### Phase 3: Medium Impact (4-5 points)
+- Meeting summaries (4)
+- Async video updates (4)
+
+**Why third:** Some value but lower priority
+
+### Backlog: Low Impact (0-3 points)
+- Team chat (3)
+
+**Why backlog:** Doesn't address top strategic drivers for this persona
+
+---
+
+## Why Saga's Analysis Works Better
+
+### It's Consistently Strategic
+
+**Saga evaluates with perfect traceability:**
+- Every score connects to a prioritized driver
+- Every driver traces to a target group
+- Every group connects to a business goal
+
+**Not arbitrary** - complete strategic chain for every decision
+
+### It's Unbiased and Objective
+
+**Without Saga (traditional approach):**
+"I think Feature A is more important" (opinion-based, political)
+
+**With Saga's analysis:**
+"Feature A scores 9, Feature B scores 4 because..." (data-driven, defensible)
+
+**Saga doesn't have pet features or political pressures**
+
+### It's Fast and Thorough
+
+**Manual scoring:**
+- Takes hours with spreadsheets
+- Easy to miss connections
+- Inconsistent application of criteria
+- Tedious and error-prone
+
+**Saga's automated analysis:**
+- Complete matrix in minutes
+- Considers all driver relationships
+- Consistent scoring methodology
+- You focus on strategic discussion, not data entry
+
+### It's Defensible to Stakeholders
+
+**When asked "Why aren't we building Feature X?"**
+
+**Saga's analysis provides:**
+1. The complete Trigger Map context
+2. Top prioritized drivers from Workshop 4
+3. Detailed scoring matrix with reasoning
+4. Feature X's lower strategic impact shown clearly
+
+**Strategic reasoning backed by systematic analysis**
+
+### It's Adaptable
+
+**When priorities shift:**
+- Update driver rankings in Saga
+- Saga re-analyzes all features instantly
+- New roadmap emerges automatically
+- No manual re-scoring needed
+
+**Strategy drives features, with Saga maintaining consistency**
+
+---
+
+## How Saga Scores (And How You Review)
+
+### Saga's Scoring Principles
+
+**Saga evaluates objectively:**
+- No pet features or political bias
+- Based purely on strategic fit to drivers
+- Applies consistent methodology across all features
+- Some features will naturally score low - that's valuable data
+
+**Saga is specific:**
+- Links each score to concrete driver impact
+- Explains HOW a feature addresses (or doesn't address) each driver
+- Provides reasoning you can challenge or validate
+
+### Your Role: Strategic Validation
+
+**When reviewing Saga's scores:**
+- Challenge assessments that feel wrong
+- Provide context Saga might have missed
+- Explain strategic factors not yet captured
+- Confirm or adjust based on your domain knowledge
+
+**Example exchange:**
+> **You:** "I'm surprised the chat feature scored so low."
+> **Saga:** "It scored 3 total because it only addresses 'build team culture' (score: 2) and retention (score: 1), but doesn't impact your top three drivers: burnout visibility, leadership demonstration, or deadline concerns. Should we reconsider its strategic fit?"
+
+### Understanding the Scale
+
+**How Saga uses 0-3:**
+- **3** = Rare - only core solutions to that specific driver
+- **2** = Significant help, clear connection
+- **1** = Some relationship, indirect benefit
+- **0** = Common - not every feature addresses every driver
+
+**Most scores land at 0-2, which is healthy**
+
+### Positive and Negative Drivers
+
+**Saga evaluates both:**
+- Negative drivers: Does this reduce pain or prevent fears?
+- Positive drivers: Does this enable goals or create gains?
+- High-impact features often address both types
+
+---
+
+## Common Patterns
+
+### Pattern 1: High Scores Across Multiple Drivers
+
+**What it means:** High-leverage feature addressing multiple needs
+
+**Example:** Daily pulse check scores high on burnout fear, leadership goals, retention fear
+
+**Action:** Prioritize - strategically valuable
+
+### Pattern 2: High Score on Top Driver Only
+
+**What it means:** Laser-focused solution for most important need
+
+**Example:** Workload balancing scores 3 on burnout fear, low on others
+
+**Action:** Still high priority if that driver is #1
+
+### Pattern 3: Moderate Scores Across Many
+
+**What it means:** Nice-to-have that helps a bit with everything
+
+**Example:** Team chat scores 1-2 on multiple drivers
+
+**Action:** Lower priority - not solving urgent problems
+
+### Pattern 4: Low Scores Everywhere
+
+**What it means:** Feature doesn't connect to strategy
+
+**Example:** Fancy animations score 0-1 across all drivers
+
+**Action:** Cut it or deprioritize significantly
+
+---
+
+## Beyond the Numbers: The Review Discussion
+
+### Why the Conversation Matters
+
+**Reviewing Saga's analysis reveals insights:**
+
+When you ask: "Why doesn't this feature score higher?"
+→ Saga shows the strategic gap clearly
+→ You might modify the feature to increase impact
+→ Or you accept it's not strategically aligned right now
+
+When you ask: "Are we missing features that would score higher?"
+→ Saga analyzes the driver coverage
+→ Identifies gaps in your feature set
+→ Suggests feature concepts that would address unmet drivers
+
+When you ask: "This score doesn't match my intuition. Why?"
+→ Either your strategy needs refinement
+→ Or Saga missed context you can provide
+→ The discussion sharpens your strategic clarity
+
+**The analysis is data. The discussion creates wisdom.**
+
+### Combining Strategic Impact with Other Factors
+
+**Saga's scores = Strategic value (from Trigger Map)**
+
+**You also consider:**
+- **Feasibility:** How hard to build?
+- **Dependencies:** What's required first?
+- **Market timing:** Competitive urgency?
+- **Resources:** Do we have capacity?
+
+**Combined decision formula:**
+```
+Priority = (Saga's Strategic Impact × Feasibility) + Urgency Factors
+```
+
+High strategic impact + easy to build = Phase 1
+High strategic impact + hard to build = Phased approach
+Low strategic impact (regardless of ease) = Backlog or cut
+
+---
+
+## What You Get from Workshop 5
+
+✅ **Complete scoring matrix** - Saga's systematic evaluation of every feature against every driver
+✅ **Ranked roadmap** - Clear, data-driven prioritization ready to execute
+✅ **Strategic justification** - Defensible reasoning for every decision
+✅ **Objective analysis** - Saga's unbiased evaluation, no political pressure
+✅ **Perfect traceability** - Feature → Driver → Group → Goal (complete chain)
+✅ **Time saved** - Minutes instead of hours of manual spreadsheet work
+✅ **Strategic clarity** - Discussion reveals insights you wouldn't see alone
+
+---
+
+## Common Mistakes to Avoid
+
+### Mistake 1: Not Providing Enough Context
+
+**Problem:** Giving Saga feature names without explaining what they do
+**Why it fails:** Saga can't evaluate strategic fit without understanding the feature
+**Fix:** Briefly explain each feature's purpose and how it works
+
+### Mistake 2: Not Challenging Scores You Disagree With
+
+**Problem:** Accepting Saga's analysis without discussion
+**Why it fails:** Misses opportunities to refine strategic thinking
+**Fix:** Question surprising scores - the discussion reveals insights
+
+### Mistake 3: Overriding Scores for Political Reasons
+
+**Problem:** "Boss wants Feature X, let's bump it up"
+**Why it fails:** Defeats the purpose of strategic analysis
+**Fix:** Use Saga's objective analysis to have strategic conversations with stakeholders
+
+### Mistake 4: Analyzing Too Many Features at Once
+
+**Problem:** Trying to score 50+ features in one session
+**Why it fails:** Analysis fatigue, loses strategic focus
+**Fix:** Start with 10-20 most viable features, expand later
+
+### Mistake 5: Ignoring Low-Scoring Features
+
+**Problem:** "But we still need to build it even though it scored low"
+**Why it fails:** Wastes resources on strategically misaligned features
+**Fix:** Accept that low scores mean deprioritize or cut - that's valuable clarity
+
+### Mistake 6: Never Re-Running the Analysis
+
+**Problem:** Using stale scores as strategy evolves
+**Why it fails:** Roadmap doesn't reflect current priorities
+**Fix:** Re-run Saga's analysis when priorities shift (takes minutes, not hours)
+
+### Mistake 7: Forgetting Feasibility
+
+**Problem:** Prioritizing impossible or extremely difficult features
+**Why it fails:** Can't actually execute the roadmap
+**Fix:** Combine Saga's strategic scores with feasibility assessment
+
+---
+
+## Using Saga's Scored Feature List
+
+### For Sprint Planning
+
+**Each sprint:**
+- Reference Saga's scored list
+- Focus on highest-impact features first
+- Validate decisions against the Trigger Map
+- Make trade-offs based on strategic data, not opinions
+
+**When questioned:**
+"Why are we building this instead of that?" → Show Saga's scoring matrix
+
+### For Stakeholder Communication
+
+**When presenting roadmap:**
+1. Show the Trigger Map (strategic foundation)
+2. Show Saga's scoring matrix (systematic analysis)
+3. Show the prioritized list (data-driven roadmap)
+4. Walk through the strategic reasoning
+
+**Stakeholders respond well to:**
+- Clear, systematic methodology
+- Traceable decisions (not "because I think so")
+- Strategic foundation (connects to business goals)
+- Objective analysis (Saga's unbiased evaluation)
+
+**You have strategic armor against political pressure**
+
+### For Design Decisions
+
+**When Freya starts design work:**
+- She references Saga's scored list
+- Focuses on high-impact features first
+- Understands which drivers each feature must address
+- Validates design decisions against the scoring
+
+**Example conversation with Freya:**
+> "We're designing the pulse check (Saga scored it 9). It addresses 'fear of burnout' (score: 3), so it needs early warning indicators and actionable suggestions. That's what makes it high-impact."
+
+**Design decisions trace back to psychological drivers through Saga's analysis**
+
+---
+
+## The Complete Chain
+
+Now you have the full Trigger Mapping system:
+
+```
+Workshop 1: Business Goals (Vision + Objectives)
+    ↓
+Workshop 2: Target Groups (3-5 prioritized personas)
+    ↓
+Workshop 3: Driving Forces (positive + negative for each)
+    ↓
+Workshop 4: Prioritization (ranked groups and drivers)
+    ↓
+Workshop 5: Feature Impact (scored feature list)
+    ↓
+Strategic Roadmap (data-driven priorities)
+```
+
+**Every feature traces back to:**
+- A psychological driver
+- A target group  
+- A business goal
+
+**No orphaned features. No guesswork. Strategic clarity.**
+
+---
+
+## What's Next
+
+You're ready to create your own Trigger Map. The tutorial walks through all 5 workshops step by step with Saga, and the next lessons cover how to create and use the visual Trigger Map.
+
+---
+
+## Key Takeaways
+
+✅ **Saga does the analytical work** - You provide features, Saga evaluates them systematically
+✅ **Automated scoring matrix** - Complete in minutes, not hours of manual work
+✅ **Objective and unbiased** - Saga has no pet features or political pressures
+✅ **Discussion-based refinement** - Review, challenge, validate, and adjust together
+✅ **Strategically defensible** - Every decision traces through the complete chain
+✅ **Instantly updateable** - When priorities shift, Saga re-analyzes in minutes
+✅ **Conversation reveals insights** - The review discussion sharpens strategic thinking
+✅ **Perfect traceability** - Feature → Driver → Group → Goal (maintained by Saga)
+
+---
+
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 7](lesson-07-workshop-4-prioritization.md) | [Next: Lesson 9 - Positive & Negative Drivers →](lesson-09-positive-negative-drivers.md)
+
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn/module-06-trigger-mapping/lesson-09-positive-negative-drivers.md b/docs/learn/module-06-trigger-mapping/lesson-09-positive-negative-drivers.md
new file mode 100644
index 000000000..36ce385ae
--- /dev/null
+++ b/docs/learn/module-06-trigger-mapping/lesson-09-positive-negative-drivers.md
@@ -0,0 +1,507 @@
+# Module 06: Trigger Mapping
+
+## Lesson 9: Positive & Negative Drivers
+
+**The Psychology That Drives Behavior**
+
+---
+
+## The Core Concept
+
+Every user has two types of motivations:
+
+**Positive Drivers (GAIN):**
+- What they want to achieve
+- Benefits they're seeking
+- Goals that pull them forward
+
+**Negative Drivers (PAIN):**
+- What they want to avoid
+- Problems they're trying to escape
+- Fears that push them to act
+
+**The key insight:** Both matter, but they work differently. Understanding both gives you the complete psychological picture.
+
+---
+
+## The Critical Distinction: Psychological Framing
+
+**Even when drivers seem "technically the same," the psychological framing is different.**
+
+### Proactive vs Reactive Modes
+
+Consider these two statements:
+- **"Everything is possible"** (POSITIVE framing)
+- **"Nothing is impossible"** (NEGATIVE framing)
+
+Logically, they express the same concept. Psychologically, they reveal completely different mental states:
+
+**"Everything is possible" - Proactive Mode:**
+- **Mental state:** Aspirational, forward-looking, seeking opportunity
+- **Emotional tone:** Optimistic, energized, exploratory
+- **Triggers action by:** Opening possibilities, creating excitement
+- **Design implications:** Inspire, enable discovery, celebrate potential
+- **Example:** "Achieve your dreams," "Build something amazing"
+
+**"Nothing is impossible" - Reactive Mode:**
+- **Mental state:** Overcoming barriers, fighting against limits, defensive
+- **Emotional tone:** Determined, defiant, problem-solving
+- **Triggers action by:** Removing obstacles, proving doubters wrong
+- **Design implications:** Remove friction, show path through barriers, validate capability
+- **Example:** "Overcome any obstacle," "Break through limits"
+
+### Why This Matters for Design
+
+**The same feature can be framed for proactive or reactive users:**
+
+**Feature:** Goal-setting tool
+
+**Proactive framing (positive driver):**
+- **Persona in proactive mode:** "Want to achieve big goals"
+- **UI language:** "Dream big," "Set your vision," "What do you want to create?"
+- **Visual tone:** Bright, aspirational, open-ended
+- **Onboarding:** "What excites you? Let's build toward it."
+
+**Reactive framing (negative driver):**
+- **Persona in reactive mode:** "Fear of goals slipping away"
+- **UI language:** "Never lose track," "Stay on target," "Don't let this slip"
+- **Visual tone:** Focused, protective, structured
+- **Onboarding:** "What's at risk if you don't stay focused? Let's prevent that."
+
+**Both address goal-setting. The psychological approach is completely different.**
+
+### Identifying the Mode During Workshop 3
+
+**When Saga explores drivers, she helps you identify the mode:**
+
+> **Saga:** "When they think about advancing their career, are they moving toward something exciting or away from something they fear?"
+> **You:** "They're worried about being stuck in their current role forever..."
+> **Saga:** "So it's reactive - fear of stagnation. That's different from proactive ambition. Note that."
+
+**This distinction affects:**
+1. **Feature design** - How features are structured and presented
+2. **UI language** - The words and tone used in the interface
+3. **Visual hierarchy** - What gets emphasized and how
+4. **Onboarding flow** - How you introduce value to users
+5. **Success metrics** - What users celebrate vs what they avoid
+
+### Example: Remote Team Lead
+
+**Same underlying need, different psychological modes:**
+
+**Proactive framing:**
+- **Driver:** "Want to build strong, connected team culture"
+- **Mode:** Seeking positive outcome
+- **Feature approach:** Team-building activities, connection tools, culture dashboards
+- **UI tone:** "Let's strengthen your team," "Build something great together"
+
+**Reactive framing:**
+- **Driver:** "Fear of team becoming disconnected and disengaged"
+- **Mode:** Preventing negative outcome
+- **Feature approach:** Engagement alerts, disconnect warnings, intervention prompts
+- **UI tone:** "Catch problems early," "Don't let disconnection grow"
+
+**Both serve team connection. The design psychology is fundamentally different.**
+
+---
+
+## Why Negative Drivers Are More Powerful
+
+Research in behavioral psychology consistently shows: **People work harder to avoid pain than to pursue gain.**
+
+This is called **loss aversion** - the psychological principle that losses feel roughly twice as painful as equivalent gains feel good.
+
+### Generic Examples
+
+**Scenario 1: Fitness App**
+
+**Positive driver:** "Want to look good for summer"
+- Motivating? Yes
+- Urgent? Not really
+- Action trigger: Weak (can start "next week")
+
+**Negative driver:** "Fear of health problems like my parent had"
+- Motivating? Extremely
+- Urgent? Yes
+- Action trigger: Strong (need to act now)
+
+**Which drives more sign-ups?** The fear.
+
+**Scenario 2: Project Management Tool**
+
+**Positive driver:** "Want to be more organized"
+- Nice to have
+- Can live without it
+- Low urgency
+
+**Negative driver:** "Fear of missing client deadline and losing contract"
+- Critical need
+- Can't afford to fail
+- High urgency
+
+**Which drives more conversions?** The fear.
+
+---
+
+## How to Identify Positive Drivers
+
+Positive drivers are what users are moving TOWARD.
+
+### The Questions to Ask
+
+- What do they want to accomplish?
+- What positive outcomes are they seeking?
+- What would make their situation better?
+- What goals are they trying to achieve?
+- What benefits would they value?
+
+### Generic Examples Across Contexts
+
+**Professional Context:**
+- Want to advance in career
+- Want to be seen as competent leader
+- Want to deliver high-quality work
+- Want to build strong professional reputation
+- Want to learn new skills
+
+**Personal Context:**
+- Want to feel in control of their life
+- Want to spend quality time with family
+- Want to maintain healthy lifestyle
+- Want to feel accomplished
+- Want to reduce stress
+
+**Social Context:**
+- Want to be respected by peers
+- Want to contribute to community
+- Want to build meaningful relationships
+- Want to be seen as helpful
+- Want to belong to a group
+
+### Avoiding Surface-Level Statements
+
+**❌ Too vague:**
+- "Want to be productive"
+- "Want to save time"
+- "Want better results"
+
+**✅ Specific and meaningful:**
+- "Want to complete projects without last-minute panic"
+- "Want to leave work on time to have dinner with family"
+- "Want to deliver work that impresses stakeholders"
+
+---
+
+## How to Identify Negative Drivers
+
+Negative drivers are what users are moving AWAY FROM.
+
+### The Questions to Ask
+
+- What problems are they trying to avoid?
+- What frustrates them about current situation?
+- What do they fear will happen?
+- What keeps them up at night?
+- What would be embarrassing or costly?
+
+### Generic Examples Across Contexts
+
+**Professional Context:**
+- Fear of missing important deadlines
+- Fear of looking incompetent to boss/clients
+- Fear of being passed over for promotion
+- Fear of making costly mistakes
+- Fear of falling behind in skills
+
+**Personal Context:**
+- Fear of burnout and health decline
+- Fear of missing important family moments
+- Fear of losing control of their life
+- Fear of financial instability
+- Fear of disappointing loved ones
+
+**Social Context:**
+- Fear of being judged by peers
+- Fear of letting team down
+- Fear of being excluded
+- Fear of conflict and confrontation
+- Fear of losing respect
+
+### The Emotional Core
+
+Negative drivers often have strong emotional components:
+
+- **Shame:** "What will people think?"
+- **Guilt:** "I'm letting people down"
+- **Anxiety:** "What if this goes wrong?"
+- **Embarrassment:** "This makes me look bad"
+- **Fear:** "I could lose something important"
+
+**These emotions drive urgent action.**
+
+---
+
+## Balancing Both Types
+
+The most powerful understanding comes from mapping BOTH:
+
+### Generic Example: Email Management Tool
+
+**Positive Drivers:**
+- Want to feel organized and in control
+- Want to respond thoughtfully to important messages
+- Want to maintain professional communication standards
+- Want to reduce mental clutter
+
+**Negative Drivers:**
+- Fear of missing urgent client emails
+- Fear of looking unprofessional with late responses
+- Fear of important messages getting buried
+- Fear of constant email anxiety disrupting focus
+
+**The design insight:**
+- Positive drivers suggest: Clean interface, thoughtful organization
+- Negative drivers suggest: Urgent message alerts, priority inbox, "nothing missed" confidence
+
+**Both inform the solution, but negative drivers create urgency to adopt.**
+
+---
+
+## Common Patterns
+
+### Pattern 1: Professional Reputation
+
+**Positive (Proactive):** Want to be seen as competent leader
+- **Mode:** Seeking recognition and advancement
+- **Design approach:** Showcase achievements, highlight strengths, enable excellence
+- **UI tone:** "Shine," "Excel," "Lead with confidence"
+
+**Negative (Reactive):** Fear of looking incompetent
+- **Mode:** Avoiding embarrassment and judgment
+- **Design approach:** Prevent mistakes, provide safety nets, avoid exposure
+- **UI tone:** "Avoid errors," "Stay protected," "Don't get caught off guard"
+
+**Design implication:** Features that help users look good (proactive) AND avoid embarrassment (reactive)
+
+### Pattern 2: Time Management
+
+**Positive (Proactive):** Want to accomplish more and be productive
+- **Mode:** Maximizing potential and achievement
+- **Design approach:** Enable efficiency, celebrate completion, unlock capacity
+- **UI tone:** "Achieve more," "Maximize your day," "Unlock potential"
+
+**Negative (Reactive):** Fear of wasting time or missing deadlines
+- **Mode:** Protecting against failure and loss
+- **Design approach:** Prevent time waste, deadline alerts, crisis avoidance
+- **UI tone:** "Never miss a deadline," "Stop the time drain," "Stay on track"
+
+**Design implication:** Time-saving features (proactive) + deadline protection (reactive)
+
+### Pattern 3: Social Connection
+
+**Positive (Proactive):** Want to build strong, meaningful relationships
+- **Mode:** Growing connections and belonging
+- **Design approach:** Facilitate bonding, enable sharing, celebrate togetherness
+- **UI tone:** "Connect deeper," "Build community," "Grow together"
+
+**Negative (Reactive):** Fear of isolation or being left out
+- **Mode:** Preventing disconnection and exclusion
+- **Design approach:** Alert to missed interactions, FOMO prevention, inclusion signals
+- **UI tone:** "Don't miss out," "Stay included," "Avoid isolation"
+
+**Design implication:** Connection features (proactive) + FOMO prevention (reactive)
+
+### Pattern 4: Control & Autonomy
+
+**Positive (Proactive):** Want to feel empowered and in command
+- **Mode:** Seeking mastery and capability
+- **Design approach:** Enable control, provide powerful tools, celebrate autonomy
+- **UI tone:** "Take control," "Master your domain," "Own your outcomes"
+
+**Negative (Reactive):** Fear of chaos and overwhelm
+- **Mode:** Preventing collapse and loss of control
+- **Design approach:** Reduce complexity, provide structure, prevent overwhelm
+- **UI tone:** "Stop the chaos," "Regain control," "Prevent overwhelm"
+
+**Design implication:** Organization tools that empower (proactive) + anxiety reduction (reactive)
+
+---
+
+## How to Use This in Design
+
+### Critical: Know the Persona's Mode
+
+**Before designing features, identify whether the persona is in:**
+- **Proactive mode** - Seeking gain, exploring possibilities, building toward
+- **Reactive mode** - Avoiding pain, solving problems, protecting against
+
+**This affects EVERYTHING about the design:**
+
+| Design Element | Proactive Mode | Reactive Mode |
+|----------------|----------------|---------------|
+| **Language** | Aspirational, enabling | Protective, preventing |
+| **Visual tone** | Bright, open, inspiring | Focused, structured, safe |
+| **Feature presentation** | "Unlock potential" | "Prevent problems" |
+| **Urgency level** | Lower (can start tomorrow) | Higher (need it now) |
+| **Success metrics** | Achievement celebrated | Disasters avoided |
+
+**Example: Same notification feature, different modes:**
+- **Proactive:** "You're on track to hit your goal! Keep it up!"
+- **Reactive:** "Warning: You're falling behind. Act now to stay on track."
+
+### For Feature Prioritization
+
+Features that address negative drivers (reactive mode) often rank higher because they solve urgent problems.
+
+**Generic example:**
+- Feature A: "Dashboard for tracking progress toward goals" (proactive, positive driver)
+- Feature B: "Alert system for missed critical tasks" (reactive, negative driver)
+- **Which is more urgent?** Feature B (prevents pain happening NOW)
+
+**But framing matters:**
+- Same dashboard, proactive framing: "See how far you've come!"
+- Same dashboard, reactive framing: "Don't let tasks slip through!"
+
+### For Messaging & Marketing
+
+**Proactive-focused messaging (positive drivers):**
+- "Achieve your goals"
+- "Build something great"
+- "Unlock your potential"
+- Appeals to: Aspirational users seeking growth
+
+**Reactive-focused messaging (negative drivers):**
+- "Never miss another deadline"
+- "Stop the chaos before it starts"
+- "Prevent costly mistakes"
+- Appeals to: Users with urgent pain points
+
+**Which converts better?** Usually reactive-focused (addresses urgent pain)
+
+**But best approach:** Lead with reactive (hook the pain), deliver proactive (show the gain)
+
+### For User Onboarding
+
+**Match the persona's mode:**
+
+**If persona is in reactive mode:**
+1. Acknowledge the specific pain immediately
+2. Show how you prevent that pain
+3. Then highlight positive outcomes as bonus
+
+**If persona is in proactive mode:**
+1. Validate their ambition
+2. Show how you enable their goals
+3. Address preventable obstacles as supporting points
+
+**Example: Onboarding for Remote Team Lead**
+
+**Reactive mode (fear of burnout):**
+> "Worried about team burnout creeping up unnoticed? Get daily pulse checks that catch problems early, so you can intervene before it's too late."
+
+**Proactive mode (want to build culture):**
+> "Ready to build a thriving remote team culture? Use daily pulse checks to understand your team's needs and celebrate what's working."
+
+**Same feature. Completely different psychological approach.**
+
+**Generic example:**
+"Tired of missing important emails? (negative)  
+Our priority inbox ensures nothing slips through. (solution)  
+Respond confidently and maintain your professional reputation. (positive)"
+
+---
+
+## Workshop 3 in Practice
+
+When you're in Workshop 3 with Saga, you'll work through each persona systematically:
+
+**For each persona:**
+1. List 3-5 positive drivers
+2. List 3-5 negative drivers
+3. Identify which are strongest
+4. Note emotional intensity
+
+**Saga will challenge you:**
+- "Is that specific enough?"
+- "What's the emotional core of that fear?"
+- "Why does that matter to them?"
+- "What would happen if they don't solve this?"
+
+**Your job:** Dig deeper than surface-level wants. Find the real psychological drivers.
+
+---
+
+## Common Mistakes to Avoid
+
+### Mistake 1: Only Mapping Positive Drivers
+
+**Problem:** You miss the urgent pain that drives adoption  
+**Solution:** Always map both types
+
+### Mistake 2: Generic "Wants" Statements
+
+**Problem:** "Want to be productive" doesn't guide design  
+**Solution:** Be specific about context and outcomes
+
+### Mistake 3: Ignoring Emotional Intensity
+
+**Problem:** All drivers seem equal  
+**Solution:** Identify which have strongest emotional pull
+
+### Mistake 4: Assuming Positive = Good, Negative = Bad
+
+**Problem:** Negative drivers feel uncomfortable to discuss  
+**Solution:** Embrace them - they're often more powerful motivators
+
+### Mistake 5: Listing Features Instead of Psychology
+
+**Problem:** "Want a calendar feature"  
+**Solution:** "Want to never miss family commitments due to work chaos"
+
+---
+
+## The Power of This Approach
+
+When you map both positive and negative drivers:
+
+✅ **Complete psychological picture** - Understand full motivation  
+✅ **Better feature prioritization** - Know what's urgent vs nice-to-have  
+✅ **Stronger messaging** - Address real pain points  
+✅ **Higher conversion** - Solve urgent problems  
+✅ **Better retention** - Deliver on both gain and pain reduction
+
+---
+
+## What You'll Learn Next
+
+The next lesson shows you how to create the visual Trigger Map - the one-page strategic document that connects all these layers and becomes your team's reference for every design decision.
+
+---
+
+## Key Takeaways
+
+✅ **Two types of drivers** - Positive (gain-seeking) and Negative (pain-avoidance)
+✅ **Negative is more powerful** - Loss aversion drives urgent action (roughly 2x stronger)
+✅ **Psychological framing matters** - "Everything is possible" ≠ "Nothing is impossible" (proactive vs reactive)
+✅ **Identify the persona's mode** - Proactive (seeking) or Reactive (avoiding) affects ALL design decisions
+✅ **Map both for each persona** - Complete psychological picture with mode identification
+✅ **Be specific** - Avoid generic wants, find emotional core AND mental state
+✅ **Design implications are different** - Language, tone, visuals, urgency all change based on mode
+✅ **Use in design phase** - Freya needs to know if persona is proactive or reactive to design appropriately
+
+---
+
+## Practice Exercise
+
+Think about a product you use regularly. Identify:
+
+1. What positive outcomes do you seek from it?
+2. What negative outcomes are you trying to avoid?
+3. Which driver is stronger for you?
+4. How does the product address both?
+
+---
+
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 8](lesson-08-workshop-5-feature-impact.md) | [Next: Lesson 10 - Visual Trigger Map →](lesson-10-visual-trigger-map.md)
+
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-10-visual-trigger-map.md b/docs/learn/module-06-trigger-mapping/lesson-10-visual-trigger-map.md
similarity index 96%
rename from docs/learn-wds/module-05-trigger-mapping/lesson-10-visual-trigger-map.md
rename to docs/learn/module-06-trigger-mapping/lesson-10-visual-trigger-map.md
index ccb5688e1..5e7fc0f4b 100644
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-10-visual-trigger-map.md
+++ b/docs/learn/module-06-trigger-mapping/lesson-10-visual-trigger-map.md
@@ -1,4 +1,6 @@
-# Lesson 5: The Visual Trigger Map
+# Module 06: Trigger Mapping
+
+## Lesson 10: The Visual Trigger Map
 
 **Your One-Page Strategic Document**
 
@@ -48,7 +50,7 @@ A Trigger Map:
 
 **What it shows:**
 - Vision statement(s) - inspirational direction
-- 3-5 SMART objectives - measurable targets
+- 3-5 strategic objectives - measurable targets
 - Multiple goals can feed into the product
 
 **Visual cues:**
@@ -406,6 +408,6 @@ The final lesson covers Feature Impact Scoring - how to systematically evaluate
 
 ---
 
-[← Back to Lesson 9](lesson-09-positive-negative-drivers.md) | [Next: Lesson 11 - Feature Impact Scoring →](lesson-11-feature-impact-scoring.md)
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 9](lesson-09-positive-negative-drivers.md) | [Next: Lesson 11 - Feature Impact Scoring →](lesson-11-feature-impact-scoring.md)
 
-*Part of Module 05: Trigger Mapping*
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/lesson-11-feature-impact-scoring.md b/docs/learn/module-06-trigger-mapping/lesson-11-feature-impact-scoring.md
similarity index 97%
rename from docs/learn-wds/module-05-trigger-mapping/lesson-11-feature-impact-scoring.md
rename to docs/learn/module-06-trigger-mapping/lesson-11-feature-impact-scoring.md
index 526815d38..f22538d8f 100644
--- a/docs/learn-wds/module-05-trigger-mapping/lesson-11-feature-impact-scoring.md
+++ b/docs/learn/module-06-trigger-mapping/lesson-11-feature-impact-scoring.md
@@ -1,4 +1,6 @@
-# Lesson 6: Feature Impact Scoring
+# Module 06: Trigger Mapping
+
+## Lesson 11: Feature Impact Scoring
 
 **Systematic Feature Prioritization**
 
@@ -398,6 +400,6 @@ You're ready to create your own Trigger Map. The tutorial will walk you through
 
 ---
 
-[← Back to Lesson 10](lesson-10-visual-trigger-map.md) | [Next: Tutorial - Create Your Trigger Map →](tutorial-05.md)
+[← Back to Module Overview](module-06-overview.md) | [← Back to Lesson 10](lesson-10-visual-trigger-map.md) | [Next: Tutorial - Create Your Trigger Map →](tutorial-06.md)
 
-*Part of Module 05: Trigger Mapping*
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/module-05-overview.md b/docs/learn/module-06-trigger-mapping/module-06-overview.md
similarity index 89%
rename from docs/learn-wds/module-05-trigger-mapping/module-05-overview.md
rename to docs/learn/module-06-trigger-mapping/module-06-overview.md
index 2e8c240ce..78a223044 100644
--- a/docs/learn-wds/module-05-trigger-mapping/module-05-overview.md
+++ b/docs/learn/module-06-trigger-mapping/module-06-overview.md
@@ -1,4 +1,4 @@
-# Module 05: Trigger Mapping
+# Module 06: Trigger Mapping
 
 **Connect Business Goals to User Psychology**
 
@@ -144,7 +144,7 @@ Deep dive into the psychology that drives behavior:
 **The Four-Layer Structure:**
 - Business Goals → Product/Solution → Target Groups → Usage Goals (Positive + Negative separated)
 
-**What you'll learn:**ategic one-page document:
+**What you'll learn:** Your strategic one-page document:
 
 - What the Trigger Map looks like
 - How to read and use it
@@ -168,7 +168,7 @@ Deep dive into systematic feature prioritization:
 
 ## Tutorials
 
-### [Tutorial 05: Create Your Trigger Map](tutorial-05.md)
+### [Tutorial 06: Create Your Trigger Map](tutorial-06.md)
 
 **Full Trigger Mapping Process (Starting from Scratch)**
 
@@ -180,19 +180,7 @@ Step-by-step hands-on guide to creating your complete Trigger Map with Saga thro
 
 ---
 
-### [Tutorial 05B: Create a Slim Trigger Map](tutorial-05b-value-trigger-chain.md)
-
-**Lightweight Alternative (Quick Validation)**
-
-Quick strategic validation for focused user journeys — one business goal, one target group, key driving forces.
-
-**Time:** 15-20 minutes  
-**What you'll create:** Single-chain map from goal to trigger  
-**Best for:** Smaller features, single journey, quick validation, time-constrained situations
-
----
-
-### [Tutorial 05C: Synthesize from Documentation](tutorial-05c-documentation-synthesis.md)
+### [Tutorial 06C: Synthesize from Documentation](tutorial-06c-documentation-synthesis.md)
 
 **Documentation Synthesis (Existing Research)**
 
@@ -202,7 +190,7 @@ Transform existing documentation into an actionable Trigger Map - validate and o
 **What you'll create:** Synthesized Trigger Map + gap analysis  
 **Best for:** Extensive vision docs, user research, plans, or interviews that need to be made actionable
 
-**Which tutorial should you use?** See [Lesson 2: Heritage & Evolution](lesson-02-heritage-evolution.md#three-approaches-choose-your-path) for guidance.
+**Which tutorial should you use?** See [Lesson 2: Heritage & Evolution](lesson-02-heritage-evolution.md#two-approaches-choose-your-path) for guidance.
 
 ---
 
@@ -216,7 +204,7 @@ Transform existing documentation into an actionable Trigger Map - validate and o
 - Includes both positive and negative psychological drivers
 
 **The Three Strategic Layers:**
-1. **Business Goals** - Your WHY (vision + SMART objectives)
+1. **Business Goals** - Your WHY (vision + strategic objectives)
 2. **Target Groups** - The WHO (user types whose success drives yours)
 3. **Usage Goals** - Their WHY (positive drivers + negative drivers)
 
@@ -256,7 +244,7 @@ By the end of this module, you will:
 ## What You'll Create
 
 **Core Deliverables:**
-- ✅ Business Goals (vision + 3-5 SMART objectives)
+- ✅ Business Goals (vision + 3-5 strategic objectives)
 - ✅ Target Groups (3-5 prioritized personas)
 - ✅ Driving Forces (positive + negative for each persona)
 - ✅ Priority Rankings (groups and drivers ranked)
@@ -278,6 +266,6 @@ By the end of this module, you will:
 
 ---
 
-[← Back to Module 04: Product Brief](../module-04-product-brief/module-04-overview.md) | [Next: Module 06: Scenarios →](../module-06-scenarios/module-06-overview.md)
+[← Back to Module 05: Platform Requirements](../module-05-platform-requirements/module-05-platform-requirements-overview.md) | [Next: Module 07: Design Phase →](../module-07-design-phase/module-07-design-phase-overview.md)
 
 *Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn-wds/module-05-trigger-mapping/tutorial-05.md b/docs/learn/module-06-trigger-mapping/tutorial-06.md
similarity index 95%
rename from docs/learn-wds/module-05-trigger-mapping/tutorial-05.md
rename to docs/learn/module-06-trigger-mapping/tutorial-06.md
index 62b35b45c..35f53be74 100644
--- a/docs/learn-wds/module-05-trigger-mapping/tutorial-05.md
+++ b/docs/learn/module-06-trigger-mapping/tutorial-06.md
@@ -1,4 +1,4 @@
-# Tutorial 05: Create Your Trigger Map
+# Tutorial 06: Create Your Trigger Map
 
 **Hands-on guide to mapping business goals to user psychology**
 
@@ -94,7 +94,7 @@ Business goals work on two levels:
 - Ask yourself: "What will we see when this is realized?"
 - Transform vision into observable evidence
 
-**3. Create 3-5 SMART objectives:**
+**3. Create 3-5 strategic objectives using the SMART model:**
 - Specific (not vague)
 - Measurable (with numbers)
 - Achievable (realistic)
@@ -113,7 +113,7 @@ See [SMART Method Reference](../../models/smart-goals-model.md) for detailed gui
 
 **You:** "We'd see teams using our tool daily, staying with us long-term, and growing their usage. We'd see revenue that proves the business model works."
 
-**Saga:** "Excellent. Let's turn those observations into SMART objectives. What specific numbers would prove daily usage?"
+**Saga:** "Excellent. Let's express those observations as strategic objectives using the SMART model. What specific numbers would prove daily usage?"
 
 **You:** "We need to achieve 5,000 active teams by Q4 2024, with at least 70% weekly retention and $50K monthly recurring revenue."
 
@@ -179,11 +179,13 @@ This workshop identifies real people whose product usage drives your business su
 - Specific enough to design for
 - Focus on who will use the product in ways that achieve your goals
 
-**Create persona for each:**
+**Create persona profile for each (WHO they are):**
 - Name and context (their real-world situation)
-- Goals and motivations
-- Frustrations and fears
-- Behavioral patterns
+- Behavioral patterns (how they act)
+
+**Then define usage goals (when they face your problem space):**
+- Positive drivers (what they want to achieve)
+- Negative drivers (what they want to avoid)
 - How their product use connects to your business goals
 
 **Rank by priority:**
@@ -430,7 +432,7 @@ Business Goals → Product/Solution → Target Groups → Usage Goals
                                                      (Positive + Negative)
 ```
 
-1. **Business Goals** (Left, Blue) - Your vision and SMART objectives
+1. **Business Goals** (Left, Blue) - Your vision and strategic objectives
 2. **Product/Solution** (Center, Yellow) - What you're building
 3. **Target Groups** (Middle-Right, Orange) - Prioritized personas (👥 primary, 👤 secondary)
 4. **Usage Goals** (Right, Green/Red) - Positive drivers (✅) and negative drivers (❌) separated
@@ -470,7 +472,7 @@ Business Goals → Product/Solution → Target Groups → Usage Goals
 
 ## What You've Accomplished
 
-✅ **Business Goals** - Clear vision and SMART objectives  
+✅ **Business Goals** - Clear vision and strategic objectives  
 ✅ **Target Groups** - 3-5 prioritized personas with deep context  
 ✅ **Driving Forces** - Positive and negative psychology mapped  
 ✅ **Prioritization** - Ranked groups and drivers by strategic value  
@@ -565,7 +567,7 @@ A: Show them the Trigger Map and scoring matrix. Walk through the strategic reas
 - Use scores to guide sprint planning
 
 **Next Module:**
-- [Module 06: Scenarios](../module-06-scenarios/module-06-overview.md)
+- [Module 06: Scenarios](../module-08-outline-scenarios/module-08-outline-scenarios-overview.md)
 - Transform your Trigger Map into detailed user scenarios
 
 ---
@@ -590,6 +592,6 @@ A: Show them the Trigger Map and scoring matrix. Walk through the strategic reas
 
 **Your Trigger Map is the strategic foundation that guides every design decision. Use it well!**
 
-[← Back to Lesson 6](lesson-06-feature-impact-scoring.md) | [Back to Module Overview](module-05-overview.md)
+[← Back to Lesson 11](lesson-11-feature-impact-scoring.md) | [Back to Module Overview](module-06-overview.md)
 
-*Part of Module 05: Trigger Mapping*
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn-wds/module-05-trigger-mapping/tutorial-05c-documentation-synthesis.md b/docs/learn/module-06-trigger-mapping/tutorial-06c-documentation-synthesis.md
similarity index 96%
rename from docs/learn-wds/module-05-trigger-mapping/tutorial-05c-documentation-synthesis.md
rename to docs/learn/module-06-trigger-mapping/tutorial-06c-documentation-synthesis.md
index e2d321e4f..88dccebbe 100644
--- a/docs/learn-wds/module-05-trigger-mapping/tutorial-05c-documentation-synthesis.md
+++ b/docs/learn/module-06-trigger-mapping/tutorial-06c-documentation-synthesis.md
@@ -1,4 +1,4 @@
-# Tutorial 05C: Synthesize from Documentation
+# Tutorial 06C: Synthesize from Documentation
 
 **Transform existing research into an actionable Trigger Map**
 
@@ -26,12 +26,9 @@ This tutorial walks you through synthesizing your existing documentation into a
 **Use Full Trigger Mapping instead if:**
 - ❌ Starting from scratch with no documentation
 - ❌ Documentation is minimal or non-existent
+- ❌ Need quick validation (use Suggest or Dream mode)
 
-**Use Slim Trigger Map instead if:**
-- ❌ Need quick validation (under 20 minutes)
-- ❌ Single user journey focus
-
-**Not sure which to use?** See [Lesson 2: Heritage & Evolution](lesson-02-heritage-evolution.md#three-approaches-choose-your-path)
+**Not sure which to use?** See [Lesson 2: Heritage & Evolution](lesson-02-heritage-evolution.md#two-approaches-choose-your-path)
 
 ---
 
@@ -466,10 +463,15 @@ A: Trigger Map organizes research into actionable structure, identifies gaps, va
 ## Related Resources
 
 - [Lesson 2: Heritage & Evolution](lesson-02-heritage-evolution.md) - Understanding the three approaches
-- [Tutorial 05: Full Trigger Mapping](tutorial-05.md) - Starting from scratch
-- [Tutorial 05B: Slim Trigger Map](tutorial-05b-value-trigger-chain.md) - Quick validation
-- [Module 05 Overview](module-05-overview.md) - Complete module guide
+- [Tutorial 06: Full Trigger Mapping](tutorial-06.md) - Starting from scratch
+- [Module 06 Overview](module-06-overview.md) - Complete module guide
 
 ---
 
 **Ready to transform your documentation into an actionable Trigger Map?** Activate Saga and begin! 🎯
+
+---
+
+[← Back to Tutorial 06](tutorial-06.md) | [Module Overview](module-06-overview.md) | [Next Module →](../module-07-design-phase/module-07-design-phase-overview.md)
+
+*Part of Module 06: Trigger Mapping*
diff --git a/docs/learn/module-07-design-phase/lesson-01-entering-design.md b/docs/learn/module-07-design-phase/lesson-01-entering-design.md
new file mode 100644
index 000000000..ae57371b1
--- /dev/null
+++ b/docs/learn/module-07-design-phase/lesson-01-entering-design.md
@@ -0,0 +1,251 @@
+# Module 07: The Design Phase
+
+## Lesson 1: Entering Design Mode
+
+**The transition from strategy to creation**
+
+---
+
+## You've Built the Foundation
+
+Take a moment to appreciate what you've accomplished:
+
+**Module 04: Product Brief** — Your North Star
+- Vision and positioning
+- Target users and stakeholders
+- Success criteria and constraints
+
+**Module 05: Platform Requirements** — Your Boundaries
+- Platforms you're targeting
+- Integrations required
+- Constraints and knowledge gaps
+
+**Module 06: Trigger Map** — User Psychology Mapped
+- Personas with driving forces
+- Business goals connected to features
+- The "why" behind every decision
+
+This is your strategic foundation. Every design decision you make from here forward references these documents.
+
+---
+
+## The Mindset Shift
+
+Strategy is about **discovering and documenting**.
+Design is about **visualizing and specifying**.
+
+You're moving from:
+
+| Strategy Mode | Design Mode |
+|---------------|-------------|
+| What should we build? | How should it work? |
+| Why does this matter? | What does the user see? |
+| Who is this for? | How do they accomplish their goal? |
+| What's possible? | What exactly happens? |
+
+Both matter. But they require different thinking.
+
+---
+
+## Before We Begin: Why Specifications Matter
+
+Before diving into the design workflow, you need to understand a critical question:
+
+**"Why can't we just skip to code?"**
+
+**Short answer:** Because code is 10-20% of the value. Specifications are 80-90%.
+
+**Your app exists in specifications.** The code is just one possible projection—like compiled output.
+
+This isn't about "doing things the hard way." This is about **doing things the professional way** with AI-assisted development.
+
+**→ [Read Lesson 2: Why Specifications Matter](lesson-02-why-specifications-matter.md)** for the complete philosophy behind WDS.
+
+Key insights you'll learn:
+- Code is a lossy projection from specifications
+- Specifications align humans on shared goals
+- Specs are meta-prompts that enable autonomous AI work
+- Professional approach: Prompt → Spec → Code (not Prompt → Code → Debug hell)
+- Why this represents "the spirit of BMad v6 through the lens of a designer"
+
+**This foundation is critical.** Read Lesson 2 before continuing.
+
+---
+
+## Meet Freya
+
+Freya is your design partner for this phase.
+
+**What Freya does:**
+
+- Thinks WITH you, not FOR you
+- Asks "WHY?" before "WHAT?"
+- Connects every decision to your Trigger Map
+- Won't let you skip the hard thinking
+
+**What Freya doesn't do:**
+
+- Create pretty pictures without substance
+- Make decisions for you
+- Let you design in isolation from strategy
+- Accept "I don't know" as a final answer
+
+She's not a pixel pusher. She's a thinking partner who happens to work with visuals.
+
+---
+
+## The Freya Approach
+
+Freya's first question is always strategic:
+
+> "Looking at your Trigger Map, which persona's journey should we design first?"
+
+Not: "What color should the button be?"
+
+Every design decision connects back to your strategic foundation. If it doesn't connect, it gets questioned.
+
+---
+
+## The Design Workflow
+
+Nine modules. Eight steps. One coherent journey.
+
+```
+Outline → Sketch → Storyboard → Specify → Components → Visual → System → Deliver
+```
+
+| Step | What You Do | What You Create |
+|------|-------------|-----------------|
+| **Outline Scenarios** | Define user journeys | Scenario outlines |
+| **Conceptual Sketching** | Visualize default states | Rough sketches |
+| **Storyboarding** | Show transformations | Keyframe sequences |
+| **Specifications** | Document every detail | Complete specs |
+| **Components** | Define reusable patterns | Component definitions |
+| **Visual Design** | Apply visual language | Polished designs |
+| **Design System** | Organize for reuse | System documentation |
+| **Delivery** | Package for implementation | Delivery package |
+
+---
+
+## Not Strictly Linear
+
+You'll loop back. That's expected.
+
+- Sketching reveals gaps in your scenario outline
+- Storyboarding exposes missing states
+- Specifications surface component needs
+- Visual design raises consistency questions
+
+**The loop is the process.** Don't fight it.
+
+---
+
+## Multiple Entry Points
+
+Every step offers choices for how you start:
+
+| Entry Point | How It Works |
+|-------------|--------------|
+| **I have a sketch** | You provide, AI refines |
+| **I have inspiration** | You share, AI extracts patterns |
+| **Dream it up** | AI creates options, you pick |
+| **Let's discuss** | Conversation shapes the concept |
+
+Same step. Same output. Different starting points.
+
+You're not forced into one way of working. Use what feels natural for each situation.
+
+---
+
+## Creative Discipline
+
+> "Creative discipline enables creativity, not constrains it."
+
+This phrase captures the WDS approach to design.
+
+**Without discipline:**
+- Endless exploration with no conclusion
+- Beautiful mockups that solve wrong problems
+- Scattered work that can't be implemented
+- Decisions without rationale
+
+**With discipline:**
+- Focused exploration with clear outcomes
+- Beautiful mockups grounded in strategy
+- Coherent work ready for implementation
+- Every decision documented with WHY
+
+Structure doesn't limit creativity. It channels it.
+
+---
+
+## What You'll Create
+
+By the end of this phase:
+
+| Artifact | Purpose |
+|----------|---------|
+| **Scenario outlines** | The journeys you're designing |
+| **Conceptual sketches** | Visual explorations of each view |
+| **Storyboards** | How elements transform |
+| **Detailed specifications** | Every decision documented |
+| **Component definitions** | Reusable patterns identified |
+| **Visual designs** | Final look and feel |
+| **Design system** | Your component library |
+| **Delivery package** | Ready for Idunn to implement |
+
+---
+
+## Design System
+
+Remember the choice from setup:
+
+| Mode | What Happens |
+|------|--------------|
+| **1. None** | Ad-hoc styling, no extraction |
+| **2. Building** | System grows from your work |
+| **3. Library** | Use external + your branding |
+| **4. Existing** | Import from previous projects |
+
+This affects how Freya works with you throughout the phase.
+
+**Mode 1-2:** You're creating the design language as you go
+**Mode 3-4:** You're working within established patterns
+
+Neither is better. Just different workflows.
+
+---
+
+## The Core Principle
+
+Every pixel has a reason.
+Every interaction traces back to user psychology.
+Every component connects to a business goal.
+
+**Nothing is decoration. Everything is decision.**
+
+When you can explain WHY something exists, you've designed well.
+
+When you can't explain it, something's missing.
+
+---
+
+## Ready to Design
+
+You have:
+- Strategic foundation (Product Brief, Trigger Map, Platform Requirements)
+- A thinking partner (Freya)
+- A clear workflow (8 steps)
+- Flexible entry points (multiple ways to start each step)
+
+Let's begin.
+
+---
+
+**[Continue to Module 08: Outline Scenarios →](../module-08-outline-scenarios/module-08-outline-scenarios-overview.md)**
+
+---
+
+[← Back to Module Overview](module-07-design-phase-overview.md)
+
+*Part of Module 07: Design Phase*
diff --git a/docs/learn/module-07-design-phase/lesson-02-why-specifications-matter.md b/docs/learn/module-07-design-phase/lesson-02-why-specifications-matter.md
new file mode 100644
index 000000000..e298c8cd7
--- /dev/null
+++ b/docs/learn/module-07-design-phase/lesson-02-why-specifications-matter.md
@@ -0,0 +1,836 @@
+# Module 07: The Design Phase
+
+## Lesson 2: Why Specifications Matter
+
+**The New Code: Specifications as the Foundation of Professional AI-Assisted Development**
+
+---
+
+## The Reason Vibe coding fails - The Amateur Question
+
+*"Why are we wasting time with scenarios and specifications? Can't we just tell the AI agent to code the app and be done with it?"*
+
+This question reveals a fundamental misunderstanding about what creates value in software development—especially in the age of AI.
+
+**The honest answer:** You can try "prompt to code." It'll be fast, broken, unmaintainable, and you'll burn 10x the credits fixing it.
+
+But more importantly, you'll have missed the entire point of professional software development.
+
+---
+
+## Foundation: The New Paradigm
+
+This lesson applies the philosophy from Sean Grove's talk "The New Code" to the WDS methodology.
+
+**→ Read the core framework:** [Model: Specifications as the New Code](../../models/specifications-as-the-new-code.md)
+
+**Watch the full talk:** [The New Code — Sean Grove, OpenAI](https://www.youtube.com/watch?v=8rABwKRsec4)
+
+**Key insight:**
+> "Code is sort of 10 to 20% of the value that you bring. The other 80 to 90% is in structured communication."
+> — Sean Grove
+
+This lesson shows **how WDS implements this philosophy** through its specification-driven workflow.
+
+---
+
+
+
+## What Actually Creates Value
+
+> "Code is sort of 10 to 20% of the value that you bring. The other 80 to 90% is in structured communication."
+>
+> — Sean Grove, "The New Code"
+
+This statement captures the fundamental truth about software development:
+
+**Code is the OUTPUT. Specifications are the WORK.**
+
+**Code is the PROJECTION. Specifications are the SOURCE.**
+
+**Code is what MACHINES execute. Specifications are how HUMANS align.**
+
+### The Shifted Paradigm
+
+**Traditional thinking:**
+- Code is the primary artifact
+- Documentation is secondary (often skipped)
+- "Just ship it and we'll figure it out"
+
+**Professional AI-assisted development:**
+- Specifications are the primary artifact (80-90% of value)
+- Code is secondary, a lossy projection (10-20% of value)
+- "Get the specs right, code follows correctly"
+
+---
+
+## Your App Exists in Specifications
+
+This is the critical insight that makes WDS unique:
+
+**Your software exists in the specifications.**
+
+The code is just one possible projection of that specification—like compiled output for one target architecture.
+
+### Think Like a Compiler
+
+When you compile C++ code:
+- **Source:** Your C++ program (human-readable intent)
+- **Target 1:** x86 machine code
+- **Target 2:** ARM machine code
+- **Target 3:** WebAssembly
+
+**Same source. Multiple targets.** All generated from the specification.
+
+### Your Specifications Work the Same Way
+
+**Source:** Your scenario specifications (human-aligned intent)
+- **Target 1:** TypeScript + React
+- **Target 2:** Rust + WASM
+- **Target 3:** Python + Django
+- **Target 4:** User documentation
+- **Target 5:** Tutorial content
+- **Target 6:** Test suites
+
+**Same specifications. Multiple outputs.** All generated by AI agents from your specs.
+
+**This is what makes specifications the primary artifact.**
+
+---
+
+## Strategic Thinking Just Got Cheaper Too
+
+Everyone knows AI made code cheap.
+
+**What most people missed:** AI made strategic thinking cheap too.
+
+**→ Read the complete strategic framework:** [Specifications as the New Code](../../models/specifications-as-the-new-code.md)
+
+**Key insights:**
+
+### The Three Eras
+
+| Era | Code Cost | Specs Cost | Communication Cost | Result |
+|-----|-----------|------------|-------------------|--------|
+| **Waterfall** | High | High | High | Upfront specs, code once |
+| **Agile** | High | Skipped | Low | Skip specs, meet constantly |
+| **AI (amateur)** | Low | Still skipped | High | Churn prototypes endlessly |
+| **AI (WDS)** | Low | **Low (AI-assisted)** | High | **Forge specs, generate correctly** |
+
+**The insight everyone missed:**
+
+Agile killed the PRD because communication was cheap and coding was expensive.
+
+AI revived the PRD because **both strategic thinking AND coding are now cheap.**
+
+**WDS exists because you can now:**
+- Use AI to forge strategic thinking (Saga, Freya as thinking partners)
+- Create polished specifications cheaply (AI-assisted)
+- Generate code from complete specs (AI agents)
+- Present ideas, not prototypes (efficient communication)
+
+**The amateur approach:**
+> "Code is cheap. Skip specs. Prompt AI. Churn prototypes."
+
+**The professional approach:**
+> "Strategic thinking is cheap too. Forge specs with AI. Generate code correctly."
+
+**Read the full framework to understand why WDS is the professional standard for AI-assisted development.**
+
+---
+
+## Code Is a Lossy Projection
+
+> "Code is actually a lossy projection from the specification."
+>
+> — Sean Grove
+
+Think about what gets LOST when you jump from "make a login screen" to code:
+
+**Lost from the specification:**
+- WHY this login exists (business goal)
+- WHO uses it (persona psychology)
+- WHAT drives them (trigger map drivers)
+- HOW they feel (emotional state)
+- WHEN it should adapt (context changes)
+- WHERE it fits in the journey (scenario flow)
+
+**What the code captures:**
+- A form with two inputs and a button
+- Some validation logic
+- An API call
+
+**The code is 10% of the story.** The specification is 100%.
+
+### Example: The Login Scenario
+
+**Just the code knows:**
+```typescript
+<form onSubmit={handleLogin}>
+  <input type="email" />
+  <input type="password" />
+  <button>Login</button>
+</form>
+```
+
+**The specification knows:**
+1. **Why:** This addresses "fear of unauthorized access" (Driver #3, Remote Team Leads)
+2. **Who:** Remote managers protecting team data
+3. **What:** Need quick, secure access without friction
+4. **How:** Proactive mode ("Everything is secure") not reactive ("Nothing can go wrong")
+5. **When:** Often logging in from different devices/locations
+6. **Where:** First step in "Daily Team Check" scenario
+7. **Default state:** Empty fields, disabled submit, "Remember me" pre-checked
+8. **Validation:** Real-time email format, password strength indicator
+9. **Error states:** Network failure, invalid credentials, account locked, too many attempts
+10. **Success flow:** Loading state (0.5s), redirect to dashboard, persist session 30 days
+11. **Accessibility:** Tab order, ARIA labels, screen reader announcements, focus management
+12. **Responsive:** Mobile-first, touch targets 44px minimum, no horizontal scroll
+13. **Edge cases:** Rate limiting, password reset flow, SSO option, back button behavior
+
+**The code is a projection of this.**
+
+When you need to rewrite in a different framework, the specification remains the source of truth.
+
+---
+
+## Specifications Align Humans
+
+> "A written specification is what enables you to align humans on the shared set of goals."
+>
+> — Sean Grove
+
+This is the 80-90% of value that specifications provide.
+
+### Before Specification
+
+**Stakeholder A thinks:** "Login should be quick and simple"
+**Stakeholder B thinks:** "Login should be highly secure"
+**Developer thinks:** "Login should use OAuth"
+**Designer thinks:** "Login should feel welcoming"
+**User thinks:** "I just want to get to my stuff"
+
+**Five people. Five different login screens in their heads.**
+
+### After Specification
+
+**Everyone reads the same specification:**
+- Security through 2FA, not friction
+- Quick for returning users (remembered device)
+- OAuth + password options (user choice)
+- Welcoming through microcopy, not animation
+- "Get to my stuff" is measured (< 3 seconds from landing)
+
+**Five people. One shared login screen.**
+
+**This alignment is the majority of the work.** The code is just typing after you've aligned.
+
+---
+
+## The Professional Approach: Prompt → Spec → Code
+
+**This is what pros do.** Not because they like extra work, but because they understand how AI agents actually work at scale.
+
+| Approach | Reliability | Testing | Maintenance | Dimensions | Credits |
+|----------|-------------|---------|-------------|------------|---------|
+| **Prompt → Spec → Code** | ✅ Reliable, repeatable | ✅ Test against spec | ✅ Maintainable, documented | ✅ Accessibility, i18n, SEO | ✅ Building, not debugging |
+| **Prompt → Code** | ❌ Inconsistent each time | ❌ No testing reference | ❌ "What does this do?" | ❌ Forgot accessibility | ❌ Endless regeneration |
+
+### Why "Prompt to Code" Fails at Scale
+
+**The amateur sees:**
+- "I prompted, I got code, I shipped. Done!"
+- *Shows you the first 10 seconds*
+
+**The professional sees:**
+- Attempt 1: "Build login" → Wrong validation
+- Attempt 2: "Fix validation" → Breaks mobile
+- Attempt 3: "Fix mobile" → Lost accessibility
+- Attempt 4: "Fix accessibility" → Errors unclear
+- Attempt 5: "Better errors" → Now navigation broke
+- Attempt 6-20: Still not right
+- *Shows you the next 10 hours*
+
+**The AI showoffs and scammers don't show you the debugging marathon.**
+
+---
+
+## Understanding Context Windows
+
+Here's what most people miss about AI agents:
+
+**You can't fit your entire app in one prompt.**
+
+Even with 200k tokens, you're trying to describe:
+- Every user flow
+- Every edge case
+- Every interaction
+- Every validation rule
+- Every error state
+- Accessibility requirements
+- Responsive behaviors
+- Loading states
+- Empty states
+- Animation timings
+- Microcopy variations
+- Error messages
+- Success states
+- Navigation patterns
+- Data persistence
+- Session management
+- Permission systems
+- ...and 1000 more micro-decisions
+
+**Try cramming that into "Build me a todo app."**
+
+### What Happens When You Try
+
+The agent makes **thousands of micro-decisions** without your input.
+
+**Most will be wrong for:**
+- YOUR app
+- YOUR users
+- YOUR psychology drivers
+- YOUR business goals
+- YOUR brand voice
+- YOUR accessibility standards
+- YOUR performance requirements
+
+**Because the agent had to guess.** You didn't specify.
+
+---
+
+## Specifications Are Meta-Prompts
+
+**This is the key insight:**
+
+Creating specifications IS creating the ultimate meta-prompt—a "super prompt" that agents reference throughout development.
+
+**You're building a digital twin**—a complete blueprint of your software that exists BEFORE the code.
+
+### Specification = Super Prompt That:
+
+- ✅ Breaks down complexity into manageable chunks
+- ✅ Provides exact context for each piece
+- ✅ Ensures consistency across the entire app
+- ✅ Enables autonomous agent work WITHOUT guessing
+- ✅ Creates a testing reference for every feature
+- ✅ Documents accessibility, i18n, SEO requirements
+- ✅ Captures edge cases and error states
+- ✅ Defines success criteria for validation
+
+**Each specification is a prompt.** Together they form the master prompt for your entire application.
+
+### Example: Login Scenario Specification
+
+**Prompt → Code approach:**
+> "Build a login screen with email and password"
+
+**Agent must guess:**
+- What happens on submit?
+- What validation rules?
+- What error messages?
+- Where does it redirect?
+- What if network fails?
+- What about password reset?
+- What about "remember me"?
+- Mobile responsive how?
+- Accessibility labels?
+- Screen reader support?
+- Keyboard navigation?
+- Focus management?
+
+**Result:** 12+ ambiguous decisions made without your input.
+
+---
+
+**Prompt → Spec → Code approach:**
+
+Specification documents exactly:
+
+1. **Default State**
+   - Empty email/password fields
+   - Submit button disabled until both valid
+   - "Remember me" checkbox (pre-checked)
+   - "Forgot password?" link below password
+
+2. **Validation Rules**
+   - Email: Standard format, real-time feedback
+   - Password: Minimum 8 characters, show/hide toggle
+   - Submit: Enabled only when both fields valid
+
+3. **Error States**
+   - Network failure: "Connection lost. Check your network." + Retry button
+   - Invalid credentials: "Email or password incorrect. Try again or reset password."
+   - Account locked: "Too many failed attempts. Account locked for 30 minutes."
+   - Too many attempts: "Please wait 5 minutes before trying again."
+
+4. **Success Flow**
+   - Loading state: Spinner on button, "Logging you in..."
+   - Redirect: Dashboard (new users) or Last Visited Page (returning)
+   - Session: 30 days if "Remember me", 24 hours if not
+
+5. **Accessibility**
+   - Tab order: Email → Password → Remember me → Forgot password → Submit
+   - ARIA: `aria-label="Email address"` on email input
+   - Screen reader: Announces errors immediately upon validation
+   - Focus management: On error, focus first invalid field
+   - Keyboard: Enter submits from any field
+
+6. **Responsive**
+   - Mobile: Full-width inputs, 16px minimum font (prevents zoom)
+   - Tablet: Centered card, max-width 480px
+   - Desktop: Centered card, max-width 480px
+   - Touch targets: 44px minimum height for all interactive elements
+
+7. **Edge Cases**
+   - Rate limiting: 5 attempts per 5 minutes per IP
+   - Password reset: Email link, expires in 1 hour
+   - SSO option: "Or sign in with Google" button below form
+   - Back button: Returns to landing page, doesn't re-submit
+   - Browser autofill: Compatible, doesn't break validation
+
+**Now the agent has ZERO ambiguity.** It builds exactly what you specified.
+
+**Result:** First attempt works. All edge cases handled. Accessibility built in. Tests pass.
+
+---
+
+## The Multi-Dimensional Benefits
+
+Specifications enable things that "prompt to code" completely misses:
+
+| Dimension | With Specs | Without Specs |
+|-----------|------------|---------------|
+| **Testing** | Test against spec, know what "correct" means | No reference, can't validate, just hope |
+| **Accessibility** | ARIA labels, keyboard nav, screen reader documented | Forgotten or inconsistent, fails WCAG |
+| **Internationalization** | String IDs, translation-ready, locale-aware | Hardcoded English everywhere, expensive fix |
+| **SEO** | Semantic HTML, meta tags, structured data specified | Generic divs, no SEO thought, poor rankings |
+| **Error handling** | Every error state documented and testable | Agent guesses, misses critical cases |
+| **Consistency** | Same patterns throughout, design system enforced | Different approach each screen, chaos |
+| **Maintenance** | Documentation exists, anyone can understand | "What does this even do?", knowledge silos |
+| **Handoff** | Any dev/designer can understand the intent | Only original prompter knows, bus factor 1 |
+| **Evolution** | Clear what changes when requirements change | Ripple effects unknown, fear of changes |
+| **Onboarding** | New team members read specs and understand | Archaeological dig through code |
+
+### Example: Accessibility
+
+**Prompt → Code:**
+> "Make it accessible"
+
+**What the agent does:**
+- Adds some ARIA labels randomly
+- Misses keyboard navigation
+- Forgets focus management
+- No screen reader testing
+- Fails WCAG audit
+
+**Result:** Inaccessible to users with disabilities, potential legal liability.
+
+---
+
+**Prompt → Spec → Code:**
+
+**Specification states:**
+- Tab order: Email → Password → Submit → Forgot password
+- ARIA: `aria-label="Email address"` on email field, `aria-label="Password"` on password field
+- Screen reader: Announces errors immediately when validation fails
+- Focus management: On error, focus moves to error message, then invalid field
+- Keyboard: Enter key submits from any field, Escape clears form
+- Error announcements: `role="alert"` on error messages for immediate announcement
+- Loading state: `aria-busy="true"` during submission
+
+**Agent implements EXACTLY this.** Nothing missed. Nothing guessed.
+
+**Result:** WCAG 2.1 AA compliant, works for all users.
+
+---
+
+## Why Scenarios Before Code
+
+You're creating a **blueprint**. A **digital twin** of your software before it exists.
+
+**Scenario = Complete journey specification**
+- What views does the user see?
+- In what order?
+- What data flows between them?
+- What can go wrong at each step?
+- How do we handle it?
+- What's the user's emotional state?
+- How do psychology drivers affect the flow?
+
+### Without Scenarios
+
+**What happens:**
+- Agent builds isolated screens with no journey context
+- Navigation breaks between screens
+- Data flow undefined or inconsistent
+- Edge cases missed completely
+- User gets stuck, can't complete tasks
+- No consideration of emotional arc
+- Psychology drivers ignored
+
+**Example:** User completes login, but where do they land? Dashboard? Last page? Onboarding? The agent guesses.
+
+### With Scenarios
+
+**What happens:**
+- Agent understands the complete flow end-to-end
+- Builds navigation correctly with proper routing
+- Handles data persistence properly across views
+- Covers edge cases from the spec
+- User journey works end-to-end
+- Emotional arc designed intentionally
+- Psychology drivers shape each step
+
+**Example:** Spec says "Returning users land on Last Visited Page. New users see Onboarding Step 1. Users from password reset see Success message then Dashboard." Agent implements exactly this.
+
+---
+
+## The OpenAI Model Spec Example
+
+Sean Grove references OpenAI's "Model Spec" as a perfect example of this approach:
+
+> "OpenAI put out their model spec, which is meant to describe how the model ought to behave. It's like 30 pages long, and it's almost incomprehensibly specific about the tiniest details of how it should behave."
+
+**Why did OpenAI write 30 pages of specification?**
+
+Because **code is a lossy projection from the specification.**
+
+The Model Spec is the **source of truth**. The model behavior is the **compiled output**.
+
+When behavior is wrong, they fix the **spec** and regenerate. They don't patch the output.
+
+**WDS applies this same principle to your software:**
+
+- Your specifications are the source of truth
+- Your code is the compiled output
+- When behavior is wrong, fix the spec and regenerate
+- Don't patch code without updating specs
+
+---
+
+## The Credit Economics
+
+### Prompt → Code Burns Credits on Chaos
+
+```
+Attempt 1: "Build login" → Wrong validation
+Attempt 2: "Fix validation" → Breaks mobile
+Attempt 3: "Fix mobile" → Lost accessibility
+Attempt 4: "Fix accessibility" → Errors unclear
+Attempt 5: "Better errors" → Now navigation broke
+Attempt 6: "Fix navigation" → Forgot edge cases
+Attempt 7: "Add edge cases" → Performance issues
+Attempt 8: "Optimize" → Broke original functionality
+Attempt 9: "Fix original" → Mobile broke again
+Attempt 10: "Fix mobile again" → Lost the optimizations
+...
+Attempt 20: Still not right, out of credits, frustrated
+```
+
+**Credits spent:** Massive regeneration loop, endless debugging
+
+**Time spent:** Days or weeks of back-and-forth
+
+**Quality:** Inconsistent, fragile, missing features
+
+---
+
+### Prompt → Spec → Code Invests Credits Wisely
+
+```
+Spec phase: Define exactly what you want (upfront investment)
+  Workshop 1: Business goals (15 min with Saga)
+  Workshop 2: Target groups (20 min with Saga)
+  Workshop 3: Driving forces (20 min with Saga)
+  Workshop 4: Prioritization (15 min with Saga)
+  Workshop 5: Feature scoring (15 min with Saga)
+  Scenario outlines: Define journeys (with Freya)
+  Specifications: Document every detail (with Freya)
+
+Code phase: Agent builds it correctly (first time)
+  Idunn reads specs
+  Generates code matching specifications exactly
+  Includes tests from specs
+
+Test phase: Verify against spec (passes)
+  Run tests
+  Validate against specifications
+  Fix any discrepancies in specs, regenerate code
+```
+
+**Credits spent:** One-time build, minimal fixes
+
+**Time spent:** Organized effort, predictable timeline
+
+**Quality:** Consistent, robust, complete features
+
+---
+
+## Professional vs Amateur
+
+**The AI showoffs and scammers say:**
+> "Just prompt to code! Look how fast!"
+
+*They show you:*
+- 10 seconds of prompting
+- Code appearing
+- "Look, it works!"
+
+*They don't show you:*
+- 10 hours of debugging
+- Missing accessibility
+- No error handling
+- Broken on mobile
+- Inconsistent patterns
+- Untestable code
+- No documentation
+- Impossible to maintain
+
+---
+
+**The professionals say:**
+> "Spec first. Code second. Ship once."
+
+*They show you:*
+- Working software that passes tests
+- Handles edge cases correctly
+- Works for all users (accessibility)
+- Performs well on all devices
+- Can be maintained and evolved
+- Documentation exists
+- Team aligned on goals
+- Strategic decisions traceable
+
+---
+
+## This Is Why WDS Works
+
+**WDS forces you to think before you build:**
+
+```
+1. Strategy first
+   ↓
+   Trigger Map ensures you're solving the right problem
+   Business goals → Target groups → Driving forces → Priorities → Features
+
+2. Scenarios second
+   ↓
+   Outline the journeys before the screens
+   User flows → Data flows → Edge cases → Emotional arcs
+
+3. Specifications third
+   ↓
+   Document every detail before code
+   Default states → Interactions → Validations → Errors → Success → Accessibility
+
+4. Code fourth
+   ↓
+   Agents build exactly what's specified
+   TypeScript → React → Tests (or any other target)
+
+5. Test fifth
+   ↓
+   Verify against specs (they pass!)
+   Automated tests reference specifications
+```
+
+**Each step is a meta-prompt for the next step.**
+
+- The trigger map prompts scenarios
+- The scenarios prompt specifications
+- The specifications prompt code
+- The code validates against specifications
+
+**It's a coherent system, not random prompting.**
+
+---
+
+## The Spirit of BMad v6 Through Design
+
+This philosophy—**specifications as the primary artifact**—represents:
+
+> "The spirit of BMad v6 through the lens of a designer with 25 years experience."
+
+### What BMad v6 Taught Us
+
+**BMad v6's innovation was conversational strategy:**
+- Guided dialog instead of forms
+- Questions that make you think deeply
+- Documentation that emerges from conversation
+- Strategic alignment before tactical decisions
+
+**BMad v6 showed:** "Talk it through properly, the right artifacts emerge."
+
+### WDS Extends This to Design
+
+**WDS applies the same principle to specifications:**
+- Guided creation instead of blank-page syndrome
+- Prompts that surface the right details
+- Specifications that emerge from strategic foundation
+- Complete blueprints before code
+
+**WDS shows:** "Spec it properly, the right code emerges."
+
+---
+
+## Engineering as Precise Exploration
+
+> "Engineering is the precise exploration by humans of software solutions to human problems."
+>
+> — Sean Grove
+
+**This statement captures what WDS is designed for:**
+
+- **Engineering:** Not just coding, but disciplined problem-solving
+- **Precise:** Specifications create precision, not vague "just build it"
+- **Exploration:** WDS supports iteration and discovery
+- **By humans:** AI assists, but humans drive strategy and alignment
+- **Software solutions:** Code is the output, not the primary work
+- **To human problems:** Trigger Map ensures you solve real problems
+
+**WDS provides the structure for this precise exploration:**
+
+1. **Discover the human problem** (Trigger Map)
+2. **Explore software solutions** (Scenarios)
+3. **Specify precisely** (Specifications)
+4. **Generate implementations** (Code)
+
+---
+
+## What Makes WDS Unique
+
+Many methodologies exist. What makes WDS different?
+
+### 1. Specifications as Primary Artifact
+
+**Other methodologies:**
+- Code-first, docs later (or never)
+- "Move fast and break things"
+- Documentation as afterthought
+
+**WDS:**
+- Specs-first, code generated from specs
+- "Think precisely and build right"
+- Specifications as source code
+
+### 2. AI-Native from the Ground Up
+
+**Other methodologies:**
+- Designed for human developers
+- AI retrofitted awkwardly
+- "How do we use AI to help with our process?"
+
+**WDS:**
+- Designed for human-AI collaboration
+- AI agents as first-class participants
+- "How do we structure work so humans and AI each do what they're best at?"
+
+### 3. Psychology-Driven Strategy
+
+**Other methodologies:**
+- "Build features users ask for"
+- Feature lists without strategic grounding
+- Stakeholder opinions drive decisions
+
+**WDS:**
+- "Build features that address psychological drivers"
+- Every feature traced to trigger map
+- Data-driven strategic decisions
+
+### 4. Complete Traceability
+
+**Other methodologies:**
+- "Why did we build this feature?" → "Someone asked for it"
+- Orphaned features with no clear purpose
+- "That's how we've always done it"
+
+**WDS:**
+- "Why did we build this feature?" → Shows complete chain:
+  - Feature → Driver → Persona → Business Goal
+- Every decision documented with reasoning
+- Strategic changes cascade correctly
+
+---
+
+## Your App Exists in Specifications
+
+**Let this sink in:**
+
+Your software doesn't exist in code.
+
+Your software exists in specifications.
+
+The code is just one possible projection—one compiled output—of your specifications.
+
+**When you need to:**
+- Rewrite in a different framework → Keep specs, generate new code
+- Add accessibility → Update specs, regenerate implementation
+- Support new language → Update specs, generate translations
+- Create documentation → Specs ARE the documentation
+- Onboard new developer → They read specs, not code archaeology
+
+**The specifications are the source of truth.**
+
+The code is the artifact you ship, but specifications are the asset you maintain.
+
+---
+
+## Key Takeaways
+
+✅ **Code is 10-20% of value** — Structured communication (specs) is 80-90%
+
+✅ **Specifications are the primary artifact** — Code is a lossy projection from specs
+
+✅ **Specs align humans on goals** — This alignment is the majority of the work
+
+✅ **Specs are meta-prompts** — Digital twin / blueprint for autonomous AI agents
+
+✅ **Specs enable dimensions code misses** — Testing, accessibility, i18n, SEO, maintenance
+
+✅ **Specs save credits and time** — Build once right vs. endless regeneration loop
+
+✅ **Specs can target multiple outputs** — TypeScript, Rust, docs, tests, tutorials (like compiler targets)
+
+✅ **Professional approach:** Prompt → Spec → Code — Amateur approach: Prompt → Code → Debug hell
+
+✅ **WDS is AI-native** — Designed for human-AI collaboration from the ground up
+
+✅ **Spirit of BMad v6** — Guided conversation creates strategic artifacts, through designer lens
+
+✅ **Engineering is precise exploration** — Specs provide the precision, WDS provides the structure
+
+---
+
+## What's Next
+
+Now that you understand WHY specifications matter, the next lessons show you HOW to create them effectively with Freya.
+
+You'll learn:
+- How to outline scenarios (user journeys)
+- How to create conceptual sketches (visualize default states)
+- How to build storyboards (show transformations)
+- How to write detailed specifications (document every decision)
+
+**Armed with this philosophy, you're ready to design professionally.**
+
+---
+
+## Further Reading
+
+**Core framework (pure philosophy, no WDS-specific content):**
+→ [Model: Specifications as the New Code](../../models/specifications-as-the-new-code.md)
+
+**Original talk:**
+→ [The New Code — Sean Grove, OpenAI (YouTube)](https://www.youtube.com/watch?v=8rABwKRsec4)
+
+---
+
+**[Continue to Lesson 3: Meet Freya →](lesson-03-meet-freya.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-entering-design.md) | [Module Overview](module-07-design-phase-overview.md)
+
+*Part of Module 07: Design Phase*
diff --git a/docs/learn/module-07-design-phase/lesson-03-meet-freya.md b/docs/learn/module-07-design-phase/lesson-03-meet-freya.md
new file mode 100644
index 000000000..3e8bde55d
--- /dev/null
+++ b/docs/learn/module-07-design-phase/lesson-03-meet-freya.md
@@ -0,0 +1,201 @@
+# Module 07: Design Phase Introduction
+
+## Lesson 3: Meet Freya
+
+**Your UX design partner for the entire design workflow**
+
+---
+
+## Who is Freya?
+
+Freya is the WDS UX design agent. She guides you through every step of the design workflow — from outlining scenarios to creating complete conceptual specifications, from sketching to design systems.
+
+If Saga helped you think strategically about **what** to build and **why**, Freya helps you figure out **how** it should work and **what it should feel like**.
+
+**Freya's role in WDS:**
+
+| Phase | What Freya Does | Modules |
+|-------|----------------|---------|
+| Outline Scenarios | Translates trigger maps into user journeys | 08 |
+| Conceptual Sketching | Guides visualization of key moments | 09 |
+| Storyboarding | Structures the flow of each scenario | 10 |
+| Conceptual Specifications | Creates detailed specs from storyboards | 11 |
+| Functional Components | Identifies patterns across specifications | 12 |
+| Design System | Establishes the mode for your project | 13 |
+| Visual Design | Applies visual language to specifications | 15 |
+| Design Delivery | Packages specifications for handoff | 16 |
+
+That's **eight modules** of design work. Freya is your constant companion through all of it.
+
+✅ **Checkpoint:** You understand that Freya leads the design workflow (Modules 08-13, 15-16)
+
+---
+
+## The WHY Before WHAT Methodology
+
+Freya's core principle is simple:
+
+> **Every design decision connects to strategy. Never design in a vacuum.**
+
+Before Freya designs anything — a button, a page, a flow — she asks:
+
+1. **WHY** does this need to exist? (Which business goal does it serve?)
+2. **WHO** is this for? (Which target group, at what awareness stage?)
+3. **WHAT** driving forces are at play? (What motivates or worries the user?)
+
+Only after answering these questions does Freya move to **HOW** it should work.
+
+**Example — Dog Week onboarding:**
+
+A traditional designer might start with: *"Let's design the registration page."*
+
+Freya starts differently:
+
+- **WHY:** Business goal BG01 is "5,000 active teams in year one." Registration is the gateway.
+- **WHO:** Dog owners who are "Problem Aware" — they know they want to connect with other dog people but haven't found the right platform yet.
+- **WHAT:** Positive driver: "I want to find my tribe." Negative driver: "I don't want another app that wastes my time."
+- **HOW:** Registration must feel instant, personal, and immediately rewarding. The user should feel they've found their people within 30 seconds.
+
+Now you're not designing a form. You're designing a **first impression that triggers belonging**.
+
+✅ **Checkpoint:** You understand WHY before WHAT — every design decision traces back to strategy
+
+---
+
+## How Freya Works With You
+
+Freya doesn't design **for** you — she designs **with** you. Think of it as a collaboration where you each bring something essential:
+
+**What you bring:**
+- User empathy and intuition
+- Creative vision
+- Domain knowledge
+- Aesthetic judgment
+
+**What Freya brings:**
+- Structural thinking and methodology
+- Connection to strategic documents (Product Brief, Trigger Map)
+- Consistency checking across scenarios
+- Specification writing discipline
+
+### The Collaboration Flow
+
+In practice, working with Freya follows a pattern:
+
+1. **You share context** — "Here's my Trigger Map and the scenario I want to design"
+2. **Freya loads strategy** — She reads your Product Brief, Trigger Map, and any existing specs
+3. **You explore together** — She asks questions, you make decisions, she structures them
+4. **She produces specifications** — Detailed, buildable documents that capture your design decisions
+5. **You review and refine** — Your judgment drives the final result
+
+### Starting a Session with Freya
+
+When you begin working with Freya on a design task, she'll typically want to know:
+
+- Which scenario are you working on?
+- What strategic documents exist? (Product Brief, Trigger Map, Platform Requirements)
+- What have you already sketched or decided?
+- Are there constraints from Platform Requirements?
+
+**Pro tip:** The more strategic context you give Freya upfront, the better her suggestions will be. If you share your Trigger Map, she can proactively suggest scenarios and design approaches you might not have considered.
+
+✅ **Checkpoint:** You understand the collaboration model — your creativity + Freya's structure
+
+---
+
+## Freya's Design Workflow
+
+Here's how Freya approaches each stage of the design workflow:
+
+### Stage 1: Outline Scenarios (Module 08)
+
+Freya takes your Trigger Map and asks: *"What are the key journeys that connect business goals to user satisfaction?"*
+
+She helps you define **sunshine scenarios** — the shortest path from current state to desired state, for both the user and the business.
+
+### Stage 2: Conceptual Sketching (Module 09)
+
+Before any detailed specification, Freya encourages **hand sketching**. Quick, rough, exploratory. The goal is to visualize the key moments in each scenario without getting locked into details.
+
+### Stage 3: Storyboarding (Module 10)
+
+Freya helps you arrange your sketches into a **linear storyboard** — a frame-by-frame sequence showing how the user moves through the scenario. Each frame captures a transformation.
+
+### Stage 4: Conceptual Specifications (Module 11)
+
+This is where Freya truly shines. She transforms your storyboards into **detailed specifications** — section by section, widget by widget, element by element. Every specification connects back to the strategic WHY.
+
+### Stage 5: Components & System (Modules 12-13)
+
+As specifications accumulate, Freya identifies **patterns** — elements that appear across multiple specifications become functional components. These components form the foundation of your design system.
+
+### Stage 6: Visual Design & Delivery (Modules 15-16)
+
+Finally, Freya helps apply visual language to your specifications and packages everything for handoff — whether to developers, AI coding agents, or your own implementation work.
+
+✅ **Checkpoint:** You understand Freya's six-stage design workflow
+
+---
+
+## When to Engage Freya
+
+**Start with Freya when:**
+- You've completed your Trigger Map (Module 06) and are ready to design
+- You want to translate strategy into concrete user experiences
+- You need to create or refine specifications
+
+**Don't start with Freya when:**
+- You haven't completed the strategic foundation yet (go back to Saga)
+- You want to write code (that's Idunn's domain)
+- You're still figuring out business goals or target groups
+
+### The Three Agents — Quick Reference
+
+| Agent | Domain | When to Use |
+|-------|--------|------------|
+| **Saga** | Strategy | Product Brief, Trigger Mapping, Platform Requirements |
+| **Freya** | Design | Scenarios, Sketching, Specifications, Components, Visual Design |
+| **Idunn** | Implementation | Prototyping, Development, Verification |
+
+Saga hands off to Freya. Freya hands off to Idunn. But the handoff isn't one-way — you'll often loop back to earlier stages as you learn from design and implementation.
+
+---
+
+## What Makes Freya Different
+
+Traditional design tools let you push pixels. Freya helps you **think through design decisions** and capture them as specifications that anyone (or any AI) can build from.
+
+**Traditional approach:**
+1. Open Figma
+2. Start placing rectangles
+3. Hope it works
+4. Redo when developers have questions
+
+**WDS approach with Freya:**
+1. Load strategic context
+2. Define the scenario and key transformations
+3. Sketch and storyboard the journey
+4. Write specifications that answer every question
+5. Build with confidence — the spec IS the design
+
+The specification Freya helps you create isn't documentation of a design. **It IS the design.** This is the fundamental shift you learned about in Lesson 2.
+
+---
+
+## Ready for Design
+
+You now have everything you need to begin the design workflow:
+
+- ✅ A Product Brief (your North Star)
+- ✅ A Trigger Map (your strategic compass)
+- ✅ Platform Requirements (your boundaries)
+- ✅ An understanding of why specifications matter
+- ✅ A design partner (Freya) ready to guide you
+
+**Next up:** Module 08, where you and Freya will outline your first scenarios — translating your Trigger Map into concrete user journeys.
+
+---
+
+[← Back to Lesson 2](lesson-02-why-specifications-matter.md) | [Module Overview](module-07-design-phase-overview.md) | [Next: Module 08 →](../module-08-outline-scenarios/module-08-outline-scenarios-overview.md)
+
+*Part of Module 07: Design Phase*
diff --git a/docs/learn/module-07-design-phase/module-07-design-phase-overview.md b/docs/learn/module-07-design-phase/module-07-design-phase-overview.md
new file mode 100644
index 000000000..0c7c10c57
--- /dev/null
+++ b/docs/learn/module-07-design-phase/module-07-design-phase-overview.md
@@ -0,0 +1,148 @@
+# Module 07: The Design Phase
+
+**Time: 20 min | Agent: Freya | Phase: Design | Focus: Overview**
+
+---
+
+## Welcome to the Heart of WDS
+
+You've completed Strategy. You have:
+- A Product Brief (your North Star)
+- Platform Requirements (your boundaries)
+- A Trigger Map (user psychology mapped)
+
+Now it's time to design.
+
+---
+
+## What This Phase Contains
+
+8 modules covering UX design and visual design. This is where creative discipline becomes real.
+
+| Module | What You'll Do | Focus |
+|--------|---------------|-------|
+| 08 | Outline Scenarios | UX |
+| 09 | Conceptual Sketching | UX |
+| 10 | Storyboarding | UX |
+| 11 | Conceptual Specifications | UX |
+| 12 | Functional Components | UX |
+| 13 | Design System | Systems |
+| 14 | Agentic Development | Build |
+| 15 | Visual Design | Visual |
+| 16 | Design Delivery | Delivery |
+
+---
+
+## The Flow
+
+```
+Outline → Sketch → Storyboard → Specify → Components → Visual → System → Deliver
+```
+
+It's not strictly linear. You'll loop back. That's the point.
+
+---
+
+## Meet Freya
+
+Freya is your design partner. She:
+
+- Thinks WITH you, not FOR you
+- Asks "WHY?" before "WHAT?"
+- Connects every decision to your Trigger Map
+- Won't let you skip the hard thinking
+
+She's not here to make pretty pictures. She's here to make **decisions visible**.
+
+---
+
+## Multiple Entry Points
+
+Every step offers choices:
+
+| Entry Point | How It Works |
+|-------------|--------------|
+| **I have a sketch** | You provide, AI refines |
+| **I have inspiration** | You share, AI extracts patterns |
+| **Dream it up** | AI creates options, you pick |
+| **Let's discuss** | Conversation shapes the concept |
+
+**Same step. Same output. Different starting points.**
+
+---
+
+## Creative Discipline in Action
+
+> "Creative discipline enables creativity, not constrains it."
+
+Each module is a discrete step with:
+- Clear input (what you need to start)
+- Clear output (what you'll produce)
+- Clear purpose (why it matters)
+
+This structure doesn't limit you. It focuses you.
+
+---
+
+## What You'll Create
+
+By the end of this phase:
+
+- **Scenario outlines** — The journeys you're designing
+- **Conceptual sketches** — Visual explorations
+- **Storyboards** — Sequenced flows
+- **Detailed specifications** — Every decision documented
+- **Component definitions** — Reusable patterns
+- **Visual designs** — How it actually looks
+- **Design system** — Your component library (if enabled)
+- **Delivery package** — Ready for implementation
+
+---
+
+## Design System
+
+Remember from setup:
+
+| Mode | What Happens |
+|------|--------------|
+| **1. None** | Ad-hoc styling, no extraction |
+| **2. Building** | System grows from your work |
+| **3. Library** | Use external + your branding |
+| **4. Existing** | Import from previous projects |
+
+This affects how Freya works with you throughout the phase.
+
+---
+
+## The Principle
+
+Every pixel has a reason.
+Every interaction traces back to user psychology.
+Every component connects to a business goal.
+
+**Nothing is decoration. Everything is decision.**
+
+---
+
+## Lessons
+
+### [Lesson 1: Entering Design Mode](lesson-01-entering-design.md)
+The transition from strategy to creation
+
+### [Lesson 2: Why Specifications Matter](lesson-02-why-specifications-matter.md)
+The New Code: Specifications as the Foundation of Professional AI-Assisted Development
+
+### [Lesson 3: Meet Freya](lesson-03-meet-freya.md)
+Your UX design partner
+
+---
+
+## Ready?
+
+**[Module 08: Outline Scenarios →](../module-08-outline-scenarios/module-08-outline-scenarios-overview.md)**
+
+Let's start designing.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-08-outline-scenarios/lesson-01-design-experiences-not-screens.md b/docs/learn/module-08-outline-scenarios/lesson-01-design-experiences-not-screens.md
new file mode 100644
index 000000000..7d9d04f25
--- /dev/null
+++ b/docs/learn/module-08-outline-scenarios/lesson-01-design-experiences-not-screens.md
@@ -0,0 +1,559 @@
+# Module 08: Outline Scenarios
+
+## Lesson 1: Scenarios, Not Pages
+
+**Why linear journeys matter more than isolated screens**
+
+---
+
+## The Page Trap
+
+Here's how most design projects start:
+
+> "We need a login page."
+> "Let's design the dashboard."
+> "What should the settings screen look like?"
+
+Pages. Screens. Static views.
+
+And here's what happens: You design a beautiful login page. Perfect layout. Clear hierarchy. Polished UI.
+
+But you've answered the wrong question.
+
+---
+
+## The Right Question
+
+A button doesn't exist in isolation. A form doesn't float in space.
+
+**Every element exists in a journey.**
+
+Where did the user come from?
+What are they trying to accomplish?
+What happens after they succeed?
+What if something goes wrong?
+
+**Scenarios answer these questions. Pages don't.**
+
+---
+
+## What Is a Scenario?
+
+A scenario is a **linear journey across logical views**.
+
+Not a page. Not a screen. A *journey*.
+
+```
+┌─────────────┐    Click CTA    ┌─────────────┐    Submit    ┌─────────────┐
+│   Landing   │ ──────────────► │   Signup    │ ───────────► │   Welcome   │
+│    Page     │                 │    Form     │              │   Screen    │
+└─────────────┘                 └─────────────┘              └─────────────┘
+     START                                                        END
+```
+
+Each box is a **logical view**. Each arrow is a **navigation event**.
+
+The scenario is the whole path — start to finish.
+
+---
+
+## Why Linear?
+
+WDS forces linear scenarios. No branching. No decision trees.
+
+This seems limiting. It's actually liberating.
+
+**Both approaches handle the same artifacts. The critical difference: separation vs integration of flow and design.**
+
+---
+
+### Traditional Flowchart Approach: Flow Divorced from Experience
+
+**Two separate artifacts that must be mentally reconciled:**
+
+```
+ABSTRACT FLOWCHART                              FIGMA PAGES (separate file)
+(no visual design)                              (no flow context)
+
+                                                ┌──────────────────┐
+                    ┌─► Password Reset ──┐      │  LOGIN PAGE      │
+                    │                    │      │  [Designed       │
+                    │  ┌─► Error Screen ─┤      │   in isolation]  │
+                    │  │                 │      │                  │
+Landing ─► Login ──┼──┼─► Signup Form ──┼──    │  • Email field   │
+                    │  │                 │      │  • Password      │
+                    │  └─► Login Form ───┤      │  • Submit btn    │
+                    │                    │      └──────────────────┘
+                    └─► Forgot Password ─┘      ┌──────────────────┐
+                                                │  SIGNUP PAGE     │
+No visual design,                               │  [Somewhere else │
+just abstract boxes                             │   in file]       │
+and arrows                                      │                  │
+                                                │  • Name field    │
+                                                │  • Email field   │
+                                                │  • Password      │
+                                                └──────────────────┘
+                                                ┌──────────────────┐
+                                                │  ERROR PAGE      │
+                                                │  [Loosely        │
+                                                │   hanging]       │
+                                                │                  │
+                                                │  • Error msg     │
+                                                │  • Retry btn     │
+                                                └──────────────────┘
+                                                ┌──────────────────┐
+                                                │  PASSWORD RESET  │
+                                                │  [Another screen │
+                                                │   in stack]      │
+                                                └──────────────────┘
+                                                ┌──────────────────┐
+                                                │  WELCOME PAGE    │
+                                                │  [Disconnected]  │
+                                                └──────────────────┘
+```
+
+**The fundamental problem — mystical complexity:**
+
+This creates **two artifacts that don't clearly map to each other:**
+
+- **Flowchart is abstract** (boxes and arrows, no actual design)
+- **Pages exist separately** as a disconnected stack in Figma
+- **No visual connection** between flowchart and screens
+- **Flow and design are divorced** - two separate artifacts to keep in sync
+- When reviewing flowchart: Can't see what screens actually look like
+- When reviewing pages: Can't see how they connect or which paths lead where
+- Requires mental gymnastics: "This Login box in the flowchart corresponds to... which Figma frame?"
+
+**As complexity grows:**
+- Every branch multiplies disconnection
+- Documentation sprawls across two systems
+- Testing becomes a nightmare (which path corresponds to which design?)
+- Changes require updating both artifacts independently
+- Easy for flow and design to drift out of sync
+
+---
+
+### WDS Approach: The Pages ARE the Flowchart
+
+**In WDS, there is no separate flowchart. The scenario IS the visual flow.**
+
+#### 1. Linear Scenario = Screen Sketches Arranged in Flow
+
+```
+SCENARIO S01-USER-SIGNUP (Sunshine Path with Storyboards)
+
+┌────────────────────┐       ┌────────────────────┐       ┌────────────────────┐
+│                    │  CTA  │                    │Submit │                    │
+│  [SKETCH 1]        │──────>│  [SKETCH 2]        │──────>│  [SKETCH 3]        │
+│  Landing Page      │ Click │  Signup Form       │       │  Welcome Screen    │
+│                    │       │                    │       │                    │
+│  • Hero image      │       │  • Email field     │       │  • Success message │
+│  • Value prop      │       │  • Password field  │       │  • Next steps      │
+│  • "Sign Up" CTA   │       │  • Name field      │       │  • Dashboard link  │
+│                    │       │  • Submit button   │       │                    │
+└────────────────────┘       └────────────────────┘       └────────────────────┘
+         │                            │                            │
+         │ Storyboard:                │ Storyboard:                │ Storyboard:
+         ▼                            ▼                            ▼
+  ○ Default state              ○ Empty (default)            ○ With confetti
+  ○ Hover on CTA               ○ Typing (validation)        ○ Without animation
+  ○ Mobile view                ○ Invalid (errors shown)
+                               ○ Valid (ready to submit)
+                               ○ Submitting (loading)
+                               ○ Network error (retry)
+```
+
+**The scenario IS visual with integrated storyboards:**
+- Top boxes = actual sketches of screens in sunshine path flow
+- Arrows = user navigation between screens
+- Underneath each sketch = storyboard states for that screen
+- **The flow, design, and state variations are one integrated artifact**
+
+**What this captures:**
+- ✓ Main navigation flow (view to view, horizontal arrows)
+- ✓ Visual representation of each screen (actual sketches)
+- ✓ State transformations within each screen (bullets underneath)
+- ✓ The sunshine path (when everything works)
+- ✓ User journey from start to desired state
+
+**What it deliberately excludes:**
+- ✗ Edge cases and business rules (that's specifications)
+- ✗ Alternative navigation paths (that's separate scenarios)
+
+**Note on storyboards:** This diagram shows storyboards integrated into scenarios as a preview of the complete artifact. You'll learn to create detailed storyboards in **Module 10: Storyboarding**. For now in Module 08, you're focusing on scenario outlines (the linear flow between screens) without detailed storyboard documentation.
+
+---
+
+#### 3. Specifications = Business Rules & Edge Cases (Text Document)
+
+```
+Edge Cases:
+- Email already exists → Show error in storyboard state 6, offer login link
+- Network failure → Show retry in storyboard state 6 with exponential backoff
+- Password too weak → Show requirements in storyboard state 3
+- User already logged in → Redirect to dashboard (before scenario starts)
+- Invalid email format → Real-time validation in storyboard state 3
+
+Alternative Paths:
+- Login instead of signup → See Scenario S02-User-Login
+- Password reset → See Scenario S03-Password-Recovery
+- Social signup → See Scenario S04-Social-Auth
+
+Business Rules:
+- Minimum password length: 8 characters
+- Required fields: email, password, name
+- Auto-login after successful signup
+```
+
+**What this captures:**
+- ✓ Error states and recovery flows (references storyboard states)
+- ✓ Alternative paths and branches (links to other scenarios)
+- ✓ Business rules and validation logic
+- ✓ Complete documentation without cluttering visual flow
+
+---
+
+### The Critical Difference
+
+| Traditional Approach | WDS Approach |
+|---------------------|--------------|
+| **Flowchart** = Abstract boxes and arrows | **Scenario** = Actual screen sketches in flow |
+| **Pages** = Separate, disconnected Figma files | **Pages** = Integrated into scenario flow |
+| Two artifacts to maintain | One integrated visual artifact |
+| Flow divorced from design | **The pages ARE the flowchart** |
+| Can't see experience in flowchart | Can see and experience the journey |
+| Can't see flow in Figma pages | Flow is explicit in scenario layout |
+| Designer reviews boxes, PM reviews pages (separately) | Everyone reviews the same visual journey |
+
+**The WDS insight:**
+
+> **In WDS, the pages ARE the flowchart.**
+
+There is no abstract diagram. The scenario is a visual arrangement of actual screen sketches showing the journey.
+
+**What this means in practice:**
+
+When you create a scenario in WDS:
+1. You sketch the screens (rough, conceptual)
+2. You arrange them in linear flow (sunshine path)
+3. **That arrangement IS your flowchart**
+4. Flow and design are integrated from the start
+
+When stakeholders review:
+- They see the actual journey visually
+- They understand the flow by looking at real screens
+- No translation needed between abstract boxes and actual design
+- Everyone sees the same integrated artifact
+
+**Traditional split:**
+```
+Product Manager reviews: [Abstract flowchart]
+Designer reviews: [Disconnected Figma pages]
+Developer receives: Both (and has to reconcile them)
+```
+
+**WDS integration:**
+```
+Everyone reviews: [Scenario = sketched screens in flow]
+Everyone sees: The actual visual journey
+No reconciliation needed: Flow and design are one
+```
+
+- **Scenario (top)** = Screen sketches arranged in sunshine path flow
+- **Storyboards (beneath)** = State variation sketches for each screen
+- **Specifications (separate doc)** = Business rules and edge cases in text
+
+**Why linear scenarios work:**
+
+- Focus attention on what matters (sunshine path first)
+- Force clear priority decisions (one main flow)
+- Make testing straightforward (follow the linear path)
+- Keep documentation manageable (complexity in storyboards, not flow)
+
+---
+
+## The Sunshine Scenario
+
+A scenario is the **shortest path** from current state to desired state — for both user and business.
+
+| Who | Current State | Desired State |
+|-----|---------------|---------------|
+| **User** | Wants to sign up | Has an account, feels welcomed |
+| **Business** | Visitor on site | Registered user in funnel |
+
+Both must be satisfied. That's what makes software sustainable.
+
+**Not just user value.** Not just business value. Both, together.
+
+---
+
+## What About Edge Cases?
+
+They exist. They matter. But they're not the scenario.
+
+**The WDS approach:**
+- **Scenario** captures the main flow (sunshine path)
+- **Specifications** document edge cases and error states
+- **Storyboarding** shows how alternatives transform within views
+
+**Scenario (main flow):**
+```
+User creates account successfully → Welcome screen
+```
+
+**Edge cases (documented in specifications):**
+- Email already exists → Show error message
+- Network failure → Show retry option
+- Invalid email format → Show validation error
+
+**Transformations (shown in storyboarding):**
+- Submit button: default → loading → success/error states
+- Form validation: empty → invalid → valid
+- Error messages: appear/disappear based on state
+
+The scenario is the sunshine path. Specifications and storyboarding handle the alternatives — but separately, so the scenario stays clean and focused.
+
+---
+
+## Selective Ignorance
+
+**During the design phase, you cannot focus on everything at once.**
+
+If you try to figure out all the things that could go wrong on every step and how to handle them, you would make no progress in designing the experience.
+
+### The Squeaky Wheel Problem
+
+**The problem:** The squeaky wheel gets the grease.
+
+When you're focused on fixing the very annoying edge cases, you lose track of the whole picture. Edge cases scream for attention because they're frustrating when they happen. But that emotional urgency doesn't mean they're strategically important.
+
+**If you chase every squeaky wheel, you end up with:**
+- 100 buttons trying to handle every edge case
+- Cluttered interfaces designed around exceptions
+- Lost sight of the core experience
+- Perfect handling of rare cases, broken handling of common ones
+
+WDS applies **selective ignorance** strategically: Focus on what gives the best experience and value to the business for the vast majority of the most valuable customers in the most valuable transactions.
+
+### The Strategic Progression
+
+**1. Main Flow First**
+- Design the most effortless journey when all is great and nothing goes wrong
+- Focus on the sunshine path where everything works perfectly
+- Get this right before anything else
+
+**2. Pressure Test with Obvious Variations**
+- When you're happy with the main flow, test it with obvious variations
+- Does it still stand? Does the structure hold?
+- If yes, proceed. If no, refine the main flow.
+
+**3. Introduce Edge Cases**
+- Now bring in edge cases and error states
+- Design for graceful failure
+- The system should fail elegantly, not catastrophically
+
+**4. The Ultimate Goal**
+> "The user should be able to use it wrong and it should be right anyway."
+
+### The Tradeoff
+
+| | What Happens |
+|---|---|
+| **Upside** | More space and attention for what matters. Clean, focused designs. Progress on the core experience. |
+| **Downside** | You may redraw as secondary cases pile up. |
+
+Worth it. The alternative is unbearable.
+
+**If you start with intricate navigation schemes and try to handle every edge case upfront, you end up with 100 buttons on the screen and make no progress on the core experience. Nobody wins.**
+
+Selective ignorance is not laziness — it's strategic focus.
+
+### Ask "What If" Questions
+
+**Selective ignorance also means asking whether steps should exist at all.**
+
+As a Linchpin designer, you ask the "what if" questions:
+
+> "We need to log in."
+
+**What if** we didn't require login upfront?
+
+- What if users arrived from email with magic links?
+- What if users could browse freely?
+- What if login was only required for sensitive data or changes?
+
+**Be the kid pointing out the emperor has no clothes.**
+
+Ask "what if" over and over until the scenario shrinks:
+- 8 steps → What if we combined these?
+- 4 steps → What if we skipped this entirely?
+- 2 steps → Now we have the essential journey
+
+**Every step in a scenario should justify its existence.**
+
+If you can't defend why a step is necessary, remove it. The best scenarios aren't the most complete — they're the most essential.
+
+---
+
+## Logical Views
+
+A logical view is a distinct screen state in your application.
+
+| Is a Logical View | Is NOT a Logical View |
+|-------------------|----------------------|
+| A page | A button state |
+| A modal overlay | A loading spinner |
+| A wizard step | A hover effect |
+| A full-screen confirmation | A toast notification |
+
+**When the user navigates** from one logical view to another — that's a scenario.
+
+**When elements transform** within a single logical view — that's a storyboard (Module 10).
+
+---
+
+## Connecting to Triggers
+
+Every scenario should trace back to your Trigger Map.
+
+| Scenario Element | Trigger Map Connection |
+|------------------|----------------------|
+| Who is doing this? | Which persona |
+| Why are they here? | Which driving force |
+| What's the goal? | Which business goal |
+| What feature enables it? | Which feature from the map |
+
+If you can't connect a scenario to your Trigger Map, question whether it should exist.
+
+---
+
+## Dual Value Check
+
+For every scenario, verify:
+
+**User value:**
+> "Does completing this satisfy the user's goal?"
+
+If the user completes this journey, do they get what they wanted?
+
+**Business value:**
+> "Does completing this advance a business objective?"
+
+If users complete this journey, does it help the business?
+
+**If either is missing, the scenario isn't sustainable.**
+
+A scenario that only serves users (no business value) won't get funded.
+A scenario that only serves business (no user value) won't get used.
+
+---
+
+## Naming Scenarios
+
+```
+01-felixs-quick-registration
+02-harriets-family-setup
+03-kids-daily-overview
+```
+
+The number indicates priority order. The name includes the **persona** and their **purpose**.
+
+**Good names:**
+- 01-felixs-quick-registration
+- 02-harriets-family-setup
+- 03-kids-daily-overview
+
+**Bad names:**
+- login-page
+- dashboard
+- settings
+
+Pages are not scenarios. Journeys are.
+
+---
+
+## How Many Scenarios?
+
+Depends on your product:
+
+| Product Type | Typical Scenarios |
+|--------------|-------------------|
+| Simple landing page | 2-3 |
+| Web application | 8-15 |
+| Complex platform | 20+ |
+
+Start with the core user journeys. Add more as needed.
+
+**Rule of thumb:** Each persona + primary goal = one scenario.
+
+If you have 3 personas with 3 primary goals each, you might have 9 scenarios.
+
+---
+
+## The Scenario's Purpose
+
+A scenario outline is NOT a detailed specification.
+
+It's a **roadmap** that tells you:
+
+1. Where the journey starts
+2. What logical views the user passes through
+3. Where the journey ends
+4. Why it matters (user + business value)
+
+The detailed work (how each view looks, what happens in each step) comes in later modules.
+
+---
+
+## What You'll Create
+
+For each scenario, Freya's 8-question dialog produces:
+
+```markdown
+# 01: Felix's Quick Registration
+
+## Transaction (Q1)
+Create account and experience first success
+
+## Business Goal (Q2)
+BG01 - Increase trial signups by 40%
+
+## User & Situation (Q3)
+Felix (Primary) — Full-stack parent, evening, skeptical but motivated
+
+## Driving Forces (Q4)
+Hope: Find a simple app the family will use
+Worry: Complex onboarding that wastes time
+
+## Device & Starting Point (Q5 + Q6)
+Mobile — Googles "family dog care app", clicks top result
+
+## Best Outcome (Q7)
+User: Account created, feels confident
+Business: New user in activation funnel
+
+## Shortest Path (Q8)
+1. **Landing Page** — Sees value, clicks "Start Free"
+2. **Signup Form** — Enters credentials
+3. **Welcome Screen** — Greeted, ready to explore ✓
+```
+
+Simple. Clear. Connected to strategy through every question.
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn how to map logical views within scenarios and understand the relationship between scenarios and storyboards.
+
+Then in the tutorial, you'll create scenario outlines for your own project with Freya's guidance.
+
+---
+
+**[Continue to Lesson 2: From Trigger Map to Scenarios →](lesson-02-from-trigger-map-to-scenarios.md)**
+
+---
+
+[← Back to Module Overview](module-08-outline-scenarios-overview.md)
+
+*Part of Module 08: Outline Scenarios*
diff --git a/docs/learn/module-08-outline-scenarios/lesson-02-from-trigger-map-to-scenarios.md b/docs/learn/module-08-outline-scenarios/lesson-02-from-trigger-map-to-scenarios.md
new file mode 100644
index 000000000..4f38be442
--- /dev/null
+++ b/docs/learn/module-08-outline-scenarios/lesson-02-from-trigger-map-to-scenarios.md
@@ -0,0 +1,667 @@
+# Module 08: Outline Scenarios
+
+## Lesson 2: From Trigger Map to Scenarios
+
+**How to identify which scenarios to create from your Trigger Map**
+
+---
+
+## The Missing Bridge
+
+You've completed your Trigger Map (Module 06):
+- Personas with driving forces
+- Business goals prioritized
+- Features connected to both
+
+Now you're in Module 08: Outline Scenarios.
+
+**But which scenarios should you create?**
+
+This lesson bridges the gap. It shows you how to use your prioritized Trigger Map to identify the scenarios that matter most.
+
+---
+
+## Strategic Context from the Trigger Map
+
+Every scenario needs **strategic context** — the thread connecting business goals to user motivations through specific transactions, selected from your Trigger Map.
+
+```
+Business Goal → User Group → Driving Forces → Transaction → Scenario
+```
+
+**Example:**
+
+```
+BG01: 5,000 active teams
+    ↓
+Remote Team Leads (Persona: Harriet)
+    ↓
+Fear of burnout, desire for team awareness
+    ↓
+Create first pulse check
+    ↓
+S01-First-Pulse-Check-Setup
+```
+
+**The strategic context answers:**
+- What's the most valuable transaction for our business?
+- What are we offering that's valuable for the end user?
+- How can we create a marriage between business goals and user driving forces?
+- What would make both the business and the user happy?
+
+**The scenario is the shortest path to make everyone happy.**
+
+---
+
+## The Marriage Question
+
+For each potential scenario, ask:
+
+**"What transaction would satisfy both this business goal AND this user's driving forces?"**
+
+This is the marriage between business value and user value.
+
+| Business Wants | User Wants | Transaction (Scenario) |
+|----------------|------------|----------------------|
+| 5,000 active teams | Quick team health check | First pulse check setup |
+| Reduce churn | Avoid burnout | Schedule automated check-ins |
+| Increase engagement | Team feels heard | Share pulse results with team |
+| Premium subscriptions | Advanced insights | Unlock trend analysis |
+
+**Each row is a potential scenario.**
+
+The ones at the top (aligned with your highest-priority business goals and persona driving forces) become your first scenarios to design.
+
+---
+
+## Identifying Your First Scenarios
+
+Use your Trigger Map prioritization to identify scenarios:
+
+### Step 1: Start with Top Business Goal
+
+Look at your Product Brief. What's your #1 business goal?
+
+Example: **BG01 - Get 5,000 active teams using the product**
+
+### Step 2: Identify Most Important User Group
+
+Which persona is most critical to achieving this goal?
+
+Example: **Remote Team Leads (Harriet)**
+
+### Step 3: Connect to Top Driving Forces
+
+What are this persona's strongest driving forces from your Trigger Map?
+
+Example:
+- Fear of team burnout
+- Desire for team awareness without micromanaging
+- Need for quick, actionable insights
+
+### Step 4: Find the Valuable Transaction
+
+What can the user do in your product that:
+- Advances the business goal?
+- Satisfies the user's driving forces?
+
+Example: **Create and send first pulse check to team**
+
+This becomes: **S01-First-Pulse-Check**
+
+### Step 5: Repeat for Secondary Priorities
+
+Continue down your prioritized Trigger Map:
+- Next business goal
+- Next persona
+- Next driving force
+
+Each valuable transaction becomes a scenario.
+
+---
+
+## The Strategic Grounding (Q1-Q4)
+
+Before mapping any pages, Freya's 8-question dialog establishes the strategic grounding through the first four questions:
+
+### Q1: Transaction — What needs to happen?
+
+The specific thing the user needs to accomplish, stated as user purpose.
+
+```
+Transaction: Create and send first pulse check to team
+```
+
+### Q2: Business Goal — Why does the business care?
+
+Direct connection to your Trigger Map business goals.
+
+```
+Business Goal: BG01 - 5,000 active teams
+Objective: Drive trial-to-active conversion
+```
+
+### Q3: User & Situation — Who, where, when?
+
+The persona AND their real-life context — not just a name but a vivid picture.
+
+```
+Harriet (Primary) — Remote team lead, Monday morning before weekly meeting.
+Motivated to try something that shows value quickly. Cautiously optimistic.
+```
+
+### Q4: Driving Forces — What do they hope and fear?
+
+Visceral, specific driving forces. One sentence each.
+
+```
+Hope: Quick visibility into team health without seeming like a micromanager
+Worry: Wasting time on another tool the team won't use
+```
+
+**These four answers connect the scenario to strategy.** Q5-Q8 then define the entry point, success criteria, and page flow.
+
+---
+
+## Complete Example: From Trigger Map to Scenario
+
+### Trigger Map (Module 06)
+
+**Business Goal:** BG01 - 5,000 active teams (Priority: High)
+
+**Persona:** Harriet the Hybrid Manager
+- Role: Remote team lead, 8-person team
+- Driving Forces:
+  - Fear: Team burnout goes unnoticed
+  - Desire: Team awareness without micromanaging
+  - Need: Quick actionable insights
+- Priority: High (critical user group)
+
+**Feature:** F05-Pulse-Checks
+- Connected to: BG01
+- Connected to: Harriet (fear of burnout)
+
+### Strategic Context (from Trigger Map)
+
+```
+BG01: 5,000 active teams
+    ↓
+Harriet (Remote Team Lead)
+    ↓
+Fear: Team burnout goes unnoticed
+Desire: Awareness without micromanaging
+    ↓
+Transaction: Create and send first pulse check
+    ↓
+S01-First-Pulse-Check
+```
+
+### The Marriage
+
+**Business wants:** 5,000 teams actively using the product
+
+**Harriet wants:** Quick way to check team health without being intrusive
+
+**Transaction that satisfies both:** Create simple pulse check, send to team, see results
+
+**This becomes:** S01-First-Pulse-Check
+
+### Scenario Outline (Q1-Q8 Format)
+
+```markdown
+# 01: Harriet's First Pulse Check
+
+## Transaction (Q1)
+Create and send first pulse check to team
+
+## Business Goal (Q2)
+BG01 - 5,000 active teams
+Objective: Drive trial-to-active conversion
+
+## User & Situation (Q3)
+Harriet (Primary) — Remote team lead, Monday morning before weekly meeting.
+Just set up her team account, motivated to try something that shows value quickly.
+
+## Driving Forces (Q4)
+Hope: Quick visibility into team health without seeming like a micromanager
+Worry: Wasting time on another tool the team won't use
+
+## Device & Starting Point (Q5 + Q6)
+Desktop — Auto-redirected after team creation to "Create Your First Pulse Check"
+
+## Best Outcome (Q7)
+User: Pulse check sent, feels proactive about team health
+Business: User activated core feature, team members receive first touchpoint
+
+## Shortest Path (Q8)
+1. **Welcome Screen** — Sees "Create First Pulse Check" prompt
+2. **Pulse Check Builder** — Chooses template, reviews questions
+3. **Select Recipients** — Picks team members
+4. **Confirmation** — Pulse check sent successfully ✓
+
+## Trigger Map Connections
+Persona: Harriet (Primary)
+Want: Team awareness without micromanaging
+Fear: Team burnout going unnoticed
+Business Goal: BG01 - 5,000 active teams
+```
+
+---
+
+## Prioritizing Multiple Scenarios
+
+You'll identify many potential scenarios. Prioritize using this hierarchy:
+
+### Priority 1: Critical Path Scenarios
+
+Scenarios directly connected to:
+- Highest-priority business goal
+- Most important persona
+- Core product value
+
+**Example:**
+- S01-First-Pulse-Check (activation)
+- S02-View-Results (value delivery)
+- S03-Team-Setup (prerequisite)
+
+Design these first. Everything else waits.
+
+### Priority 2: Supporting Scenarios
+
+Scenarios that support Priority 1:
+- Secondary personas using same features
+- Alternative paths to same goal
+- Enhancement scenarios
+
+**Example:**
+- S04-Recurring-Pulse (power user scenario)
+- S05-Export-Results (advanced usage)
+
+Design these after Priority 1 is validated.
+
+### Priority 3: Edge Case Scenarios
+
+Scenarios for less common situations:
+- Error recovery paths
+- Administrative tasks
+- Rare user segments
+
+**Example:**
+- S12-Password-Recovery
+- S15-Delete-Team
+
+Design these last, or defer to later iterations.
+
+---
+
+## The Shortest Path Principle
+
+> **"The scenario is the shortest path to make everyone happy."**
+
+When identifying scenarios from your Trigger Map:
+
+**Don't design everything.**
+
+Design the **shortest path** from:
+- User's current state → User's desired state (user happy)
+- Business's current state → Business's desired state (business happy)
+
+**Ask:**
+- What's the minimum number of steps?
+- What's the fastest path to mutual value?
+- What can we skip or defer?
+
+**Example:**
+
+**Bad (too long):**
+```
+Landing → Signup → Email Verify → Profile Setup → Team Creation →
+Invite Members → Wait for Accepts → Tutorial → Feature Tour → Dashboard →
+Finally Create Pulse Check
+```
+
+**Good (shortest path):**
+```
+Signup → Team Setup → First Pulse Check ✓
+```
+
+Everything else is optional or deferred to later scenarios.
+
+---
+
+## Multiple Entry Points
+
+Some scenarios have multiple natural starting points:
+
+**Example: S05-Add-Team-Member**
+
+```
+## Natural Starting Points
+
+1. From Dashboard → "Add Member" button (most common)
+2. From Team Settings → "Manage Members" → "Add"
+3. From Email → "You were added as admin" → "Invite your team"
+4. From Pulse Results → "Only 3/8 members responded" → "Invite missing members"
+```
+
+**Document all entry points**, but design for the most common one first.
+
+Alternative entry points get documented in specifications, not designed separately.
+
+---
+
+## From Features to Scenarios
+
+Your Trigger Map includes features. Scenarios implement those features.
+
+**Relationship:**
+
+| Trigger Map Feature | Scenarios That Implement It |
+|-------------------|---------------------------|
+| F05-Pulse-Checks | S01-First-Pulse-Check<br>S04-Recurring-Pulse<br>S07-Customize-Questions |
+| F08-Results-Dashboard | S02-View-Results<br>S05-Export-Results<br>S09-Share-With-Team |
+| F02-Team-Management | S03-Team-Setup<br>S06-Add-Member<br>S10-Remove-Member |
+
+**One feature → Multiple scenarios**
+
+Each scenario is a specific user journey through that feature.
+
+---
+
+## The Scenario Decision Matrix
+
+Use this to decide if a potential scenario should be designed:
+
+| Question | Must Answer |
+|----------|-------------|
+| **Does it connect to a business goal?** | Which one? |
+| **Does it serve a persona from your Trigger Map?** | Which persona? |
+| **Does it satisfy a driving force?** | Which force? |
+| **What's the valuable transaction?** | Be specific. |
+| **Where does the user come from?** | Natural starting point? |
+| **What value does the user get?** | Concrete outcome? |
+| **What value does the business get?** | Measurable result? |
+
+**If you can't answer all seven questions, it's not ready to be a scenario.**
+
+Go back to your Trigger Map and clarify.
+
+---
+
+## Common Patterns
+
+### Pattern 1: Onboarding Sequence
+
+Connected scenarios that form activation flow:
+
+```
+S01-Signup → S02-Team-Setup → S03-First-Pulse-Check → S04-View-Results
+```
+
+Each scenario hands off to the next. Natural starting point is previous scenario's end state.
+
+### Pattern 2: Core Feature Variations
+
+Same feature, different personas or situations:
+
+```
+F05-Pulse-Checks implemented as:
+- S03-First-Pulse-Check (new user, guided)
+- S08-Quick-Pulse (power user, shortcuts)
+- S12-Recurring-Pulse-Setup (advanced, automation)
+```
+
+Each serves different driving forces for different personas.
+
+### Pattern 3: Administrative Tasks
+
+Supporting scenarios that enable core scenarios:
+
+```
+Core: S03-First-Pulse-Check
+Supporting: S05-Add-Team-Member (so they have someone to send to)
+Supporting: S11-Update-Questions (so they can customize)
+```
+
+Design core first. Add supporting scenarios as needed.
+
+---
+
+## How Freya Suggests Scenarios
+
+Freya doesn't just help you create scenarios - she **proactively suggests them** by analyzing your Product Brief and Trigger Map.
+
+### What Freya Analyzes
+
+**From your Product Brief:**
+- Top business goals (ranked by priority)
+- Success metrics
+- Critical constraints
+
+**From your Trigger Map:**
+- Persona rankings (from Workshop 4)
+- Ranked driving forces per persona (top 5-7)
+- Feature-to-driver connections
+- Business goal alignments
+
+**Freya combines these to identify strategic context for scenarios automatically.**
+
+### Freya's Suggestion Process
+
+**Phase 1: Identify High-Value Chains**
+
+Freya looks for the strongest connections:
+
+```
+Priority #1 Business Goal
+    ↓ (which persona drives this?)
+Priority #1 Persona
+    ↓ (what's their top driver?)
+Top-Ranked Driving Force
+    ↓ (what transaction satisfies both?)
+Suggested Scenario
+```
+
+**Example:**
+
+```
+BG01: 5,000 active teams (Priority #1 from Brief)
+    ↓
+Remote Team Leads (Priority #1 from Workshop 4)
+    ↓
+Fear: Team burnout goes unnoticed (Top driver from Workshop 4)
+    ↓
+Transaction: Create first pulse check
+    ↓
+Freya suggests: S01-First-Pulse-Check
+```
+
+**Phase 2: Present Ranked Scenario Suggestions**
+
+Freya presents scenarios in priority order with strategic reasoning:
+
+> **Freya:** "Based on your Trigger Map, I've identified 8 potential scenarios. Here are the top 3 by strategic value:
+>
+> **S01-First-Pulse-Check** (Priority #1)
+> - Business Goal: BG01 - 5,000 active teams
+> - Persona: Remote Team Leads (your #1 priority group)
+> - Driver: Fear of team burnout (their #1 driver)
+> - Why this matters: Each team lead brings 5-10 team members. Solving their top fear drives activation and retention.
+> - Estimated impact: High (multiplier effect + urgent pain)
+>
+> **S02-View-Results** (Priority #2)
+> - Business Goal: BG01 - 5,000 active teams
+> - Persona: Remote Team Leads
+> - Driver: Desire for actionable insights (their #2 driver)
+> - Why this matters: Completes the value loop from S01. Without seeing results, pulse check has no value.
+> - Estimated impact: High (required for S01 to deliver value)
+>
+> **S03-Team-Setup** (Priority #3)
+> - Business Goal: BG01 - 5,000 active teams
+> - Persona: Remote Team Leads
+> - Driver: Want simple onboarding (their #4 driver)
+> - Why this matters: Prerequisite for S01. Must exist but isn't where the core value lives.
+> - Estimated impact: Medium (enabler, not value driver)
+>
+> Should we start with S01?"
+
+**Phase 3: Walk Through the 8-Question Dialog**
+
+Once you select a scenario, Freya walks you through 8 questions — one at a time:
+
+> **Freya:** "Let's outline Harriet's First Pulse Check. Q1: What transaction do we need to get really right for Harriet?"
+>
+> **You:** "Create and send her first pulse check to the team."
+>
+> **Freya:** "Q2: Which business goal does this serve?"
+>
+> **You:** "BG01 - getting 5,000 active teams."
+>
+> **Freya:** "Q3: Tell me about Harriet in this moment — who is she, where is she, what's happening?"
+>
+> **You:** "She just finished setting up her team. Monday morning before the weekly meeting. Cautiously optimistic but won't tolerate anything complicated."
+>
+> **Freya:** "Q4: What does she hope for and what does she fear?"
+
+Each answer shapes the next question naturally. By Q8, the scenario outline is complete.
+
+### How Freya Ranks Scenario Suggestions
+
+Freya scores potential scenarios using:
+
+**1. Strategic Alignment (40%)**
+- Connection to top business goal: 20%
+- Connection to priority persona: 10%
+- Connection to top-ranked driver: 10%
+
+**2. Impact Potential (30%)**
+- Multiplier effect (does it bring more users?)
+- Urgency of pain being solved
+- Measurable business outcome
+
+**3. Dependencies (20%)**
+- Is this a prerequisite for other scenarios?
+- Does it complete a value chain?
+- What's the activation sequence?
+
+**4. Scope Clarity (10%)**
+- Can we define clear start/end states?
+- Is the transaction well-bounded?
+- Linear path possible?
+
+**Freya shows her work:**
+
+> **Freya:** "I ranked S01-First-Pulse-Check as #1 because:
+> - ✓ Connects to your top business goal (BG01)
+> - ✓ Serves your priority #1 persona (Team Leads)
+> - ✓ Addresses their #1 driver (fear of burnout)
+> - ✓ High multiplier (each lead brings a team)
+> - ✓ Urgent pain (happening now)
+> - ✓ Clear transaction (create → send → done)
+>
+> S02 ranked #2 because it completes the value chain but doesn't initiate it. S03 ranked #3 because it's an enabler, not core value."
+
+### What Freya Needs From You
+
+Freya can answer Q1 and Q2 automatically from your Trigger Map. She needs your input for:
+
+**Q3: The real-life situation** — Only you know when and why this persona would actually use your product.
+
+**Q4: Visceral driving forces** — Freya can reference your Trigger Map, but you refine the hope and worry to be specific to this transaction.
+
+**Q6: How they actually arrive** — Only you know your marketing channels and discovery paths.
+
+**Q8: The page flow** — Only you know your product's structure and what screens exist.
+
+**Freya knows the "why" from your Trigger Map. You provide the "how" from your product knowledge.**
+
+### Collaborative Flow
+
+**Freya suggests → You validate → Together you detail**
+
+```
+Freya: "Your top 3 scenarios based on Trigger Map analysis..."
+You: "Yes, S01 makes sense. But S03 should come before S01 - they need a team first."
+Freya: "Good catch. Revising sequence: S03-Team-Setup, then S01-First-Pulse-Check."
+You: "Exactly."
+Freya: "Let's start with S03. How does a new user arrive at team setup?..."
+```
+
+**This is collaborative scenario identification**, not Freya dictating or you guessing.
+
+### Freya's Questions (After Suggestions)
+
+After suggesting scenarios, Freya asks clarifying questions:
+
+> "I suggested S01-First-Pulse-Check as priority #1. Does this align with your product vision?"
+
+> "Should S03-Team-Setup come before S01, or can they happen in parallel?"
+
+> "I see a gap: How does the user get from signup to team setup? Is that a separate scenario?"
+
+> "Looking at your top 3 suggested scenarios - do they form a complete activation flow, or are we missing steps?"
+
+> "Your Trigger Map has 3 priority personas. Should we create parallel scenarios for each, or focus on Remote Team Leads first?"
+
+**These questions refine the suggestions into a complete scenario roadmap.**
+
+---
+
+## Red Flags
+
+Watch out for these signs that a scenario isn't ready:
+
+❌ **"Users might want to..."** — Too vague, not connected to driving forces
+
+❌ **Can't identify which persona** — Scenario isn't grounded in strategy
+
+❌ **No clear business value** — Won't be sustainable
+
+❌ **No clear user value** — Won't be used
+
+❌ **Too many steps** — Not the shortest path
+
+❌ **Branches everywhere** — This is multiple scenarios, not one
+
+---
+
+## Practical Exercise
+
+**From your Trigger Map, answer the first 4 questions for your top scenario:**
+
+1. **Q1:** What transaction do we need to get right? (user purpose, not feature name)
+2. **Q2:** Which business goal does it serve?
+3. **Q3:** Which persona, in what real-life situation?
+4. **Q4:** What do they hope and fear?
+
+**Write it down:**
+
+```
+Q1 Transaction: [What the user needs to accomplish]
+Q2 Business Goal: [Which goal from your Trigger Map]
+Q3 User & Situation: [Persona name + vivid context]
+Q4 Hope: [One sentence]
+Q4 Worry: [One sentence]
+
+This becomes scenario: 01-[personas-purpose]
+```
+
+---
+
+## What's Next
+
+Now you know:
+- ✓ What scenarios are (Lesson 1)
+- ✓ How to identify which scenarios to create (Lesson 2)
+
+Next lesson: **The 8-question dialog** — how Freya walks you through Q1-Q8 to create a complete scenario outline.
+
+---
+
+**[Continue to Lesson 3: Mapping the Journey →](lesson-03-mapping-the-journey.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-design-experiences-not-screens.md) | [Back to Module Overview](module-08-outline-scenarios-overview.md)
+
+*Part of Module 08: Outline Scenarios*
diff --git a/docs/learn/module-08-outline-scenarios/lesson-03-mapping-the-journey.md b/docs/learn/module-08-outline-scenarios/lesson-03-mapping-the-journey.md
new file mode 100644
index 000000000..4f51677be
--- /dev/null
+++ b/docs/learn/module-08-outline-scenarios/lesson-03-mapping-the-journey.md
@@ -0,0 +1,347 @@
+# Module 08: Outline Scenarios
+
+## Lesson 3: Mapping the Journey
+
+**How to structure scenario outlines using the 8-question dialog**
+
+---
+
+## The 8-Question Dialog
+
+Every scenario outline is built through 8 strategic questions. Freya walks you through them one at a time — each answer shapes the next question naturally.
+
+| # | Question | What it captures |
+|---|----------|-----------------|
+| Q1 | What transaction do we need to get right? | User purpose |
+| Q2 | Which business goal does it serve? | Strategic connection |
+| Q3 | Which user, in what situation? | Persona + real-life context |
+| Q4 | What do they hope and fear? | Driving forces |
+| Q5 | What device? | Design approach |
+| Q6 | How do they arrive? | Entry point + discovery |
+| Q7 | Best outcome for both sides? | Success criteria |
+| Q8 | Shortest path through the site? | Linear page flow |
+
+When all 8 are answered, the scenario outline writes itself.
+
+---
+
+## Q1: "What transaction do we need to get really right?"
+
+Start with the WHY. What's the most important thing a user needs to accomplish?
+
+State as **user purpose**, not feature name.
+
+- **Bad:** "Homepage and service pages"
+- **Good:** "Verify service availability before booking"
+
+A **transaction** isn't just purchases. Browsing content page-by-page counts. Comparing options counts. Any meaningful journey where the user moves through the site with intent.
+
+---
+
+## Q2: "Which business goal does it serve?"
+
+Connect to your Trigger Map immediately. Which specific business goal and objective does this transaction advance?
+
+```
+Business Goal: BG01 - 5,000 active teams
+Objective: Drive trial-to-active conversion
+```
+
+This grounds the scenario in business strategy, not just user needs.
+
+---
+
+## Q3: "Which user experiences this most, and in what real-life situation?"
+
+Identify the persona AND their context. Not just "who" but "who, where, when."
+
+- **Bad:** "A customer looking for information"
+- **Good:** "Hasse, 55, motorhome tourist stranded in Byxelkrok with a broken vehicle during family vacation"
+
+Use actual personas from your Trigger Map. The situation should feel visceral and specific.
+
+---
+
+## Q4: "What do they hope and fear?"
+
+The driving forces — hope and worry. These must be visceral and specific.
+
+- **Hope:** What they're hoping to find or achieve
+- **Worry:** What they're afraid of or want to avoid
+
+**One sentence max per component.** Phrases, not paragraphs.
+
+- **Bad:** "User is interested in the product"
+- **Good:** Hope: "Find trustworthy mechanic nearby, get back on road today." Worry: "Being stranded for days, getting ripped off by unknown mechanic."
+
+---
+
+## Q5: "What device are they on?"
+
+Mobile, desktop, or tablet. This shapes the entire design approach.
+
+Simple question, but it matters — a panicked tourist on mobile needs a completely different experience than a manager at their desk.
+
+---
+
+## Q6: "How do they actually arrive?"
+
+How the user ACTUALLY gets to the site. Be specific about discovery method.
+
+- **Bad:** "User opens the website"
+- **Good:** "Googles 'car repair Öland' on mobile while parked at gas station, clicks top organic result"
+
+**1-2 sentences max.** Device + context + discovery method.
+
+---
+
+## Q7: "What does the best possible outcome look like — for both sides?"
+
+Mutual success — user AND business. Both specific and measurable.
+
+- **User Success:** Tangible outcome the user achieves
+- **Business Success:** Measurable result for the business
+
+- **Bad:** User: "Successfully use the site" / Business: "Get more customers"
+- **Good:** User: "Confirmed mechanic fixes motorhomes, has location and hours, feels confident calling" / Business: "High-intent tourist call captured, positioned as emergency-capable, info call avoided"
+
+---
+
+## Q8: "What's the shortest path through the site?"
+
+The linear sunshine path. Numbered steps, each with page name + what the user accomplishes.
+
+**Rules:**
+- Completely linear — ZERO "if" statements, ZERO branches
+- Minimum viable steps — can you remove any without breaking the flow?
+- Each step moves meaningfully toward success
+
+```
+1. **Start Page** — Sees hero with emergency message, clicks "Vehicle Service"
+2. **Service Page** — Confirms motorhome service available, sees phone number
+3. **Contact Page** — Gets address, hours, and map directions ✓
+```
+
+---
+
+## After the 8 Questions
+
+### Name the Scenario
+
+Use the persona name + purpose:
+
+```
+01: Hasse's Emergency Search
+02: Harriet's Family Setup
+03: Felix's Quick Registration
+```
+
+The number indicates priority order. The name tells you who and what.
+
+### Trigger Map Connections
+
+Explicitly link back to your strategic foundation:
+
+```
+## Trigger Map Connections
+Persona: Hasse (Primary)
+Want: Find trustworthy mechanic nearby
+Fear: Being stranded, getting ripped off
+Business Goal: BG01 - Capture high-intent service calls
+```
+
+### Pages Table
+
+List the pages that will be designed:
+
+```
+| Page | Folder | Purpose | Exit Action |
+|------|--------|---------|-------------|
+| 1.1 | 1.1-start-page/ | See value, find service | Click "Vehicle Service" |
+| 1.2 | 1.2-service-page/ | Confirm capability | Click "Contact" |
+| 1.3 | 1.3-contact-page/ | Get address + hours | Call or navigate ✓ |
+```
+
+---
+
+## Scenario vs. Storyboard Boundary
+
+This is crucial to understand:
+
+**Scenario = Journey between logical views**
+```
+Start Page → Service Page → Contact Page
+```
+
+**Storyboard = Transformations within a logical view**
+```
+Service Page: Loading → Content visible → Phone number copied
+```
+
+| Question | Answer |
+|----------|--------|
+| User clicks button and new screen loads | Scenario |
+| Button changes from "Submit" to "Loading..." | Storyboard |
+| Modal opens on top of current page | Scenario (modal is new logical view) |
+| Form field shows validation error | Storyboard |
+
+---
+
+## Edge Cases: Where Do They Go?
+
+Edge cases are real. They need documentation. But not in the scenario outline.
+
+**In scenario outline (Q8):**
+```
+1. **Signup Form** — Enters email and password
+2. **Welcome Screen** — Greeted, ready to explore ✓
+```
+
+**In page specification (Module 11):**
+```
+## Error States
+
+### Email Already Exists
+- Message: "This email is already registered. [Log in instead]"
+- User action: Click link to login flow
+
+### Network Error
+- Message: "Connection lost. Your data is saved. [Retry]"
+- User action: Click retry to resubmit
+```
+
+The scenario outline is the sunshine path. Page specifications handle the shadows.
+
+**Module progression:**
+- **Module 08** (now): Outline scenarios — 8-question dialog defines the journey
+- **Module 09**: Conceptual sketching — visualize each screen's default state
+- **Module 10**: Storyboarding — document state transformations within each screen
+- **Module 11**: Detailed specifications — document edge cases, error states, business rules
+
+---
+
+## The Complete Template
+
+Here's what a finished scenario outline looks like:
+
+```markdown
+# 01: Felix's Quick Registration
+
+**Project:** Dog Walker App
+**Created:** 2026-02-26
+**Method:** Whiteport Design Studio (WDS)
+
+---
+
+## Transaction (Q1)
+Create account and experience first success with minimal friction
+
+## Business Goal (Q2)
+BG01 - Increase trial signups by 40%
+Objective: Drive visitor-to-registered conversion
+
+## User & Situation (Q3)
+Felix (Primary) — Full-stack parent, late evening after kids asleep.
+Saw Google ad, motivated to find solution but skeptical of time investment.
+
+## Driving Forces (Q4)
+Hope: Find a simple app the whole family will actually use
+Worry: Complex onboarding that wastes his limited free time
+
+## Device & Starting Point (Q5 + Q6)
+Mobile — Googles "family dog care app", clicks top organic result
+
+## Best Outcome (Q7)
+User: Account created, feels confident this app will help the family
+Business: New user in activation funnel, one step closer to subscription
+
+## Shortest Path (Q8)
+1. **Landing Page** — Sees value proposition, clicks "Start Free"
+2. **Signup Form** — Enters email and password
+3. **Welcome Screen** — Greeted, ready to add first dog profile ✓
+
+## Trigger Map Connections
+Persona: Felix (Primary)
+Want: Try before committing
+Fear: Complex onboarding that wastes time
+Business Goal: BG01 - Increase trial signups
+
+## Pages in This Scenario
+
+| Page | Folder | Purpose | Exit Action |
+|------|--------|---------|-------------|
+| 1.1 | 1.1-landing-page/ | See value, click CTA | Click "Start Free" |
+| 1.2 | 1.2-signup-form/ | Create account | Submit credentials |
+| 1.3 | 1.3-welcome-screen/ | Feel welcomed, ready to explore | Scenario complete ✓ |
+```
+
+---
+
+## Folder Structure
+
+Each scenario gets its own folder:
+
+```
+C-UX-Scenarios/
+├── 01-felixs-quick-registration/
+│   ├── 01-felixs-quick-registration.md
+│   ├── 1.1-landing-page/
+│   ├── 1.2-signup-form/
+│   └── 1.3-welcome-screen/
+├── 02-harriets-family-setup/
+│   ├── 02-harriets-family-setup.md
+│   └── ...
+```
+
+The scenario file contains the 8-question outline.
+Page folders are created via Freya's page outline dialog or when you jump to Phase 4 (UX Design).
+
+---
+
+## Two Modes
+
+Freya offers two ways to work through the 8 questions:
+
+**Conversation mode** (default): Freya asks one question at a time. Your answers shape the next question naturally. Best for learning and complex scenarios.
+
+**Suggest mode**: Ask Freya to suggest, and she answers all 8 questions based on your Trigger Map and Product Brief. You review and adjust. Best when you want speed or have a clear Trigger Map.
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Starting with pages | Start with Q1 — the transaction |
+| Including branches in Q8 | Keep it linear — zero "if" statements |
+| Generic driving forces in Q4 | Make them visceral and specific |
+| Vague outcomes in Q7 | Both user and business must be measurable |
+| Skipping Q2 | Every scenario must connect to a business goal |
+
+---
+
+## How to Start
+
+From your Trigger Map:
+
+1. **Pick your highest-priority business goal**
+2. **Identify which persona is critical to that goal**
+3. **Find the transaction that satisfies both** — Q1
+4. **Walk through Q2-Q8** with Freya
+5. **Name it** using persona + purpose
+
+---
+
+## What's Next
+
+In the tutorial, you'll create scenario outlines for your own project. Freya will guide you through the 8-question dialog, building each scenario from your Trigger Map.
+
+---
+
+**[Continue to Tutorial: Create Scenario Outlines →](tutorial-08.md)**
+
+---
+
+[← Back to Lesson 2](lesson-02-from-trigger-map-to-scenarios.md) | [Back to Module Overview](module-08-outline-scenarios-overview.md)
+
+*Part of Module 08: Outline Scenarios*
diff --git a/docs/learn/module-08-outline-scenarios/module-08-outline-scenarios-overview.md b/docs/learn/module-08-outline-scenarios/module-08-outline-scenarios-overview.md
new file mode 100644
index 000000000..6cb011704
--- /dev/null
+++ b/docs/learn/module-08-outline-scenarios/module-08-outline-scenarios-overview.md
@@ -0,0 +1,298 @@
+# Module 08: Outline Scenarios
+
+**Time: 30 min | Agent: Freya | Phase: Design | Focus: UX**
+
+---
+
+## Scenarios, Not Pages
+
+You don't design "a login page."
+
+You design "new user creates account and experiences first success."
+
+**Scenarios are linear journeys across logical views.**
+
+---
+
+## The Sunshine Scenario
+
+WDS forces linear motion. No branching. No decision trees.
+
+A scenario is the **shortest path** from current state to desired state — for both business and user.
+
+| Who | Current State | Desired State |
+|-----|---------------|---------------|
+| **User** | Wants to sign up | Has an account, feels welcomed |
+| **Business** | Visitor on site | Registered user in funnel |
+
+Both must be satisfied. That's what makes software sustainable.
+
+---
+
+## Selective Ignorance
+
+By focusing on the primary scenario first, you get the important stuff done and usable.
+
+Less important things? Deprioritized. Not ignored forever — just not now.
+
+WDS applies **selective ignorance** to all the itsy-bitsy stuff "you have to have" in favor of what matters most.
+
+Everything else? Treated as an edge case.
+
+### The Tradeoff
+
+| | What Happens |
+|---|---|
+| **Upside** | More space and attention for what matters. Clean, focused designs. |
+| **Downside** | You may redraw as secondary cases pile up. |
+
+Worth it. The alternative is unbearable.
+
+When you start with intricate navigation schemes, you end up with 100 buttons on the screen. Nobody wins.
+
+---
+
+## What Is a Logical View?
+
+A logical view is a distinct screen state in your application.
+
+- A page is a logical view
+- A modal overlay is a logical view
+- A wizard step is a logical view
+
+When the user **navigates** from one logical view to another — that's a scenario.
+
+When elements **transform** within a single logical view — that's a storyboard (Module 10).
+
+---
+
+## Scenario vs. Storyboard
+
+| Concept | What Changes | Example |
+|---------|--------------|---------|
+| **Scenario** | Logical views change | Signup → Email Verification → Welcome |
+| **Storyboard** | Elements within a view change | Button loading → success animation |
+
+This module focuses on **scenarios** — the journey between views.
+
+**You'll learn storyboarding in Module 10.** For now, focus on mapping the linear flow between screens. The detailed state transformations within each screen come later.
+
+---
+
+## Why This Matters
+
+Pages in isolation are meaningless. A button only makes sense in context.
+
+- Where did the user come from?
+- What are they trying to accomplish?
+- What happens after they succeed?
+- What if something goes wrong?
+
+Scenarios answer these questions.
+
+---
+
+## What Makes a Good Scenario
+
+### 1. Linear
+
+One path. No branches. The shortest way from A to B.
+
+Error handling and edge cases exist — but they're not the scenario. They're exceptions documented separately.
+
+### 2. Dual Value
+
+Serves both user and business.
+
+| Check | Question |
+|-------|----------|
+| User value | Does completing this satisfy the user's goal? |
+| Business value | Does completing this advance a business objective? |
+
+If either is missing, the scenario isn't sustainable.
+
+### 3. Connected to Persona
+
+Who is doing this?
+
+- Which persona from your Trigger Map?
+- What driving forces brought them here?
+
+### 4. Testable
+
+Can you verify it works?
+
+- Clear start and end states
+- Observable outcomes
+- Measurable success
+
+---
+
+## Mapping the Journey
+
+A scenario traces the linear path through logical views:
+
+```
+┌─────────────┐    Click CTA    ┌─────────────┐    Submit    ┌─────────────┐
+│   Landing   │ ──────────────► │   Signup    │ ───────────► │   Welcome   │
+│    Page     │                 │    Form     │              │   Screen    │
+└─────────────┘                 └─────────────┘              └─────────────┘
+     START                                                        END
+```
+
+Each box is a **logical view**. Each arrow is a **navigation event**.
+
+**No branches.** Error states and edge cases are documented separately — they don't clutter the sunshine path.
+
+What happens *within* each box (loading states, animations, validation feedback) — that's storyboarding.
+
+---
+
+## Naming Convention
+
+```
+01-felixs-quick-registration
+02-harriets-family-setup
+03-kids-daily-overview
+```
+
+The number prefix keeps them ordered by priority. The name includes the **persona** and their **purpose**.
+
+**Not:** `login-page`, `dashboard`, `settings`
+
+---
+
+## The 8-Question Dialog
+
+Freya outlines scenarios through an 8-question dialog. Each question builds on the previous answer, creating a complete scenario outline from strategy to page flow.
+
+**Two modes — same 8 questions:**
+- **Conversation** (default): Freya asks, you answer. One question at a time.
+- **Suggest**: Freya answers all 8 based on your Trigger Map, then you review and adjust.
+
+The questions:
+
+| # | Question | What it defines |
+|---|----------|----------------|
+| Q1 | What transaction do we need to get right? | The user purpose |
+| Q2 | Which business goal does it serve? | Strategic connection |
+| Q3 | Which user, in what situation? | Persona + context |
+| Q4 | What do they hope and fear? | Driving forces |
+| Q5 | What device? | Design approach |
+| Q6 | How do they arrive? | Entry point |
+| Q7 | Best outcome for both sides? | Success criteria |
+| Q8 | Shortest path through the site? | Linear page flow |
+
+---
+
+## Scenario Outline Template
+
+```markdown
+# 01: Felix's Quick Registration
+
+## Transaction (Q1)
+Verify service availability before booking
+
+## Business Goal (Q2)
+BG01 - Increase trial signups by 40%
+
+## User & Situation (Q3)
+Felix (Primary) — Full-stack parent, evening after kids asleep, skeptical but motivated
+
+## Driving Forces (Q4)
+Hope: Find a simple app that the whole family will actually use
+Worry: Wasting time on another tool nobody adopts
+
+## Device & Starting Point (Q5 + Q6)
+Mobile — Googles "family dog care app", clicks top result
+
+## Best Outcome (Q7)
+User: Account created, feels confident this will help
+Business: New user in activation funnel, one step closer to subscription
+
+## Shortest Path (Q8)
+1. **Landing Page** — Sees value proposition, clicks "Start Free"
+2. **Signup Form** — Enters email and password
+3. **Welcome Screen** — Greeted, ready to explore ✓
+
+## Trigger Map Connections
+Persona: Felix (Primary)
+Want: Try before committing
+Fear: Complex onboarding that wastes time
+Business Goal: BG01 - Increase trial signups
+```
+
+Error states and edge cases are documented in the page specifications, not the scenario outline.
+
+---
+
+## Output
+
+```
+C-UX-Scenarios/
+└── 01-felixs-quick-registration/
+    ├── 01-felixs-quick-registration.md
+    ├── 1.1-landing-page/
+    ├── 1.2-signup-form/
+    └── 1.3-welcome-screen/
+```
+
+Each scenario gets its own folder. Pages use `NN.step-page-slug` naming and are created via the page outline dialog or when you jump to Phase 4 (UX Design).
+
+---
+
+## How Many Scenarios?
+
+Depends on your product. Common patterns:
+
+| Product Type | Typical Scenarios |
+|--------------|-------------------|
+| Simple landing page | 2-3 |
+| Web application | 8-15 |
+| Complex platform | 20+ |
+
+Start with the core user journeys. Add more as needed.
+
+---
+
+## Practice
+
+From your Trigger Map:
+
+1. List your personas
+2. For each persona, identify their primary goal
+3. That goal becomes a scenario
+4. Map the logical views they'll pass through
+5. Name it clearly
+
+---
+
+## Lessons
+
+### [Lesson 1: Scenarios, Not Pages](lesson-01-design-experiences-not-screens.md)
+Why linear journeys matter more than isolated screens
+
+### [Lesson 2: From Trigger Map to Scenarios](lesson-02-from-trigger-map-to-scenarios.md)
+How to identify which scenarios to create from your Trigger Map
+
+### [Lesson 3: Mapping the Journey](lesson-03-mapping-the-journey.md)
+How to structure scenario outlines for clarity and action
+
+---
+
+## Tutorial
+
+### [Tutorial 08: Create Your Scenario Outlines](tutorial-08.md)
+Hands-on guide to defining user journeys with Freya
+
+---
+
+## Next Module
+
+**[Module 09: Conceptual Sketching →](../module-09-conceptual-sketching/module-09-conceptual-sketching-overview.md)**
+
+Time to sketch the default state of each logical view.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-08-outline-scenarios/tutorial-08.md b/docs/learn/module-08-outline-scenarios/tutorial-08.md
new file mode 100644
index 000000000..e230322ae
--- /dev/null
+++ b/docs/learn/module-08-outline-scenarios/tutorial-08.md
@@ -0,0 +1,397 @@
+# Tutorial 08: Create Your Scenario Outlines
+
+**Hands-on guide to defining user journeys with Freya's 8-question dialog**
+
+---
+
+## Overview
+
+This tutorial walks you through creating scenario outlines using Freya's 8-question dialog — the structured conversation that maps user journeys across your application.
+
+**Time:** 20-25 minutes
+**Prerequisites:** Trigger Map completed (Module 06)
+**Agent:** Freya
+**What you'll create:** Scenario outline documents in `C-UX-Scenarios/`
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- Your completed Trigger Map
+- Understanding of your personas and their goals
+- Product Brief for context
+
+**Freya will help you:**
+
+- Identify which scenarios to prioritize
+- Walk through the 8-question dialog for each scenario
+- Connect every answer back to your Trigger Map
+- Ensure dual value (user + business)
+
+---
+
+## Step 1: Start the Conversation with Freya (2 min)
+
+### Open your AI IDE and initiate:
+
+**You say:**
+> "I want to create scenario outlines for my project. I have my Trigger Map ready. Can you help me identify and structure the key user journeys?"
+
+**Freya responds with context questions about your personas.**
+
+### Share your Trigger Map:
+
+Reference your B-Trigger-Map folder or summarize your personas and their primary goals.
+
+---
+
+## Step 2: Freya Analyzes and Suggests Scenarios (5 min)
+
+### Ask Freya to analyze your Trigger Map:
+
+**You say:**
+> "I'd like you to analyze my Trigger Map and suggest prioritized scenarios. Here's my Product Brief and Trigger Map..." (share the files)
+
+### Freya analyzes automatically:
+
+Freya examines:
+- Your top business goals (from Product Brief)
+- Priority personas (from Trigger Map workshops)
+- Top driving forces per persona
+- Feature-to-driver connections
+
+**Then suggests scenarios ranked by strategic value.**
+
+### Freya presents ranked suggestions:
+
+> **Freya:** "Based on your Trigger Map, I've identified 8 potential scenarios. Here are the top 3 by strategic value:
+>
+> **01: Harriet's Family Setup** (Priority #1)
+> - Business Goal: BG01 - Multi-user adoption
+> - Persona: Harriet the Household Manager (your #1 priority)
+> - Driver: Need to get whole family on same page (her #1 driver)
+> - Why this matters: Household with multiple members = higher retention
+>
+> **02: Felix's Daily Overview** (Priority #2)
+> - Business Goal: BG02 - Daily active usage
+> - Persona: Felix the Full-Stack (Harriet's spouse)
+> - Driver: Quick visibility into what's needed (his #2 driver)
+> - Why this matters: Enables daily habit formation
+>
+> **03: Kids' Task Completion** (Priority #3)
+> - Business Goal: BG02 - Daily active usage
+> - Persona: Kids (Junior Members)
+> - Driver: Clear expectations and progress visibility
+> - Why this matters: Completes family loop
+>
+> Should we start with 01: Harriet's Family Setup?"
+
+### You validate and adjust:
+
+**You respond:**
+> "Yes, 01 makes sense. Let's start there."
+
+---
+
+## Step 3: Walk Through the 8-Question Dialog (10 min)
+
+Freya guides you through 8 questions, one at a time. Each answer shapes the next question.
+
+### Q1: The Transaction
+
+**Freya:**
+> "What transaction do we need to get really right for Harriet? What's the most important thing she needs to accomplish?"
+
+**You:**
+> "Set up her household and get at least one family member to join."
+
+### Q2: Business Goal
+
+**Freya:**
+> "If this transaction succeeds, which business goal does it serve?"
+
+**You:**
+> "BG01 - Multi-user adoption. Each household with multiple members means higher retention."
+
+### Q3: User & Situation
+
+**Freya:**
+> "Tell me about Harriet in this moment. Who is she, where is she, what's happening?"
+
+**You:**
+> "She's a mom, evening after kids are in bed. Just saw a Facebook ad for the app. She's motivated but skeptical — she's tried 2 other family apps that nobody used."
+
+### Q4: Hope & Worry
+
+**Freya:**
+> "What does Harriet hope for and what does she fear going into this?"
+
+**You:**
+> "Hope: Finally get the family coordinated without nagging. Worry: Another app nobody will actually use."
+
+### Q5: Device
+
+**Freya:**
+> "What device is she on?"
+
+**You:**
+> "Mobile — she's on her phone on the couch."
+
+### Q6: Starting Point
+
+**Freya:**
+> "How does she actually arrive at the first screen?"
+
+**You:**
+> "Clicks the download link from the Facebook ad, lands on the app store page, installs, opens the app."
+
+### Q7: Best Outcome
+
+**Freya:**
+> "What does the best possible outcome look like — for Harriet AND for the business?"
+
+**You:**
+> "Harriet: Household created, husband invited, feels like she's actually made progress. Business: Activated user plus second user invited — retention signal and network effect."
+
+### Q8: Shortest Path
+
+**Freya:**
+> "What's the shortest path through the app to get there? Walk me through the screens."
+
+**You:**
+> "Landing screen, then signup, then create household with a name, then invite screen where she sends invite to her husband, then dashboard showing the household is set up."
+
+**Freya structures it:**
+
+```
+1. **Welcome Screen** — Sees value proposition, taps "Start Free"
+2. **Signup** — Enters email and password
+3. **Create Household** — Names the household
+4. **Invite Family** — Sends invite to husband
+5. **Dashboard** — Sees household created, invite sent ✓
+```
+
+---
+
+## Step 4: Review the Complete Scenario (2 min)
+
+### Freya presents the full outline:
+
+```markdown
+# 01: Harriet's Family Setup
+
+**Project:** Dog Walker App
+**Created:** 2026-02-26
+**Method:** Whiteport Design Studio (WDS)
+
+---
+
+## Transaction (Q1)
+Set up household and get first family member to join
+
+## Business Goal (Q2)
+BG01 - Multi-user adoption
+Objective: Drive household activation with multiple members
+
+## User & Situation (Q3)
+Harriet (Primary) — Mom, evening after kids in bed.
+Just saw Facebook ad, motivated but skeptical after 2 failed app attempts.
+
+## Driving Forces (Q4)
+Hope: Finally get the family coordinated without nagging
+Worry: Another app nobody will actually use
+
+## Device & Starting Point (Q5 + Q6)
+Mobile — Clicks download link from Facebook ad, installs app
+
+## Best Outcome (Q7)
+User: Household created, husband invited, feels like real progress
+Business: Activated user + second user invited (retention signal + network effect)
+
+## Shortest Path (Q8)
+1. **Welcome Screen** — Sees value proposition, taps "Start Free"
+2. **Signup** — Enters email and password
+3. **Create Household** — Names the household
+4. **Invite Family** — Sends invite to husband
+5. **Dashboard** — Sees household created, invite sent ✓
+
+## Trigger Map Connections
+Persona: Harriet (Primary)
+Want: Get whole family on same page
+Fear: Another app nobody will use
+Business Goal: BG01 - Multi-user adoption
+
+## Pages in This Scenario
+
+| Page | Folder | Purpose | Exit Action |
+|------|--------|---------|-------------|
+| 1.1 | 1.1-welcome-screen/ | See value, start signup | Tap "Start Free" |
+| 1.2 | 1.2-signup/ | Create account | Submit credentials |
+| 1.3 | 1.3-create-household/ | Name the household | Enter name, continue |
+| 1.4 | 1.4-invite-family/ | Invite first member | Send invite |
+| 1.5 | 1.5-dashboard/ | See success confirmation | Scenario complete ✓ |
+```
+
+### Verify and adjust:
+
+> "Does this capture the journey accurately? Anything missing or incorrect?"
+
+---
+
+## Step 5: After Each Scenario — Choose What's Next
+
+After completing a scenario, Freya presents options:
+
+> **Freya:** "Scenario 01 complete! What would you like to do?
+>
+> **[N]** Define the next scenario — 02: Felix's Daily Overview
+> **[O]** Outline scenario pages — create page folders for scenario 01
+> **[D]** Start designing — create first page and jump to Phase 4
+> **[C]** Continue to overview — when all scenarios are done"
+
+**Choose based on your workflow:**
+- **[N]** to keep outlining scenarios (most common)
+- **[O]** to detail the pages in this scenario before moving on
+- **[D]** to jump straight into designing the first page
+- **[C]** only when ALL planned scenarios are complete
+
+---
+
+## Step 6: Continue with Remaining Scenarios (5 min)
+
+### Work through remaining scenarios using the same 8-question dialog:
+
+**You:**
+> "Let's do [N] — next scenario."
+
+**Freya:**
+> "Great. Let's work on 02: Felix's Daily Overview.
+>
+> **Q1:** What transaction do we need to get right for Felix?"
+
+Work through Q1-Q8 again. Each scenario follows the same dialog pattern but the answers are unique to the persona and their situation.
+
+### Freya tracks progress:
+
+> "We've completed:
+> - 01: Harriet's Family Setup ✓
+> - 02: Felix's Daily Overview ✓
+> - 03: Kids' Task Completion (next)
+>
+> These 3 cover your core activation flow. Ready for 03?"
+
+---
+
+## Step 7: Save the Scenarios (2 min)
+
+### Freya saves each scenario:
+
+```
+C-UX-Scenarios/
+├── 01-harriets-family-setup/
+│   └── 01-harriets-family-setup.md
+├── 02-felixs-daily-overview/
+│   └── 02-felixs-daily-overview.md
+├── 03-kids-task-completion/
+│   └── 03-kids-task-completion.md
+```
+
+### Confirm the structure:
+
+> "I've created the scenario folders with outline documents. Each scenario is ready for the next steps: page outlining, conceptual sketching, or detailed specifications."
+
+---
+
+## What You've Created
+
+### For each scenario, the 8-question dialog produced:
+
+- **Transaction (Q1)** — What the user needs to accomplish
+- **Business Goal (Q2)** — Strategic connection to Trigger Map
+- **User & Situation (Q3)** — Persona + real-life context
+- **Driving Forces (Q4)** — Hope and worry, visceral and specific
+- **Device (Q5)** — Design approach
+- **Starting Point (Q6)** — How they actually arrive
+- **Best Outcome (Q7)** — Success for user AND business
+- **Shortest Path (Q8)** — Linear page flow, no branches
+- **Trigger Map Connections** — Explicit link back to strategic foundation
+- **Pages Table** — Page folders ready for Phase 4
+
+---
+
+## What Happens Next
+
+### Immediate:
+
+- Each scenario is a roadmap for design
+- Pages from Q8 become screens to sketch
+- The 8-question answers inform every design decision
+
+### Next Module:
+
+- **Module 09: Conceptual Sketching** — Visualize the default state of each page
+- Take one scenario and sketch what the user sees at each step
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Keep Q8 linear (zero "if" statements)
+- Make Q4 visceral — "interested" is too weak
+- Connect every scenario to the Trigger Map (Q2)
+- Be specific in Q3 — who, where, when, why
+- Make Q7 measurable for both sides
+
+**DON'T:**
+
+- Design pages in isolation
+- Include edge cases in Q8 (those go in page specs)
+- Create more scenarios than you need for MVP
+- Use generic driving forces in Q4
+- Skip Q2 — every scenario needs a business goal
+
+---
+
+## Common Questions
+
+**Q: How many scenarios should I have?**
+A: For MVP, typically 3-8. Each persona's primary transaction = one scenario. Start core, expand later.
+
+**Q: What if a scenario feels too long?**
+A: If Q8 has more than 7 steps, consider splitting into two scenarios. Look for natural milestones.
+
+**Q: Where do error states go?**
+A: In page specifications (Module 11), not the scenario outline. Q8 is the sunshine path.
+
+**Q: Can one page appear in multiple scenarios?**
+A: Absolutely. The Dashboard might be the end of scenario 01 and the start of scenario 02.
+
+**Q: Conversation mode or Suggest mode?**
+A: Conversation (default) is best for learning. Suggest is faster when you have a detailed Trigger Map and want Freya to draft all 8 answers for your review.
+
+---
+
+## You've Completed Module 08!
+
+**Your scenarios are outlined.** You know:
+- The journeys you're designing (Q1 + Q8)
+- Who is taking each journey (Q3 + Q4)
+- What value each journey delivers (Q2 + Q7)
+
+---
+
+## Next Module
+
+**[Module 09: Conceptual Sketching →](../module-09-conceptual-sketching/module-09-conceptual-sketching-overview.md)**
+
+Time to visualize what the user sees at each step.
+
+---
+
+[← Back to Lesson 3](lesson-03-mapping-the-journey.md) | [Back to Module Overview](module-08-outline-scenarios-overview.md)
+
+*Part of Module 08: Outline Scenarios*
diff --git a/docs/learn/module-09-conceptual-sketching/lesson-01-visualize-first.md b/docs/learn/module-09-conceptual-sketching/lesson-01-visualize-first.md
new file mode 100644
index 000000000..11b5b998b
--- /dev/null
+++ b/docs/learn/module-09-conceptual-sketching/lesson-01-visualize-first.md
@@ -0,0 +1,286 @@
+# Module 09: Conceptual Sketching
+
+## Lesson 1: Visualize First
+
+**Why seeing comes before specifying**
+
+---
+
+## The Specification Problem
+
+You can't specify what you can't see.
+
+Try writing a detailed specification for a page layout purely in words:
+
+> "The header should contain the logo on the left, navigation in the center, and user profile on the right. Below that, a hero section with a headline, subheadline, and call-to-action button. The button should be prominent..."
+
+How big is prominent? How much space between elements? What's the visual hierarchy?
+
+Words fail at spatial problems. You need to see it.
+
+---
+
+## Keyframe 0
+
+This module is about **keyframe 0** — the default state of each logical view.
+
+What does the user see when the page first loads?
+
+Before any interactions. Before any animations. Before any state changes.
+
+Just: what appears on screen?
+
+---
+
+## Why Default State First?
+
+Everything else is a transformation FROM the default state.
+
+- Loading states → default state
+- User interactions → transform from default
+- Error states → modify the default
+- Success states → change from default
+
+If you don't nail the default state, everything built on top wobbles.
+
+---
+
+## The Conceptual Mindset
+
+### Low Fidelity on Purpose
+
+Rough visuals prevent attachment.
+
+If your sketch looks finished, you'll defend it. You'll argue about it. You'll resist changes.
+
+If your sketch looks rough, you'll iterate freely. You'll explore alternatives. You'll find better solutions.
+
+**Keep it ugly. Keep it fast. Keep it flexible.**
+
+### Quantity Over Quality
+
+Your first idea is rarely your best.
+
+Professional designers know this. They explore 3-5 approaches before picking one. They generate options before converging.
+
+**One perfect sketch = probably wrong.**
+**Five rough sketches = probably right (one of them).**
+
+### Think Out Loud
+
+Visualize while talking through the scenario.
+
+- What does the user see first?
+- What draws their attention?
+- Where do they click?
+- What are they trying to accomplish?
+
+Connect every visual decision to the user's journey.
+
+---
+
+## Entry Points
+
+You don't have to start from scratch.
+
+| Entry Point | How It Works |
+|-------------|--------------|
+| **Workshop** | Talk through the screen together — conversation shapes the concept |
+| **Visualize** | Send any visual — AI analyzes and refines |
+| **Example** | "I like how this site does it" → AI extracts patterns |
+| **Dream it up** | "Show me 3 ways to lay out a signup form" → AI generates options |
+
+Same output. Different starting points. Use whatever feels natural.
+
+---
+
+## Ways to Visualize
+
+You can send anything visual. All methods work.
+
+| Method | When to Use |
+|--------|-------------|
+| **Pixel-perfect Figma** | You already have detailed designs |
+| **Wireframes** | Structure without visual noise |
+| **Hand sketch (paper)** | Fastest way to think out loud |
+| **Hand sketch (digital)** | iPad, tablet, stylus |
+| **Whiteboard concepts** | Rough, collaborative, big picture |
+| **Screen dumps** | "This feature from another product" |
+| **Generated images** | AI creates options for you |
+| **ASCII art** | Quick text-based layouts from AI |
+| **Vibe coded example** | Quick prototype → agent screenshots states |
+
+Mix and match. One view might be a polished wireframe, another a napkin sketch.
+
+**What matters is communication, not polish.**
+
+---
+
+## The Great Divide
+
+You can make something amazing with AI.
+
+Beautiful mockups. Working prototypes. Impressive demos.
+
+But then what?
+
+**There's a great divide between conceptualizing and producing.**
+
+In the middle stands the specification — with its static visualization.
+
+```
+┌───────────────┐         ┌───────────────┐         ┌───────────────┐
+│ CONCEPTUALIZE │ ──────► │ SPECIFICATION │ ──────► │   PRODUCTION  │
+│               │         │               │         │     CODE      │
+│ Cool mockups  │         │ Static visual │         │ Real software │
+│ AI demos      │         │ + behavior    │         │               │
+│ Prototypes    │         │ + content     │         │               │
+└───────────────┘         └───────────────┘         └───────────────┘
+    Creative                  The Bridge                Deliverable
+```
+
+No matter how cool your concept — you still create a specification.
+
+That's what gets built.
+
+---
+
+## What Sketching Reveals
+
+Sketching isn't just about showing what you know.
+
+It's about discovering what you don't know.
+
+**Common discoveries:**
+
+- "This page needs more content than I thought"
+- "These two elements compete for attention"
+- "The user's next action isn't obvious"
+- "This layout doesn't work on mobile"
+
+Better to discover these with rough sketches than polished mockups.
+
+---
+
+## Connected to Scenarios
+
+Every sketch maps to a logical view in your scenario.
+
+```
+Scenario: S01-User-Registration
+
+Logical Views:
+1. Landing Page     → [Sketch needed]
+2. Signup Form      → [Sketch needed]
+3. Welcome Screen   → [Sketch needed]
+```
+
+You're not sketching random pages. You're sketching the steps in a user journey.
+
+This keeps your work connected to purpose.
+
+---
+
+## What to Capture
+
+For each logical view, sketch:
+
+### 1. Overall Layout
+Where do major elements go?
+- Header, main content, footer
+- Navigation placement
+- Primary action location
+
+### 2. Visual Hierarchy
+What's most important?
+- Primary element (biggest, boldest)
+- Secondary elements
+- Supporting content
+
+### 3. User Flow
+Where does the eye travel?
+- Entry point (where they look first)
+- Path through the content
+- Call to action
+
+### 4. Key Interactions
+What's clickable?
+- Primary CTA
+- Secondary actions
+- Navigation elements
+
+---
+
+## Not Yet
+
+At this stage, don't worry about:
+
+- **Colors** — Too early
+- **Final typography** — Too early
+- **Exact spacing** — Too early
+- **Animations** — Too early (that's Module 10)
+- **Edge cases** — That's Module 11
+
+Focus on structure and hierarchy. Everything else comes later.
+
+---
+
+## Quick Visualization Patterns
+
+### Boxes and Labels
+
+```
+┌─────────────────────┐
+│      HEADER         │
+├─────────────────────┤
+│                     │
+│   [Form Area]       │
+│                     │
+├─────────────────────┤
+│   [ CTA Button ]    │
+└─────────────────────┘
+```
+
+### Variants
+
+Sketch the same screen 3 different ways. Label them A, B, C.
+
+```
+Variant A: Form centered, minimal
+Variant B: Form left, benefits right
+Variant C: Step-by-step wizard style
+```
+
+Pick the best. Or combine elements from multiple.
+
+---
+
+## The Freya Method
+
+Freya helps you explore visually while staying connected to strategy:
+
+> "Based on Felix's fear of complicated signups, what's the simplest layout?"
+
+> "Here are 3 approaches — which resonates with your trigger map?"
+
+> "I notice this sketch has 5 fields. Your scenario mentioned 'quick signup.' Which is right?"
+
+She won't let you sketch in isolation from purpose.
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn specific techniques for sketching effectively — whether you're using paper, digital tools, or AI-generated options.
+
+Then in the tutorial, you'll sketch the default states for your own scenario views with Freya's guidance.
+
+---
+
+**[Continue to Lesson 2: Sketching Techniques →](lesson-02-sketching-techniques.md)**
+
+---
+
+[← Back to Module Overview](module-09-conceptual-sketching-overview.md)
+
+*Part of Module 09: Conceptual Sketching*
diff --git a/docs/learn/module-09-conceptual-sketching/lesson-02-sketching-techniques.md b/docs/learn/module-09-conceptual-sketching/lesson-02-sketching-techniques.md
new file mode 100644
index 000000000..458c6d221
--- /dev/null
+++ b/docs/learn/module-09-conceptual-sketching/lesson-02-sketching-techniques.md
@@ -0,0 +1,270 @@
+# Module 09: Conceptual Sketching
+
+## Lesson 2: Sketching Techniques
+
+**Practical methods for visualizing your logical views**
+
+---
+
+## The Goal
+
+Communicate structure and hierarchy quickly.
+
+Not beauty. Not polish. Just enough clarity to:
+- Understand what the user sees
+- Know where key elements are positioned
+- Serve as the foundation for specifications
+
+---
+
+## Paper Sketching
+
+The fastest way to think out loud.
+
+### Materials
+
+- Paper (any kind works)
+- Pen or marker
+- 5 minutes
+
+### Photograph and Share
+
+Phone camera → send to AI → get feedback.
+
+Freya can analyze hand sketches and suggest refinements.
+
+---
+
+## Digital Sketching
+
+If you prefer tablet or stylus.
+
+### Tools
+
+- iPad + Apple Pencil
+- Any drawing app (Notes app works fine)
+- Freeform, Concepts, Paper
+
+### Approach
+
+Same as paper, but digital:
+- Rough shapes
+- Quick text labels
+- Multiple variants
+- Export and share
+
+### Advantage
+
+Easy to share directly with AI. No photography step.
+
+---
+
+## Wireframe Tools
+
+If you want more structure than freehand.
+
+### Tools
+
+- Figma
+- Balsamiq
+- Whimsical
+- Excalidraw
+
+### Low-Fi Mode
+
+**Black lines only. No colors. No real content.**
+
+The more you reduce, the more you communicate.
+
+```
+┌─────────────────────────────────────┐
+│ [Logo]                    [Nav] [P] │
+├─────────────────────────────────────┤
+│                                     │
+│           [Hero Image]              │
+│                                     │
+│         ─────────────────           │
+│         Large Headline Here         │
+│         ─────────────────           │
+│         Supporting text that        │
+│         explains the value          │
+│                                     │
+│         [  Primary CTA  ]           │
+│                                     │
+└─────────────────────────────────────┘
+```
+
+Placeholders force focus on structure, not content. Black lines force focus on layout, not decoration.
+
+---
+
+## AI-Generated Sketches
+
+Let the AI create options for you.
+
+### Prompting for Layouts
+
+**Good prompt:**
+> "Show me 3 different layouts for a signup form. The user is Felix who wants to try quickly with minimal friction. Mobile-first."
+
+**Better prompt:**
+> "I need a signup form for S01-User-Registration. The persona is Felix who fears complicated onboarding. Show me 3 approaches: minimal, conversational, and wizard-style. ASCII art is fine."
+
+### ASCII Art
+
+AI can generate quick text-based layouts:
+
+```
+┌─────────────────────────────────┐
+│  Dog Week                 [?]  │
+├─────────────────────────────────┤
+│                                 │
+│     Welcome to Dog Week         │
+│                                 │
+│   ┌───────────────────────┐     │
+│   │ Email                 │     │
+│   └───────────────────────┘     │
+│                                 │
+│   ┌───────────────────────┐     │
+│   │ Password              │     │
+│   └───────────────────────┘     │
+│                                 │
+│   [    Create Account    ]      │
+│                                 │
+│   Already have an account?      │
+│   Log in →                      │
+│                                 │
+└─────────────────────────────────┘
+```
+
+Fast to generate. Easy to iterate. Clear enough to discuss.
+
+---
+
+## Screen Dumps as Reference
+
+Using existing products for inspiration.
+
+### The Pattern
+
+1. Find a product you admire
+2. Screenshot the relevant screen
+3. Share with Freya: "I like how this handles signup"
+4. AI extracts the patterns
+
+### What to Share
+
+- "I like this form layout"
+- "This navigation feels right"
+- "The hierarchy here works"
+
+### What Freya Does
+
+> "I see this uses a single-column form with progressive disclosure. The CTA is high-contrast and fixed at the bottom. Should we apply similar patterns to Felix's signup experience?"
+
+She extracts what works, connects to your context.
+
+---
+
+## Vibe-Coded Prototypes
+
+Quick prototypes that the AI can analyze.
+
+### The Pattern
+
+1. Ask AI to build a quick prototype
+2. View it in browser
+3. Screenshot the states
+4. Use screenshots as sketches
+
+### Example
+
+> "Build me a quick HTML signup form based on our S01-User-Registration scenario. Just the structure, no styling."
+
+Then screenshot the result and use it as your starting point.
+
+---
+
+## Responsive Considerations
+
+Sketch for your primary platform first.
+
+### Mobile-First
+
+If users are primarily on mobile (like Dog Week):
+- Sketch mobile layout first
+- Everything stacks vertically
+- Touch-friendly tap targets
+
+### Desktop-First
+
+If users are primarily on desktop:
+- Sketch desktop layout first
+- Multiple columns allowed
+- Hover states possible
+
+### Then Adapt
+
+Once primary platform is sketched:
+- "How does this adapt to secondary platform?"
+- Key elements stay, layout adjusts
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Too polished | Keep it rough |
+| Only one variant | Explore 3-5 options |
+| Designing in isolation | Reference your scenario |
+| Starting with edge cases | Focus on default state |
+| Using colors | Black lines only—colors distract from structure |
+
+---
+
+## The Sketching Conversation
+
+With Freya:
+
+**You:** "Here's my sketch for the signup form. [share image]"
+
+**Freya:** "I see a two-field form with prominent CTA. This aligns with Felix's need for simplicity. A few questions:
+- Where does the user see they can log in instead?
+- Is there a way to try before creating an account?
+- How prominent should the value proposition be?"
+
+**You:** "Good points. Let me sketch variant B with those addressed..."
+
+The conversation refines the concept.
+
+---
+
+## Output
+
+For each logical view in your scenario:
+
+- **1-3 rough sketches** showing layout options
+- **Selected direction** with rationale
+
+The sketches show WHAT appears on screen. The specifications (Module 11) document WHY—explaining decisions, persona connections, and business rationale.
+
+These sketches become the foundation for storyboarding (what changes after load) and specifications (the detailed documentation).
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn why hand sketching (paper or tablet) is still the recommended approach in the AI era—and what makes it superior to other methods.
+
+Then in the tutorial, you'll sketch the default states for your own scenario views with Freya's guidance.
+
+---
+
+**[Continue to Lesson 3: Why Hand Sketching is Still King →](lesson-03-why-hand-sketching.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-visualize-first.md) | [Back to Module Overview](module-09-conceptual-sketching-overview.md)
+
+*Part of Module 09: Conceptual Sketching*
diff --git a/docs/learn/module-09-conceptual-sketching/lesson-03-why-hand-sketching.md b/docs/learn/module-09-conceptual-sketching/lesson-03-why-hand-sketching.md
new file mode 100644
index 000000000..73cde99db
--- /dev/null
+++ b/docs/learn/module-09-conceptual-sketching/lesson-03-why-hand-sketching.md
@@ -0,0 +1,250 @@
+# Module 09: Conceptual Sketching
+
+## Lesson 3: Why Hand Sketching is Still King
+
+**Grab pen and paper. Let's go.**
+
+---
+
+## The AI Paradox
+
+AI can generate beautiful mockups in seconds.
+
+So why are we recommending you grab a pen?
+
+**Because sketching isn't about the artifact. It's about the thinking.**
+
+---
+
+## Your Hand, Your Brain
+
+When you draw by hand, something magical happens:
+
+**Your hand draws what your mind sees. Instantly.**
+
+No boot time. No interface. No fighting with tools.
+
+**The thought becomes visible in real time.**
+
+This is faster than any digital tool will ever be.
+
+---
+
+## Being Sketchy is a Superpower
+
+Here's what people get wrong about sketching:
+
+**They think "sketchy" means vague.**
+
+**Actually, sketchy means: rough but complete.**
+
+- 20 minutes making it concrete and complete
+- Not 2 hours making it pixel-perfect
+
+**Ugly is good. Ugly keeps you moving.**
+
+---
+
+## Five Things Only Hand Sketching Can Do
+
+### 1. **Fastest from Thought to Visual**
+
+Think it. Draw it. Done.
+
+**Digital tools make you wait. Paper doesn't.**
+
+### 2. **Forces You to Be Concrete**
+
+Can't hide behind "we'll figure it out later."
+
+**If you can't draw it, you haven't thought it through.**
+
+### 3. **Invites Everyone to Participate**
+
+Non-designers feel safe with rough sketches.
+
+**Polished mockups intimidate. Rough sketches invite.**
+
+### 4. **Keeps You Exploring**
+
+Low stakes = more options.
+
+**You'll sketch 10 variants. You'll wireframe 2.**
+
+### 5. **Shows Your Thinking Process**
+
+Looking back at variants shows how you got to the answer.
+
+**This is valuable documentation.**
+
+---
+
+## You Don't Need Artistic Skills
+
+Seriously. You need four things:
+
+1. **Box** — Any UI element
+2. **Line** — Separators, borders
+3. **Text** — Labels
+4. **Arrow** — Flow
+
+**That's it. You can sketch any interface.**
+
+If you can write your name, you can sketch UX.
+
+---
+
+## What You Need
+
+**Materials:**
+- Paper (any kind)
+- Pen or marker
+- 5 minutes
+
+**Permission:**
+- To be ugly
+- To explore
+- To cross out and start over
+
+**That's it. You're ready.**
+
+---
+
+## Digital Sketching Works Too
+
+Prefer iPad + Apple Pencil? That works.
+
+Any tablet + stylus? Great.
+
+**Same approach:**
+- Rough shapes
+- Quick labels
+- Multiple variants
+
+**The principle stays the same: rough but complete.**
+
+---
+
+## The Collaborative Superpower
+
+Here's where it gets powerful:
+
+### Path A: You Already Sketched
+1. Take a photo
+2. Share with Freya
+3. Get strategic feedback connected to your personas
+
+### Path B: You Haven't Sketched Yet
+1. Discuss the page with Freya
+2. Explore options together
+3. Sketch based on discussion
+4. Share for feedback
+
+**Either way, the sketch becomes the thinking tool.**
+
+---
+
+## Why This Beats AI-Generated Layouts
+
+AI can generate options fast. That's true.
+
+**But here's what AI can't do:**
+
+**AI generates layouts. Sketching generates understanding.**
+
+Use both:
+1. **Sketch to think** through the structure
+2. **Share with AI** for strategic feedback
+3. **Generate if needed** for digital artifacts
+
+**The sketch comes first. Always.**
+
+---
+
+## Common Objections Destroyed
+
+**"I can't draw"**
+→ You don't need to. Boxes and labels work perfectly.
+
+**"My sketches are ugly"**
+→ Perfect. Ugly = rough = flexible = good.
+
+**"I work faster in Figma"**
+→ You polish faster in Figma. You think faster on paper.
+
+**"AI can generate layouts instantly"**
+→ AI generates options. Sketching generates thinking. Do both.
+
+---
+
+## The Standard: Concrete and Complete
+
+However you visualize (hand, tablet, digital), meet this standard:
+
+✓ **Concrete** — Shows actual objects, not vague concepts
+✓ **Complete** — Everything on screen, nothing more
+✓ **Rough** — Fast and ugly, not polished
+
+**Sketches show WHAT. Specifications document WHY.**
+
+**Method doesn't matter. Meeting the standard does.**
+
+---
+
+## Want the Full Case?
+
+This lesson gives you the energy to start.
+
+**For the comprehensive argument** (45 reasons across 9 categories), see the model:
+
+**[Sketching Concepts by Hand Model](../../models/whiteport-sketching-concepts-by-hand.md)**
+
+It covers:
+- Speed & Flow
+- Thinking Quality
+- Collaboration Benefits
+- Design Quality
+- Psychological Advantages
+- And much more
+
+**But you don't need to read that to start.**
+
+---
+
+## Right Now
+
+Here's what to do:
+
+1. **Grab paper and pen** (seriously, right now)
+2. **Pick one logical view** from your scenario
+3. **Sketch 3 variants** (rough boxes and labels)
+4. **Take 15 minutes max**
+
+**That's it. That's the lesson.**
+
+Stop reading. Start sketching.
+
+---
+
+## What's Next
+
+In the tutorial, you'll sketch default states for your scenario views.
+
+Freya will:
+- Help you explore options
+- Connect decisions to personas
+- Keep you strategically aligned
+
+**But first, you need to experience sketching yourself.**
+
+So grab that pen.
+
+---
+
+**[Continue to Tutorial: Sketch Your Views →](tutorial-09.md)**
+
+---
+
+[← Back to Lesson 2: Sketching Techniques](lesson-02-sketching-techniques.md) | [Back to Module Overview](module-09-conceptual-sketching-overview.md)
+
+*Part of Module 09: Conceptual Sketching*
diff --git a/docs/learn/module-09-conceptual-sketching/lesson-04-image-sketching-best-practices.md b/docs/learn/module-09-conceptual-sketching/lesson-04-image-sketching-best-practices.md
new file mode 100644
index 000000000..00e74039f
--- /dev/null
+++ b/docs/learn/module-09-conceptual-sketching/lesson-04-image-sketching-best-practices.md
@@ -0,0 +1,272 @@
+# WDS Sketching Best Practices: Images
+
+**How to represent images in UI sketches**
+
+---
+
+## ✅ Recommended: Sketch the Actual Image Content
+
+### Why Sketch Real Content?
+
+When you sketch what the image should actually show (rather than just "X" or "image here"), you:
+
+- **Provide visual direction** - Designer/developer understands image purpose
+- **Enable AI interpretation** - Agent can suggest appropriate image content
+- **Guide art direction** - Photographer/illustrator knows what's needed
+- **Communicate intent** - Stakeholders visualize the final design
+- **Inspire creativity** - More engaging than abstract placeholders
+
+---
+
+## Image Sketching Techniques
+
+### 1. Portrait/Profile Photos
+
+**Sketch a simple face:**
+
+```
+┌──────────────┐
+│   ◠  ◠       │  ← Simple eyes
+│              │
+│      ᵕ       │  ← Simple smile
+└──────────────┘
+```
+
+or
+
+```
+┌──────────────┐
+│   ●  ●       │  ← Dots for eyes
+│              │
+│    \_/       │  ← Smile
+└──────────────┘
+```
+
+**Purpose:** Profile pictures, team photos, author avatars, user images
+
+### 2. Hero Images / Backgrounds
+
+**Sketch landscape/scenery:**
+
+```
+┌──────────────────────────┐
+│                          │
+│    /\   /\    /\         │  ← Mountains
+│   /  \ /  \  /  \        │
+│  /    X    \/    \       │
+└──────────────────────────┘
+```
+
+**Sketch clouds/sky:**
+
+```
+┌──────────────────────────┐
+│  ~   ~      ~            │
+│    ~    ~      ~   ~     │  ← Soft clouds
+│       ~           ~      │
+│                          │
+└──────────────────────────┘
+```
+
+**Sketch abstract shapes:**
+
+```
+┌──────────────────────────┐
+│   ∿∿∿     ≈≈≈           │
+│      ∿∿  ≈≈   ∿∿        │  ← Waves, organic shapes
+│         ≈≈≈    ∿∿∿      │
+└──────────────────────────┘
+```
+
+**Purpose:** Hero sections, full-width backgrounds, feature images
+
+### 3. Product Images
+
+**Sketch the product outline:**
+
+```
+┌──────────────┐
+│   |‾‾‾‾|     │  ← Phone outline
+│   |    |     │
+│   | ●  |     │  ← Home button
+│   |____|     │
+└──────────────┘
+```
+
+```
+┌──────────────┐
+│   _____      │  ← Laptop screen
+│  |     |     │
+│  |_____|     │
+│  '-----'     │  ← Keyboard
+└──────────────┘
+```
+
+**Purpose:** Product photos, e-commerce images, feature showcases
+
+### 4. Icons / Illustrations
+
+**Sketch simple icon shapes:**
+
+```
+┌──────┐
+│  ⚙   │  ← Settings gear
+└──────┘
+```
+
+```
+┌──────┐
+│  ♥   │  ← Heart icon (favorites/likes)
+└──────┘
+```
+
+```
+┌──────┐
+│  ✓   │  ← Checkmark (success)
+└──────┘
+```
+
+**Purpose:** UI icons, feature illustrations, decorative graphics
+
+### 5. Abstract/Decorative Images
+
+**Use soft, flowing shapes:**
+
+```
+┌──────────────────────────┐
+│    ∞                     │
+│       ≋≋≋                │  ← Abstract flowing shapes
+│           ⌇⌇             │
+│              ∿∿∿         │
+└──────────────────────────┘
+```
+
+**Use geometric patterns:**
+
+```
+┌──────────────────────────┐
+│  ◆    ○    ▢             │
+│    ▢    ◆    ○           │  ← Geometric pattern
+│  ○    ▢    ◆             │
+└──────────────────────────┘
+```
+
+**Purpose:** Background patterns, decorative elements, brand graphics
+
+---
+
+## ❌ Discouraged: Generic "X" Marker
+
+**Why avoid X markers?**
+
+```
+┌──────────────┐
+│      X       │  ← Generic, uninformative
+└──────────────┘
+```
+
+**Problems with X markers:**
+
+- ❌ **No context** - Doesn't communicate what image shows
+- ❌ **No direction** - No guidance for content selection
+- ❌ **Intrusive** - Visually distracting in sketch
+- ❌ **Uninspiring** - Doesn't engage stakeholders
+- ❌ **Ambiguous** - Could be mistaken for "delete" or error
+
+**Only use X if:** Sketch is extremely rough/quick and image content is described elsewhere
+
+---
+
+## WDS Detection Rules
+
+### AI Image Detection
+
+When analyzing sketches, the AI should:
+
+1. **Look for rectangular containers** (image boundaries)
+2. **Check for sketched content inside** (faces, landscapes, products, shapes)
+3. **Interpret the sketch** to understand image purpose
+4. **Route to `image.md`** for specification
+
+### Example Detection
+
+**Sketch shows:**
+
+```
+┌──────────────────────────┐
+│    /\   /\    /\         │
+│   /  \ /  \  /  \        │  ← Mountains sketched
+│  /    X    \/    \       │
+└──────────────────────────┘
+```
+
+**AI interprets:**
+
+- Rectangle container detected
+- Mountain/landscape sketch inside
+- **Purpose:** Hero background image showing outdoor/nature scene
+- **Route to:** `image.md`
+- **Suggested content:** Mountain landscape, outdoor scenery, nature photography
+
+---
+
+## Benefits of Sketching Real Content
+
+### For Designers
+
+- ✅ Communicate visual intent clearly
+- ✅ Test composition and layout
+- ✅ Provide art direction
+- ✅ Inspire creative solutions
+
+### For AI Agents
+
+- ✅ Understand image purpose from context
+- ✅ Suggest appropriate image sources
+- ✅ Recommend image dimensions and aspect ratios
+- ✅ Generate meaningful alt text
+
+### For Developers
+
+- ✅ Understand what image represents
+- ✅ Know how to style and position image
+- ✅ Select appropriate placeholder images
+- ✅ Write meaningful alt text for accessibility
+
+### For Stakeholders
+
+- ✅ Visualize final design better
+- ✅ Provide meaningful feedback
+- ✅ Understand design intent
+- ✅ Approve with confidence
+
+---
+
+## Quick Reference
+
+| Image Type        | Sketch Technique                | Example             |
+| ----------------- | ------------------------------- | ------------------- |
+| **Portrait/Face** | Simple face with eyes and smile | ◠ ◠ ᵕ               |
+| **Landscape**     | Mountains, trees, horizon       | /\\ /\\ /\\         |
+| **Sky/Clouds**    | Wavy cloud shapes               | ~ ~ ~               |
+| **Product**       | Product outline/silhouette      | Phone, laptop shape |
+| **Icon**          | Simple icon shape               | ⚙ ♥ ✓             |
+| **Abstract**      | Flowing, organic shapes         | ∿ ≋ ∞               |
+| **Geometric**     | Shapes and patterns             | ◆ ○ ▢               |
+
+---
+
+## Summary
+
+**WDS Image Sketching Philosophy:**
+
+> "Sketch what you see, not just where it goes."
+
+**Guidelines:**
+
+- ✅ **Draw the actual content** - Faces, landscapes, products
+- ✅ **Use soft, organic shapes** - Clouds, waves for abstract images
+- ✅ **Keep it simple** - Quick sketches are fine, detail level matches sketch fidelity
+- ❌ **Avoid generic X markers** - Provides no useful context
+
+**Result:** Better communication, clearer intent, more useful AI analysis! 🎨✨
diff --git a/docs/learn/module-09-conceptual-sketching/lesson-05-sketch-text-strategy.md b/docs/learn/module-09-conceptual-sketching/lesson-05-sketch-text-strategy.md
new file mode 100644
index 000000000..ff88cc6cb
--- /dev/null
+++ b/docs/learn/module-09-conceptual-sketching/lesson-05-sketch-text-strategy.md
@@ -0,0 +1,509 @@
+# Sketch Text Strategy: Actual Text vs. Markers
+
+**Guidance for Creating WDS Sketches**
+
+---
+
+## The Two Approaches
+
+### 1. Actual Text (Recommended for Headlines)
+
+**Draw readable text directly in sketch**
+
+```
+┌─────────────────────────────────────┐
+│                                     │
+│    Every walk. on time.             │
+│    Every time.                      │
+│                                     │
+│    [Get Started - Free Forever]    │
+│                                     │
+└─────────────────────────────────────┘
+```
+
+**When to use:**
+
+- Headlines (H1, H2, H3)
+- Button labels
+- Navigation items
+- CTAs (calls-to-action)
+- Any short, important text
+
+**Why:**
+✅ Agent can read and interpret text
+✅ Provides content context
+✅ Shows character count naturally
+✅ Guides design decisions
+✅ Can still be refined during specification
+
+### 2. Horizontal Line Markers (For Body Text)
+
+**Draw lines to indicate text blocks**
+
+```
+┌─────────────────────────────────────┐
+│                                     │
+│ ─────────────────────────────────── │ ← Body text
+│ ─────────────────────────────────── │
+│ ─────────────────────────────────── │
+│ ─────────────────────────────────── │
+│                                     │
+└─────────────────────────────────────┘
+```
+
+**When to use:**
+
+- Body paragraphs
+- Long descriptions
+- Feature lists (when wording TBD)
+- Content where you want to show SIZE, not specific text
+
+**Why:**
+✅ Faster to sketch
+✅ Shows font size (distance between lines)
+✅ Shows font weight (line thickness)
+✅ Indicates capacity without committing to content
+✅ Focuses on layout, not copywriting
+
+---
+
+## Mixed Approach (Recommended)
+
+**Combine both methods for best results:**
+
+```
+┌──────────────────────────────────────────┐
+│                                          │
+│        Welcome to Dog Week               │  ← ACTUAL TEXT (H1)
+│                                          │
+│ ─────────────────────────────────────── │  ← LINE MARKERS
+│ ─────────────────────────────────────── │  ← (Body paragraph)
+│ ─────────────────────────────────────── │
+│ ─────────────────────────────────────── │
+│                                          │
+│        [Start Planning]                  │  ← ACTUAL TEXT (CTA)
+│                                          │
+└──────────────────────────────────────────┘
+```
+
+**Result:**
+
+- Headlines provide content guidance
+- Body text shows sizing and capacity
+- Buttons show clear actions
+- Fast to sketch, still informative
+
+---
+
+## Dog Week Example
+
+### Start Page Hero Sketch
+
+```
+┌─────────────────────────────────────────────┐
+│                                             │
+│     🐕 Dog Week                             │  ← Logo (actual)
+│                          [Sign In]  SE ▼    │  ← Buttons (actual)
+│                                             │
+│                                             │
+│       Every walk. on time.                  │  ← H1 (actual text)
+│       Every time.                           │
+│                                             │
+│  ────────────────────────────────────────  │  ← Subtext (markers)
+│  ────────────────────────────────────────  │
+│                                             │
+│  [start planning - free forever]            │  ← CTA (actual)
+│                                             │
+│  ┌───────────────────────────────────────┐ │
+│  │                                       │ │
+│  │      [Person with dog image]          │ │  ← Image placeholder
+│  │                                       │ │
+│  └───────────────────────────────────────┘ │
+│                                             │
+│  Never ask whose turn it is again           │  ← Small text (actual)
+│                                             │
+│  ─────────────────────────────────────────│  ← Feature description
+│  ─────────────────────────────────────────│  ← (markers)
+│  ─────────────────────────────────────────│
+│                                             │
+└─────────────────────────────────────────────┘
+```
+
+### Agent Analysis
+
+**Agent reads:**
+
+1. **Logo text:** "Dog Week" → suggests as logo content
+2. **H1 actual text:** "Every walk. on time. Every time." → suggests as starting headline
+3. **Marker analysis:** 2 thin lines → body text, spacing matches icon size (~16-20px), ~120-140 chars
+4. **CTA actual text:** "start planning - free forever" → suggests as button label
+5. **Small actual text:** "Never ask whose turn it is again" → suggests as supporting text
+6. **Marker analysis:** 3 thin lines → feature description, spacing matches icon size (~16-20px), ~180-210 chars
+
+**Agent output:**
+
+```
+I found text in your sketch: "Every walk. on time. Every time."
+
+Would you like to use this for the Primary Headline, or change it?
+
+EN: Every walk. on time. Every time.
+SE: [Your Swedish translation]
+```
+
+**User can:**
+
+- ✅ Keep the sketch text
+- ✅ Change it completely
+- ✅ Refine it slightly
+
+---
+
+## Technical Details for Markers
+
+### Line Thickness → Font Weight (Relative)
+
+```
+═══════════════════  ← Thickest = Bold (700)
+───────────────────  ← Medium = Medium (500)
+─────────────────────  ← Thinnest = Regular (400)
+```
+
+**Compare relative thickness within the sketch, not absolute pixels.**
+
+### Distance Between Lines → Font Size (Context-Based)
+
+```
+═══════════════════
+      ↕ ~Button Height  ← H1 (~40-48px)
+═══════════════════
+
+───────────────────
+    ↕ ~Icon Size        ← Body (~16-20px)
+───────────────────
+```
+
+**Use UI elements (buttons, icons, scrollbars) as scale references.**
+
+### Complete Example
+
+```
+═══════════════════  ← Thickest lines in sketch
+      ↕ ~Button Height
+═══════════════════  ← Thickest lines in sketch
+```
+
+**Analysis:**
+
+- Thickness: Bold (relative to other text)
+- Distance: Matches button height (~40-48px)
+- Lines: 2
+- Capacity: ~50-60 chars
+
+---
+
+## Agent Behavior
+
+### When Sketch Has Actual Text
+
+**Agent says:**
+
+```
+I found text in your sketch: "Every walk. on time."
+
+Content for Primary Headline:
+
+EN: Every walk. on time.
+SE:
+
+(You can keep the sketch text or change it)
+```
+
+**Benefits:**
+
+- Pre-filled starting point
+- Still editable
+- Saves time
+- Provides context
+
+### When Sketch Has Line Markers
+
+**Agent says:**
+
+```
+Text placeholder detected:
+- 4 horizontal lines
+- Line thickness: Thinnest → Regular weight
+- Distance: Matches icon/scrollbar size → ~16-20px font
+- Capacity: ~240-280 characters
+
+Content for Feature Description:
+
+Please provide content in one language, and I'll suggest translations!
+
+EN:
+```
+
+**User provides:**
+
+```
+EN: Organize your family around dog care. Assign walks, track feeding schedules, and never miss a walk again.
+```
+
+**Agent suggests:**
+
+```
+Great! Here are translation suggestions:
+
+SE: Organisera din familj kring hundvård. Tilldela promenader, spåra matscheman och missa aldrig en promenad igen.
+
+Does this work, or would you like to adjust it?
+```
+
+**Benefits:**
+
+- Clear capacity guidance
+- Agent suggests translations
+- User reviews and confirms
+- Helps with content length
+
+---
+
+## Workflow: From Analysis to Specification
+
+When AI analyzes sketch text markers, the workflow is:
+
+### Step 1: AI Analyzes Sketch
+
+Agent detects text markers and estimates properties:
+
+```
+Line thickness: Thicker than body text → Bold font weight
+Spacing between pairs: Similar to button height → ~40-48px font size estimate
+Line-height: ~1.2 (calculated from font size)
+Character capacity: ~35 characters per line
+```
+
+### Step 2: AI Presents Estimates with Reasoning
+
+Agent shows analysis WITH explanation of how estimates were derived:
+
+```markdown
+- **Style**:
+  - Font weight: Bold (from thick line markers, relative to body text)
+  - Font size: 42px (est. from spacing matching button height)
+  - Line-height: 1.2 (est. calculated as font-size × 1.2)
+```
+
+**Why show reasoning?**
+
+- Designer understands **how** AI interpreted the sketch
+- Designer can judge if estimation logic makes sense
+- Makes it easy to adjust if sketch measurements were different
+- Builds trust through transparency
+
+### Step 3: Designer Confirms/Adjusts
+
+Designer reviews estimates and either:
+
+1. **Confirms** - "Yes, 42px based on button-height spacing is correct"
+2. **Adjusts** - "Actually, the spacing is larger, make it 48px instead"
+3. **Overrides** - "Ignore the sketch measurements, I want it to be 56px"
+
+### Step 4: Finalize Specification
+
+Agent updates spec with confirmed values, removes estimation notes:
+
+```markdown
+- **Style**:
+  - Font weight: Bold
+  - Font size: 48px
+  - Line-height: 1.15
+```
+
+Clean, production-ready specification with no estimation artifacts.
+
+**Key Principle:**
+
+- **All estimated values are spelled out explicitly** (not hidden)
+- **Marked with (est.) label** to indicate AI interpretation
+- **Designer confirms or adjusts** each estimated value
+- **Label removed** once designer specifies actual values
+
+This ensures **transparency** about which values came from AI sketch analysis vs. designer specification.
+
+---
+
+## Best Practices
+
+### ✅ DO:
+
+1. **Use actual text for headlines**
+   - Provides content direction
+   - Agent can read and suggest
+   - Still changeable during spec
+
+2. **Use markers for body text**
+   - Shows sizing without committing
+   - Faster to sketch
+   - Focuses on layout
+
+3. **Mix both approaches**
+   - Headlines = actual text
+   - Body = markers
+   - Best of both worlds
+
+4. **Keep sketch text informal**
+   - It's a suggestion, not final
+   - Can be refined later
+   - Agent will ask to confirm/change
+
+### ❌ DON'T:
+
+1. **Don't use Lorem Ipsum**
+   - Not helpful for context
+   - Agent can't interpret
+   - Use real(ish) content or markers
+
+2. **Don't commit too early**
+   - Sketch text is guidance
+   - Refinement happens in spec phase
+   - Stay flexible
+
+3. **Don't mix for same element**
+   - Either actual text OR markers
+   - Not both for one text block
+   - Confuses analysis
+
+---
+
+## Workflow Integration
+
+### During Sketching
+
+**Designer:**
+
+```
+1. Draw page layout
+2. Add ACTUAL TEXT for headlines/buttons
+3. Add LINE MARKERS for body paragraphs
+4. Show font weight (thickness)
+5. Show font size (distance)
+```
+
+### During Specification (Phase 4)
+
+**Agent:**
+
+```
+1. Analyze sketch
+2. Read any actual text found
+3. Suggest sketch text as starting point
+4. Analyze markers for sizing
+5. Request final content
+6. Allow refinement
+7. Document in spec
+```
+
+**User:**
+
+```
+1. See sketch text as suggestion
+2. Keep, change, or refine
+3. Add translations
+4. Confirm length fits capacity
+```
+
+---
+
+## Real Dog Week Flow
+
+### Sketch Shows:
+
+```
+Every walk. on time. Every time.  ← Actual text in sketch
+```
+
+### Agent Says:
+
+```
+I found text in your sketch: "Every walk. on time. Every time."
+
+Let me suggest translations...
+
+Suggested content for Primary Headline:
+
+EN: Every walk. on time. Every time.
+SE: Varje promenad. i tid. Varje gång.
+
+These are my suggestions. Do they work?
+
+1. Use these translations
+2. Adjust translations
+3. Manual input
+
+Choice [1/2/3]:
+```
+
+### User Says:
+
+```
+1  ← Accepts!
+```
+
+Or refines:
+
+```
+2
+
+SE: Varje promenad. Punktligt. Varje gång.  ← Adjusted
+```
+
+EN: Every walk. on time. Every time. ← Keeps it!
+SE: Varje promenad. i tid. Varje gång.
+
+````
+
+### Specification Result:
+
+```markdown
+#### Primary Headline
+**OBJECT ID**: `start-hero-headline`
+- **Component**: H1 heading
+- **Position**: Center of hero
+- **Style**: Bold, 42px, line-height 1.2
+- **Content**:
+  - EN: "Every walk. on time. Every time."
+  - SE: "Varje promenad. i tid. Varje gång."
+````
+
+**Result:** Sketch text became final content! ✅
+
+---
+
+## Summary
+
+| Element Type        | Sketch Method | Agent Behavior                               |
+| ------------------- | ------------- | -------------------------------------------- |
+| **Headlines**       | Actual text   | Reads & suggests as starting content         |
+| **Buttons**         | Actual text   | Reads & suggests as button label             |
+| **Navigation**      | Actual text   | Reads & suggests as nav items                |
+| **Body paragraphs** | Line markers  | Analyzes for size/capacity, requests content |
+| **Descriptions**    | Line markers  | Analyzes for size/capacity, requests content |
+
+**Golden Rule:**
+
+- **Important/short text** = Draw actual text
+- **Long/placeholder text** = Use line markers
+- **Mix both** for best results
+
+**Remember:**
+
+- Sketch text is a suggestion, not final
+- Agent will ask to confirm or change
+- Refinement happens during specification
+- Stay flexible, iterate as needed
+
+---
+
+**Use actual text for headlines, markers for body text!** 📝✨
diff --git a/docs/learn/module-09-conceptual-sketching/lesson-06-ai-wireframe-generation.md b/docs/learn/module-09-conceptual-sketching/lesson-06-ai-wireframe-generation.md
new file mode 100644
index 000000000..000e88081
--- /dev/null
+++ b/docs/learn/module-09-conceptual-sketching/lesson-06-ai-wireframe-generation.md
@@ -0,0 +1,211 @@
+# Module 09: Conceptual Sketching
+
+## Lesson 6: AI Wireframe Generation
+
+**Using Nano Banana for wireframe exploration — what works, what doesn't**
+
+---
+
+## What This Is
+
+AI image generators like Nano Banana (Gemini 2.5 Flash / Gemini 3 Pro) can generate wireframe-style layouts from page specifications. You describe the structure of a page, and the AI creates a grayscale wireframe image.
+
+This lesson covers what we've learned from extensive testing with real projects.
+
+---
+
+## The Promise
+
+In theory, AI wireframe generation is compelling:
+
+1. Describe a page layout in text
+2. AI generates a clean wireframe image
+3. Transform wireframe into a styled mockup
+4. Iterate until satisfied
+
+**The reality is more nuanced.** AI wireframes work well for some things and poorly for others.
+
+---
+
+## What AI Wireframes Are Good At
+
+### Layout Exploration
+
+AI can quickly generate different layout arrangements from a page specification. You can see how sections stack, how the visual hierarchy flows, and whether the proportions feel right.
+
+> "Generate a grayscale wireframe: Header with logo and nav, full-width hero image with overlay text, 3-column feature cards, about section with photo left and text right, footer with 4 columns."
+
+**Result:** A clean layout showing all sections in correct proportion. Useful for validating that the page structure makes sense.
+
+### Section Proportions
+
+AI wireframes are good at showing relative sizes — how much space the hero takes versus the content area, whether the footer feels proportional, whether there's enough breathing room.
+
+### Quick Alternatives
+
+Want to see the same content in a different arrangement? Change "photo left, text right" to "photo right, text left" and regenerate. Faster than redrawing.
+
+### Mood and Direction
+
+Wireframes generated from detailed specs can show the overall feeling of a page — dense vs. airy, image-heavy vs. text-heavy, structured vs. organic.
+
+---
+
+## What AI Wireframes Struggle With
+
+### All Text Is Garbled
+
+AI image generators cannot render readable text. Every word in the wireframe will be gibberish that looks like text from a distance but is unreadable up close.
+
+**This is the single biggest limitation.** You can never trust text in an AI-generated wireframe.
+
+### Wireframe Labels Leak Into Mockups
+
+If you label sections in your wireframe ("HERO SECTION", "TRUST CARDS", "FOOTER"), those labels will bleed through when you transform the wireframe into a styled mockup. The AI treats them as visual elements to preserve.
+
+**Prevention:** Use clean, unlabeled wireframes. Describe structure through layout, not annotations.
+
+### 2x2 Grids Flatten to 1x4 Rows
+
+When you specify "2 rows of 2 cards," the AI often produces a single row of 4 cards instead. Two-dimensional grid layouts are a consistent weak point.
+
+**Workaround:** Explicitly describe "2 rows, 2 columns, stacked vertically" — but even this doesn't always work.
+
+### You Cannot Edit the Result
+
+This is the critical limitation. An AI wireframe is an image. You cannot:
+
+- Move an element
+- Resize a section
+- Add a missing component
+- Adjust spacing
+
+If something is wrong, you must regenerate the entire thing. This makes iteration slow and frustrating compared to tools where you can simply drag and adjust.
+
+### Logos Cannot Be Reproduced
+
+The AI will generate something that looks "inspired by" your logo, but it won't be your actual logo. Wireframes should use a simple placeholder rectangle for logos.
+
+### Structural Changes Require Full Regeneration
+
+If you want to move a section, swap the order of two elements, or change the column count — you must regenerate from scratch. Edit mode (transforming an existing image) cannot restructure layout.
+
+### Broad Edits Cause Section Loss
+
+In edit mode, instructions like "make everything look more premium" can cause entire sections to disappear. The AI struggles with broad changes — targeted, specific edits work much better.
+
+---
+
+## The Two-Step Pipeline
+
+Despite its limitations, AI wireframe generation works best in a two-step pipeline:
+
+### Step 1: Generate Wireframe from Spec
+
+Use **generate mode** with a detailed layout description:
+
+```
+Grayscale digital wireframe, clean boxes and placeholder text.
+
+Header bar: logo placeholder left, navigation links center, contact info right.
+Hero section: full-width photo area, large heading overlay, subtitle, CTA button.
+About section: photo left (40%), text right (60%) with heading and paragraph.
+Services section: 3 equal cards in a row, each with icon, heading, description.
+Footer: 4 columns with links, contact details, social icons.
+```
+
+**Settings:**
+- Mode: `generate`
+- Model: `pro` (better structural accuracy)
+- Aspect ratio: `9:16` (full page scroll) or `16:9` (desktop viewport)
+- System instruction: "Clean grayscale wireframe with boxes and shapes. No colors, no photography."
+
+### Step 2: Transform to Mockup (Optional)
+
+Use **edit mode** with the wireframe as input image:
+
+```
+Transform this wireframe into a styled web page mockup.
+Replace gray boxes with realistic content.
+Hero image: Swedish countryside landscape.
+Color palette: navy blue headers, white backgrounds, warm gray accents.
+```
+
+**Settings:**
+- Mode: `edit`
+- Input image 1: The wireframe (layout source)
+- Input image 2-3: Reference photos for style
+- Aspect ratio: **Must match wireframe** (critical — changing it causes content loss)
+
+**Result:** Layout-accurate mockup, but with garbled text and possible wireframe label leakage.
+
+---
+
+## When to Use AI Wireframes
+
+### Good Use Cases
+
+- **Early exploration** — "What would this spec look like as a page?"
+- **Stakeholder previews** — Quick visual to discuss layout direction
+- **Layout validation** — Does the section order and proportion feel right?
+- **Mood visualization** — Getting a sense of how dense or airy the page will be
+
+### Poor Use Cases
+
+- **Iterative refinement** — Can't adjust elements, must regenerate everything
+- **Detailed design** — Text is garbled, grids flatten, details get lost
+- **Production reference** — Not accurate enough for developers to build from
+- **Client presentations** — Garbled text looks unprofessional
+
+---
+
+## AI Wireframes vs. Hand Sketching vs. Excalidraw
+
+| | AI Wireframes | Hand Sketch | Excalidraw |
+|---|---|---|---|
+| **Speed to first version** | Fast (seconds) | Fast (minutes) | Medium (minutes) |
+| **Editability** | None (regenerate) | Redraw | Full (drag, resize) |
+| **Text quality** | Garbled | Readable | Readable |
+| **Iteration speed** | Slow (regenerate) | Fast (redraw) | Fastest (edit in place) |
+| **Layout accuracy** | Approximate | As drawn | As drawn |
+| **Collaboration** | View only | Photo + discuss | Share + co-edit |
+| **Best for** | Quick preview | Thinking out loud | Iterative design |
+
+**Recommendation:** Use hand sketching or Excalidraw for wireframing. Use AI generation for image assets (hero photos, card images, illustrations).
+
+---
+
+## Critical Rules
+
+If you do use AI wireframe generation:
+
+1. **Always pin `aspect_ratio` in edit mode** — The #1 cause of content loss
+2. **One targeted change per edit** — Never combine multiple changes
+3. **Regenerate rather than edit for structural changes** — Moving sections, changing column counts
+4. **Use `pro` model for wireframes** — Better structural accuracy than `flash`
+5. **No section labels in wireframes** — They leak into mockup transforms
+6. **Maximum 2-3 edit iterations** — Quality degrades after that; regenerate from wireframe
+
+---
+
+## The Verdict
+
+AI wireframe generation is a **rapid exploration tool**, not a production wireframe tool. It's useful for getting a quick visual sense of a page structure, but it cannot replace editable tools like Excalidraw or hand sketching for iterative design work.
+
+The non-editable nature of AI wireframes is the fundamental problem. In design, you need to move things around, try different arrangements, respond to feedback. An image you can only regenerate from scratch doesn't support this workflow.
+
+**Use AI wireframes for:** Quick layout previews, mood visualization, early exploration.
+**Use Excalidraw/hand sketching for:** Iterative wireframing, detailed layout work, collaborative design.
+**Use Nano Banana for:** Image asset production (hero photos, card images, seasonal photos, persona illustrations). This is where it truly shines.
+
+---
+
+## What's Next
+
+These wireframes — whether hand-drawn, Excalidraw, or AI-generated — become the foundation for storyboarding (Module 10) and specifications (Module 11). The method doesn't matter. Meeting the standard does: concrete, complete, and rough.
+
+---
+
+[Back to Lesson 5](lesson-05-sketch-text-strategy.md) | [Back to Module Overview](module-09-conceptual-sketching-overview.md)
+
+*Part of Module 09: Conceptual Sketching*
diff --git a/docs/learn/module-09-conceptual-sketching/module-09-conceptual-sketching-overview.md b/docs/learn/module-09-conceptual-sketching/module-09-conceptual-sketching-overview.md
new file mode 100644
index 000000000..396f778b8
--- /dev/null
+++ b/docs/learn/module-09-conceptual-sketching/module-09-conceptual-sketching-overview.md
@@ -0,0 +1,243 @@
+# Module 09: Conceptual Sketching
+
+**Time: 45 min | Agent: Freya | Phase: Design | Focus: UX**
+
+---
+
+## Visualize the Default State
+
+You need to see it. How you get there is up to you.
+
+This is **keyframe 0** — the default state of each logical view, what the user sees when the page first loads.
+
+Everything that happens *after* (interactions, animations, state changes) comes in Module 10: Storyboarding.
+
+---
+
+## Why Visualize First?
+
+You need to see it before you can specify it. Visualization is faster than words for spatial problems.
+
+Sketching is one way to visualize. Not the only way.
+
+- Where does this element go?
+- How big should it be?
+- What's the visual hierarchy?
+- Does this layout make sense?
+
+You can't answer these questions in a specification. You have to see it.
+
+---
+
+## The Conceptual Mindset
+
+### Low Fidelity on Purpose
+
+Rough visuals prevent attachment. If it looks finished, you'll defend it.
+
+Keep it ugly. Keep it fast. Keep it flexible.
+
+### Quantity Over Quality
+
+First idea is rarely best. Explore 3-5 approaches before picking one.
+
+### Think Out Loud
+
+Visualize while talking through the scenario. What does the user see first? What draws their attention? Where do they click?
+
+---
+
+## Entry Points
+
+You don't have to start from scratch.
+
+| Entry Point | How It Works |
+|-------------|--------------|
+| **Workshop** | Talk through the screen together — conversation shapes the concept |
+| **Visualize** | Send any visual — AI analyzes and refines |
+| **Example** | "I like how this site does it" → AI extracts patterns |
+| **Dream it up** | "Show me 3 ways to lay out a signup form" → AI generates options |
+
+**Same output. Different starting points.**
+
+---
+
+## The Collaborative Workflow
+
+Working with Freya, you can take two paths:
+
+**Path A: Already Sketched**
+1. Sketch on paper or tablet
+2. Share photo with Freya
+3. Get strategic feedback connected to your personas
+
+**Path B: Not Yet Sketched**
+1. Discuss the page with Freya
+2. Explore options together
+3. Sketch based on discussion
+4. Share for feedback
+
+Either way, the sketch becomes the thinking tool.
+
+---
+
+## Ways to Visualize
+
+You can send anything visual. All methods work. Use them interchangeably within a scenario or storyboard.
+
+| Method | When to Use |
+|--------|-------------|
+| **Pixel-perfect Figma** | You already have detailed designs |
+| **Wireframes** | Structure without visual noise |
+| **Hand sketch (paper)** | Fastest way to think out loud |
+| **Hand sketch (digital)** | iPad, tablet, stylus |
+| **Whiteboard concepts** | Rough, collaborative, big picture |
+| **Screen dumps** | "This feature from another product" |
+| **Generated images** | AI creates options for you |
+| **ASCII art** | Quick text-based layouts from AI |
+| **Vibe coded example** | Quick prototype → agent screenshots states |
+
+Mix and match. One view might be a polished wireframe, another a napkin sketch. Doesn't matter — as long as it communicates the concept.
+
+---
+
+## The Great Divide
+
+You can make something amazing with AI. Beautiful mockups. Working prototypes. Impressive demos.
+
+But then what?
+
+**There's a great divide between conceptualizing and producing.**
+
+In the middle stands the specification — with its static visualization.
+
+```
+┌───────────────┐         ┌───────────────┐         ┌───────────────┐
+│ CONCEPTUALIZE │ ──────► │ SPECIFICATION │ ──────► │   PRODUCTION  │
+│               │         │               │         │     CODE      │
+│ Cool mockups  │         │ Static visual │         │ Real software │
+│ AI demos      │         │ + behavior    │         │               │
+│ Prototypes    │         │ + content     │         │               │
+└───────────────┘         └───────────────┘         └───────────────┘
+    Creative                  The Bridge                Deliverable
+```
+
+No matter how cool your concept — you still create a specification. That's what gets built.
+
+---
+
+## The Freya Method
+
+Freya helps you explore visually while staying connected to strategy:
+
+> "Based on Felix's fear of complicated signups, what's the simplest layout?"
+> "Here are 3 approaches — which resonates with your trigger map?"
+> "I notice this sketch has 5 fields. Your spec says 3. Which is right?"
+
+She keeps you connected to strategy while exploring form.
+
+---
+
+## What to Visualize
+
+For each logical view in your scenario:
+
+1. **Overall layout** — Where do major elements go?
+2. **Visual hierarchy** — What's most important?
+3. **User flow** — Where does the eye travel?
+4. **Key interactions** — What's clickable?
+
+---
+
+## Not Yet
+
+At this stage, don't worry about:
+
+- Colors (too early)
+- Final typography (too early)
+- Exact spacing (too early)
+- Animations (too early)
+
+Those come in Visual Design (Module 14).
+
+---
+
+## Quick Visualization Patterns
+
+Whatever method you use, these patterns communicate clearly.
+
+### Boxes and Labels
+
+```
+┌─────────────────────┐
+│      HEADER         │
+├─────────────────────┤
+│                     │
+│   [Form Area]       │
+│                     │
+├─────────────────────┤
+│   [ CTA Button ]    │
+└─────────────────────┘
+```
+
+### Variants
+
+Sketch the same screen 3 different ways. Label them A, B, C. Pick the best.
+
+---
+
+## Output
+
+Rough sketches showing the **default state** of each logical view in your scenario.
+
+Not polished. Not pretty. Just clear enough to:
+- Understand what the user sees first
+- Know where key elements are positioned
+- Serve as keyframe 0 for storyboarding
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Too polished | Keep it rough |
+| Only one idea | Explore 3 variants |
+| Designing in isolation | Reference your scenario |
+| Starting with edge cases | Focus on default state |
+| Including colors/typography | Save for Module 14 |
+
+---
+
+## Practice
+
+Take one scenario from Module 08:
+
+1. Identify the key logical views
+2. Visualize each one (use any entry point)
+3. Explore variants
+4. Discuss with Freya
+
+---
+
+## Learn More
+
+- **[Lesson 1: Visualize First](lesson-01-visualize-first.md)** — Why seeing comes before specifying
+- **[Lesson 2: Sketching Techniques](lesson-02-sketching-techniques.md)** — Practical methods for all visualization approaches
+- **[Lesson 3: Why Hand Sketching is Still King](lesson-03-why-hand-sketching.md)** — The case for paper and tablet in the AI era
+- **[Lesson 4: Image Sketching Best Practices](lesson-04-image-sketching-best-practices.md)** — How to represent images in UI sketches
+- **[Lesson 5: Sketch Text Strategy](lesson-05-sketch-text-strategy.md)** — Actual text vs. markers in sketches
+- **[Lesson 6: AI Wireframe Generation](lesson-06-ai-wireframe-generation.md)** — Using Nano Banana for wireframe exploration — what works, what doesn't
+- **[Tutorial: Sketch Your Views](tutorial-09.md)** — Hands-on practice with Freya
+
+---
+
+## Next Module
+
+**[Module 10: Storyboarding →](../module-10-storyboarding/module-10-storyboarding-overview.md)**
+
+Show how elements transform within each view — keyframe by keyframe.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-09-conceptual-sketching/tutorial-09.md b/docs/learn/module-09-conceptual-sketching/tutorial-09.md
new file mode 100644
index 000000000..811afa4f3
--- /dev/null
+++ b/docs/learn/module-09-conceptual-sketching/tutorial-09.md
@@ -0,0 +1,381 @@
+# Tutorial 09: Sketch Your Views
+
+**Hands-on guide to visualizing logical views with Freya**
+
+---
+
+## Overview
+
+This tutorial walks you through creating conceptual sketches for each logical view in your scenarios.
+
+**Time:** 30-40 minutes
+**Prerequisites:** Scenario outlines completed (Module 08)
+**Agent:** Freya
+**What you'll create:** Rough sketches showing default state for each logical view
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- Your scenario outlines (from Module 08)
+- A way to sketch (paper, tablet, or just conversation)
+- Your Trigger Map for persona reference
+
+**Freya will help you:**
+
+- Explore multiple layout options
+- Connect visual decisions to personas
+- Identify gaps before detailed specification
+- Refine through conversation
+
+---
+
+## Step 1: Choose Your Entry Point (2 min)
+
+### Decide how you'll visualize:
+
+**Option A: Workshop (conversation-first)**
+> "I want to talk through what this screen should contain, then you help me visualize it."
+
+**Option B: You sketch first**
+> "I'll sketch this on paper and share a photo for your feedback."
+
+**Option C: AI generates options**
+> "Show me 3 different layout approaches for this screen."
+
+**Option D: Reference example**
+> "I like how [product] handles this. Can we use similar patterns?"
+
+All paths lead to the same outcome. Choose what feels natural.
+
+---
+
+## Step 2: Select First Scenario (2 min)
+
+### Start with your most important scenario:
+
+**You say:**
+> "Let's sketch the views for S01-User-Registration. Starting with the landing page — the first logical view in the journey."
+
+**Freya acknowledges:**
+> "Perfect. S01-User-Registration takes the user from landing page to welcome screen. Let's start with the landing page — keyframe 0, the default state when the page loads."
+
+---
+
+## Step 3: Explore the First View (10 min)
+
+### If using Workshop approach:
+
+**Freya asks:**
+> "What's the primary purpose of this landing page? What must the user understand immediately?"
+
+**You respond:**
+> "They need to understand what Dog Week is and feel confident it's worth trying. The primary action is clicking 'Start Free.'"
+
+**Freya continues:**
+> "For Felix, who fears complicated tools, how prominent should that CTA be? And what supporting information helps him feel confident?"
+
+**Work through:**
+- What elements are needed?
+- What's the visual hierarchy?
+- Where does the eye flow?
+
+**Freya might suggest:**
+```
+Here's one approach:
+
+┌─────────────────────────────────┐
+│  Dog Week            [Login]   │
+├─────────────────────────────────┤
+│                                 │
+│     Coordinate Your Family's    │
+│          Dog Care               │
+│                                 │
+│     Everyone knows what to do.  │
+│     No more missed walks.       │
+│                                 │
+│     [   Start Free   ]          │
+│                                 │
+│     No credit card required     │
+│                                 │
+└─────────────────────────────────┘
+
+The CTA is prominent and the risk-reducer
+("No credit card") addresses Felix's try-first
+mentality.
+```
+
+### If sketching yourself:
+
+1. Do 3 quick variants (60 seconds each)
+2. Photo/scan and share with Freya
+3. Discuss which elements work
+
+**Freya responds:**
+> "I see variant B has the CTA above the fold and minimal text. This aligns well with Felix. Variant C has more social proof — should we consider adding testimonials?"
+
+---
+
+## Step 4: Select Direction (5 min)
+
+### Choose the layout that best serves the user:
+
+**Freya helps evaluate:**
+> "Looking at these options, which layout best addresses Felix's need for simplicity and quick start?"
+
+**You decide:**
+> "I think the centered layout with minimal distractions. It keeps the focus on the primary action."
+
+**Freya confirms:**
+> "Got it. The centered single-column layout becomes our selected direction for the landing page. Ready to sketch the next view?"
+
+The WHY behind these decisions will be documented later in specifications (Module 11).
+
+---
+
+## Step 5: Continue Through Scenario (10 min)
+
+### Move to next logical view:
+
+**Freya prompts:**
+> "Landing page is sketched. The next view in S01 is the Signup Form. What happens when Felix clicks 'Start Free'?"
+
+**Repeat the process:**
+1. What's the purpose of this view?
+2. Explore layout options
+3. Connect to persona
+4. Select direction
+
+**Example for Signup Form:**
+
+```
+Signup Form - S01-User-Registration - View 02
+
+┌─────────────────────────────────┐
+│  Dog Week            [Login]   │
+├─────────────────────────────────┤
+│                                 │
+│     Create Your Account         │
+│                                 │
+│   ┌───────────────────────┐     │
+│   │ Email                 │     │
+│   └───────────────────────┘     │
+│                                 │
+│   ┌───────────────────────┐     │
+│   │ Password              │     │
+│   └───────────────────────┘     │
+│                                 │
+│   [    Create Account    ]      │
+│                                 │
+│   ← Back                        │
+│                                 │
+└─────────────────────────────────┘
+
+Layout: Centered form, minimal distractions
+Elements: Email field, password field, CTA button, back link
+```
+
+---
+
+## Step 6: Complete the Scenario (5 min)
+
+### Sketch remaining views:
+
+For S01-User-Registration:
+- ✓ Landing Page
+- ✓ Signup Form
+- Email Verification Prompt
+- Welcome Screen
+
+**Freya tracks progress:**
+> "We have 2 of 4 views sketched. The Email Verification Prompt is next — this is a transitional view. What does Felix need to see and do here?"
+
+### Keep moving:
+
+Don't over-polish. Rough and complete is the goal.
+
+---
+
+## Step 7: Review and Refine (5 min)
+
+### Look at the complete flow:
+
+**Freya presents:**
+> "Here's the full S01-User-Registration journey with sketches:
+>
+> 1. Landing Page — Value prop, prominent CTA
+> 2. Signup Form — Minimal 2-field form
+> 3. Email Verification — Check inbox prompt
+> 4. Welcome Screen — Next step guidance
+>
+> Does this flow feel right for Felix?"
+
+### Check for gaps:
+
+- Does each view connect smoothly to the next?
+- Is there any missing information?
+- Does the layout serve the user's needs?
+
+### Adjust as needed:
+
+> "Looking at this, I think the welcome screen needs more guidance. Felix just signed up — what should he do next?"
+
+---
+
+## Step 8: Save and Organize (3 min)
+
+### Save sketches with scenarios:
+
+```
+C-UX-Scenarios/
+└── S01-User-Registration/
+    ├── scenario-overview.md
+    ├── sketches/
+    │   ├── 01-landing-page-sketch.png
+    │   ├── 02-signup-form-sketch.png
+    │   ├── 03-email-verification-sketch.png
+    │   └── 04-welcome-screen-sketch.png
+```
+
+Or keep sketches in the chat:
+
+> "These sketches are saved in our conversation. Ready to reference when we create detailed specifications and document the WHY behind each decision."
+
+---
+
+## What You've Created
+
+### For each logical view:
+
+- **Rough sketch** showing default state layout
+- **Selected direction** identified through exploration
+- **Sketches ready** to serve as keyframe 0 for storyboarding
+
+### Example deliverable:
+
+```markdown
+# S01-User-Registration Sketches
+
+## View 01: Landing Page
+[Sketch image or ASCII layout]
+
+┌─────────────────────────────────┐
+│  Dog Week            [Login]   │
+├─────────────────────────────────┤
+│                                 │
+│     Coordinate Your Family's    │
+│          Dog Care               │
+│                                 │
+│     Everyone knows what to do.  │
+│     No more missed walks.       │
+│                                 │
+│     [   Start Free   ]          │
+│                                 │
+│     No credit card required     │
+│                                 │
+└─────────────────────────────────┘
+
+Selected: Single-column, centered, mobile-first
+
+## View 02: Signup Form
+[Sketch image or ASCII layout]
+
+┌─────────────────────────────────┐
+│  Dog Week            [Login]   │
+├─────────────────────────────────┤
+│                                 │
+│     Create Your Account         │
+│                                 │
+│   ┌───────────────────────┐     │
+│   │ Email                 │     │
+│   └───────────────────────┘     │
+│                                 │
+│   ┌───────────────────────┐     │
+│   │ Password              │     │
+│   └───────────────────────┘     │
+│                                 │
+│   [    Create Account    ]      │
+│                                 │
+│   ← Back                        │
+│                                 │
+└─────────────────────────────────┘
+
+Selected: Centered minimal form, 2 fields only
+```
+
+---
+
+## What Happens Next
+
+### These sketches become:
+
+- **Storyboards** (Module 10) — What changes after the default state
+- **Specifications** (Module 11) — Detailed documentation of every element
+
+### Your sketches inform:
+
+- Layout structure
+- Element hierarchy
+- User flow
+- Key interactions
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Keep sketches rough
+- Explore multiple variants
+- Focus on WHAT appears on screen
+- Move quickly through all views
+- Select a direction for each view
+
+**DON'T:**
+
+- Polish too early
+- Settle on first idea
+- Skip exploring alternatives
+- Ignore mobile considerations
+- Include colors/typography yet
+
+---
+
+## Common Questions
+
+**Q: Do I need to be able to draw?**
+A: No. Boxes and labels communicate structure. Freya can generate visual options too.
+
+**Q: How detailed should sketches be?**
+A: Just detailed enough to understand layout and hierarchy. Details come in specifications.
+
+**Q: What if I change my mind later?**
+A: That's the point of sketching. Better to change a rough sketch than a polished mockup.
+
+**Q: Should I sketch every state?**
+A: Just the default state for now. Other states (loading, error, success) come in storyboarding.
+
+---
+
+## You've Completed Module 09!
+
+**Your logical views are visualized.** You have:
+- Rough sketches showing default state for each view
+- Selected layout directions identified through exploration
+- Keyframe 0 ready for storyboarding
+
+---
+
+## Next Module
+
+**[Module 10: Storyboarding →](../module-10-storyboarding/module-10-storyboarding-overview.md)**
+
+Time to show what happens AFTER the default state — the transformations within each view.
+
+---
+
+[← Back to Lesson 3](lesson-03-why-hand-sketching.md) | [Back to Module Overview](module-09-conceptual-sketching-overview.md)
+
+*Part of Module 09: Conceptual Sketching*
diff --git a/docs/learn/module-10-storyboarding/lesson-01-transformations.md b/docs/learn/module-10-storyboarding/lesson-01-transformations.md
new file mode 100644
index 000000000..7d988f9ce
--- /dev/null
+++ b/docs/learn/module-10-storyboarding/lesson-01-transformations.md
@@ -0,0 +1,392 @@
+# Module 10: Storyboarding
+
+## Lesson 1: Transformations Within a View
+
+**What happens after the page loads**
+
+---
+
+## Pages Aren't Static
+
+You have sketches of your pages now. The default state — keyframe 0.
+
+But pages don't stay frozen. Things change.
+
+- Buttons get clicked
+- Forms get filled
+- Data loads in
+- Errors appear
+- Animations play
+
+All of this happens **without leaving the page**.
+
+---
+
+## Scenario vs. Storyboard
+
+This distinction is crucial:
+
+| Concept | What Changes | Example |
+|---------|--------------|---------|
+| **Scenario** | Logical views change | User navigates Signup → Welcome |
+| **Storyboard** | Elements within a view change | Button: Default → Loading → Success |
+
+A scenario is the journey **across** pages.
+A storyboard is the transformation **within** a page.
+
+```
+SCENARIO (across pages):
+┌──────────────┐        ┌──────────────┐        ┌──────────────┐
+│   Page 1:    │  nav   │   Page 2:    │  nav   │   Page 3:    │
+│   Signup     │ ─────► │   Welcome    │ ─────► │  Dashboard   │
+└──────────────┘        └──────────────┘        └──────────────┘
+
+STORYBOARD (within one page):
+┌──────────────────────────────────────────────────────────────┐
+│                        Page 2: Welcome                       │
+│                                                              │
+│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐    │
+│  │   K0     │  │   K1     │  │   K2     │  │   K3     │    │
+│  │          │  │          │  │          │  │          │    │
+│  │ Default  │  │ Loading  │  │ Success  │  │ Animate  │    │
+│  └──────────┘  └──────────┘  └──────────┘  └──────────┘    │
+│                                                              │
+│  Same page, element transformations                         │
+└──────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## Why Storyboard?
+
+Without storyboarding:
+
+> Developer: "What happens when the user clicks submit?"
+> Designer: "Uh... it submits."
+> Developer: "But what do they see? Loading state? Confirmation? Does the button change?"
+> Designer: "I... didn't think about that."
+
+With storyboarding:
+
+> Developer reads specification:
+> "Submit button: Default → Loading (spinner replaces text) → Success (checkmark appears, redirects in 1.5s)"
+> Developer knows exactly what to build.
+
+---
+
+## The Default State Anchor
+
+Everything starts from the default state.
+
+Your sketch from Module 09? That's keyframe 0.
+
+```
+Keyframe 0: Default State
+├── User hasn't interacted yet
+├── Data hasn't loaded yet
+├── No errors, no success
+└── This is what they see first
+```
+
+Every transformation you document is a change FROM this state.
+
+---
+
+## What Storyboards Capture
+
+```
+Three Types of Transformations:
+
+1. USER INTERACTIONS
+   User action → Element responds
+
+   ┌────────┐  user    ┌────────┐
+   │ [btn]  │  clicks  │  ...   │
+   └────────┘  ──────► └────────┘
+   Accordion           Expands
+
+2. SYSTEM STATE CHANGES
+   System event → View updates
+
+   ┌────────┐  data    ┌────────┐
+   │ ▓▓▓▓▓▓ │  loads   │ Content│
+   └────────┘  ──────► └────────┘
+   Skeleton            Real data
+
+3. ANIMATIONS
+   Time-based transformation
+
+   ┌────────┐  200ms   ┌────────┐
+   │  ✓     │  fade    │  ✓     │
+   │        │  ──────► │Success!│
+   └────────┘    in    └────────┘
+   Icon              + Message
+```
+
+### 1. Interactions
+
+User does something → Element responds
+
+- Button pressed → Loading spinner appears
+- Input focused → Placeholder fades, label animates
+- Accordion clicked → Content expands
+- Drag initiated → Element follows cursor
+
+### 2. System State Changes
+
+Something happens in the system → View reflects it
+
+- Data loads → Skeleton replaced with content
+- Error occurs → Error message appears
+- Timer expires → Session timeout modal
+- Real-time update → New item appears
+
+### 3. Animations
+
+Something changes over time
+
+- Form submitted → Success message fades in
+- Page loads → Elements stagger in
+- Scroll happens → Header shrinks
+- Error occurs → Field shakes
+
+---
+
+## Keyframes
+
+Storyboards are sequences of **keyframes**.
+
+Each keyframe is a snapshot of the view at a specific moment:
+
+```
+Timeline View:
+
+Keyframe 0: Default State
+    ↓ (user clicks submit)
+Keyframe 1: Loading State
+    ↓ (server responds success)
+Keyframe 2: Success State
+    ↓ (redirect after 1.5s)
+[Navigate to Welcome Screen]
+
+
+Visual View:
+
+  K0              K1              K2
+┌─────────┐    ┌─────────┐    ┌─────────┐
+│         │    │         │    │         │
+│ [Submit]│    │  (...)  │    │   ✓     │
+│         │    │         │    │         │
+└─────────┘    └─────────┘    └─────────┘
+  Default       Loading        Success
+
+  ↑             ↑              ↑
+  User sees   User clicks   Server
+  button      button        responds
+```
+
+The spaces between keyframes are animations or transitions.
+
+---
+
+## Example: Password Field
+
+```
+K0: Default State        K1: User Types          K2: Password Strong     K3: Show Password
+┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
+│ Password         │    │ Password         │    │ Password         │    │ Password         │
+│ ┌──────────────┐ │    │ ┌──────────────┐ │    │ ┌──────────────┐ │    │ ┌──────────────┐ │
+│ │              │👁│    │ │ •••••        │👁│    │ │ ••••••••     │👁│    │ │ MyP@ssw0rd!  │👁│
+│ └──────────────┘ │    │ └──────────────┘ │    │ └──────────────┘ │    │ └──────────────┘ │
+│                  │    │ [▌    ] Weak     │    │ [████▌] Strong   │    │ [████▌] Strong   │
+│                  │    │                  │    │        ✓         │    │        ✓         │
+└──────────────────┘    └──────────────────┘    └──────────────────┘    └──────────────────┘
+   Empty input            Typing starts          Strong password         Click eye to reveal
+```
+
+**The Transformation:**
+
+```
+Keyframe 0: Default State
+- Input empty
+- Eye icon visible (closed)
+- No validation message
+
+Keyframe 1: User Types
+- Characters masked as dots
+- Strength indicator appears
+- Shows "Weak" in red
+
+Keyframe 2: Password Strong
+- Strength indicator fills
+- Shows "Strong" in green
+- Checkmark appears
+
+Keyframe 3: Show Password (on eye click)
+- Characters become visible
+- Eye icon opens
+```
+
+Each keyframe is a distinct state. The storyboard shows how they connect.
+
+---
+
+## Why Each Change Happens
+
+Don't just show what changes. Explain **why**.
+
+| Transition | What Changes | Why |
+|------------|--------------|-----|
+| 0 → 1 | Strength indicator appears | User needs feedback while typing |
+| 1 → 2 | Color shifts red → green | Reinforce password quality visually |
+| 2 → 3 | Characters visible | User wants to verify what they typed |
+
+The "why" connects to user experience. Every change serves a purpose.
+
+---
+
+## What to Storyboard
+
+Focus on **complex, meaningful transformations**:
+
+| Interaction Type | What to Document |
+|------------------|-----------------|
+| **Async Actions** | Submit → Loading (spinner) → Success/Error states |
+| **Multi-step Forms** | Step progression, validation feedback, dynamic fields |
+| **Modals/Dialogs** | Open animation, content loading, close behavior |
+| **Expand/Collapse** | Accordion opens, content reveals, height animations |
+| **Complex Dropdowns** | Multi-level menus, search filtering, dynamic options |
+| **Data Loading** | Skeleton → Content, empty states, error states |
+| **Notifications** | Entrance animation, auto-dismiss timing, user dismiss |
+| **Progressive Disclosure** | Show more, inline editing, conditional fields |
+
+**Don't storyboard:** Hover states, focus rings, standard link colors, or other behaviors developers already know.
+
+---
+
+## Timing Matters
+
+Some transitions need timing specifications:
+
+```
+Loading spinner: Appears after 300ms delay
+(Don't show spinner for quick operations)
+
+Success message: Visible for 3 seconds
+(Then auto-dismiss)
+
+Modal open: 200ms ease-out animation
+(Feels snappy but not jarring)
+```
+
+Timing affects user perception. Specify when it matters.
+
+---
+
+## Error States
+
+Don't forget what happens when things go wrong:
+
+```
+Happy Path vs Error Path:
+
+HAPPY PATH:                    ERROR PATHS:
+K0 ──► K1 ──► K2              K0 ──► K1 ──► E1 (Validation)
+                              │      │      │
+┌──────┐  ┌──────┐  ┌──────┐ │      │      └─► ┌──────────┐
+│Submit│  │ ...  │  │  ✓   │ │      │          │ Email!   │
+└──────┘  └──────┘  └──────┘ │      │          │ ┌──────┐ │
+Default   Loading  Success   │      │          │ │error │ │
+                              │      │          │ └──────┘ │
+                              │      │          └──────────┘
+                              │      │          Field error
+                              │      │
+                              │      └─► E2 (Network)
+                              │          ┌──────────┐
+                              │          │ Network  │
+                              │          │ error!   │
+                              │          │ [Retry]  │
+                              │          └──────────┘
+                              │          System error
+```
+
+**Error State Details:**
+
+```
+Keyframe E1: Validation Error
+- Field border turns red
+- Error message appears below
+- Focus moves to first error field
+
+Keyframe E2: Network Error
+- Form grays out slightly
+- Error banner appears at top
+- Retry button becomes available
+```
+
+Error states are as important as success states.
+
+---
+
+## The Storyboarding Principle
+
+**When to create a storyboard:**
+
+Ask: "Would a developer know exactly what to build without this?"
+
+- **YES** → Don't storyboard (it's standard behavior)
+- **NO** → Storyboard it (it needs documentation)
+
+```
+SKIP STORYBOARDING:              DO STORYBOARD:
+
+Simple hover state               Async form submission
+┌────────┐  ┌────────┐          ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐
+│ Submit │  │ Submit │          │ Submit │  │  ...   │  │   ✓    │  │ Error! │
+└────────┘  └────────┘          └────────┘  └────────┘  └────────┘  └────────┘
+  Default     Hover                K0          K1          K2          K3
+  ❌ Too simple                    ✅ Complex flow needs documentation
+
+
+Link color change                Modal dialog animation
+─────────────                    ┌──────────────────────────────────┐
+  Click me                       │                                  │
+─────────────                    │  ┌──────────────────────────┐   │
+  ❌ Standard                     │  │                          │   │
+                                 │  │    Modal Content         │   │
+                                 │  │                          │   │
+                                 │  └──────────────────────────┘   │
+                                 │                                  │
+                                 └──────────────────────────────────┘
+                                 K0 → K1 (fade in, 200ms ease-out)
+                                 ✅ Custom timing & effect
+```
+
+**Examples:**
+
+| Behavior | Storyboard? | Why |
+|----------|-------------|-----|
+| Button hover effect | ❌ No | Standard design system behavior |
+| Form submission with loading state | ✅ Yes | Complex async flow with multiple states |
+| Link color change on click | ❌ No | Standard browser behavior |
+| Modal opening animation | ✅ Yes | Custom timing and entrance effect |
+| Input focus ring | ❌ No | Standard accessibility pattern |
+| Multi-step wizard progress | ✅ Yes | Complex flow with validation between steps |
+
+**The rule:** Storyboard custom, complex, or non-obvious behaviors. Skip standard UI patterns.
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn specific techniques for documenting storyboards effectively — the format, tools, and level of detail that makes specifications actionable for developers.
+
+---
+
+**[Continue to Lesson 2: Storyboard Format →](lesson-02-storyboard-format.md)**
+
+---
+
+[← Back to Module Overview](module-10-storyboarding-overview.md)
+
+*Part of Module 10: Storyboarding*
diff --git a/docs/learn/module-10-storyboarding/lesson-02-storyboard-format.md b/docs/learn/module-10-storyboarding/lesson-02-storyboard-format.md
new file mode 100644
index 000000000..48ba77403
--- /dev/null
+++ b/docs/learn/module-10-storyboarding/lesson-02-storyboard-format.md
@@ -0,0 +1,410 @@
+# Module 10: Storyboarding
+
+## Lesson 2: Storyboard Format
+
+**How to document transformations clearly**
+
+---
+
+## The Structure
+
+Every storyboard follows this pattern:
+
+1. **Element name** — What's being storyboarded
+2. **Keyframes** — Each distinct state
+3. **Transitions** — What triggers the change
+4. **Why** — Purpose of each state
+5. **Timing** — Duration where relevant
+
+```
+Storyboard Anatomy:
+
+┌────────────────────────────────────────────────────────────┐
+│ ## [Element Name] Storyboard ◄─── 1. What's being tracked │
+├────────────────────────────────────────────────────────────┤
+│                                                            │
+│ ### Keyframe 0: Default State  ◄──── 2. Each distinct     │
+│ [Visual representation]                  state            │
+│ - State description                                        │
+│ - Key elements                                             │
+│                                                            │
+│ **Transition:** User clicks  ◄────── 3. What triggers      │
+│ **Why:** User needs feedback          change              │
+│                                                            │
+│ ### Keyframe 1: Loading State                             │
+│ [Visual representation]                                    │
+│ - What changed                                             │
+│ **Duration:** 300ms  ◄───────────── 5. Timing where       │
+│ **Why:** Prevents confusion             relevant          │
+│                                                            │
+└────────────────────────────────────────────────────────────┘
+                          ▲
+                    4. Purpose of each state
+```
+
+---
+
+## Basic Format
+
+```markdown
+## [Element Name] Storyboard
+
+### Keyframe 0: Default State
+[Image/description]
+- State description
+- Key visual elements
+- What user can interact with
+
+**Transition:** [What triggers next keyframe]
+
+### Keyframe 1: [State Name]
+[Image/description]
+- What changed
+- What's visible now
+- What user can do
+
+**Transition:** [What triggers next keyframe]
+
+### Keyframe 2: [State Name]
+...
+```
+
+---
+
+## Detailed Example: Form Submit Flow
+
+**Visual Overview:**
+
+```
+K0: Ready          K1: Submitting     K2: Success        K3: Error (alt)
+┌─────────────┐   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
+│ Email       │   │ Email       │   │ Email       │   │ Email       │
+│ ┌─────────┐ │   │ ┌─────────┐ │   │ ┌─────────┐ │   │ ┌─────────┐ │
+│ │email@...│ │   │ │email@...│ │   │ │email@...│ │   │ │email@...│ │ ⚠
+│ └─────────┘ │   │ └─────────┘ │   │ └─────────┘ │   │ └─────────┘ │
+│             │   │             │   │             │   │ ┌─────────┐ │
+│ Password    │   │ Password    │   │ Password    │   │ │Email    │ │
+│ ┌─────────┐ │   │ ┌─────────┐ │   │ ┌─────────┐ │   │ │exists!  │ │
+│ │•••••••••│ │   │ │•••••••••│ │   │ │•••••••••│ │   │ └─────────┘ │
+│ └─────────┘ │   │ └─────────┘ │   │ └─────────┘ │   │ Password    │
+│             │   │             │   │             │   │ ┌─────────┐ │
+│ ┌─────────┐ │   │ ┌─────────┐ │   │ ┌─────────┐ │   │ │•••••••••│ │
+│ │ Submit  │ │   │ │   ...   │ │   │ │   ✓     │ │   │ └─────────┘ │
+│ └─────────┘ │   │ └─────────┘ │   │ └─────────┘ │   │             │
+└─────────────┘   └─────────────┘   │ Account     │   │ ┌─────────┐ │
+                                    │ created!    │   │ │ Submit  │ │
+  User clicks       Processing       └─────────────┘   │ └─────────┘ │
+                    (300ms delay)    Success           └─────────────┘
+                                     (1.5s, redirect)   Error state
+```
+
+**Documented Format:**
+
+```markdown
+## Form Submit Storyboard
+
+### Keyframe 0: Default State (Ready to Submit)
+[Image: form-ready.png]
+- Form filled with valid data
+- Submit button: "Create Account" (enabled)
+- No loading indicators visible
+
+**Why:** User has completed form, ready to submit
+
+### Keyframe 1: Submitting State
+[Image: form-submitting.png]
+- Submit button shows spinner (text replaced)
+- Button disabled (grayed out)
+- Form fields locked (can't edit)
+**Transition:** User clicks submit (appears after 300ms delay)
+**Duration:** Until server responds
+
+**Why:** User knows request is processing, prevents double-submit
+
+### Keyframe 2: Success State
+[Image: form-success.png]
+- Submit button shows checkmark icon
+- Button background: Green
+- Success message appears above form: "Account created!"
+**Transition:** Server responds successfully
+**Duration:** 1.5s visible, then redirect
+
+**Why:** Confirms success before navigation
+
+### Keyframe 3: Error State
+[Image: form-error.png]
+- Submit button returns to default "Create Account"
+- Error banner appears at top: "Email already exists"
+- Email field highlighted in red
+- Form re-enabled for corrections
+**Transition:** Server responds with error
+
+**Why:** User can identify and fix the problem
+```
+
+---
+
+## Visual Options
+
+You can document storyboards with:
+
+### 1. Screenshots/Images
+
+Most precise. Capture exact states.
+
+```
+[Image: form-empty.png]
+[Image: form-filling.png]
+[Image: form-error.png]
+[Image: form-success.png]
+```
+
+### 2. ASCII Art
+
+Quick to create, easy to iterate.
+
+```
+Keyframe 0:        Keyframe 1:        Keyframe 2:
+┌──────────────┐   ┌──────────────┐   ┌──────────────┐
+│ Email        │   │ jane@...     │   │ jane@co.com  │
+└──────────────┘   └──────────────┘   └──────────────┘
+                                      ✓ Valid format
+```
+
+### 3. Description Only
+
+When visuals aren't critical.
+
+```
+Keyframe 0: Button shows "Submit"
+Keyframe 1: Button shows spinner, text hidden
+Keyframe 2: Button shows checkmark, turns green
+```
+
+### 4. Figma/Design Tool States
+
+Create component variants showing each state.
+
+---
+
+## Transition Types
+
+Document how states change:
+
+```
+INSTANT                   TIMED ANIMATION            DELAYED
+K0 ──► K1                K0 ─────────► K1           K0 ─ ─ ─► K1
+     0ms                      200ms                      300ms wait
+┌────┐ ┌────┐           ┌────┐   fade  ┌────┐      ┌────┐ wait ┌────┐
+│ A  │ │ A  │           │    │  ─────► │ ▓▓ │      │ X  │      │ X  │
+└────┘ └────┘           │    │   in    │ ▓▓ │      └────┘      │ ⚠  │
+Default Hover           └────┘         └────┘      No error    └────┘
+                        Hidden         Modal                    Error
+                                      visible                   appears
+
+No animation            Smooth fade    Prevents flash
+Instant feedback        200ms ease     After delay
+```
+
+### Instant
+
+```
+**Transition:** Instant (no animation)
+```
+
+Used for: Hover states, active states, error appearances
+
+### Timed Animation
+
+```
+**Transition:** 200ms ease-out
+```
+
+Used for: Modals, expandable sections, smooth state changes
+
+### Delayed
+
+```
+**Transition:** Appears after 300ms delay
+```
+
+Used for: Loading spinners (avoid flash), auto-dismiss messages
+
+### User-Triggered
+
+```
+**Transition:** On button click
+**Transition:** On input focus
+**Transition:** On scroll to element
+```
+
+### System-Triggered
+
+```
+**Transition:** On server response
+**Transition:** On data load complete
+**Transition:** On timer expiry
+```
+
+---
+
+## Grouping Storyboards
+
+Organize by element type:
+
+```
+Page Structure:
+┌─────────────────────────────────────────────────┐
+│ # Page: Signup Form                             │
+├─────────────────────────────────────────────────┤
+│ ## Form Fields                                  │
+│   ├── Email Field Storyboard ────┐              │
+│   │   K0 → K1 → K2                │ User input  │
+│   └── Password Field Storyboard ─┘              │
+│                                                  │
+│ ## Buttons                                      │
+│   ├── Submit Button Storyboard ──┐              │
+│   │   K0 → K1 → K2 → K3           │ Actions     │
+│   └── Back Button Storyboard ────┘              │
+│                                                  │
+│ ## System States                                │
+│   ├── Form Validation Storyboard ┐              │
+│   │   K0 → K1 → K2                │ Feedback    │
+│   └── Network Error Storyboard ──┘              │
+└─────────────────────────────────────────────────┘
+```
+
+**Documented Format:**
+
+```markdown
+# Page: Signup Form
+
+## Form Fields
+
+### Email Field Storyboard
+[keyframes...]
+
+### Password Field Storyboard
+[keyframes...]
+
+## Buttons
+
+### Submit Button Storyboard
+[keyframes...]
+
+### Back Button Storyboard
+[keyframes...]
+
+## System States
+
+### Form Validation Storyboard
+[keyframes...]
+
+### Network Error Storyboard
+[keyframes...]
+```
+
+---
+
+## The Freya Method
+
+Freya helps you think through transformations:
+
+> "When the user submits, what do they see while waiting?"
+
+> "This dropdown opens instantly. Should it animate for smoother UX?"
+
+> "The error appears, but how does the user know which field caused it?"
+
+She ensures every state change serves the user.
+
+---
+
+## What NOT to Storyboard
+
+**Skip storyboarding standard UI behaviors:**
+
+- **Button hover/active states** — Developers know these
+- **Link colors** — Standard browser behavior
+- **Focus states** — Design system handles this
+- **Cursor changes** — Standard pointer/text cursors
+- **Simple show/hide** — Basic visibility toggles
+- **Static content** — No interactivity
+
+**DO storyboard complex, non-standard transformations:**
+
+- **Async operations** — Loading → Success/Error flows
+- **Modal dialogs** — Open/close with animations
+- **Expandable sections** — Accordion behavior, content reveals
+- **Complex dropdowns** — Multi-level, searchable, filtered
+- **Form wizards** — Multi-step progress and validation
+- **Animations** — Custom entrance/exit effects
+- **Real-time updates** — Live data, notifications
+
+**The rule:** If it's a standard behavior developers already know, don't document it. If it's complex or custom, storyboard it.
+
+---
+
+## Connecting to Specifications
+
+Storyboards become part of your page specifications (Module 11):
+
+```markdown
+## Signup Form Specification
+
+### Submit Button
+- Component: Button (primary, large)
+- Label: "Create Account"
+- **Storyboard:** See Submit Button Storyboard
+
+### Email Field
+- Component: Input (email)
+- Label: "Email"
+- **Storyboard:** See Email Field Storyboard
+```
+
+The storyboard provides the dynamic behavior; the specification provides the full context.
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Confusing with scenarios | Storyboards stay on one page |
+| Missing intermediate states | Show every step, not just start/end |
+| No "why" | Explain the purpose of each state |
+| Forgetting error states | What happens when things fail? |
+| Over-documenting | Focus on meaningful transformations |
+| No timing | Specify duration when it matters |
+
+---
+
+## Checklist
+
+For each interactive element:
+
+- [ ] Default state documented
+- [ ] All user-triggered states
+- [ ] All system-triggered states
+- [ ] Error states
+- [ ] Success states
+- [ ] Transition types specified
+- [ ] Timing where relevant
+- [ ] Why for each state
+
+---
+
+## What's Next
+
+In the tutorial, you'll create storyboards for the interactive elements in your own page sketches. Freya will guide you through identifying what needs storyboarding and documenting each transformation.
+
+---
+
+**[Continue to Tutorial: Create Your Storyboards →](tutorial-10.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-transformations.md) | [Back to Module Overview](module-10-storyboarding-overview.md)
+
+*Part of Module 10: Storyboarding*
diff --git a/docs/learn/module-10-storyboarding/module-10-storyboarding-overview.md b/docs/learn/module-10-storyboarding/module-10-storyboarding-overview.md
new file mode 100644
index 000000000..9d1686caf
--- /dev/null
+++ b/docs/learn/module-10-storyboarding/module-10-storyboarding-overview.md
@@ -0,0 +1,290 @@
+# Module 10: Storyboarding
+
+**Time: 45 min | Agent: Freya | Phase: Design | Focus: UX**
+
+---
+
+## Transformations Within a View
+
+You have sketches of your pages. But pages aren't static.
+
+Things change. Elements transform. States shift.
+
+**Without leaving the page.**
+
+---
+
+## Scenario vs. Storyboard
+
+| Concept | What Changes | Example |
+|---------|--------------|---------|
+| **Scenario** | Logical views change | User navigates from Signup to Welcome |
+| **Storyboard** | Elements within a view change | Signup form shows loading → success → confetti |
+
+A scenario is the journey **across** pages.
+
+A storyboard is the transformation **within** a page.
+
+Think of it like a film: scenarios are scene changes, storyboards are what happens in each scene.
+
+---
+
+## The Comic Strip Analogy
+
+Think of storyboarding like a comic strip for your interface.
+
+```
+┌────────────────────────┐
+│  [Logo]      [Nav]     │     ┌──────────────────────────────────────────────┐
+├────────────────────────┤     │ SIGNUP FORM - STATE TRANSFORMATIONS          │
+│                        │     ├──────────────────────────────────────────────┤
+│   Hero Section         │     │                                              │
+│                        │     │  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐     │
+├────────────────────────┤     │  │  1   │  │  2   │  │  3   │  │  4   │     │
+│ ┌──────────────────┐   │ ──► │  │      │  │      │  │      │  │      │     │
+│ │                  │   │     │  │[btn] │  │ ...  │  │  ✓   │  │  🎉  │     │
+│ │   Signup Form    │◄──┼─┐   │  │      │  │      │  │      │  │      │     │
+│ │  (Focus area)    │   │ │   │  └──────┘  └──────┘  └──────┘  └──────┘     │
+│ └──────────────────┘   │ │   │   Click      Loading   Success   Celebrate  │
+│                        │ │   │   Button     State     Message   Animation   │
+├────────────────────────┤ │   │                                              │
+│   Footer               │ │   └──────────────────────────────────────────────┘
+└────────────────────────┘ │
+    Full Page              │
+    (Default State)        └─── Same section, 4 keyframes showing transformation
+```
+
+**The page stays the same. One section transforms.**
+
+Like a comic strip, each frame shows what changes:
+1. **Default** — User sees the button
+2. **Loading** — Button becomes spinner
+3. **Success** — Checkmark appears
+4. **Celebration** — Confetti animation
+
+---
+
+## The Default State
+
+Every page starts somewhere.
+
+This is **keyframe 0** — the default state of all objects on the screen.
+
+Your sketch from Module 09? That's typically the default state.
+
+What happens next is the storyboard.
+
+---
+
+## What Storyboards Capture
+
+Storyboards document **complex, non-standard transformations**:
+
+### Async Operations
+- Form submission → Loading → Success/Error
+- Data fetching → Skeleton screens → Content
+- File upload → Progress → Complete
+
+### User Interactions (Complex)
+- Accordion expand/collapse with animation
+- Modal dialogs opening and closing
+- Multi-step wizards with validation
+- Searchable/filterable dropdowns
+
+### Animations (Custom)
+- Entrance effects when content loads
+- Success celebrations (confetti, checkmarks)
+- Error shake animations
+- Progressive disclosure reveals
+
+### System State Changes
+- Real-time notifications appearing
+- Live data updates
+- Session timeout warnings
+- Conditional content showing/hiding
+
+**What storyboards DON'T capture:** Standard hover states, focus rings, simple link colors, or any behavior developers already know from design systems.
+
+---
+
+## Storyboard Format
+
+Add the storyboard images to the section in question.
+
+Specify step by step:
+
+**Visual Example:**
+
+```
+K0: Default          K1: User Types      K2: Strong          K3: Show Password
+┌────────────────┐  ┌────────────────┐  ┌────────────────┐  ┌────────────────┐
+│ Password       │  │ Password       │  │ Password       │  │ Password       │
+│ ┌────────────┐ │  │ ┌────────────┐ │  │ ┌────────────┐ │  │ ┌────────────┐ │
+│ │            │👁│  │ │ •••••      │👁│  │ │ ••••••••   │👁│  │ │MyP@ssw0rd! │👁│
+│ └────────────┘ │  │ └────────────┘ │  │ └────────────┘ │  │ └────────────┘ │
+│                │  │ [▌  ] Weak     │  │ [████▌] Strong │  │ [████▌] Strong │
+│                │  │                │  │      ✓         │  │      ✓         │
+└────────────────┘  └────────────────┘  └────────────────┘  └────────────────┘
+```
+
+**Documented Format:**
+
+```markdown
+## Password Field Storyboard
+
+### Keyframe 0: Default State
+[Image: password-field-default.png]
+- Input empty
+- Eye icon visible (closed)
+- No validation message
+
+### Keyframe 1: User Types
+[Image: password-field-typing.png]
+- Characters masked as dots
+- Strength indicator appears
+- Shows "Weak" in red
+
+### Keyframe 2: Password Strong
+[Image: password-field-strong.png]
+- Strength indicator fills
+- Shows "Strong" in green
+- Checkmark appears
+
+### Keyframe 3: Show Password
+[Image: password-field-visible.png]
+- User clicks eye icon
+- Characters become visible
+- Eye icon opens
+```
+
+---
+
+## Why Each Change Happens
+
+Don't just show what changes. Explain **why**.
+
+```
+The Complete Picture:
+
+K0              K1              K2              K3
+Empty    ─────► Typing   ─────► Strong   ─────► Visible
+                  │               │               │
+                  ▼               ▼               ▼
+               WHY: User       WHY: User       WHY: User
+               needs           needs           wants to
+               feedback        visual          verify
+               while           reinforcement   what they
+               typing                          typed
+```
+
+| Keyframe | What Changes | Why |
+|----------|--------------|-----|
+| 0 → 1 | Strength indicator appears | User needs feedback while typing |
+| 1 → 2 | Color shifts red → green | Reinforce password quality visually |
+| 2 → 3 | Characters visible | User wants to verify what they typed |
+
+---
+
+## The Freya Method
+
+Freya helps you think through on-page transformations:
+
+> "When the user submits, what do they see while waiting?"
+> "This dropdown opens instantly. Should it animate?"
+> "The error appears, but how does the user know which field?"
+
+She ensures every state change serves the user.
+
+---
+
+## What Needs Storyboarding
+
+Storyboard **complex, non-standard transformations**:
+
+```
+✅ DO STORYBOARD:                    ❌ DON'T STORYBOARD:
+
+Async Actions                        Button Hover
+┌──────┐ ┌──────┐ ┌──────┐          ┌──────┐ ┌──────┐
+│Submit│ │ ...  │ │  ✓   │          │Button│ │Button│
+└──────┘ └──────┘ └──────┘          └──────┘ └──────┘
+K0 → K1 → K2 → K3                    Default   Hover
+Complex flow                         Standard behavior
+
+Modal Dialog                         Focus Ring
+    ┌──────────────┐                 ┌──────────┐
+    │              │                 │ [Input ] │
+    │   Content    │                 └──────────┘
+    │              │                 Standard pattern
+    └──────────────┘
+Fade in, 200ms ease
+Custom animation
+```
+
+| Element | What to Storyboard |
+|---------|-------------------|
+| **Async Actions** | Submit → Loading → Success/Error states |
+| **Forms** | Multi-step validation, progressive disclosure, dynamic fields |
+| **Modals** | Open animation, content transitions, close behavior |
+| **Expandable Sections** | Collapsed → Expanded with content reveal |
+| **Complex Dropdowns** | Multi-level menus, filtered searches, dynamic options |
+| **Animations** | Entrance effects, celebration moments, transitions |
+| **Real-time Updates** | Live data appearing, notifications arriving |
+
+**Don't storyboard standard behaviors** like button hovers, link colors, or focus states — developers already know these.
+
+---
+
+## Output
+
+For each interactive section of your page:
+
+- Keyframe images showing transformation
+- Step-by-step description of changes
+- Reason for each change
+- Timing/duration where relevant
+
+This becomes the specification for developers.
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Confusing with scenarios | Storyboards stay on one page |
+| Missing intermediate states | Show every step, not just start/end |
+| No "why" | Explain the purpose of each change |
+| Forgetting error states | What happens when things fail? |
+
+---
+
+## Practice
+
+Take one interactive section from your sketch:
+
+1. Identify the default state (keyframe 0)
+2. List all possible changes
+3. Draw/describe each keyframe
+4. Explain why each change happens
+5. Note timing if relevant
+
+---
+
+## Learn More
+
+- **[Lesson 1: Transformations](lesson-01-transformations.md)** — Understanding state changes within views
+- **[Lesson 2: Storyboard Format](lesson-02-storyboard-format.md)** — How to document keyframes effectively
+- **[Tutorial: Storyboard Your Views](tutorial-10.md)** — Hands-on practice with Freya
+
+---
+
+## Next Module
+
+**[Module 11: Conceptual Specifications →](../module-11-conceptual-specifications/module-11-conceptual-specifications-overview.md)**
+
+Document every decision.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-10-storyboarding/tutorial-10.md b/docs/learn/module-10-storyboarding/tutorial-10.md
new file mode 100644
index 000000000..dae3cf623
--- /dev/null
+++ b/docs/learn/module-10-storyboarding/tutorial-10.md
@@ -0,0 +1,405 @@
+# Tutorial 10: Create Your Storyboards
+
+**Hands-on guide to documenting transformations with Freya**
+
+---
+
+## Overview
+
+This tutorial walks you through creating storyboards for the interactive elements in your page sketches.
+
+**Time:** 30-40 minutes
+**Prerequisites:** Conceptual sketches completed (Module 09)
+**Agent:** Freya
+**What you'll create:** Storyboard documentation for key interactive elements
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- Your page sketches from Module 09
+- Understanding of what happens on each page
+- Awareness of user interactions
+
+**Freya will help you:**
+
+- Identify what needs storyboarding
+- Think through all states
+- Document transitions clearly
+- Connect each state to user needs
+
+---
+
+## Step 1: Identify Interactive Elements (5 min)
+
+### Start with your first page:
+
+**You say:**
+> "Let's storyboard the signup form from S01-User-Registration. What elements need storyboards?"
+
+**Freya analyzes:**
+> "Looking at your signup form sketch, I see these interactive elements:
+>
+> 1. **Email field** — Focus, typing, validation
+> 2. **Password field** — Focus, typing, strength indicator, show/hide
+> 3. **Submit button** — Hover, click, loading, success/error
+> 4. **Form overall** — Empty, filling, validating, submitting, error, success
+>
+> Which should we start with?"
+
+### Prioritize:
+
+**You respond:**
+> "Let's start with the submit button since that's the main action."
+
+---
+
+## Step 2: Document Default State (3 min)
+
+### Freya asks about keyframe 0:
+
+> "What's the default state of the submit button when the page first loads?"
+
+**You describe:**
+> "Primary button, says 'Create Account', blue background, full width on mobile."
+
+**Freya documents:**
+```markdown
+## Submit Button Storyboard
+
+### Keyframe 0: Default State
+- Label: "Create Account"
+- Style: Primary (blue background, white text)
+- Width: Full width on mobile, auto on desktop
+- State: Enabled, clickable
+
+**Why:** Clear call-to-action that matches landing page CTA for continuity
+```
+
+---
+
+## Step 3: Map All States (10 min)
+
+### Freya guides through each state:
+
+> "What happens when the user hovers over the button?"
+
+**You respond:**
+> "It gets slightly darker, maybe a shadow appears."
+
+**Freya documents and continues:**
+```markdown
+### Keyframe 1: Hover State
+- Background: Darker blue
+- Shadow: Subtle elevation
+**Transition:** Mouse enters (instant)
+
+**Why:** Confirms the button is interactive
+```
+
+> "And when they click?"
+
+**You respond:**
+> "Button presses down slightly, then shows a loading spinner."
+
+**Freya continues:**
+```markdown
+### Keyframe 2: Active/Pressed
+- Scale: 98% (pressed effect)
+- Background: Even darker
+**Transition:** Mouse down (instant)
+
+**Why:** Physical feedback for click action
+
+### Keyframe 3: Loading
+- Label replaced with spinner
+- Button disabled
+- Background unchanged
+**Transition:** Form submitted → appears after 100ms delay
+**Duration:** Until server responds
+
+**Why:** User knows their action is being processed
+```
+
+### Continue for remaining states:
+
+> "What about success and error states?"
+
+**You respond:**
+> "Success: checkmark icon, green background, 'Done!' text, then redirect. Error: button returns to normal, error message appears above form."
+
+---
+
+## Step 4: Document Transitions (5 min)
+
+### Freya clarifies transitions:
+
+> "Let's be specific about transitions. When does the loading state appear — immediately on click or with a delay?"
+
+**You respond:**
+> "Small delay, maybe 100ms, so it doesn't flash if the server is fast."
+
+**Freya asks:**
+> "And the success state — how long is it visible before redirecting?"
+
+**You respond:**
+> "About 1.5 seconds. Long enough to register success, not so long it feels slow."
+
+**Freya documents:**
+```markdown
+### Timing Summary
+| Transition | Timing |
+|------------|--------|
+| Default → Hover | Instant |
+| Hover → Active | Instant |
+| Active → Loading | 100ms delay |
+| Loading → Success | On server response |
+| Success → Navigate | 1.5s delay |
+| Loading → Error | On server error |
+```
+
+---
+
+## Step 5: Add Error States (5 min)
+
+### Freya ensures completeness:
+
+> "We've covered the happy path. What happens when things go wrong?"
+
+**You respond:**
+> "If there's a validation error, the button should stay disabled until fields are fixed. If there's a server error, button goes back to normal and an error banner appears."
+
+**Freya documents:**
+```markdown
+### Error States
+
+#### Form Invalid
+- Button remains disabled (grayed out)
+- No hover or active states
+**Transition:** Form becomes invalid (instant)
+**Why:** Prevents submission of incomplete data
+
+#### Server Error
+- Button returns to default state
+- Error banner appears above form
+- Button text: "Try Again"
+**Transition:** Server returns error
+**Why:** Clear recovery path
+```
+
+---
+
+## Step 6: Repeat for Other Elements (10 min)
+
+### Move to next element:
+
+**Freya:**
+> "Submit button is complete. Next, let's storyboard the password field — it has the most states."
+
+**Work through:**
+- Default (empty)
+- Focused (cursor in field)
+- Typing (characters masked)
+- Strength indicator states
+- Show/hide password toggle
+- Validation error
+- Valid state
+
+### Example password field storyboard:
+
+```markdown
+## Password Field Storyboard
+
+### Keyframe 0: Default
+- Empty field
+- Label above: "Password"
+- Placeholder: none (clean look)
+- Eye icon: Closed state
+- Strength indicator: Hidden
+
+### Keyframe 1: Focused
+- Border: Blue (focus ring)
+- Cursor blinking in field
+**Transition:** User clicks or tabs to field
+
+### Keyframe 2: Typing (Weak)
+- Characters masked as dots
+- Strength indicator appears: 1/4 fill, red
+- Text below: "Weak password"
+**Transition:** User starts typing
+
+### Keyframe 3: Typing (Medium)
+- Strength indicator: 2/4 fill, orange
+- Text: "Getting better"
+**Transition:** Password meets some requirements
+
+### Keyframe 4: Typing (Strong)
+- Strength indicator: 4/4 fill, green
+- Text: "Strong password" + checkmark
+**Transition:** Password meets all requirements
+
+### Keyframe 5: Password Visible
+- Characters shown instead of dots
+- Eye icon: Open state
+**Transition:** User clicks eye icon
+**Toggle:** Clicking again returns to masked
+```
+
+---
+
+## Step 7: Document Form-Level States (5 min)
+
+### Consider the form as a whole:
+
+**Freya:**
+> "Individual elements are storyboarded. Now let's document form-level states — how does the overall form behave?"
+
+**Work through:**
+- Empty form (just loaded)
+- Partially filled
+- All fields valid (submit enabled)
+- Submitting (fields disabled)
+- Server error (recovery state)
+
+```markdown
+## Form-Level Storyboard
+
+### State: Empty
+- All fields at default
+- Submit button disabled
+- No validation messages
+
+### State: Partially Filled
+- Some fields have content
+- Validation shows on blur
+- Submit remains disabled until all valid
+
+### State: Ready to Submit
+- All fields valid (green indicators)
+- Submit button enabled
+- User can proceed
+
+### State: Submitting
+- All fields disabled (grayed slightly)
+- Submit button in loading state
+- No new input allowed
+
+### State: Error Recovery
+- Fields re-enabled
+- Error banner at top
+- Last values preserved
+- Submit button ready for retry
+```
+
+---
+
+## Step 8: Review and Finalize (5 min)
+
+### Freya presents complete storyboards:
+
+> "Here's the complete storyboard documentation for the signup form:
+>
+> 1. **Submit Button** — 6 states documented
+> 2. **Password Field** — 5 states + toggle
+> 3. **Email Field** — 4 states
+> 4. **Form-Level** — 5 states
+>
+> Anything missing?"
+
+### Review checklist:
+
+- [ ] All interactive elements covered
+- [ ] Default states documented
+- [ ] Error states included
+- [ ] Success states included
+- [ ] Transitions specified
+- [ ] Timing noted where relevant
+- [ ] "Why" explained for each state
+
+---
+
+## What You've Created
+
+### Storyboard documentation for each page:
+
+```
+C-UX-Scenarios/
+└── S01-User-Registration/
+    ├── scenario-overview.md
+    ├── 02-signup-form/
+    │   ├── sketch.png
+    │   ├── storyboard-submit-button.md
+    │   ├── storyboard-password-field.md
+    │   ├── storyboard-email-field.md
+    │   └── storyboard-form-states.md
+```
+
+Or integrated into a single storyboards.md file per page.
+
+---
+
+## What Happens Next
+
+### These storyboards become:
+
+- **Specifications** (Module 11) — Full documentation including storyboards
+- **Developer reference** — Exact behavior to implement
+- **QA checklist** — States to test
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Start with high-impact elements
+- Document error states
+- Include the "why"
+- Specify timing
+- Use visuals when helpful
+
+**DON'T:**
+
+- Storyboard everything
+- Skip error states
+- Forget transitions
+- Over-document micro-interactions
+- Ignore edge cases
+
+---
+
+## Common Questions
+
+**Q: Do I need images for every keyframe?**
+A: No. Descriptions work for simple states. Images help for complex visual changes.
+
+**Q: How detailed should timing be?**
+A: Detailed enough to implement. "Fast" is vague; "200ms ease-out" is specific.
+
+**Q: What if I'm not sure about a state?**
+A: Document your best guess and note it as "needs validation." Better to have something than nothing.
+
+---
+
+## You've Completed Module 10!
+
+**Your transformations are documented.** You know:
+- What changes on each page
+- How each state looks
+- Why each transformation happens
+
+---
+
+## Next Module
+
+**[Module 11: Conceptual Specifications →](../module-11-conceptual-specifications/module-11-conceptual-specifications-overview.md)**
+
+Time to document every decision in complete specifications.
+
+---
+
+[← Back to Lesson 2](lesson-02-storyboard-format.md) | [Back to Module Overview](module-10-storyboarding-overview.md)
+
+*Part of Module 10: Storyboarding*
diff --git a/docs/learn/module-11-conceptual-specifications/lesson-01-design-is-specification.md b/docs/learn/module-11-conceptual-specifications/lesson-01-design-is-specification.md
new file mode 100644
index 000000000..18d77e16a
--- /dev/null
+++ b/docs/learn/module-11-conceptual-specifications/lesson-01-design-is-specification.md
@@ -0,0 +1,593 @@
+# Module 11: Conceptual Specifications
+
+## Lesson 1: Page-Level Specifications
+
+**Start with the big picture, then work down**
+
+---
+
+## The Hierarchy of Specification
+
+Specifications work from large to small:
+
+```
+┌─────────────────────────────────────────────────┐
+│ LAYER 1: PAGE                                   │  ← Start here
+│ Purpose, Strategy, Context                      │
+│  ┌───────────────────────────────────────────┐  │
+│  │ LAYER 2: SECTION                          │  │
+│  │ Major areas, placement, priority          │  │
+│  │  ┌─────────────────────────────────────┐  │  │
+│  │  │ LAYER 3: WIDGET                     │  │  │
+│  │  │ Reusable components, states         │  │  │
+│  │  │  ┌───────────────────────────────┐  │  │  │
+│  │  │  │ LAYER 4: CARD                 │  │  │  │
+│  │  │  │ Content grouping              │  │  │  │
+│  │  │  │  ┌─────────┐  ┌─────────┐    │  │  │  │
+│  │  │  │  │ LAYER 5 │  │ LAYER 5 │    │  │  │  │
+│  │  │  │  │ ELEMENT │  │ ELEMENT │    │  │  │  │
+│  │  │  │  └─────────┘  └─────────┘    │  │  │  │
+│  │  │  └───────────────────────────────┘  │  │  │
+│  │  └─────────────────────────────────────┘  │  │
+│  └───────────────────────────────────────────┘  │
+└─────────────────────────────────────────────────┘
+```
+
+**You cannot specify a button until you understand the page.**
+
+This lesson shows you how to specify each layer, from large to small.
+
+---
+
+## Layer 1: Page-Level Specification
+
+The page is the container for everything. Specify it first.
+
+### What to Specify
+
+Every page specification must answer:
+
+1. **Purpose** — What is this page trying to accomplish?
+2. **Personas** — Who is this page for?
+3. **Trigger Map Connection** — Which driving forces does it address?
+4. **Layout Approach** — Mobile-first? Desktop-first? Responsive strategy?
+5. **Accessibility Requirements** — WCAG level, keyboard navigation, screen reader support
+6. **Performance Priorities** — What loads first? What can wait?
+7. **SEO Requirements** — Meta descriptions, structured data, OG tags
+
+### Page Specification Format
+
+```markdown
+# Page: [Page Name]
+**ID:** [Page-ID]
+
+## Purpose
+[What this page accomplishes for the user]
+
+## Personas Served
+- [Persona Name]: [How this page serves them]
+
+## Connects To
+- Scenario: [Scenario ID]
+- Trigger Map: [Driving Force quote]
+- Feature: [Feature ID]
+
+## Layout Strategy
+- Primary Platform: [Mobile/Desktop]
+- Responsive Approach: [Mobile-first/Desktop-first]
+- Breakpoints: [List key breakpoints]
+
+## Accessibility
+- WCAG Level: [A/AA/AAA]
+- Keyboard Navigation: [Full/Partial]
+- Screen Reader: [Fully supported/Basic support]
+- Focus Management: [How focus is managed on page load]
+
+## Performance
+- Priority Loading: [What loads first]
+- Lazy Loading: [What loads on demand]
+- Skeleton Screens: [Yes/No, where]
+
+## SEO
+- Title Tag: "[Exact title]"
+- Meta Description: "[Exact description]"
+- OG Tags: [Yes/No]
+- Structured Data: [Schema type if applicable]
+
+## Sections
+[List of sections, detailed in Section-level specs]
+```
+
+### Example: Signup Page Specification
+
+```markdown
+# Page: Signup Page
+**ID:** P01-signup-page
+
+## Purpose
+Enable Felix (persona) to create an account with minimal friction by
+collecting only essential information (email + password) so he can start
+trying the product immediately without lengthy onboarding.
+
+## Personas Served
+- Felix the Full-Stack: Wants to try before committing, fears complicated
+  onboarding
+
+## Connects To
+- Scenario: S01-User-Registration
+- Trigger Map: "I want to try this without jumping through hoops"
+- Feature: F03-Quick-Signup
+
+## Layout Strategy
+- Primary Platform: Mobile
+- Responsive Approach: Mobile-first
+- Breakpoints: 640px (tablet), 1024px (desktop)
+
+## Accessibility
+- WCAG Level: AA
+- Keyboard Navigation: Full (tab order: logo → form fields → CTA → footer links)
+- Screen Reader: Fully supported
+- Focus Management: Focus moves to email field on page load
+
+## Performance
+- Priority Loading: Header, hero section, form (critical path)
+- Lazy Loading: Footer, testimonials (below fold)
+- Skeleton Screens: No (page loads quickly, < 1s)
+
+## SEO
+- Title Tag: "Sign Up - Dog Week | Plan Your Week with Your Dog"
+- Meta Description: "Create your free Dog Week account in 60 seconds.
+  No credit card required. Start planning activities with your dog today."
+- OG Tags: Yes (signup-og.jpg)
+- Structured Data: None
+
+## Sections
+- S01: Header (Logo, Login link)
+- S02: Hero (Value proposition, trust signals)
+- S03: Form Area (Signup widget)
+- S04: Footer (Legal links)
+```
+
+**Notice:** The page spec establishes context. We know WHO it's for (Felix), WHY it exists (minimal friction signup), and HOW it performs (mobile-first, AA accessibility).
+
+Now we can specify sections.
+
+---
+
+## Layer 2: Section-Level Specification
+
+Sections organize the page into major areas.
+
+### What to Specify
+
+For each section:
+
+1. **Purpose** — Why this section exists
+2. **Placement** — Where it appears on the page
+3. **Behavior** — Responsive behavior, sticky, collapsible
+4. **Load Priority** — When it loads relative to other sections
+5. **Accessibility** — Landmark role, heading structure
+
+### Section Specification Format
+
+```markdown
+## Section: [Section Name]
+**ID:** [Page-ID]-[Section-ID]
+
+### Purpose
+[Why this section exists]
+
+### Placement
+- Position: [Header/Above fold/Below fold/Footer]
+- Responsive: [How it adapts across breakpoints]
+
+### Behavior
+- Sticky: [Yes/No]
+- Collapsible: [Yes/No]
+- Animation: [Entry animation if any]
+
+### Load Priority
+[Critical/High/Normal/Low]
+
+### Accessibility
+- Landmark: [role="banner/main/navigation/contentinfo/complementary"]
+- Heading: [h1/h2/h3 - what level starts this section]
+
+### Contains
+[List of widgets/cards in this section]
+```
+
+### Example: Hero Section Specification
+
+```markdown
+## Section: Hero Section
+**ID:** P01-S02-hero-section
+
+### Purpose
+Communicate value proposition quickly to reduce Felix's hesitation and
+make the benefit of signing up immediately clear.
+
+### Placement
+- Position: Above fold, immediately after header
+- Responsive:
+  - Mobile: Stacked vertically (headline → subtext → visual)
+  - Tablet: Side-by-side (text left, visual right, 60/40 split)
+  - Desktop: Same as tablet
+
+### Behavior
+- Sticky: No
+- Collapsible: No
+- Animation: Fade in on page load (300ms ease-in)
+
+### Load Priority
+Critical (above fold, visible immediately)
+
+### Accessibility
+- Landmark: role="main"
+- Heading: h1 (main page headline)
+
+### Contains
+- W01: Value Proposition Widget (headline + subtext)
+- No cards or complex widgets, just text + image
+```
+
+**Notice:** The section spec explains WHERE it appears and HOW it behaves. We haven't specified the exact content yet — that comes at the widget/element level.
+
+---
+
+## Layer 3: Widget-Level Specification
+
+Widgets are reusable components that can appear in multiple places.
+
+### What to Specify
+
+For each widget:
+
+1. **Reusability** — Where else does this widget appear?
+2. **States** — All possible states (default, loading, error, etc.)
+3. **Validation** — What rules apply?
+4. **Accessibility** — ARIA patterns, keyboard interactions
+5. **Content Structure** — What content slots does it have?
+
+### Widget Specification Format
+
+```markdown
+## Widget: [Widget Name]
+**ID:** [Page-ID]-[Section-ID]-[Widget-ID]
+
+### Purpose
+[What this widget accomplishes]
+
+### Used In
+- [List of pages/sections where this widget appears]
+
+### States
+- [State name]: [Description]
+
+### Validation
+[Validation rules if applicable]
+
+### Accessibility
+- ARIA Pattern: [Combobox/Dialog/Tabs/etc.]
+- Keyboard: [Key interactions]
+- Focus: [Focus management]
+
+### Content Structure
+[Slots or content areas]
+
+### Elements
+[List of child elements, detailed in Element-level specs]
+```
+
+### Example: Signup Form Widget
+
+```markdown
+## Widget: Signup Form
+**ID:** P01-S03-W01-signup-form
+
+### Purpose
+Collect minimal information (email + password) to create account
+with real-time validation to prevent submission errors.
+
+### Used In
+- P01-signup-page (Section S03)
+- Modal signup (when triggered from marketing pages)
+- Embedded signup (partner sites)
+
+### States
+- Default: Empty form, submit button enabled
+- Filling: Real-time validation as user types
+- Validating: Check email availability (async)
+- Invalid: Error messages shown, submit disabled
+- Submitting: Loading state, form locked
+- Success: Confirmation message, redirect after 1.5s
+- Error: Server error message, form re-enabled
+
+### Validation
+- Email: Valid format, check availability against database
+- Password: Minimum 8 characters, show strength indicator
+
+### Accessibility
+- ARIA Pattern: Form with live regions for validation
+- Keyboard: Tab order: email → password → show password toggle → submit
+- Focus: On error, focus moves to first invalid field
+- Screen Reader: Error messages announced via aria-live="assertive"
+
+### Content Structure
+- Form heading slot
+- Email field slot
+- Password field slot
+- Submit button slot
+- Error message slot
+- Terms acceptance slot
+
+### Elements
+- E01: Email Field
+- E02: Password Field
+- E03: Show Password Toggle
+- E04: Password Strength Indicator
+- E05: Submit Button
+- E06: Terms Link
+```
+
+**Notice:** The widget spec defines WHAT it does and WHERE it's used. It's specified once but can be reused anywhere. States and validation rules are explicit.
+
+---
+
+## Layer 4: Card-Level Specification
+
+Cards group related content into repeatable patterns.
+
+### What to Specify
+
+For each card:
+
+1. **Content Pattern** — What information does it display?
+2. **Data Structure** — What data feeds into it?
+3. **Repetition** — How many instances appear?
+4. **Interaction** — Is it clickable? Expandable?
+
+### Card Specification Format
+
+```markdown
+## Card: [Card Name]
+**ID:** [Page-ID]-[Section-ID]-[Card-ID]
+
+### Purpose
+[What this card displays]
+
+### Data Structure
+[What data it receives]
+
+### Instances
+[How many appear, or is it a template]
+
+### Interaction
+[Clickable/Static/Expandable]
+
+### Elements
+[List of elements within the card]
+```
+
+### Example: Feature Card
+
+```markdown
+## Card: Feature Card
+**ID:** P01-S04-C01-feature-card
+
+### Purpose
+Display one product feature with icon, title, and description to
+build trust before signup.
+
+### Data Structure
+```json
+{
+  "icon": "string (icon name)",
+  "title": "string",
+  "description": "string (max 120 chars)"
+}
+```
+
+### Instances
+Template card, rendered 3 times with different data
+
+### Interaction
+Static (not clickable)
+
+### Elements
+- E01: Feature Icon
+- E02: Feature Title
+- E03: Feature Description
+```
+
+**Notice:** Cards define the PATTERN for grouped content. The data structure shows what feeds into each instance.
+
+---
+
+## Layer 5: Element-Level Specification
+
+Elements are the smallest specifiable units: buttons, fields, icons, labels.
+
+### What to Specify
+
+For each element:
+
+1. **All States** — Every possible state it can be in
+2. **Content** — Exact text (not lorem ipsum)
+3. **ARIA Attributes** — Specific accessibility properties
+4. **Behavior** — What happens on interaction
+5. **Translations** — Content in all supported languages
+
+### Element Specification Format
+
+```markdown
+## Element: [Element Name]
+**ID:** [Full-Hierarchy-ID]
+
+### Type
+[Button/Input/Icon/Label/Link]
+
+### States
+- Default: [Description]
+- [Other states]: [Description]
+
+### Content
+- Label: "[Exact text]"
+- Translations:
+  - ES: "[Spanish text]"
+  - DE: "[German text]"
+
+### ARIA
+- role: "[Role]"
+- aria-label: "[Label]"
+- aria-required: "[true/false]"
+- [Other ARIA attributes]
+
+### Behavior
+[What happens when user interacts]
+```
+
+### Example: Email Field Element
+
+```markdown
+## Element: Email Field
+**ID:** P01-S03-W01-E01-email-field
+
+### Type
+Text input (email)
+
+### States
+- Default: Empty, placeholder visible
+- Focused: Border highlight, placeholder fades
+- Typing: Real-time format validation
+- Valid: Green checkmark appears
+- Invalid: Red border, error message below
+- Disabled: Grayed out (during submission)
+
+### Content
+- Label: "Email"
+- Placeholder: "you@company.com"
+- Error Message (invalid format): "Please enter a valid email address"
+- Error Message (taken): "This email is already registered. [Log in instead →]"
+- Translations:
+  - ES:
+    - Label: "Correo electrónico"
+    - Placeholder: "tu@empresa.com"
+    - Error (invalid): "Por favor, introduce una dirección de correo válida"
+    - Error (taken): "Este correo ya está registrado. [Iniciar sesión →]"
+
+### ARIA
+- role: "textbox"
+- aria-label: "Email address for your account"
+- aria-required: "true"
+- aria-invalid: "false" (default) → "true" (when error)
+- aria-describedby: "email-error" (when error message shown)
+
+### Behavior
+- On focus: Placeholder fades to 50% opacity
+- On blur: Validate email format
+- On change (after 1s delay): Check email availability (async)
+- On error: Focus remains in field, error announced to screen reader
+```
+
+**Notice:** The element spec is COMPLETE. A developer can build this exactly from the specification without asking questions.
+
+---
+
+## The Pattern
+
+Working from large to small ensures:
+
+```
+Page establishes:     → WHY this exists, WHO it's for
+  ↓
+Sections establish:   → WHERE things appear, WHEN they load
+  ↓
+Widgets establish:    → WHAT can be reused, HOW it validates
+  ↓
+Cards establish:      → PATTERN for grouped content
+  ↓
+Elements establish:   → EXACT implementation details
+```
+
+**You cannot specify an element without understanding the widget.**
+**You cannot specify a widget without understanding the section.**
+**You cannot specify a section without understanding the page.**
+
+---
+
+## IDs Connect the Hierarchy
+
+```
+P01-signup-page
+│
+├── P01-S01-header-section
+│   └── P01-S01-W01-logo-link
+│       └── P01-S01-W01-E01-logo-image
+│
+├── P01-S02-hero-section
+│   └── P01-S02-W01-value-prop-widget
+│       ├── P01-S02-W01-E01-headline
+│       └── P01-S02-W01-E02-subtext
+│
+├── P01-S03-form-section
+│   └── P01-S03-W01-signup-form
+│       ├── P01-S03-W01-E01-email-field
+│       ├── P01-S03-W01-E02-password-field
+│       ├── P01-S03-W01-E03-show-password-toggle
+│       ├── P01-S03-W01-E04-strength-indicator
+│       └── P01-S03-W01-E05-submit-button
+│
+└── P01-S04-footer-section
+    ├── P01-S04-W01-legal-links
+    └── P01-S04-C01-feature-card (template, 3 instances)
+        ├── P01-S04-C01-E01-icon
+        ├── P01-S04-C01-E02-title
+        └── P01-S04-C01-E03-description
+```
+
+Every ID traces from page to element. This is your implementation map.
+
+---
+
+## Completeness Test
+
+Your specification is complete when:
+
+✅ A developer can build the page without asking questions
+✅ A translator can extract all content and know where it appears
+✅ A tester can verify every state in every element
+✅ An accessibility auditor can validate all ARIA attributes
+✅ A designer returning 6 months later can understand every decision
+
+**If any role needs to guess, the spec is incomplete.**
+
+---
+
+## Common Mistakes
+
+| Mistake | Why It Fails | Fix |
+|---------|--------------|-----|
+| Starting with buttons | No context for decisions | Start with page purpose |
+| Skipping sections | Don't know where widgets appear | Always specify section first |
+| Forgetting states | Bugs in edge cases | Document all states |
+| Lorem ipsum content | Can't plan for translations | Write real copy |
+| No IDs | Can't trace to implementation | ID everything from page to element |
+
+---
+
+## What's Next
+
+In Lesson 2, you'll learn how to specify sections and widgets in detail, including advanced patterns for complex components.
+
+In Lesson 3, you'll learn how to specify elements and states completely, covering all edge cases and accessibility requirements.
+
+---
+
+**[Continue to Lesson 2: Section & Widget Specifications →](lesson-02-section-widget-specifications.md)**
+
+---
+
+[← Back to Module Overview](module-11-conceptual-specifications-overview.md)
+
+*Part of Module 11: Conceptual Specifications*
diff --git a/docs/learn/module-11-conceptual-specifications/lesson-02-section-widget-specifications.md b/docs/learn/module-11-conceptual-specifications/lesson-02-section-widget-specifications.md
new file mode 100644
index 000000000..e883eeec4
--- /dev/null
+++ b/docs/learn/module-11-conceptual-specifications/lesson-02-section-widget-specifications.md
@@ -0,0 +1,704 @@
+# Module 11: Conceptual Specifications
+
+## Lesson 2: Section & Widget Specifications
+
+**Deep dive on Layers 2 & 3 of the hierarchy**
+
+---
+
+## Working Down the Hierarchy
+
+You've specified the page-level context (Lesson 1). Now you work down to the major structural elements:
+
+- **Layer 2: Sections** — Major areas that organize the page
+- **Layer 3: Widgets** — Reusable components with complex behavior
+
+These middle layers bridge strategy (page level) and implementation (element level).
+
+---
+
+## Section-Level Specifications (Layer 2)
+
+Sections divide the page into logical areas. Each section serves a purpose.
+
+### What Sections Define
+
+```
+Page-Level:     "This is the signup page for Felix"
+                ↓
+Section-Level:  "This hero section communicates value prop"
+                "This form section collects minimal data"
+                "This footer section provides legal links"
+```
+
+Sections answer:
+- **Why does this section exist?**
+- **Where does it appear on the page?**
+- **How does it behave responsively?**
+- **When does it load?**
+
+---
+
+## Section Specification Pattern
+
+Every section follows this structure:
+
+```markdown
+## Section: [Section Name]
+**ID:** [Page-ID]-[Section-ID]
+
+### Purpose
+[Why this section exists, what it accomplishes]
+
+### Placement
+- Position: [Header/Above fold/Below fold/Footer]
+- Order: [Relative to other sections]
+- Responsive: [How it adapts across breakpoints]
+
+### Behavior
+- Sticky: [Yes/No, conditions]
+- Collapsible: [Yes/No, interaction]
+- Animation: [Entry/exit animations]
+- Visibility: [Always/Conditional]
+
+### Load Priority
+[Critical/High/Normal/Low - when it loads]
+
+### Accessibility
+- Landmark: [ARIA landmark role]
+- Heading: [h1/h2/h3 - heading hierarchy]
+- Skip Link: [Yes/No - skip to this section]
+
+### Contains
+[List of widgets/cards in this section]
+```
+
+---
+
+## Section Example: Header
+
+```markdown
+## Section: Header
+**ID:** P01-S01-header-section
+
+### Purpose
+Provide consistent navigation and branding across all authenticated pages.
+Allow users to access account settings and log out.
+
+### Placement
+- Position: Top of page (header)
+- Order: First section on all pages
+- Responsive:
+  - Mobile (<768px): Logo left, hamburger menu right
+  - Tablet (768-1024px): Logo left, condensed nav center, profile right
+  - Desktop (>1024px): Logo left, full nav center, profile + logout right
+
+### Behavior
+- Sticky: Yes (remains visible on scroll)
+- Collapsible: No
+- Animation: Slides down on page load (200ms ease-out)
+- Visibility: Always (on all authenticated pages)
+
+### Load Priority
+Critical (renders immediately, blocks page display)
+
+### Accessibility
+- Landmark: role="banner"
+- Heading: No heading in header (page h1 is below)
+- Skip Link: Yes ("Skip to main content" link for keyboard users)
+
+### Contains
+- W01: Logo Link (navigates to dashboard)
+- W02: Main Navigation Widget
+- W03: User Profile Menu Widget
+```
+
+---
+
+## Section Example: Form Area
+
+```markdown
+## Section: Form Area
+**ID:** P01-S03-form-section
+
+### Purpose
+Contain the signup form widget, isolated from distractions to maintain
+focus on the primary action (account creation).
+
+### Placement
+- Position: Above fold, centered
+- Order: After hero section, before footer
+- Responsive:
+  - Mobile: Full width, padding 16px
+  - Tablet: Max-width 480px, centered
+  - Desktop: Max-width 480px, centered
+
+### Behavior
+- Sticky: No
+- Collapsible: No
+- Animation: Fade in after hero (300ms delay)
+- Visibility: Always
+
+### Load Priority
+Critical (primary conversion point)
+
+### Accessibility
+- Landmark: role="main"
+- Heading: h1 ("Create Your Account")
+- Skip Link: No (already in main content)
+
+### Contains
+- W01: Signup Form Widget
+```
+
+---
+
+## Section Responsive Behavior
+
+Document how sections adapt across breakpoints:
+
+```markdown
+### Dashboard Section Responsive Behavior
+
+**Mobile (<768px):**
+- Stack all content vertically
+- Full width cards
+- Collapse navigation to hamburger
+- Priority content first (tasks before calendar)
+
+**Tablet (768-1024px):**
+- Two-column grid
+- Tasks left (60%), Calendar right (40%)
+- Condensed navigation
+- Touch targets 44px minimum
+
+**Desktop (>1024px):**
+- Three-column grid
+- Tasks left (40%), Calendar center (40%), Sidebar right (20%)
+- Full navigation visible
+- Hover interactions enabled
+```
+
+**The pattern:** Mobile-first content priority, progressive enhancement for larger screens.
+
+---
+
+## Widget-Level Specifications (Layer 3)
+
+Widgets are reusable components. They appear in multiple places and carry complex behavior.
+
+### What Widgets Define
+
+```
+Section-Level:  "This section contains the signup form"
+                ↓
+Widget-Level:   "The signup form widget has 7 states,
+                 validates in real-time, and can be
+                 embedded in modal or standalone page"
+```
+
+Widgets answer:
+- **Where is this widget reused?**
+- **What are all its states?**
+- **How does it validate?**
+- **What accessibility pattern does it follow?**
+
+---
+
+## Widget Specification Pattern
+
+Every widget follows this structure:
+
+```markdown
+## Widget: [Widget Name]
+**ID:** [Page-ID]-[Section-ID]-[Widget-ID]
+
+### Purpose
+[What this widget accomplishes]
+
+### Reusability
+- Used in: [List all pages/contexts]
+- Variations: [Different configurations if any]
+
+### States
+[All possible states with descriptions]
+
+### Validation
+[Rules, timing, feedback]
+
+### Accessibility
+- ARIA Pattern: [Standard pattern name]
+- Keyboard: [Key interactions]
+- Focus: [Focus management rules]
+- Screen Reader: [Announcement strategy]
+
+### Responsive Behavior
+[How widget adapts to screen sizes]
+
+### Content Structure
+[Slots, placeholders, dynamic content areas]
+
+### Contains
+[List child elements - detailed in Lesson 3]
+```
+
+---
+
+## Widget Example: Navigation Menu
+
+```markdown
+## Widget: Main Navigation Menu
+**ID:** W02-main-nav-widget
+
+### Purpose
+Provide access to all primary sections of the application.
+Orient users to available features.
+
+### Reusability
+- Used in: All authenticated pages (header section)
+- Variations:
+  - Full navigation (desktop)
+  - Condensed navigation (tablet)
+  - Hamburger menu (mobile)
+
+### States
+- Default: All nav items visible (desktop)
+- Hover: Item background highlights
+- Active: Current page highlighted with underline
+- Mobile Closed: Hamburger icon only
+- Mobile Open: Full-screen overlay with nav items
+- Disabled: Some items disabled based on user permissions
+
+### Validation
+N/A (navigation doesn't validate)
+
+### Accessibility
+- ARIA Pattern: Navigation landmark + menu pattern
+- Keyboard:
+  - Tab: Move through nav items
+  - Enter/Space: Activate link
+  - Escape: Close mobile menu (when open)
+  - Arrow keys: Optional, move between items
+- Focus: Visible focus ring (2px blue, 2px offset)
+- Screen Reader:
+  - Announces "Main navigation"
+  - Announces current page as "Current page, [Page Name]"
+  - Mobile menu state: "Menu, collapsed" / "Menu, expanded"
+
+### Responsive Behavior
+**Desktop (>1024px):**
+- Horizontal list, all items visible
+- Hover states active
+- Dropdown menus on hover (if nested)
+
+**Tablet (768-1024px):**
+- Condensed labels ("Dashboard" → "Dash")
+- Icons + short text
+- Touch-friendly spacing (44px targets)
+
+**Mobile (<768px):**
+- Hamburger icon only (☰)
+- Full-screen overlay when open
+- Vertical list, large touch targets
+- Close button (×) in top-right
+
+### Content Structure
+- Logo slot (left)
+- Nav items collection (center)
+  - Each item: Label + optional icon + optional badge
+- User menu slot (right)
+
+### Contains
+- E01: Logo Link
+- E02-E06: Navigation Links (5 primary nav items)
+- E07: User Profile Menu Trigger
+```
+
+---
+
+## Widget Example: Searchable Dropdown
+
+```markdown
+## Widget: User Selector Dropdown
+**ID:** W05-user-selector-widget
+
+### Purpose
+Allow task assignment by selecting from household members.
+Provide quick search/filter when household has many members.
+
+### Reusability
+- Used in: Task creation form, Task edit form, Calendar event form
+- Variations: Single-select (most contexts), Multi-select (bulk assignment)
+
+### States
+- Closed: Shows selected user (or "Select user..." placeholder)
+- Opening: 150ms ease-out animation, dropdown expands
+- Open: All users visible, search field focused
+- Searching: Filtered list based on search input
+- No Results: "No users found" empty state
+- Selected: Checkmark next to selected user
+- Closing: 150ms ease-in animation, dropdown collapses
+
+### Validation
+- Required field: Must select at least one user before form submit
+- Validation timing: On blur and on submit attempt
+- Error message: "Please select a user" (appears below dropdown)
+
+### Accessibility
+- ARIA Pattern: Combobox with listbox
+- Keyboard:
+  - Tab: Focus dropdown trigger
+  - Enter/Space: Open dropdown
+  - Arrow Down: Next user (when open)
+  - Arrow Up: Previous user (when open)
+  - Home: First user
+  - End: Last user
+  - Type characters: Filter list
+  - Enter: Select current user
+  - Escape: Close without selection
+- Focus: Moves to search field when dropdown opens
+- Screen Reader:
+  - Dropdown trigger: "Select user, combobox, collapsed"
+  - When open: "Select user, combobox, expanded, 5 users"
+  - Each option: "User name, [selected/not selected]"
+  - No results: "No users found, 0 results"
+
+### Responsive Behavior
+**All screen sizes:**
+- Dropdown width matches trigger button width (min 240px)
+- Max height: 320px, scrollable if more users
+- Search field always visible at top when open
+
+**Mobile considerations:**
+- Larger touch targets (48px rows)
+- Search field gets focus + brings up keyboard
+- Consider modal on very small screens (<375px)
+
+### Content Structure
+- Trigger button (shows current selection or placeholder)
+- Dropdown container (visible when open):
+  - Search field
+  - User list (scrollable)
+  - Each user item:
+    - Avatar (optional)
+    - Name
+    - Role label (optional)
+    - Selection indicator (checkmark)
+
+### Contains
+- E01: Dropdown Trigger Button
+- E02: Search Input Field
+- E03: User List Container
+- E04-E0N: User List Items (dynamic count)
+- E0N+1: No Results Message (conditional)
+```
+
+---
+
+## Widget States in Depth
+
+Widgets often have complex state machines. Document them systematically:
+
+```markdown
+### Accordion Widget States
+
+**State Diagram:**
+
+```
+┌─────────────┐
+│  Collapsed  │ ◄─── Default
+└──────┬──────┘
+       │ (user clicks header)
+       ↓
+┌─────────────┐
+│  Expanding  │ ◄─── Transition (300ms)
+└──────┬──────┘
+       │
+       ↓
+┌─────────────┐
+│  Expanded   │
+└──────┬──────┘
+       │ (user clicks header again)
+       ↓
+┌─────────────┐
+│ Collapsing  │ ◄─── Transition (300ms)
+└──────┬──────┘
+       │
+       ↓
+Back to Collapsed
+```
+
+**State Details:**
+
+| State | Visual | Keyboard Focus | ARIA |
+|-------|--------|----------------|------|
+| Collapsed | Content hidden, chevron → | Header focusable | aria-expanded="false" |
+| Expanding | Content animates in, chevron rotates | Focus stays on header | aria-expanded="true" |
+| Expanded | Content visible, chevron ↓ | Content focusable | aria-expanded="true" |
+| Collapsing | Content animates out, chevron rotates | Focus stays on header | aria-expanded="false" |
+```
+
+---
+
+## Widget Interaction Details
+
+For complex widgets, specify exact interaction behavior:
+
+```markdown
+### Modal Dialog Interaction
+
+**Opening:**
+1. Trigger: User clicks "Create Task" button
+2. Animation: 200ms ease-out
+   - Backdrop: Fade in from 0% to 60% opacity
+   - Modal: Scale from 0.95 to 1.0 + fade in
+3. Focus: Moves to first input field in modal
+4. Body scroll: Disabled (overflow: hidden on body)
+
+**While Open:**
+- Tab: Cycles through focusable elements within modal
+- Shift+Tab: Reverse cycle
+- Escape: Close modal (same as clicking Cancel)
+- Click backdrop: Prompt "Unsaved changes. Close anyway?" if form is dirty
+
+**Closing:**
+1. Trigger: Click Cancel, click X, press Escape, or submit successfully
+2. Animation: 150ms ease-in
+   - Modal: Fade out + scale to 0.95
+   - Backdrop: Fade out (starts when modal hits 50% opacity)
+3. Focus: Returns to trigger button that opened modal
+4. Body scroll: Re-enabled
+
+**Submit Flow:**
+1. User clicks Submit
+2. Validation runs (client-side)
+3. If invalid: Show errors, focus first error, stay open
+4. If valid: Submit to server
+5. While submitting: Show loading spinner, disable all inputs
+6. On success: Brief success state (1s), then close modal
+7. On error: Show error message, re-enable inputs, stay open
+```
+
+---
+
+## Widget Validation Patterns
+
+Document validation rules clearly:
+
+```markdown
+### Form Widget Validation
+
+**Validation Strategy:**
+- Inline validation (on blur from field)
+- Submit validation (when Submit clicked)
+- Real-time validation (for password strength, username availability)
+
+**Validation Rules:**
+
+| Field | Rule | Check Timing | Error Message |
+|-------|------|--------------|---------------|
+| Email | Required | On blur, On submit | "Email is required" |
+| Email | Valid format | On blur, On submit | "Please enter a valid email" |
+| Email | Not already registered | 1s after typing stops | "This email is already registered. [Log in →]" |
+| Password | Required | On blur, On submit | "Password is required" |
+| Password | Min 8 characters | Real-time (as typing) | "At least 8 characters needed" |
+| Password | Contains number | Real-time (as typing) | "Include at least one number" |
+| Password | Strength check | Real-time (as typing) | Indicator: Weak/Fair/Strong |
+
+**Validation Display:**
+- Error messages: Below field, red text (#DC2626)
+- Field border: Red (#DC2626) when invalid
+- Success indicator: Green checkmark (when valid + blurred)
+- Submit button: Disabled until all fields valid
+```
+
+---
+
+## Section & Widget Integration
+
+Sections contain widgets. Specify the relationship:
+
+```markdown
+## Section: Dashboard Main
+**ID:** P05-S02-dashboard-main
+
+### Contains
+- W01: Task List Widget
+  - Displays user's assigned tasks
+  - Allows status updates
+  - Supports filtering by status/date
+  - See: [Widget W01 specification](../widgets/W01-task-list.md)
+
+- W02: Calendar Widget
+  - Shows weekly view
+  - Displays scheduled tasks and events
+  - Allows drag-to-reschedule
+  - See: [Widget W02 specification](../widgets/W02-calendar.md)
+
+- W03: Quick Add Widget
+  - Floating action button (bottom-right)
+  - Opens task creation modal
+  - Persists across page scroll
+  - See: [Widget W03 specification](../widgets/W03-quick-add.md)
+```
+
+**The pattern:** Sections define WHERE and WHEN. Widgets define WHAT and HOW.
+
+---
+
+## Responsive Section + Widget Example
+
+```markdown
+## Section: Product Grid
+**ID:** P08-S03-product-grid-section
+
+### Responsive Behavior
+
+**Mobile (<768px):**
+- Single column layout
+- Each product card full width
+- Stack: Image → Title → Price → Add to Cart
+- Infinite scroll (load more on scroll)
+
+**Tablet (768-1024px):**
+- Two-column grid
+- Product cards in 2-up layout
+- Gap: 24px between cards
+- Pagination (load more button at bottom)
+
+**Desktop (>1024px):**
+- Three-column grid
+- Product cards in 3-up layout
+- Gap: 32px between cards
+- Pagination (load more button at bottom)
+
+### Contains
+- W01: Filter Bar Widget (sticky on scroll)
+- W02: Product Card Widget (template, rendered N times)
+  - Widget adapts to container width
+  - See: [Widget W02 specification](../widgets/W02-product-card.md)
+```
+
+---
+
+## Accessibility Landmarks
+
+Sections use ARIA landmarks for screen reader navigation:
+
+```markdown
+### Page Landmark Structure
+
+```
+<body>
+  <header role="banner">                    ← P01-S01-header-section
+    <nav role="navigation">                 ← W02-main-nav-widget
+  </header>
+
+  <main role="main">                        ← P01-S02-main-section
+    <section aria-labelledby="tasks-heading">  ← P01-S03-tasks-section
+      <h2 id="tasks-heading">Your Tasks</h2>
+    </section>
+
+    <aside role="complementary" aria-label="Calendar">  ← P01-S04-calendar-section
+    </aside>
+  </main>
+
+  <footer role="contentinfo">               ← P01-S05-footer-section
+  </footer>
+</body>
+```
+
+**Landmark Guidelines:**
+- One banner per page (header)
+- One main per page
+- One contentinfo per page (footer)
+- Navigation landmarks for nav menus
+- Complementary for sidebars/related content
+- Label sections with aria-labelledby or aria-label when multiple of same type
+```
+
+---
+
+## Common Section Patterns
+
+### Sticky Header
+
+```markdown
+### Behavior
+- Sticky: Yes
+- Sticky Threshold: Scroll > 100px
+- Animation: Shrinks from 80px to 60px height on scroll
+- Shadow: Adds drop shadow when stuck
+- Z-index: 100 (above all other content)
+```
+
+### Collapsible Sidebar
+
+```markdown
+### Behavior
+- Collapsible: Yes
+- Collapsed Width: 60px (icons only)
+- Expanded Width: 240px (icons + labels)
+- Toggle: Button in sidebar header
+- Animation: 200ms ease-out width transition
+- Persistence: State saved to localStorage
+```
+
+### Loading Section
+
+```markdown
+### Load Priority
+Priority: Low (below fold)
+
+### Loading Behavior
+- Skeleton: Show 3 skeleton cards while loading
+- Lazy: Only load when user scrolls within 200px of section
+- Timeout: If load exceeds 5s, show "Taking longer..." message
+- Error: If load fails, show "Couldn't load. [Retry]" button
+```
+
+---
+
+## Common Widget Patterns
+
+### Form Widgets
+
+- Real-time validation as user types
+- Debounced async checks (username availability, email verification)
+- Disabled submit until valid
+- Loading state on submit
+- Error recovery (re-enable form on error)
+
+### List Widgets
+
+- Empty states ("No items yet")
+- Loading states (skeleton items)
+- Pagination or infinite scroll
+- Sort and filter controls
+- Bulk actions (select multiple items)
+
+### Dialog/Modal Widgets
+
+- Backdrop click behavior
+- Escape key closes
+- Focus trap (Tab cycles within modal)
+- Return focus to trigger on close
+- Prevent body scroll when open
+
+---
+
+## What's Next
+
+You've specified sections and widgets — the structural and behavioral layers.
+
+In Lesson 3, you'll learn how to specify cards and elements with complete state coverage, including all edge cases, error states, and exact content.
+
+---
+
+**[Continue to Lesson 3: Element & State Specifications →](lesson-03-element-state-specifications.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-design-is-specification.md) | [Back to Module Overview](module-11-conceptual-specifications-overview.md)
+
+*Part of Module 11: Conceptual Specifications*
diff --git a/docs/learn/module-11-conceptual-specifications/lesson-03-element-state-specifications.md b/docs/learn/module-11-conceptual-specifications/lesson-03-element-state-specifications.md
new file mode 100644
index 000000000..d0b18a884
--- /dev/null
+++ b/docs/learn/module-11-conceptual-specifications/lesson-03-element-state-specifications.md
@@ -0,0 +1,949 @@
+# Module 11: Conceptual Specifications
+
+## Lesson 3: Element & State Specifications
+
+**Deep dive on Layers 4 & 5 — Complete implementation details**
+
+---
+
+## The Final Layers
+
+You've specified pages, sections, and widgets. Now you document the details that developers implement:
+
+- **Layer 4: Cards** — Content grouping patterns
+- **Layer 5: Elements** — Individual UI pieces with complete state coverage
+
+These are the most detailed specifications. Get them right, and developers build exactly what you envisioned.
+
+---
+
+## Card-Level Specifications (Layer 4)
+
+Cards group related content into repeatable patterns.
+
+### What Cards Define
+
+```
+Widget-Level:   "Task list widget displays user tasks"
+                ↓
+Card-Level:     "Each task card shows title, assignee,
+                 due date, status, and action buttons"
+```
+
+Cards answer:
+- **What content pattern does this represent?**
+- **What data structure feeds it?**
+- **How many instances appear?**
+- **Is it interactive?**
+
+---
+
+## Card Specification Pattern
+
+```markdown
+## Card: [Card Name]
+**ID:** [Parent-ID]-[Card-ID]
+
+### Purpose
+[What this card displays/represents]
+
+### Data Structure
+[Schema or data shape that feeds this card]
+
+### Instances
+[Single/Template/Fixed count]
+
+### Interaction
+[Static/Clickable/Expandable/Draggable]
+
+### States
+[If interactive, document states]
+
+### Content Slots
+[What content areas exist]
+
+### Layout
+[Visual arrangement of elements]
+
+### Contains
+[List child elements]
+```
+
+---
+
+## Card Example: Task Card
+
+```markdown
+## Card: Task Card
+**ID:** W01-C01-task-card
+
+### Purpose
+Display one task with key information and actions.
+Allow quick status updates and task access.
+
+### Data Structure
+```json
+{
+  "id": "string (UUID)",
+  "title": "string (max 100 chars)",
+  "assignee": {
+    "id": "string",
+    "name": "string",
+    "avatar": "string (URL)"
+  },
+  "dueDate": "ISO 8601 date string",
+  "status": "enum (pending|in_progress|completed)",
+  "priority": "enum (low|medium|high)"
+}
+```
+
+### Instances
+Template card, rendered once per task (dynamic count)
+
+### Interaction
+- Clickable: Yes (entire card navigates to task detail)
+- Expandable: No
+- Draggable: Yes (for reordering in list)
+
+### States
+- Default: White background, normal text
+- Hover: Light gray background (#F3F4F6)
+- Pressed: Slight scale down (0.98)
+- Dragging: Lifted appearance (shadow), slightly rotated
+- Overdue: Red accent border when past due date
+- Completed: Strikethrough title, muted colors
+
+### Content Slots
+- Priority indicator (left edge, colored bar)
+- Title text
+- Assignee avatar + name
+- Due date
+- Status badge
+- Quick action menu (three dots, right edge)
+
+### Layout
+```
+┌────────────────────────────────────┐
+│ ┃ [Title Text]           [•••]    │
+│ ┃                                  │
+│ ┃ [👤 Assignee]  [📅 Date]  [●]   │
+└────────────────────────────────────┘
+ ↑                               ↑
+Priority                      Status
+```
+
+### Contains
+- E01: Priority Bar
+- E02: Task Title
+- E03: Assignee Avatar
+- E04: Assignee Name
+- E05: Due Date Label
+- E06: Status Badge
+- E07: Action Menu Button
+```
+
+---
+
+## Card Example: Feature Card
+
+```markdown
+## Card: Feature Card
+**ID:** P01-S04-C01-feature-card
+
+### Purpose
+Highlight one product feature to build trust before signup.
+
+### Data Structure
+```json
+{
+  "icon": "string (icon identifier)",
+  "title": "string (max 50 chars)",
+  "description": "string (max 120 chars)"
+}
+```
+
+### Instances
+Template, rendered 3 times with fixed data
+
+### Interaction
+Static (not clickable)
+
+### States
+N/A (no interactive states)
+
+### Content Slots
+- Icon (centered, 48x48px)
+- Title (centered, h3)
+- Description (centered, body text)
+
+### Layout
+```
+┌─────────────────┐
+│                 │
+│      [Icon]     │
+│                 │
+│   Feature Title │
+│                 │
+│   Description   │
+│   text goes     │
+│   here          │
+│                 │
+└─────────────────┘
+```
+
+### Contains
+- E01: Feature Icon
+- E02: Feature Title
+- E03: Feature Description
+```
+
+---
+
+## Element-Level Specifications (Layer 5)
+
+Elements are the atomic UI pieces: buttons, inputs, labels, icons.
+
+### What Elements Define
+
+```
+Card-Level:     "Task card contains title, assignee, status"
+                ↓
+Element-Level:  "Status badge has 3 states: pending (gray),
+                 in_progress (blue), completed (green),
+                 with specific text and aria-label for each"
+```
+
+Elements answer:
+- **What are ALL possible states?**
+- **What is the EXACT content?**
+- **What ARIA attributes apply?**
+- **How does it behave on interaction?**
+- **What are the translations?**
+
+---
+
+## Element Specification Pattern
+
+```markdown
+## Element: [Element Name]
+**ID:** [Full-Hierarchy-ID]
+
+### Type
+[Button/Input/Label/Icon/Link/Text/etc.]
+
+### States
+[Every possible state with complete description]
+
+### Content
+- Label: "[Exact text]"
+- Placeholder: "[Exact text if applicable]"
+- Translations: [All supported languages]
+
+### ARIA
+[All ARIA attributes for each state]
+
+### Behavior
+[What happens on interaction]
+
+### Visual
+[Colors, sizes, spacing if critical to specification]
+```
+
+---
+
+## Element Example: Submit Button
+
+```markdown
+## Element: Submit Button
+**ID:** P01-S03-W01-E05-submit-button
+
+### Type
+Button (primary action)
+
+### States
+
+#### Default
+- Label: "Create Free Account"
+- Appearance: Blue background (#2563EB), white text
+- Cursor: Pointer
+- Enabled: Yes
+- aria-disabled: "false"
+
+#### Hover
+- Appearance: Darker blue (#1E40AF)
+- Transition: 150ms ease
+- Everything else: Same as default
+
+#### Active (pressed)
+- Appearance: Even darker blue (#1E3A8A)
+- Scale: 0.98 (slight press effect)
+
+#### Disabled
+- Label: "Create Free Account"
+- Appearance: Gray background (#D1D5DB), gray text (#6B7280)
+- Cursor: Not-allowed
+- Enabled: No
+- aria-disabled: "true"
+- Reason: Form validation incomplete
+
+#### Loading
+- Label: [Hidden, replaced by spinner]
+- Appearance: Blue background, spinner centered
+- Cursor: Wait
+- Enabled: No (can't click during submit)
+- aria-busy: "true"
+- aria-label: "Creating account, please wait"
+
+#### Success (brief)
+- Label: [Hidden, replaced by checkmark ✓]
+- Appearance: Green background (#10B981)
+- Duration: 1.5s visible, then redirect
+- aria-label: "Account created successfully"
+
+#### Error (server error)
+- Returns to Default state
+- Error message appears above form (not on button)
+
+### Content
+
+**English:**
+- Label: "Create Free Account"
+- Loading: aria-label "Creating account, please wait"
+- Success: aria-label "Account created successfully"
+
+**Spanish:**
+- Label: "Crear Cuenta Gratuita"
+- Loading: aria-label "Creando cuenta, por favor espere"
+- Success: aria-label "Cuenta creada exitosamente"
+
+**German:**
+- Label: "Kostenloses Konto erstellen"
+- Loading: aria-label "Konto wird erstellt, bitte warten"
+- Success: aria-label "Konto erfolgreich erstellt"
+
+### ARIA
+
+**Default/Hover/Active:**
+- role: "button" (implicit from <button>)
+- type: "submit"
+- aria-label: Not needed (label is visible)
+- aria-disabled: "false"
+
+**Disabled:**
+- aria-disabled: "true"
+- aria-describedby: Points to validation error if specific reason
+
+**Loading:**
+- aria-busy: "true"
+- aria-label: "Creating account, please wait"
+- aria-live: "polite" (announces state change)
+
+**Success:**
+- aria-label: "Account created successfully"
+- aria-live: "polite" (announces success)
+
+### Behavior
+
+**On Click (when enabled):**
+1. Trigger form validation
+2. If invalid: Prevent submit, focus first error field
+3. If valid: Change to Loading state
+4. Submit form data to server
+5. On success response: Change to Success state (1.5s), then redirect
+6. On error response: Return to Default, show error message above form
+
+**On Enter key (when focused):**
+Same as click behavior
+
+### Visual
+- Height: 48px (comfortable touch target)
+- Width: 100% of form width (mobile), min 200px (desktop)
+- Border radius: 8px
+- Font: 16px, semi-bold
+- Padding: 12px 24px
+```
+
+---
+
+## Element Example: Email Input Field
+
+```markdown
+## Element: Email Input Field
+**ID:** P01-S03-W01-E01-email-field
+
+### Type
+Text input (email)
+
+### States
+
+#### Default (empty)
+- Placeholder: "you@example.com"
+- Border: 1px gray (#D1D5DB)
+- Background: White
+- Label: "Email" (above field)
+- Value: ""
+- aria-invalid: "false"
+
+#### Focused (user clicks in)
+- Border: 2px blue (#2563EB)
+- Placeholder: Fades to 50% opacity
+- Focus ring: 2px blue outline, 2px offset
+- All else: Same as default
+
+#### Typing (user entering text)
+- Shows typed characters
+- Placeholder: Hidden
+- Validation: Not yet triggered
+- All else: Same as focused
+
+#### Valid (after blur, email format correct)
+- Border: 1px green (#10B981)
+- Success icon: Green checkmark appears (right side)
+- aria-invalid: "false"
+- All else: Same as default
+
+#### Invalid - Format (after blur, email format incorrect)
+- Border: 2px red (#DC2626)
+- Error message: "Please enter a valid email address" (below field)
+- Error icon: Red X appears (right side)
+- aria-invalid: "true"
+- aria-describedby: "email-error"
+
+#### Invalid - Taken (async check, email already registered)
+- Border: 2px red (#DC2626)
+- Error message: "This email is already registered. [Log in instead →]" (below field)
+- Error icon: Red X appears
+- aria-invalid: "true"
+- aria-describedby: "email-error"
+- Link: "Log in instead" navigates to login page
+
+#### Disabled (during form submission)
+- Background: Light gray (#F3F4F6)
+- Text: Gray (#6B7280)
+- Cursor: Not-allowed
+- Editable: No
+- aria-disabled: "true"
+
+### Content
+
+**English:**
+- Label: "Email"
+- Placeholder: "you@example.com"
+- Error (format): "Please enter a valid email address"
+- Error (taken): "This email is already registered. [Log in instead →]"
+- Helper text: None
+
+**Spanish:**
+- Label: "Correo electrónico"
+- Placeholder: "tu@ejemplo.com"
+- Error (format): "Por favor, introduce una dirección de correo válida"
+- Error (taken): "Este correo ya está registrado. [Iniciar sesión →]"
+
+**German:**
+- Label: "E-Mail"
+- Placeholder: "du@beispiel.com"
+- Error (format): "Bitte geben Sie eine gültige E-Mail-Adresse ein"
+- Error (taken): "Diese E-Mail ist bereits registriert. [Anmelden →]"
+
+### ARIA
+
+**Default:**
+- role: "textbox" (implicit)
+- type: "email"
+- id: "email-field"
+- aria-label: "Email address for your account"
+- aria-required: "true"
+- aria-invalid: "false"
+- autocomplete: "email"
+
+**Invalid:**
+- aria-invalid: "true"
+- aria-describedby: "email-error"
+- Error element: id="email-error", role="alert"
+
+**Disabled:**
+- aria-disabled: "true"
+
+### Behavior
+
+**On Focus:**
+- Border becomes blue
+- Placeholder fades
+- Cursor appears in field
+
+**On Blur (user leaves field):**
+1. Validate email format (regex check)
+2. If invalid format: Show format error
+3. If valid format: Start async check (debounced 1s)
+4. Async check: Verify email not already registered
+5. If taken: Show "already registered" error with login link
+6. If available: Show green checkmark
+
+**On Change (while typing):**
+- Real-time character entry
+- No validation until blur (except clearing previous errors)
+
+**On Paste:**
+- Accept pasted text
+- Trigger validation after paste completes
+
+### Visual
+- Height: 48px
+- Width: 100% of form width
+- Border radius: 8px
+- Font: 16px (prevents zoom on iOS)
+- Padding: 12px 16px
+- Error message: 14px, red (#DC2626), 4px below field
+```
+
+---
+
+## All States Matter
+
+Every element needs complete state documentation:
+
+### Button States Checklist
+
+- [ ] Default
+- [ ] Hover
+- [ ] Active (pressed)
+- [ ] Focused (keyboard navigation)
+- [ ] Disabled
+- [ ] Loading
+- [ ] Success (if applicable)
+- [ ] Error (if applicable)
+
+### Input States Checklist
+
+- [ ] Default (empty)
+- [ ] Focused
+- [ ] Typing
+- [ ] Valid
+- [ ] Invalid (with all error types)
+- [ ] Disabled
+- [ ] Read-only (if applicable)
+
+### Link States Checklist
+
+- [ ] Default
+- [ ] Hover
+- [ ] Active (pressed)
+- [ ] Visited (if applicable)
+- [ ] Focused
+
+**The rule: If developers might ask "What happens when...", you need a state for it.**
+
+---
+
+## Edge Cases
+
+Document what happens when things go wrong or unusual:
+
+```markdown
+## Edge Cases for Form Submission
+
+### Email Already Exists
+- **Trigger:** Server returns 409 Conflict
+- **Display:** Error below email field: "This email is already registered. [Log in instead →]"
+- **Action:** Link navigates to login page
+- **Recovery:** User can try different email or click link to login
+- **State:** Form re-enabled, focus stays on email field
+
+### Network Error
+- **Trigger:** Request times out (>10s) or connection fails
+- **Display:** Error banner above form: "Connection lost. Your data is saved."
+- **Action:** [Retry] button appears
+- **Recovery:** Click Retry resubmits with same data (not lost)
+- **State:** Form re-enabled
+
+### Rate Limited
+- **Trigger:** Too many signup attempts from IP
+- **Display:** Error banner: "Too many attempts. Try again in 5 minutes."
+- **Action:** Countdown timer visible (5:00, 4:59, 4:58...)
+- **Recovery:** Wait for timer, form re-enables when timer expires
+- **State:** Form disabled during countdown
+
+### Browser Back Button During Submit
+- **Trigger:** User clicks browser back while form is submitting
+- **Display:** Browser confirms: "Are you sure? Form submission in progress."
+- **Recovery:** If user proceeds back, request is cancelled
+- **State:** Form data lost (unless browser preserves it)
+
+### JavaScript Disabled
+- **Trigger:** User has JavaScript disabled
+- **Display:** Form still renders, no client-side validation
+- **Behavior:** Server-side validation handles everything
+- **Recovery:** Server returns page with errors highlighted
+- **State:** Progressive enhancement - works without JS
+```
+
+---
+
+## Empty States
+
+Every collection can be empty. Document what users see:
+
+```markdown
+## Task List Empty State
+
+**When:** User has no tasks assigned
+
+**Display:**
+- Illustration: Simple line drawing of empty checklist
+- Headline: "No tasks yet"
+- Subtext: "Tasks will appear here when they're assigned to you"
+- Action: [Browse all household tasks] button
+- Alternative: If user can create tasks: [Create your first task] button
+
+**Why:** Reduces confusion, sets expectation, provides next action
+
+**Visual:**
+```
+┌─────────────────────────────────┐
+│                                 │
+│           [Empty                │
+│            checklist            │
+│            illustration]        │
+│                                 │
+│         No tasks yet            │
+│                                 │
+│   Tasks will appear here when   │
+│   they're assigned to you       │
+│                                 │
+│   [Browse all household tasks]  │
+│                                 │
+└─────────────────────────────────┘
+```
+
+**ARIA:**
+- Container: role="status" (announces to screen readers)
+- aria-label: "No tasks assigned"
+```
+
+---
+
+## Loading States
+
+Document what users see while data loads:
+
+```markdown
+## Dashboard Loading State
+
+**Duration:** Typically 0-3 seconds
+
+**Skeleton Structure:**
+- Header: Static (user info visible, loaded from auth)
+- Task section: 3 skeleton cards (gray shimmer rectangles)
+- Calendar section: Skeleton grid matching final layout
+- Sidebar: Skeleton menu items
+
+**Animation:**
+- Shimmer effect: Light sweep left-to-right
+- Duration: 1.5s loop
+- Color: Gray (#E5E7EB) to lighter gray (#F3F4F6)
+
+**Fallback:**
+- If loading exceeds 5 seconds: Show "Taking longer than expected..."
+- Action: [Refresh] button appears
+- Why: Network issue or slow connection
+
+**Error State:**
+- If load fails: "Couldn't load dashboard"
+- Message: "Something went wrong. Please try again."
+- Action: [Retry] button
+- Alternative: "If problem persists, [contact support]"
+
+**Visual Comparison:**
+
+```
+LOADING                          LOADED
+┌────────────────────┐          ┌────────────────────┐
+│ ▓▓▓▓▓▓▓▓▓▓        │          │ Walk Max at 3pm    │
+│ ▓▓▓▓              │          │ Assigned: Alice    │
+│                    │          │ Due: Today         │
+├────────────────────┤          ├────────────────────┤
+│ ▓▓▓▓▓▓▓▓▓▓        │          │ Buy dog food       │
+│ ▓▓▓▓              │          │ Assigned: Bob      │
+│                    │          │ Due: Tomorrow      │
+└────────────────────┘          └────────────────────┘
+```
+
+**Accessibility:**
+- aria-busy="true" on loading container
+- aria-live="polite" announces when loaded
+- Screen reader: "Loading tasks..." → "3 tasks loaded"
+```
+
+---
+
+## Content Specifications
+
+Go beyond just listing text. Specify tone, constraints, and variations:
+
+```markdown
+## Error Message Content Standards
+
+### Tone
+- Helpful, not blaming
+- Use "Please" for requests
+- Avoid "Invalid", "Error", "Wrong"
+- Offer solutions when possible
+
+### Format
+- Sentence case (not ALL CAPS)
+- Period at end if complete sentence
+- No period if fragment
+- Link format: [Action text →]
+
+### Validation Error Table
+
+| Field | Condition | Message | Link |
+|-------|-----------|---------|------|
+| Email | Empty | "Email is required" | None |
+| Email | Invalid format | "Please enter a valid email address" | None |
+| Email | Already exists | "This email is already registered." | [Log in instead →] |
+| Password | Empty | "Password is required" | None |
+| Password | Too short | "Password must be at least 8 characters" | None |
+| Password | No number | "Include at least one number" | None |
+| Name | Empty | "Name is required" | None |
+| Name | Too long | "Name must be under 50 characters" | None |
+
+### System Error Messages
+
+| Scenario | Message | Action |
+|----------|---------|--------|
+| Network timeout | "Connection lost. Your data is saved." | [Retry] |
+| Server error (5xx) | "Something went wrong. Please try again." | [Retry] |
+| Rate limit | "Too many attempts. Try again in {time}." | Timer countdown |
+| Maintenance mode | "We're performing maintenance. Back soon!" | None |
+
+### Position
+- Field errors: 4px below field, left-aligned
+- Form errors: Above form, full width, with icon
+- System errors: Top of page, banner style, dismissible
+```
+
+---
+
+## Timing and Animation
+
+When timing matters, specify it precisely:
+
+```markdown
+## Modal Dialog Timing
+
+### Opening Animation
+- Duration: 200ms
+- Easing: ease-out
+- Sequence:
+  1. Backdrop fades in: 0% → 60% opacity
+  2. Modal scales + fades: scale(0.95) opacity(0) → scale(1) opacity(1)
+  3. Both complete simultaneously
+
+### Closing Animation
+- Duration: 150ms
+- Easing: ease-in
+- Sequence:
+  1. Modal fades out + scales down
+  2. When modal reaches 50% opacity: Backdrop starts fade out
+  3. Both complete, modal removed from DOM
+
+### Auto-Dismiss (Success Message)
+- Visible duration: 3 seconds
+- Fade out: Last 300ms
+- Total time on screen: 3.3s
+- User can dismiss early by clicking X
+
+### Delayed Appearance (Loading Spinner)
+- Delay: 300ms
+- Why: Don't flash spinner for quick operations
+- If operation completes < 300ms: No spinner shown
+- If operation > 300ms: Spinner appears
+
+### Debounced Validation
+- Delay: 1000ms after last keystroke
+- Why: Don't validate while actively typing
+- Triggers: After user stops typing for 1 second
+- Example: Email availability check
+```
+
+---
+
+## Accessibility Attributes in Detail
+
+Complete ARIA specification for complex elements:
+
+```markdown
+## Dropdown Menu ARIA Specification
+
+### Trigger Button
+
+```html
+<button
+  id="user-menu-button"
+  type="button"
+  aria-haspopup="true"
+  aria-expanded="false"  <!-- Changes to "true" when open -->
+  aria-controls="user-menu-list"
+  aria-label="User menu">
+  [User Avatar] John Doe ▼
+</button>
+```
+
+### Dropdown Container (when open)
+
+```html
+<ul
+  id="user-menu-list"
+  role="menu"
+  aria-labelledby="user-menu-button"
+  aria-orientation="vertical">
+
+  <li role="none">
+    <a role="menuitem" href="/profile">Profile</a>
+  </li>
+
+  <li role="none">
+    <a role="menuitem" href="/settings">Settings</a>
+  </li>
+
+  <li role="separator"></li>
+
+  <li role="none">
+    <button role="menuitem" type="button" onclick="logout()">
+      Log out
+    </button>
+  </li>
+</ul>
+```
+
+### Focus Management
+1. When opened: Focus moves to first menu item
+2. Arrow Down: Next menu item
+3. Arrow Up: Previous menu item
+4. Home: First menu item
+5. End: Last menu item
+6. Escape: Close menu, return focus to trigger
+7. Tab: Close menu, move focus to next focusable element
+8. Click outside: Close menu, focus stays where clicked
+
+### Screen Reader Announcements
+- Button: "User menu, button, collapsed"
+- Opens: "User menu, menu, 4 items"
+- Each item: "Profile, menu item" / "Settings, menu item" / etc.
+- Closes: "User menu, button, collapsed"
+```
+
+---
+
+## Translation Planning
+
+Document content in all supported languages:
+
+```markdown
+## Task Status Badge Translations
+
+### English
+- pending: "Pending"
+- in_progress: "In Progress"
+- completed: "Completed"
+- overdue: "Overdue"
+
+### Spanish
+- pending: "Pendiente"
+- in_progress: "En Progreso"
+- completed: "Completado"
+- overdue: "Atrasado"
+
+### German
+- pending: "Ausstehend"
+- in_progress: "In Bearbeitung"
+- completed: "Abgeschlossen"
+- overdue: "Überfällig"
+
+### French
+- pending: "En attente"
+- in_progress: "En cours"
+- completed: "Terminé"
+- overdue: "En retard"
+
+### Text Expansion Considerations
+- English "Pending" (7 chars)
+- German "Ausstehend" (10 chars) — 43% longer
+- Design must accommodate ±40% expansion
+- Badge width: Min 80px to handle longest translation
+```
+
+---
+
+## Completeness Checklist
+
+Use this to verify each element specification:
+
+### For Every Element:
+
+**States:**
+- [ ] All possible states documented
+- [ ] State transitions specified
+- [ ] Default state clearly identified
+- [ ] Edge case states covered
+
+**Content:**
+- [ ] Real text (not lorem ipsum)
+- [ ] All labels written
+- [ ] All error messages written
+- [ ] All helper text written
+- [ ] Translations provided (all supported languages)
+
+**Accessibility:**
+- [ ] ARIA role specified (if not semantic HTML)
+- [ ] aria-label provided (where needed)
+- [ ] aria-required for required fields
+- [ ] aria-invalid for validation states
+- [ ] aria-describedby for error messages
+- [ ] Focus management specified
+- [ ] Keyboard interactions documented
+- [ ] Screen reader behavior described
+
+**Behavior:**
+- [ ] Click/tap behavior defined
+- [ ] Keyboard behavior defined
+- [ ] Validation timing specified
+- [ ] Animation timing specified (if applicable)
+- [ ] What triggers state changes
+
+**Visual (if critical):**
+- [ ] Colors specified (with hex codes)
+- [ ] Sizes specified (touch targets 44px+)
+- [ ] Spacing specified (if precise)
+- [ ] Responsive behavior noted
+
+---
+
+## The Test
+
+**Your element specification is complete when:**
+
+✅ A developer can build it without asking questions
+✅ A translator can extract all content
+✅ A tester can verify every state
+✅ An accessibility auditor can validate ARIA
+✅ A designer can recreate it 6 months later
+
+**If any role needs to guess, the spec is incomplete.**
+
+---
+
+## What's Next
+
+In the tutorial, you'll practice writing complete specifications with Freya guiding you through each section. She'll ensure nothing is missed.
+
+---
+
+**[Continue to Tutorial: Write Your Specifications →](tutorial-11.md)**
+
+---
+
+[← Back to Lesson 2](lesson-02-section-widget-specifications.md) | [Back to Module Overview](module-11-conceptual-specifications-overview.md)
+
+*Part of Module 11: Conceptual Specifications*
diff --git a/docs/learn/module-11-conceptual-specifications/module-11-conceptual-specifications-overview.md b/docs/learn/module-11-conceptual-specifications/module-11-conceptual-specifications-overview.md
new file mode 100644
index 000000000..119b3d100
--- /dev/null
+++ b/docs/learn/module-11-conceptual-specifications/module-11-conceptual-specifications-overview.md
@@ -0,0 +1,460 @@
+# Module 11: Conceptual Specifications
+
+**Time: 60 min | Agent: Freya | Phase: Design | Focus: UX**
+
+---
+
+## Every Decision Documented
+
+This is where design becomes specification.
+
+This is the core of WDS.
+
+**Specifications are the new code.**
+
+In an AI-powered world, well-structured specifications get transformed into working software. The clearer and more complete your specifications, the better the code that gets generated from them.
+
+WDS specifications provide what sketches and mockups cannot:
+
+- **[Unique IDs](#ids-are-the-key)** — Every object traceable from spec to code to test
+- **[Real Content](#why-content-isnt-lorem-ipsum)** — Actual copy with translations ready
+- **[Functional Objects](#design-system-terminology)** — Reusable components identified and specified
+- **[The Invisible Layer](#multiple-dimensions)** — SEO, accessibility, performance, analytics
+- **[Strategic Context](#why-start-with-page-purpose)** — Every decision connected to user needs
+- **[Complete Behavior](#why-elements-need-states)** — All states, all interactions, all edge cases
+
+**Sketches show what you see. Specifications define what gets built.**
+
+---
+
+## Why Specifications Matter
+
+A sketch can be interpreted 10 different ways.
+
+A specification has one meaning.
+
+When you specify, you decide:
+- No ambiguity
+- No guessing
+- No "I thought you meant..."
+- No developer questions
+- No implementation drift
+
+**If they need to ask, your spec is incomplete.**
+
+
+ 
+---
+
+## The Hierarchy
+
+Specifications work from big to small:
+
+```
+┌─────────────────────────────────────────────────┐
+│ PAGE                                            │
+│ Purpose, Layout, Accessibility                  │
+│                                                 │
+│  ┌───────────────────────────────────────────┐  │
+│  │ SECTION                                   │  │
+│  │ Purpose, Placement, Behavior              │  │
+│  │                                           │  │
+│  │  ┌─────────────────────────────────────┐  │  │
+│  │  │ WIDGET                              │  │  │
+│  │  │ Reusable component, States          │  │  │
+│  │  │                                     │  │  │
+│  │  │  ┌───────────────────────────────┐  │  │  │
+│  │  │  │ CARD                          │  │  │  │
+│  │  │  │ Content grouping              │  │  │  │
+│  │  │  │                               │  │  │  │
+│  │  │  │  ┌─────────┐  ┌─────────┐    │  │  │  │
+│  │  │  │  │ BUTTON  │  │  FIELD  │    │  │  │  │
+│  │  │  │  └─────────┘  └─────────┘    │  │  │  │
+│  │  │  │  Individual elements          │  │  │  │
+│  │  │  └───────────────────────────────┘  │  │  │
+│  │  └─────────────────────────────────────┘  │  │
+│  └───────────────────────────────────────────┘  │
+└─────────────────────────────────────────────────┘
+```
+
+**You don't specify a button until you understand the page.**
+
+---
+
+## Design System Terminology
+
+Specifications use consistent terminology:
+
+| Term | What It Means | Example |
+|------|---------------|---------|
+| **Page** | Complete view in scenario | Signup page, Dashboard |
+| **Section** | Major area of page | Header, Hero, Form area, Footer |
+| **Widget** | Reusable component | Navigation bar, User menu, Search box |
+| **Card** | Grouped content container | Profile card, Feature card, Stat card |
+| **Element** | Individual UI piece | Button, Input field, Icon, Label |
+
+**Use these terms consistently across all specifications.**
+
+---
+
+## IDs Are the Key
+
+Every object gets a unique ID:
+
+```
+Page:       P01-signup-page
+Section:    P01-S01-hero-section
+Widget:     P01-S02-W01-signup-form
+Card:       P01-S03-C01-feature-card
+Element:    P01-S02-W01-E01-email-field
+```
+
+**Why IDs matter:**
+
+1. **Traceability** — From spec → code → test
+2. **Maintenance** — Find exactly what needs updating
+3. **Translation** — Map content to language files
+4. **Accessibility** — Reference specific elements for ARIA
+5. **Analytics** — Track interactions precisely
+6. **Testing** — Target elements for automation
+
+**Without IDs, specifications are just documentation. With IDs, they're implementation maps.**
+
+---
+
+## Multiple Dimensions
+
+Every specification addresses:
+
+### 1. Structure & Behavior
+What appears, what happens, what changes
+
+### 2. Content & Copy
+Actual text, not placeholders, in all languages
+
+### 3. Accessibility
+Screen reader labels, keyboard navigation, focus management
+
+### 4. Internationalization
+Text expansion, RTL support, locale formats
+
+### 5. Performance
+Loading priorities, lazy loading, skeleton screens
+
+**A complete specification covers all dimensions.**
+
+---
+
+## Why Start with Page Purpose
+
+Before you specify anything, answer:
+
+**What is this page trying to accomplish?**
+
+```
+BAD:
+"This is the signup page."
+
+GOOD:
+"This page lets Felix (persona) create an account with
+minimal friction (driving force) by asking only for
+essential information (email + password) so he can
+start trying the product immediately."
+```
+
+**Purpose connects specification to strategy.**
+
+Every element on the page must serve this purpose. If it doesn't, it shouldn't be there.
+
+---
+
+## Why Section Structure Matters
+
+Sections organize the page:
+
+```
+Signup Page Sections:
+┌─────────────────────────────────────┐
+│ S01: Header (Logo, Login link)     │
+├─────────────────────────────────────┤
+│ S02: Hero (Value prop)             │
+├─────────────────────────────────────┤
+│ S03: Form Area (Signup widget)     │
+├─────────────────────────────────────┤
+│ S04: Trust Signals (Testimonials)  │
+├─────────────────────────────────────┤
+│ S05: Footer (Legal links)          │
+└─────────────────────────────────────┘
+```
+
+**Each section has:**
+- Purpose (why it exists)
+- Placement (where it appears)
+- Behavior (responsive, sticky, collapsible)
+- Priority (load order, importance)
+
+**Sections before widgets. Structure before details.**
+
+---
+
+## Why Widgets Are Reusable
+
+A widget is a component that appears in multiple places:
+
+```
+signup-form widget:
+- Used on: Signup page, Modal signup, Embedded signup
+- Same behavior everywhere
+- Same validation everywhere
+- Specify once, use many times
+```
+
+**Widgets enforce consistency.**
+
+---
+
+## Why Cards Group Content
+
+Cards contain related information:
+
+```
+feature-card:
+┌───────────────────┐
+│ [Icon]            │
+│ Feature Title     │
+│ Description here  │
+│ [Learn More →]    │
+└───────────────────┘
+```
+
+**Cards make content scannable and repeatable.**
+
+---
+
+## Why Elements Need States
+
+An element isn't just one thing. It transforms:
+
+```
+Button States:
+Default  → Hover → Active → Loading → Success → Error
+                                    → Disabled
+
+Each state needs:
+- Visual appearance
+- Behavior
+- Accessibility label
+- Content (if changes)
+```
+
+**Incomplete state specifications = bugs.**
+
+---
+
+## Why Content Isn't Lorem Ipsum
+
+Actual copy affects design:
+
+```
+BAD:
+Button: "Lorem ipsum"
+
+GOOD:
+Button: "Create Free Account"
+Translation (ES): "Crear Cuenta Gratuita"
+Translation (DE): "Kostenloses Konto erstellen"
+```
+
+**Real content reveals:**
+- Length constraints
+- Wrapping issues
+- Translation expansion
+- Tone and voice
+
+**Write real copy in specifications.**
+
+---
+
+## Why Accessibility Isn't Optional
+
+Every element needs:
+
+```
+email-field:
+- Label: "Email" (visible)
+- aria-label: "Email address for your account"
+- aria-required: "true"
+- aria-invalid: "false" (default) → "true" (on error)
+- aria-describedby: "email-error" (when error shown)
+```
+
+**Accessibility is part of the specification, not added later.**
+
+---
+
+## Why Translations Matter Early
+
+Content expands in translation:
+
+```
+English:  "Sign up" (7 chars)
+German:   "Registrieren" (13 chars)
+Finnish:  "Rekisteröidy" (13 chars)
+
+English:  "Delete account" (14 chars)
+German:   "Konto löschen" (13 chars)
+Russian:  "Удалить аккаунт" (15 chars)
+```
+
+**Design for expansion. Specify content constraints.**
+
+---
+
+## The Specification Layers
+
+```
+Layer 1: PAGE LEVEL
+- Purpose
+- Personas served
+- Trigger Map connections
+- Layout approach (mobile-first, responsive)
+- Accessibility requirements
+- Performance priorities
+
+Layer 2: SECTION LEVEL
+- Purpose of each section
+- Placement and hierarchy
+- Responsive behavior
+- Load priority
+
+Layer 3: WIDGET LEVEL
+- Reusable components
+- States and interactions
+- Validation rules
+- Accessibility patterns
+
+Layer 4: CARD LEVEL
+- Content grouping
+- Repeatable patterns
+- Data structure
+
+Layer 5: ELEMENT LEVEL
+- Individual buttons, fields, icons
+- States, content, behavior
+- Specific ARIA attributes
+```
+
+**Start at Layer 1. Work down to Layer 5.**
+
+**The lessons teach HOW to specify each layer.**
+
+---
+
+## The Completeness Test
+
+Your specification is complete when:
+
+✅ A developer can build it without asking questions
+✅ A translator can extract all content
+✅ A tester can verify every state
+✅ An accessibility auditor can validate ARIA
+✅ A designer can maintain it 6 months later
+
+**If any role needs to guess, the spec is incomplete.**
+
+---
+
+## Common Mistakes
+
+| Mistake | Why It Fails | Fix |
+|---------|--------------|-----|
+| Starting with buttons | No context for decisions | Start with page purpose |
+| Lorem ipsum content | Can't plan for translations | Write real copy |
+| Missing states | Bugs in edge cases | Document all states |
+| No IDs | Can't trace implementation | ID everything |
+| Vague descriptions | Multiple interpretations | Be specific |
+| Skipping accessibility | Fails audits | Specify ARIA from start |
+
+---
+
+## Output Structure
+
+```
+C-UX-Scenarios/
+└── S01-User-Registration/
+    ├── scenario-overview.md
+    ├── pages/
+    │   ├── P01-signup-page.md       ← Complete page spec
+    │   └── P02-welcome-screen.md
+    ├── widgets/
+    │   ├── W01-signup-form.md       ← Reusable component
+    │   └── W02-header-nav.md
+    └── content/
+        ├── copy-en.md               ← English content
+        ├── copy-es.md               ← Spanish content
+        └── copy-de.md               ← German content
+```
+
+**Organized by hierarchy, not by feature.**
+
+---
+
+## What You'll Learn
+
+**Lesson 1: Hierarchical Specification**
+Learn the 5-layer pattern (Page → Section → Widget → Card → Element) and how to work from large to small
+
+**Lesson 2: Section & Widget Specifications**
+Deep dive on specifying sections (placement, responsive behavior) and widgets (reusability, states, validation)
+
+**Lesson 3: Element & State Specifications**
+Complete element specifications with all states, exact content, ARIA attributes, edge cases, and translations
+
+**Tutorial: Specify Your Pages**
+Hands-on practice with Freya creating complete specifications
+
+---
+
+## The Freya Method
+
+Freya ensures completeness:
+
+> "You specified the page purpose, but which persona is this for?"
+> "This section appears on mobile — what's the responsive behavior?"
+> "Your button has a default state but no disabled state. When is it disabled?"
+> "This error message is in English. What about Spanish users?"
+> "Where's the ID for this widget? How will developers reference it?"
+
+**She won't let you ship incomplete specs.**
+
+---
+
+## Lessons
+
+### [Lesson 1: Page-Level Specifications](lesson-01-design-is-specification.md)
+Start with the big picture, then work down
+
+### [Lesson 2: Section & Widget Specifications](lesson-02-section-widget-specifications.md)
+Deep dive on Layers 2 & 3 of the hierarchy
+
+### [Lesson 3: Element & State Specifications](lesson-03-element-state-specifications.md)
+Deep dive on Layers 4 & 5 — Complete implementation details
+
+---
+
+## Tutorial
+
+### [Tutorial 11: Write Your Specifications](tutorial-11.md)
+Hands-on guide to creating complete page specifications with Freya
+
+---
+
+## Next Module
+
+**[Module 12: Functional Components →](../module-12-functional-components/module-12-functional-components-overview.md)**
+
+Time to identify reusable patterns across your specifications.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-11-conceptual-specifications/storyboards/password-field.md b/docs/learn/module-11-conceptual-specifications/storyboards/password-field.md
new file mode 100644
index 000000000..21edba2bb
--- /dev/null
+++ b/docs/learn/module-11-conceptual-specifications/storyboards/password-field.md
@@ -0,0 +1,32 @@
+# Storyboard: Password Field
+
+**Example storyboard specification for the WDS course**
+
+---
+
+## Coming Soon
+
+This is an example storyboard referenced from [Module 11 Tutorial](../tutorial-11.md). It will demonstrate a complete behavior storyboard for a password field component.
+
+---
+
+## State Transitions
+
+| From | To | Trigger | Duration | Visual |
+|------|----|---------|----------|--------|
+| Default | Focused | Click/Tab | Instant | Blue border |
+| Focused | Typing | Keypress | Instant | Strength indicator appears |
+| Typing | Visible | Eye icon click | Instant | Text revealed, icon toggles |
+| Visible | Hidden | Eye icon click | Instant | Dots replace text |
+
+## Strength Indicator
+
+| Strength | Color | Label |
+|----------|-------|-------|
+| Weak | Red | "Weak" |
+| Fair | Orange | "Fair" |
+| Strong | Green | "Strong" |
+
+---
+
+*This is a teaching example for the WDS course.*
diff --git a/docs/learn/module-11-conceptual-specifications/storyboards/submit-button.md b/docs/learn/module-11-conceptual-specifications/storyboards/submit-button.md
new file mode 100644
index 000000000..301c50aa6
--- /dev/null
+++ b/docs/learn/module-11-conceptual-specifications/storyboards/submit-button.md
@@ -0,0 +1,26 @@
+# Storyboard: Submit Button
+
+**Example storyboard specification for the WDS course**
+
+---
+
+## Coming Soon
+
+This is an example storyboard referenced from [Module 11 Tutorial](../tutorial-11.md). It will demonstrate a complete behavior storyboard for a submit button component.
+
+---
+
+## State Transitions
+
+| From | To | Trigger | Duration | Visual |
+|------|----|---------|----------|--------|
+| Default | Hover | Mouse enter | Instant | Darker background |
+| Hover | Default | Mouse leave | Instant | Original background |
+| Default | Loading | Click | 100ms delay | Spinner replaces text |
+| Loading | Success | API response OK | Instant | Checkmark, green background |
+| Loading | Error | API response fail | Instant | Return to default, show error |
+| Success | Redirect | Timer | 1.5s | Fade out, navigate |
+
+---
+
+*This is a teaching example for the WDS course.*
diff --git a/docs/learn/module-11-conceptual-specifications/tutorial-11.md b/docs/learn/module-11-conceptual-specifications/tutorial-11.md
new file mode 100644
index 000000000..b1c7b5a8a
--- /dev/null
+++ b/docs/learn/module-11-conceptual-specifications/tutorial-11.md
@@ -0,0 +1,472 @@
+# Tutorial 11: Write Your Specifications
+
+**Hands-on guide to creating complete page specifications with Freya**
+
+---
+
+## Overview
+
+This tutorial walks you through creating detailed specifications that developers can implement without asking questions.
+
+**Time:** 45-60 minutes
+**Prerequisites:** Sketches (Module 09) and Storyboards (Module 10) completed
+**Agent:** Freya
+**What you'll create:** Complete specification documents for each page
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- Your page sketches
+- Your storyboard documentation
+- Your Trigger Map for references
+- Real content ideas (not lorem ipsum)
+
+**Freya will help you:**
+
+- Structure specifications consistently
+- Catch missing states and edge cases
+- Write real content
+- Ensure completeness
+
+---
+
+## Step 1: Choose Your First Page (2 min)
+
+### Start with a key page:
+
+**You say:**
+> "Let's create the specification for the signup form from S01-User-Registration. I have the sketch and storyboards ready."
+
+**Freya acknowledges:**
+> "Great. Let's build a complete specification. I'll guide you through each section to ensure nothing is missed."
+
+---
+
+## Step 2: Document Purpose and Connections (5 min)
+
+### Freya asks about context:
+
+> "First, let's establish why this page exists. What's its purpose?"
+
+**You respond:**
+> "Allow new users to create an account with minimal friction. Get them from curious visitor to registered user."
+
+**Freya continues:**
+> "Which persona and driving force does this serve?"
+
+**You respond:**
+> "Felix the Full-Stack. His driving force is 'Want to try before committing.' He fears complicated onboarding."
+
+**Freya documents:**
+```markdown
+# P02: Signup Form Specification
+
+## Purpose
+Allow new users to create an account with minimal friction.
+Transform curious visitors into registered users.
+
+## Connects To
+- Scenario: S01-User-Registration
+- Persona: Felix the Full-Stack
+- Driving Force: "Want to try before committing"
+- Feature: F03-Quick-Signup
+- Business Goal: User acquisition and activation
+```
+
+---
+
+## Step 3: List All Elements (10 min)
+
+### Freya guides element identification:
+
+> "Looking at your sketch, let's identify every element on this page. What's visible?"
+
+**Work through systematically:**
+
+**You respond:**
+> "Header with logo and back button. Main heading and subheading. Email field. Password field with strength indicator. Submit button. Terms text with link. Login link for existing users."
+
+**Freya creates structure:**
+```markdown
+## Elements
+
+### Header Section
+- Logo (left)
+- Back button (left of logo or top-left)
+
+### Form Section
+- Headline
+- Subheadline
+- Email field
+- Password field
+- Password strength indicator
+- Submit button
+
+### Footer Section
+- Terms text with link
+- Login link
+```
+
+### Detail each element:
+
+**Freya:**
+> "Let's specify each element. Starting with the email field — what are the details?"
+
+**You respond:**
+> "Text input, label says 'Email', placeholder 'you@example.com', validates email format, error message 'Please enter a valid email'."
+
+**Freya documents:**
+```markdown
+### Email Field
+- ID: signup-email-field
+- Type: Text input (email)
+- Label: "Email"
+- Placeholder: "you@example.com"
+- Validation: Valid email format (on blur)
+- Error message: "Please enter a valid email"
+- Required: Yes
+```
+
+### Continue for all elements...
+
+---
+
+## Step 4: Define All States (10 min)
+
+### Freya ensures state coverage:
+
+> "Now let's document all possible states for this page. What's the default state when someone arrives?"
+
+**You respond:**
+> "Empty form, submit button disabled, no validation messages, headline and subhead visible."
+
+**Freya continues:**
+> "What states does the form go through as the user interacts?"
+
+**Work through:**
+- Default (empty)
+- Filling (typing)
+- Partially valid
+- All valid (submit enabled)
+- Submitting
+- Error (from server)
+- Success
+
+**Freya documents:**
+```markdown
+## Page States
+
+### Default
+- Form: Empty
+- Email field: Placeholder visible
+- Password field: Empty, strength indicator hidden
+- Submit button: Disabled (grayed)
+- Validation: None visible
+
+### Filling
+- Fields show user input
+- Validation appears on blur
+- Strength indicator shows as user types password
+- Submit button: Disabled until all valid
+
+### Ready to Submit
+- All fields valid (no error messages)
+- Password strength: Acceptable or better
+- Submit button: Enabled (primary blue)
+
+### Submitting
+- All fields: Disabled (slightly grayed)
+- Submit button: Loading spinner
+- No new input allowed
+
+### Server Error
+- Fields: Re-enabled
+- Error banner: Appears above form
+- Submit button: Returns to enabled
+- User input: Preserved
+
+### Success
+- Brief success state (1.5s)
+- Then redirect to Welcome Screen
+```
+
+---
+
+## Step 5: Write Real Content (10 min)
+
+### Freya prompts for actual copy:
+
+> "Let's write the real content. No lorem ipsum. What should the headline say?"
+
+**You respond:**
+> "Something like 'Create your account' — but that's boring. Maybe 'Start in 2 minutes' to emphasize speed?"
+
+**Freya helps refine:**
+> "Given Felix's fear of complexity, emphasizing speed is smart. What about the subheadline?"
+
+**You respond:**
+> "'No credit card required. Cancel anytime.'"
+
+**Freya documents:**
+```markdown
+## Content
+
+### Headlines
+- Main: "Start in 2 minutes"
+- Sub: "No credit card required. Cancel anytime."
+
+### Form Labels
+- Email: "Email"
+- Password: "Password"
+
+### Button Text
+- Submit: "Create Free Account"
+- Loading: [Spinner, no text]
+
+### Helper Text
+- Password requirements: "At least 8 characters"
+- Strength indicators: "Weak" / "Fair" / "Strong"
+
+### Links
+- Terms: "By continuing, you agree to our Terms and Privacy Policy"
+- Login: "Already have an account? Log in"
+
+### Error Messages
+| Condition | Message |
+|-----------|---------|
+| Email empty | "Email is required" |
+| Email invalid | "Please enter a valid email" |
+| Email exists | "This email is already registered. Log in instead →" |
+| Password empty | "Password is required" |
+| Password too short | "Password must be at least 8 characters" |
+| Server error | "Something went wrong. Please try again." |
+| Network error | "Connection lost. Please check your internet." |
+```
+
+---
+
+## Step 6: Add Behavior Details (5 min)
+
+### Include storyboard references:
+
+**Freya:**
+> "Let's link the behavioral details. You have storyboards for the submit button and password field, correct?"
+
+**You respond:**
+> "Yes, those are documented."
+
+**Freya adds:**
+```markdown
+## Behavior
+
+### Submit Button
+See: [Submit Button Storyboard](./storyboards/submit-button.md)
+
+Summary:
+- Default → Hover (instant, darker)
+- Click → Loading (100ms delay)
+- Success → Checkmark, green (1.5s then redirect)
+- Error → Return to default
+
+### Password Field
+See: [Password Field Storyboard](./storyboards/password-field.md)
+
+Summary:
+- Focus → Blue border
+- Typing → Strength indicator appears
+- Eye click → Toggle visibility
+```
+
+---
+
+## Step 7: Edge Cases and Accessibility (5 min)
+
+### Freya prompts for completeness:
+
+> "A few more things to cover. What edge cases should we document?"
+
+**You respond:**
+> "User hitting back button during submit. User on slow connection. User with JavaScript disabled."
+
+**Freya documents:**
+```markdown
+## Edge Cases
+
+### Back Button During Submit
+- Behavior: Cancel request, return to form
+- Form state: Preserved (not lost)
+
+### Slow Connection (>3s)
+- After 3s: Show "Still working..." below spinner
+- After 10s: Show retry option
+
+### JavaScript Disabled
+- Form still submits (progressive enhancement)
+- No client-side validation (server handles)
+- No password strength indicator
+```
+
+### Accessibility:
+
+**Freya:**
+> "Let's add accessibility notes for the form."
+
+```markdown
+## Accessibility
+
+### Form
+- Labels: Associated with inputs via htmlFor
+- Required fields: aria-required="true"
+- Errors: aria-describedby pointing to error message
+
+### Submit Button
+- Type: button (within form)
+- Loading state: aria-busy="true"
+- Disabled: aria-disabled="true"
+
+### Focus Order
+1. Back button
+2. Email field
+3. Password field
+4. Show/hide password toggle
+5. Submit button
+6. Terms link
+7. Login link
+
+### Keyboard Navigation
+- Tab: Moves through focusable elements
+- Enter: Submits form (when on submit button or input)
+- Escape: No action (modal not applicable)
+```
+
+---
+
+## Step 8: Review Complete Specification (5 min)
+
+### Freya presents the full document:
+
+> "Here's the complete specification. Let's review for completeness."
+
+### Checklist:
+
+- [x] Purpose documented
+- [x] Persona/Trigger Map connection
+- [x] All elements listed with IDs
+- [x] All states documented
+- [x] Real content written
+- [x] Error messages complete
+- [x] Storyboards referenced
+- [x] Edge cases covered
+- [x] Accessibility included
+
+### Ask the test question:
+
+> "Can a developer build this from the spec alone, without asking questions?"
+
+If yes, you're done. If not, identify what's missing.
+
+---
+
+## Step 9: Save and Organize (2 min)
+
+### Save the specification:
+
+```
+C-UX-Scenarios/
+└── S01-User-Registration/
+    └── P02-signup-form/
+        ├── specification.md    ← Complete specification
+        ├── sketch.png
+        └── storyboards/
+            ├── submit-button.md
+            └── password-field.md
+```
+
+### Move to next page:
+
+Repeat for P01-landing-page, P03-welcome-screen, etc.
+
+---
+
+## What You've Created
+
+### For each page:
+
+A complete specification including:
+- Purpose and context
+- All elements with IDs
+- All states
+- Real content
+- Behavior details
+- Edge cases
+- Accessibility
+
+### The specification is:
+
+- **Implementation-ready** — Developers can build it
+- **Testable** — QA can verify every state
+- **Traceable** — Every element has an ID
+- **Connected** — Links to personas and features
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Write real content
+- Document all states
+- Include error messages
+- Reference storyboards
+- Cover accessibility
+- Use consistent IDs
+
+**DON'T:**
+
+- Use lorem ipsum
+- Skip edge cases
+- Forget loading states
+- Leave content TBD
+- Ignore keyboard navigation
+
+---
+
+## Common Questions
+
+**Q: How long should a specification be?**
+A: As long as needed to be complete. A simple page might be 1 page; a complex form might be 5+ pages.
+
+**Q: What if content isn't final?**
+A: Write your best guess and mark it "[CONTENT TBD - awaiting copy review]". Something is better than lorem ipsum.
+
+**Q: Do I need all the accessibility details?**
+A: For critical interactive elements, yes. For simple text, standard HTML semantics suffice.
+
+---
+
+## You've Completed Module 11!
+
+**Your specifications are complete.** You've documented:
+- Every element
+- Every state
+- All content
+- All behavior
+
+This is the core deliverable of WDS.
+
+---
+
+## Next Module
+
+**[Module 12: Functional Components →](../module-12-functional-components/module-12-functional-components-overview.md)**
+
+Time to identify reusable patterns across your specifications.
+
+---
+
+[← Back to Lesson 3](lesson-03-element-state-specifications.md) | [Back to Module Overview](module-11-conceptual-specifications-overview.md)
+
+*Part of Module 11: Conceptual Specifications*
diff --git a/docs/learn/module-12-functional-components/components/button.md b/docs/learn/module-12-functional-components/components/button.md
new file mode 100644
index 000000000..114455978
--- /dev/null
+++ b/docs/learn/module-12-functional-components/components/button.md
@@ -0,0 +1,41 @@
+# Component: Button
+
+**Example functional component specification for the WDS course**
+
+---
+
+## Coming Soon
+
+This is an example component specification referenced from [Module 12 Tutorial](../tutorial-12.md). It will demonstrate a complete functional component specification for a button.
+
+---
+
+## Component Overview
+
+| Property | Value |
+|----------|-------|
+| **Name** | Button |
+| **Category** | Core Components |
+| **Usage** | Action triggers |
+| **Instances** | 7 across project |
+
+## Variants
+
+| Variant | Use Case |
+|---------|----------|
+| Primary | Main actions (submit, confirm) |
+| Secondary | Alternative actions (cancel, back) |
+| Destructive | Dangerous actions (delete, remove) |
+| Ghost | Subtle actions (close, dismiss) |
+
+## Sizes
+
+| Size | Height | Padding | Font |
+|------|--------|---------|------|
+| sm | 32px | 8px 16px | 14px |
+| md | 40px | 10px 20px | 16px |
+| lg | 48px | 12px 24px | 18px |
+
+---
+
+*This is a teaching example for the WDS course.*
diff --git a/docs/learn/module-12-functional-components/components/card.md b/docs/learn/module-12-functional-components/components/card.md
new file mode 100644
index 000000000..08efc0e24
--- /dev/null
+++ b/docs/learn/module-12-functional-components/components/card.md
@@ -0,0 +1,40 @@
+# Component: Card
+
+**Example functional component specification for the WDS course**
+
+---
+
+## Coming Soon
+
+This is an example component specification referenced from [Module 12 Tutorial](../tutorial-12.md). It will demonstrate a complete functional component specification for a card container.
+
+---
+
+## Component Overview
+
+| Property | Value |
+|----------|-------|
+| **Name** | Card |
+| **Category** | Core Components |
+| **Usage** | Content containers |
+| **Instances** | Multiple across project |
+
+## Variants
+
+| Variant | Use Case |
+|---------|----------|
+| Default | Standard content card |
+| Interactive | Clickable card with hover state |
+| Highlighted | Featured/promoted content |
+| Compact | Reduced padding for dense layouts |
+
+## Anatomy
+
+- Header (optional): Title + action buttons
+- Body: Main content area
+- Footer (optional): Actions or metadata
+- Image (optional): Top or side image
+
+---
+
+*This is a teaching example for the WDS course.*
diff --git a/docs/learn/module-12-functional-components/components/input.md b/docs/learn/module-12-functional-components/components/input.md
new file mode 100644
index 000000000..b3ffde462
--- /dev/null
+++ b/docs/learn/module-12-functional-components/components/input.md
@@ -0,0 +1,42 @@
+# Component: Input
+
+**Example functional component specification for the WDS course**
+
+---
+
+## Coming Soon
+
+This is an example component specification referenced from [Module 12 Tutorial](../tutorial-12.md). It will demonstrate a complete functional component specification for a text input.
+
+---
+
+## Component Overview
+
+| Property | Value |
+|----------|-------|
+| **Name** | Input |
+| **Category** | Core Components |
+| **Usage** | Text entry |
+| **Instances** | Multiple across forms |
+
+## Variants
+
+| Variant | Use Case |
+|---------|----------|
+| Text | Standard text input |
+| Password | Masked input with visibility toggle |
+| Search | With search icon and clear button |
+| Textarea | Multi-line text entry |
+
+## States
+
+| State | Visual |
+|-------|--------|
+| Default | Gray border |
+| Focused | Blue border |
+| Error | Red border + error message |
+| Disabled | Muted background, no interaction |
+
+---
+
+*This is a teaching example for the WDS course.*
diff --git a/docs/learn/module-12-functional-components/lesson-01-patterns-emerge.md b/docs/learn/module-12-functional-components/lesson-01-patterns-emerge.md
new file mode 100644
index 000000000..7b1212dde
--- /dev/null
+++ b/docs/learn/module-12-functional-components/lesson-01-patterns-emerge.md
@@ -0,0 +1,247 @@
+# Module 12: Functional Components
+
+## Lesson 1: When Patterns Emerge
+
+**Identifying reusable elements across your specifications**
+
+---
+
+## The Natural Progression
+
+You've written specifications for multiple pages. And something happens:
+
+You're specifying a button on page 3... and realize it's identical to the button on page 1.
+
+Same states. Same behavior. Same styling. Different label.
+
+**A pattern has emerged.**
+
+---
+
+## Why Extract Functional Components?
+
+### Consistency
+
+Same Functional Component = same behavior everywhere.
+
+When the button on the signup form works like the button on the settings page, users don't have to relearn anything.
+
+### Efficiency
+
+Specify once, reference many times.
+
+Instead of copying the full button specification to every page, you define it once and reference it.
+
+### Maintainability
+
+Change once, update everywhere.
+
+Need to update the loading state? Change the component definition. Every instance inherits the update.
+
+### Communication
+
+Shared vocabulary with developers.
+
+"Use the primary Button component" is clearer than "make a blue button that does this specific thing."
+
+---
+
+## When to Extract
+
+Not everything should be a component. Look for:
+
+**Appears more than once**
+
+Once is an instance. Twice or more is a pattern worth considering.
+
+**Consistent behavior**
+
+The element behaves the same way everywhere. If behavior differs, they're different elements.
+
+**Worth centralizing**
+
+The extraction provides value. Sometimes inline is simpler.
+
+**Meaningful abstraction**
+
+"Button" is meaningful. "Blue rectangle with text" is not.
+
+---
+
+## What IS a Functional Component?
+
+A **Functional Component** is a reusable widget with defined functionality:
+
+- **Variants** — Different configurations (detailed, compact, minimal)
+- **States** — Behavioral states (loading, loaded, error, refreshing)
+- **Props** — Configurable options (location, maxResults, onSelect)
+- **Behavior** — What the widget does (fetches data, handles input, manages state)
+
+**Key distinction:** Functional Components are specification-level widgets, not implementation-level UI components (React, Vue, etc.).
+
+### Examples
+
+| Functional Component | What It Does |
+|---------------------|--------------|
+| Weather Widget | Fetches weather, displays forecast, handles location, refresh |
+| Search Widget | Accepts input, fetches suggestions, handles selection, keyboard nav |
+| Login Form | Validates fields, manages auth flow, handles errors |
+| Comment Section | Manages comment input, character count, submission, validation |
+| Task Card | Displays task, handles status changes, actions, completion |
+
+---
+
+## What Is NOT a Functional Component
+
+Not everything needs extraction:
+
+| Functional Component | NOT a Functional Component |
+|---------------------|---------------------------|
+| Weather Widget | A single temperature display |
+| Search Widget | A single input field |
+| Login Form | A single button |
+| Task Card | A checkbox element |
+| Comment Section | A color value or margin |
+
+**Functional Components have functionality and behavior.** Simple elements and styles don't.
+
+If the thing doesn't have complex behavior, states, and reusable functionality, it's probably just an element or style token, not a Functional Component.
+
+---
+
+## Functional Component vs. Instance
+
+**Functional Component:** The widget definition
+
+```markdown
+## Weather Widget (Functional Component)
+Variants: compact, detailed, minimal
+States: loading, loaded, error, refreshing
+Props: location, variant, autoRefresh, units
+```
+
+**Instance:** A specific usage
+
+```markdown
+### Homepage Hero Weather
+- Functional Component: Weather Widget
+- Variant: detailed
+- Location: User's city
+- AutoRefresh: true
+- OnLoad: Fetch forecast data
+```
+
+The Functional Component defines the possibilities. The instance applies them.
+
+---
+
+## The Extraction Process
+
+When you notice a pattern:
+
+### 1. Identify the Pattern
+
+"This button appears in signup, settings, and checkout..."
+
+### 2. Document the Variations
+
+- Primary (blue, white text)
+- Secondary (white, blue border)
+- Ghost (transparent, text only)
+
+### 3. List All States
+
+- Default
+- Hover
+- Active
+- Loading
+- Disabled
+
+### 4. Define the Props
+
+| Prop | Type | Default | Options |
+|------|------|---------|---------|
+| variant | string | primary | primary, secondary, ghost |
+| size | string | md | sm, md, lg |
+| disabled | boolean | false | |
+
+### 5. Create the Component Document
+
+Goes in `C-UX-Scenarios/Functional-Components/weather-widget.md`
+
+### 6. Update Page Specs
+
+Replace inline definitions with component references.
+
+### Visual Extraction Flow
+
+```
+STEP 1: IDENTIFY PATTERN
+┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐
+│  Signup Page     │   │  Settings Page   │   │  Checkout Page   │
+├──────────────────┤   ├──────────────────┤   ├──────────────────┤
+│ Button (primary) │   │ Button (primary) │   │ Button (primary) │
+│ States: default, │   │ States: default, │   │ States: default, │
+│  hover, loading  │   │  hover, loading  │   │  hover, loading  │
+└──────────────────┘   └──────────────────┘   └──────────────────┘
+        ↓                      ↓                      ↓
+        └──────────────────────┴──────────────────────┘
+                              ↓
+                   PATTERN RECOGNIZED
+                              ↓
+
+STEP 2-4: DOCUMENT COMPONENT
+┌────────────────────────────────────────────────────────────┐
+│ C-UX-Scenarios/Functional-Components/weather-widget.md                       │
+├────────────────────────────────────────────────────────────┤
+│ Variants: primary, secondary, ghost                        │
+│ States: default, hover, active, loading, disabled          │
+│ Props: variant, size, disabled, loading                    │
+└────────────────────────────────────────────────────────────┘
+                              ↓
+
+STEP 5-6: UPDATE PAGE SPECS
+┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐
+│  Signup Page     │   │  Settings Page   │   │  Checkout Page   │
+├──────────────────┤   ├──────────────────┤   ├──────────────────┤
+│ Component:       │   │ Component:       │   │ Component:       │
+│   Button         │   │   Button         │   │   Button         │
+│   (primary, lg)  │   │   (primary, md)  │   │   (primary, lg)  │
+│ Label: "Sign Up" │   │ Label: "Save"    │   │ Label: "Pay Now" │
+└──────────────────┘   └──────────────────┘   └──────────────────┘
+        ↑                      ↑                      ↑
+        └──────────────────────┴──────────────────────┘
+                              ↑
+                 ALL REFERENCE SAME DEFINITION
+```
+
+---
+
+## Design System
+
+How you handle components depends on your mode:
+
+| Mode | Component Handling |
+|------|-------------------|
+| **None** | Keep inline in page specs |
+| **Building** | Extract to C-UX-Scenarios/Functional-Components/ |
+| **Library** | Reference external (shadcn, etc.) |
+| **Existing** | Import from previous project |
+
+If you're in Mode 1 (None), you can still document patterns — just keep them inline rather than extracting to separate files.
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn the component anatomy in detail — how to document variants, states, props, and usage rules.
+
+---
+
+**[Continue to Lesson 2: Component Anatomy →](lesson-02-component-anatomy.md)**
+
+---
+
+[← Back to Module Overview](module-12-functional-components-overview.md)
+
+*Part of Module 12: Functional Components*
diff --git a/docs/learn/module-12-functional-components/lesson-02-component-anatomy.md b/docs/learn/module-12-functional-components/lesson-02-component-anatomy.md
new file mode 100644
index 000000000..66f14a932
--- /dev/null
+++ b/docs/learn/module-12-functional-components/lesson-02-component-anatomy.md
@@ -0,0 +1,332 @@
+# Module 12: Functional Components
+
+## Lesson 2: Functional Component Anatomy
+
+**How to document Functional Components completely**
+
+---
+
+## The Functional Component Template
+
+Every Functional Component follows this structure:
+
+```markdown
+## [Component Name]
+
+### Description
+What this Functional Component is and when to use it.
+
+### Variants
+Different visual styles.
+
+### States
+Behavioral states.
+
+### Props
+Configurable options.
+
+### Usage Rules
+When and how to use it correctly.
+
+### Accessibility
+Keyboard, screen reader, and focus requirements.
+```
+
+### Component Structure Visualized
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│                FUNCTIONAL COMPONENT DEFINITION                │
+│      (weather-widget.md in C-UX-Scenarios/Functional-Components/)  │
+└──────────────────────────────────────────────────────────────┘
+                              │
+        ┌─────────────────────┼─────────────────────┐
+        │                     │                     │
+        ↓                     ↓                     ↓
+┌──────────────┐    ┌──────────────┐    ┌──────────────┐
+│ WHAT         │    │ HOW          │    │ WHEN         │
+│ Description  │    │ Variants     │    │ Usage Rules  │
+│              │    │ States       │    │              │
+│ Purpose &    │    │ Props        │    │ DO/DON'T     │
+│ use cases    │    │              │    │ guidelines   │
+└──────────────┘    └──────────────┘    └──────────────┘
+        │                     │                     │
+        └─────────────────────┼─────────────────────┘
+                              │
+                              ↓
+                    ┌──────────────────┐
+                    │ WHO              │
+                    │ Accessibility    │
+                    │                  │
+                    │ Screen readers,  │
+                    │ keyboard, ARIA   │
+                    └──────────────────┘
+                              │
+                              ↓
+        ╔═══════════════════════════════════════════╗
+        ║      COMPLETE FUNCTIONAL COMPONENT        ║
+        ║                                           ║
+        ║  Ready to be referenced by page specs    ║
+        ║  All behavior defined, no ambiguity      ║
+        ╚═══════════════════════════════════════════╝
+                              │
+        ┌─────────────────────┼─────────────────────┐
+        ↓                     ↓                     ↓
+┌──────────────┐    ┌──────────────┐    ┌──────────────┐
+│ Page 1       │    │ Page 2       │    │ Page 3       │
+│ Instance A   │    │ Instance B   │    │ Instance C   │
+│              │    │              │    │              │
+│ Button       │    │ Button       │    │ Button       │
+│ (primary,lg) │    │ (secondary)  │    │ (primary,md) │
+└──────────────┘    └──────────────┘    └──────────────┘
+```
+
+**Each section serves a purpose:** Description explains WHY, Variants/States/Props explain HOW, Usage Rules explain WHEN, Accessibility explains WHO can use it.
+
+---
+
+## Section: Description
+
+One paragraph explaining what the Functional Component is and its purpose.
+
+```markdown
+### Description
+Primary action trigger used throughout the application.
+Communicates importance through visual weight and draws
+user attention to key actions.
+```
+
+Keep it concise. This is the "why this exists" summary.
+
+---
+
+## Section: Variants
+
+Different visual styles for different purposes.
+
+```markdown
+### Variants
+
+| Variant | Use Case | Visual |
+|---------|----------|--------|
+| Primary | Main action on page | Blue bg, white text |
+| Secondary | Alternative action | White bg, blue border |
+| Ghost | Tertiary action | Transparent, text only |
+| Danger | Destructive action | Red bg, white text |
+```
+
+**Rule:** One primary action per screen. Everything else is secondary or lower.
+
+---
+
+## Section: States
+
+How the Functional Component looks in different conditions.
+
+```markdown
+### States
+
+| State | Trigger | Visual Change |
+|-------|---------|---------------|
+| Default | Initial load | Standard appearance |
+| Hover | Mouse over | Slight darkening, shadow |
+| Active | Mouse down | Pressed appearance (scale 98%) |
+| Focused | Keyboard focus | Blue outline, 2px offset |
+| Disabled | disabled=true | Grayed out, no interactions |
+| Loading | loading=true | Spinner replaces text |
+```
+
+Include the trigger (what causes this state) and the visual change.
+
+---
+
+## Section: Props
+
+Configurable options for instances.
+
+```markdown
+### Props
+
+| Prop | Type | Default | Description |
+|------|------|---------|-------------|
+| variant | string | "primary" | Visual style: primary, secondary, ghost, danger |
+| size | string | "md" | Size: sm (32px), md (40px), lg (48px) |
+| disabled | boolean | false | Disables interaction |
+| loading | boolean | false | Shows loading spinner |
+| icon | node | null | Optional leading icon |
+| iconPosition | string | "left" | Icon position: left, right |
+| fullWidth | boolean | false | Spans full container width |
+| type | string | "button" | HTML type: button, submit, reset |
+```
+
+**Important:** Specify the exact values, not just the types.
+
+---
+
+## Section: Usage Rules
+
+When and how to use the Functional Component correctly.
+
+```markdown
+### Usage Rules
+
+**DO:**
+- Use primary variant for the main action on each screen
+- Always include text label (icon optional)
+- Ensure minimum touch target of 44px
+- Use loading state during async operations
+- Position primary action prominently
+
+**DON'T:**
+- Use multiple primary buttons on one screen
+- Use icon-only buttons without aria-label
+- Disable buttons without explanation
+- Use ghost variant for primary actions
+- Mix variants in a single button group
+```
+
+These rules prevent misuse.
+
+---
+
+## Section: Accessibility
+
+Requirements for keyboard, screen reader, and focus management.
+
+```markdown
+### Accessibility
+
+**Semantic:**
+- Element: `<button>` (or `<a>` if navigating)
+- Role: Implicit from element
+
+**Keyboard:**
+- Focusable: Yes (when not disabled)
+- Activation: Enter or Space
+- Focus visible: 2px blue outline with 2px offset
+
+**Screen Reader:**
+- Announces: "[label], button"
+- Loading: aria-busy="true", announce "Loading"
+- Disabled: aria-disabled="true", announce "disabled"
+
+**ARIA (when needed):**
+- Icon-only: aria-label="[action description]"
+- Opens dialog: aria-haspopup="dialog"
+- Expanded state: aria-expanded="true/false"
+```
+
+---
+
+## Complete Example: Button Component
+
+```markdown
+# Button Component
+
+## Description
+Primary action trigger used throughout the application.
+Communicates importance through visual weight and guides
+users toward key actions.
+
+## Variants
+
+| Variant | Use Case | Visual |
+|---------|----------|--------|
+| Primary | Main page action | Blue bg (#0066FF), white text |
+| Secondary | Alternative action | White bg, blue border |
+| Ghost | Tertiary/inline action | Transparent, blue text |
+| Danger | Destructive action | Red bg (#DC2626), white text |
+
+## States
+
+| State | Trigger | Visual |
+|-------|---------|--------|
+| Default | Initial | Standard appearance |
+| Hover | Mouse over | 10% darker, subtle shadow |
+| Active | Mouse down | Scale 98%, darker still |
+| Focused | Keyboard | Blue 2px outline |
+| Disabled | prop | 50% opacity, cursor not-allowed |
+| Loading | prop | Spinner replaces text |
+
+## Props
+
+| Prop | Type | Default | Options |
+|------|------|---------|---------|
+| variant | string | "primary" | primary, secondary, ghost, danger |
+| size | string | "md" | sm (32px), md (40px), lg (48px) |
+| disabled | boolean | false | |
+| loading | boolean | false | |
+| icon | node | null | Any icon Functional Component |
+| iconPosition | string | "left" | left, right |
+| fullWidth | boolean | false | |
+
+## Usage Rules
+
+**One primary per screen.** Secondary and ghost for other actions.
+
+**Always has text.** Icon-only requires aria-label.
+
+**Loading replaces text.** Button stays same size.
+
+**Touch target: 44px minimum.** Even if visually smaller.
+
+## Accessibility
+
+- Element: `<button type="button">`
+- Keyboard: Enter/Space activates
+- Focus: Visible blue outline
+- Loading: aria-busy="true"
+- Disabled: aria-disabled="true"
+- Icon-only: aria-label required
+```
+
+---
+
+## The Freya Method
+
+Freya notices patterns as you specify:
+
+> "This is the third time you've specified a card with image, title, and description. Should we extract it as a Functional Component?"
+
+> "Your submit buttons are inconsistent — some say 'Submit', others say 'Save'. Should we standardize?"
+
+She helps you see what's becoming a pattern before you realize it.
+
+---
+
+## File Organization
+
+```
+C-UX-Scenarios/Functional-Components/
+├── Functional Components/
+│   ├── button.md
+│   ├── input.md
+│   ├── card.md
+│   ├── modal.md
+│   └── toast.md
+├── tokens/
+│   ├── colors.yaml
+│   ├── typography.yaml
+│   └── spacing.yaml
+└── patterns/
+    ├── form-layout.md
+    └── page-structure.md
+```
+
+Components go in `Functional Components/`. Design tokens (colors, fonts, spacing) go in `tokens/`.
+
+---
+
+## What's Next
+
+In the tutorial, you'll identify Functional Components from your existing specifications and document them using this anatomy.
+
+---
+
+**[Continue to Tutorial: Extract Your Components →](tutorial-12.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-patterns-emerge.md) | [Back to Module Overview](module-12-functional-components-overview.md)
+
+*Part of Module 12: Functional Components*
diff --git a/docs/learn/module-12-functional-components/module-12-functional-components-overview.md b/docs/learn/module-12-functional-components/module-12-functional-components-overview.md
new file mode 100644
index 000000000..541c67553
--- /dev/null
+++ b/docs/learn/module-12-functional-components/module-12-functional-components-overview.md
@@ -0,0 +1,384 @@
+# Module 12: Functional Components
+
+**Time: 45 min | Agent: Freya | Phase: Design | Focus: UX**
+
+---
+
+## From Pages to Patterns
+
+You've specified your pages. You documented every element, every state, every interaction.
+
+And now something happens.
+
+You're writing the specification for your third page... and you notice you're describing the same button again. Same states. Same behavior. Same validation pattern.
+
+**You're repeating yourself.**
+
+This is good. This means patterns have emerged.
+
+---
+
+## What Are Functional Components?
+
+Functional Components are the **reusable building blocks** of your interface.
+
+Not colors. Not fonts. Not individual buttons.
+
+**Widgets with functionality.**
+
+```
+NOT a component:           IS a component:
+- Blue (#0066FF)           - Login Form (email, password, validation, submit)
+- A single button          - Search Widget (input, suggestions, keyboard nav)
+- 16px font size           - Comment Section (textarea, submit, character count)
+- A margin value           - Task Card (checkbox, title, status, actions)
+```
+
+**The difference:** Functional Components are widgets that DO something - they have behavior, validation, state management, and user interactions.
+
+---
+
+## Where You Are in WDS
+
+```
+Module 11: Conceptual Specifications
+You wrote complete specifications for each page.
+You documented every element in detail.
+    ↓
+Module 12: Functional Components  ← YOU ARE HERE
+You identify what's repeated across pages.
+You extract patterns into reusable components.
+    ↓
+Module 13: Visual Design
+You apply visual style to your components.
+```
+
+**This module is the bridge** between detailed specifications and actual design system.
+
+---
+
+## Why This Matters
+
+When you specify pages across your app, you might write the same widget specification multiple times.
+
+- Homepage: "Weather widget: location, current temp, 5-day forecast, icons..."
+- Dashboard: "Weather widget: location, current temp, 5-day forecast, icons..."
+- User profile: "Weather widget: location, current temp, 5-day forecast, icons..."
+
+**That's inefficient.** And when something changes (like adding hourly forecast), you update multiple places.
+
+Instead, you extract the pattern:
+
+- **Component:** Weather Widget (defined once with all variants, data sources, states)
+- **Page specs:** "Use Weather Widget (compact variant)"
+
+**Define once. Reference everywhere. Change once. Update everywhere.**
+
+### How Functional Components Connect Pages
+
+```
+      PAGE                    COMPONENT                    PAGE
+┌──────────────────┐   ┌────────────────────┐   ┌──────────────────┐
+│ P01: Homepage    │   │    WEATHER         │   │ P04: Dashboard   │
+├──────────────────┤   │    WIDGET          │   ├──────────────────┤
+│                  │   ├────────────────────┤   │                  │
+│ Hero Section:    │   │ Data:              │   │ Sidebar:         │
+│ - Component:     │◄──┤  • Current temp    │──►│ - Component:     │
+│   WeatherWidget  │   │  • Conditions      │   │   WeatherWidget  │
+│   (detailed)     │   │  • Location        │   │   (compact)      │
+│ - Location:      │   │  • 5-day forecast  │   │ - Location:      │
+│   User's city    │   │  • Hourly (opt.)   │   │   Auto-detect    │
+│                  │   │                    │   │                  │
+│                  │   │ Variants:          │   │                  │
+│                  │   │  • compact         │   │                  │
+│                  │   │  • detailed        │   │                  │
+│                  │   │  • minimal         │   │                  │
+│                  │   │                    │   │                  │
+│                  │   │ States:            │   │                  │
+│                  │   │  • loading         │   │                  │
+│                  │   │  • loaded          │   │                  │
+│                  │   │  • error           │   │                  │
+│                  │   │  • refreshing      │   │                  │
+└──────────────────┘   └────────────────────┘   └──────────────────┘
+                               │
+                               ▼
+                         INTEGRATION
+┌──────────────────────────────────────────────────────────────────┐
+│ When homepage renders hero weather widget:                      │
+│                                                                  │
+│ 1. Reads: Component = WeatherWidget (detailed)                  │
+│ 2. Looks up: WeatherWidget definition                           │
+│ 3. Applies: Detailed variant (current + 5-day + hourly)         │
+│ 4. Configures: Location = User's city                           │
+│ 5. Inherits: All states, API integration, refresh logic         │
+│ 6. Renders: Full weather display with forecast                  │
+│                                                                  │
+│ Result: Fully-functional weather widget with detailed view      │
+└──────────────────────────────────────────────────────────────────┘
+```
+
+**The structure:** Multiple pages reference one widget. Change the widget definition, all instances update.
+
+---
+
+## What Happens in This Module
+
+You'll learn to:
+
+1. **Identify patterns** — Spot elements that appear 2+ times
+2. **Decide what to extract** — Not everything should be a component
+3. **Document components** — Create reusable definitions
+4. **Update page specs** — Reference components instead of repeating specs
+
+By the end, your specifications become **modular and maintainable**.
+
+---
+
+## Why Extract Components?
+
+### Consistency
+
+Same component = same behavior everywhere.
+
+### Efficiency
+
+Specify once, reference many times.
+
+### Maintainability
+
+Change once, update everywhere.
+
+### Communication
+
+Shared vocabulary with developers.
+
+---
+
+## When to Extract
+
+A pattern becomes a component when:
+
+- **Appears 2+ times** — More than once signals a pattern worth extracting
+- **Consistent behavior** — Same interactions everywhere
+- **Worth centralizing** — Benefits from single definition
+- **Meaningful abstraction** — Not just "box with text"
+
+---
+
+## Component Anatomy
+
+```markdown
+## Search Widget
+
+### Description
+Reusable search interface with input, suggestions, and keyboard navigation.
+Used in header navigation, content libraries, and admin panels.
+
+### Variants
+| Variant | Use Case |
+|---------|----------|
+| Global | Site-wide search (all content types) |
+| Scoped | Category-specific search |
+| Instant | Real-time filtering (no submit) |
+
+### States
+- Empty (placeholder visible)
+- Typing (suggestions appear)
+- Loading (fetching results)
+- Results (dropdown with matches)
+- No Results (helpful message)
+- Selected (item chosen from suggestions)
+- Error (API failure)
+
+### Props
+| Prop | Type | Default | Description |
+|------|------|---------|-------------|
+| variant | string | global | Search scope |
+| placeholder | string | "Search..." | Input placeholder |
+| minChars | number | 3 | Min chars before search |
+| debounce | number | 300 | Delay before API call (ms) |
+| maxResults | number | 10 | Max suggestions shown |
+| onSelect | function | - | Callback when item selected |
+
+### Usage Rules
+- Search triggers after 3 characters typed
+- Shows max 10 suggestions
+- Escape key clears and closes
+- Enter selects first result
+- Click outside closes suggestions
+
+### Accessibility
+- Role: combobox
+- Keyboard: Arrow keys navigate, Enter selects, Escape closes
+- Screen reader announces result count
+- aria-autocomplete="list"
+- aria-expanded when suggestions visible
+```
+
+---
+
+## The Freya Method
+
+Freya notices patterns as you specify:
+
+> "This is the third time you've specified a search widget with autocomplete. Should we extract it as a component?"
+
+> "Your comment forms have different validation rules — should we standardize?"
+
+She helps you see what's becoming a pattern.
+
+---
+
+## Component vs. Instance
+
+**Component:** The widget definition (Search Widget)
+**Instance:** A specific usage (header-global-search)
+
+In your specs:
+- Define components in your Design System
+- Reference components in your page specs
+
+```markdown
+### Global Search
+- Component: Search Widget (global)
+- Placeholder: "Search documentation..."
+- OnSelect: Navigate to selected page
+```
+
+### How Integration Works
+
+```
+COMPONENT DEFINITION (C-UX-Scenarios/Functional-Components/search-widget.md)
+┌────────────────────────────────────────────────────────────┐
+│ Search Widget                                              │
+├────────────────────────────────────────────────────────────┤
+│ Variants:                                                  │
+│   - global: All content types                              │
+│   - scoped: Category-specific                              │
+│   - instant: Real-time filtering                           │
+│                                                            │
+│ States:                                                    │
+│   - empty, typing, loading, results, no-results, error     │
+│                                                            │
+│ Props:                                                     │
+│   - variant (global|scoped|instant)                        │
+│   - placeholder (string)                                   │
+│   - minChars (number, default: 3)                          │
+│   - onSelect (function)                                    │
+└────────────────────────────────────────────────────────────┘
+                           ↓
+              INHERITS ALL PROPERTIES
+                           ↓
+┌────────────────────────────────────────────────────────────┐
+│ INSTANCE (P01-homepage/specification.md)                   │
+├────────────────────────────────────────────────────────────┤
+│ header-global-search:                                      │
+│   - Component: Search Widget        ← References def       │
+│   - variant: global                 ← Selects variant      │
+│   - placeholder: "Search docs..."   ← Instance-specific    │
+│   - onSelect: Navigate to page      ← Instance-specific    │
+│                                                            │
+│ INHERITS FROM COMPONENT:                                   │
+│   ✓ All global variant behavior (searches all content)    │
+│   ✓ All states (typing, loading, results, errors...)      │
+│   ✓ All accessibility (keyboard nav, screen reader...)    │
+│   ✓ All usage rules (min 3 chars, debounce, max results)  │
+└────────────────────────────────────────────────────────────┘
+```
+
+**The power:** Change the Search Widget once, all instances update everywhere.
+
+---
+
+## Not Everything Is a Component
+
+Some things are just styled elements:
+
+| Component | Not a Component |
+|-----------|-----------------|
+| Button | A specific color |
+| Card | A specific margin |
+| Input | A single label |
+| Modal | A page layout |
+
+Components have behavior. Styles have appearance.
+
+---
+
+## Output
+
+Functional Components documented:
+
+```
+C-UX-Scenarios/
+└── Functional-Components/
+    ├── weather-widget.md
+    ├── search-widget.md
+    ├── login-form.md
+    └── task-card.md
+```
+
+**Location:** Functional Components live in the UX Scenarios folder, separate from the Design System (which handles visual styling only).
+
+---
+
+## Design System
+
+| Mode | Component Handling |
+|------|-------------------|
+| **None** | Inline in page specs |
+| **Building** | Extract to C-UX-Scenarios/Functional-Components/ |
+| **Library** | Reference external (shadcn, etc.) |
+| **Existing** | Import from previous project |
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Extracting too early | Wait for 2+ usages |
+| Too specific | Keep components generic |
+| Too generic | Must have clear purpose |
+| Missing states | Document all states |
+| Inconsistent naming | Use clear conventions |
+
+---
+
+## Practice
+
+Review your specifications from Module 11:
+
+1. Identify repeated patterns
+2. List elements that appear 2+ times
+3. Document one as a component
+4. Update specs to reference it
+
+---
+
+## Lessons
+
+### [Lesson 1: When Patterns Emerge](lesson-01-patterns-emerge.md)
+Identifying reusable elements across your specifications
+
+### [Lesson 2: Functional Component Anatomy](lesson-02-component-anatomy.md)
+How to document Functional Components completely
+
+---
+
+## Tutorial
+
+### [Tutorial 12: Extract Your Components](tutorial-12.md)
+Hands-on guide to identifying and documenting reusable patterns
+
+---
+
+## Next Module
+
+**[Module 13: Design System →](../module-13-design-system/module-13-design-system-overview.md)**
+
+Choose your design system approach.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-12-functional-components/tutorial-12.md b/docs/learn/module-12-functional-components/tutorial-12.md
new file mode 100644
index 000000000..ef7595d7c
--- /dev/null
+++ b/docs/learn/module-12-functional-components/tutorial-12.md
@@ -0,0 +1,405 @@
+# Tutorial 12: Extract Your Components
+
+**Hands-on guide to identifying and documenting reusable patterns**
+
+---
+
+## Overview
+
+This tutorial walks you through identifying reusable patterns in your specifications and documenting them as components.
+
+**Time:** 30-40 minutes
+**Prerequisites:** Page specifications completed (Module 11)
+**Agent:** Freya
+**What you'll create:** Component documentation in `C-UX-Scenarios/Functional-Components/`
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- Your completed page specifications
+- Understanding of common UI patterns
+- Your Design System mode (None, Building, Library, Existing)
+
+**Note on modes:**
+
+- **Mode 1 (None):** You can still identify patterns but keep them inline
+- **Mode 2 (Building):** Extract components to separate files
+- **Mode 3 (Library):** Reference external library components
+- **Mode 4 (Existing):** Import and extend from previous project
+
+---
+
+## Step 1: Identify Repeated Patterns (10 min)
+
+### Ask Freya to scan your specs:
+
+**You say:**
+> "Review my page specifications and identify elements that appear 2 or more times. Which patterns should we consider extracting as components?"
+
+**Freya analyzes:**
+> "Scanning your specifications... I found these repeated patterns:
+>
+> **Buttons (7 occurrences)**
+> - Signup submit, Login submit, Settings save, Profile update...
+> - Variants: primary (5), secondary (2)
+> - States: loading appears 4 times
+>
+> **Input Fields (12 occurrences)**
+> - Email (3), Password (2), Text (7)
+> - Validation patterns consistent
+>
+> **Cards (4 occurrences)**
+> - Task cards, Profile card, Summary cards
+> - Structure: image + title + description
+>
+> Recommend starting with Button — highest usage, clear patterns."
+
+### Pattern Discovery Visualization
+
+```
+FREYA'S ANALYSIS: Scanning Page Specifications
+┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐
+│ P01-landing │  │ P02-signup  │  │ P03-settings│  │ P04-profile │
+└─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘
+      ↓                ↓                ↓                ↓
+      └────────────────┴────────────────┴────────────────┘
+                              ↓
+                    PATTERN DETECTION
+                              ↓
+        ┌─────────────────────┼─────────────────────┐
+        ↓                     ↓                     ↓
+┌──────────────┐    ┌──────────────┐    ┌──────────────┐
+│ Button       │    │ Input        │    │ Card         │
+│ 7 instances  │    │ 12 instances │    │ 4 instances  │
+├──────────────┤    ├──────────────┤    ├──────────────┤
+│ ✓ Primary(5) │    │ ✓ Email(3)   │    │ ✓ Task cards │
+│ ✓ Second.(2) │    │ ✓ Password(2)│    │ ✓ Profile    │
+│ ✓ Loading(4) │    │ ✓ Text(7)    │    │ ✓ Summary    │
+└──────────────┘    └──────────────┘    └──────────────┘
+   HIGH PRIORITY       HIGH PRIORITY       MED PRIORITY
+        ↓
+  START HERE (most used, clearest pattern)
+```
+
+---
+
+## Step 2: Document First Component (10 min)
+
+### Start with Button:
+
+**Freya:**
+> "Let's document the Button component. First, what variants have you used across your specs?"
+
+**You respond:**
+> "Primary for main actions, secondary for alternatives. I also used a ghost style for inline actions."
+
+**Freya continues:**
+> "And what states appear in your storyboards?"
+
+**You respond:**
+> "Default, hover, active, loading, disabled. The loading state shows a spinner."
+
+**Freya builds the component:**
+
+```markdown
+# Button Component
+
+## Description
+Action trigger used throughout the application.
+Communicates importance through visual hierarchy.
+
+## Variants
+| Variant | Use Case |
+|---------|----------|
+| Primary | Main action per screen |
+| Secondary | Alternative actions |
+| Ghost | Inline/tertiary actions |
+
+## States
+| State | Trigger | Behavior |
+|-------|---------|----------|
+| Default | Initial | Standard appearance |
+| Hover | Mouse over | Darkens 10% |
+| Active | Mouse down | Scale 98% |
+| Loading | loading=true | Spinner, disabled |
+| Disabled | disabled=true | 50% opacity |
+
+## Props
+| Prop | Type | Default |
+|------|------|---------|
+| variant | string | "primary" |
+| size | string | "md" |
+| loading | boolean | false |
+| disabled | boolean | false |
+| fullWidth | boolean | false |
+```
+
+### Add usage rules:
+
+**Freya:**
+> "Based on your specs, what usage rules should we document?"
+
+**You respond:**
+> "One primary per screen. Always has text label. Loading replaces text but keeps width."
+
+**Freya adds:**
+```markdown
+## Usage Rules
+- One primary button per screen
+- Always include text label
+- Loading state: spinner replaces text, width unchanged
+- Minimum touch target: 44px
+```
+
+---
+
+## Step 3: Continue with Other Components (10 min)
+
+### Move to Input:
+
+**Freya:**
+> "Button is complete. Next, let's document Input. What types have you used?"
+
+**You respond:**
+> "Text, email, password. Password has the show/hide toggle."
+
+**Work through:**
+- Types: text, email, password
+- States: default, focus, filled, error, disabled
+- Features: validation, error messages, helper text
+
+**Freya documents:**
+```markdown
+# Input Component
+
+## Description
+Text entry field with validation and error handling.
+
+## Types
+| Type | Features |
+|------|----------|
+| text | Standard input |
+| email | Email validation |
+| password | Masked, show/hide toggle |
+
+## States
+| State | Visual |
+|-------|--------|
+| Default | Gray border |
+| Focus | Blue border |
+| Filled | Content visible |
+| Error | Red border, error message |
+| Disabled | Grayed out |
+
+## Props
+| Prop | Type | Description |
+|------|------|-------------|
+| type | string | text, email, password |
+| label | string | Above field |
+| placeholder | string | In field when empty |
+| error | string | Error message |
+| required | boolean | Required indicator |
+```
+
+### Repeat for Card and other patterns...
+
+---
+
+## Step 4: Update Page Specifications (5 min)
+
+### Replace inline definitions with references:
+
+**Before (inline):**
+```markdown
+### Submit Button
+- Type: Button
+- Style: Primary, blue background, white text
+- States: Default, Hover, Active, Loading, Disabled
+- Label: "Create Account"
+- Loading: Shows spinner
+- OnClick: Submit form
+```
+
+**After (reference):**
+```markdown
+### Submit Button
+- Component: Button (primary, lg)
+- Label: "Create Account"
+- OnClick: Submit form
+- See: [Button Component](../../C-UX-Scenarios/Functional-Components/button.md)
+```
+
+The component definition handles the states and styling. The page spec only needs to specify what's unique to this instance.
+
+### Transformation Visualization
+
+```
+BEFORE: Inline Specifications (Repetitive)
+┌──────────────────────────────────────────────────────────────┐
+│ P02-signup-page/specification.md                             │
+├──────────────────────────────────────────────────────────────┤
+│ Submit Button:                                               │
+│ - Type: Button                                               │
+│ - Style: Primary, blue background, white text                │
+│ - States: Default, Hover, Active, Loading, Disabled          │
+│ - Hover: Darkens 10%, subtle shadow                          │
+│ - Loading: Spinner replaces text                             │
+│ - Disabled: 50% opacity, cursor not-allowed                  │
+│ - Accessibility: role=button, keyboard navigation            │
+│ - Label: "Create Account"                                    │
+│ - OnClick: Submit form                                       │
+│                                                              │
+│ 9 lines of specification (7 are repeated elsewhere)         │
+└──────────────────────────────────────────────────────────────┘
+                              ↓
+                    EXTRACT TO COMPONENT
+                              ↓
+┌──────────────────────────────────────────────────────────────┐
+│ C-UX-Scenarios/Functional-Components/button.md                         │
+├──────────────────────────────────────────────────────────────┤
+│ All variants, states, props, rules, accessibility defined    │
+│ (Single source of truth for all buttons)                     │
+└──────────────────────────────────────────────────────────────┘
+                              ↓
+AFTER: Component References (Concise)
+┌──────────────────────────────────────────────────────────────┐
+│ P02-signup-page/specification.md                             │
+├──────────────────────────────────────────────────────────────┤
+│ Submit Button:                                               │
+│ - Component: Button (primary, lg)                            │
+│ - Label: "Create Account"                                    │
+│ - OnClick: Submit form                                       │
+│                                                              │
+│ 4 lines of specification (only instance-specific details)   │
+│ All behavior inherited from Button component ✓               │
+└──────────────────────────────────────────────────────────────┘
+```
+
+**Result:** 9 lines → 4 lines. Clearer, more maintainable, single source of truth.
+
+---
+
+## Step 5: Verify Consistency (5 min)
+
+### Check for inconsistencies:
+
+**Freya:**
+> "Let me check your specs for consistency against the new components..."
+
+> "Found 2 issues:
+> 1. P03-settings uses 'Cancel' as secondary button, but P02-signup uses 'Back' — should terminology be consistent?
+> 2. P04-profile has a button without specified variant — which should it be?"
+
+**Resolve:**
+> "Back for navigation, Cancel for canceling an action. The profile button should be primary."
+
+**Freya updates the specs accordingly.**
+
+---
+
+## Step 6: Save Component Documentation (2 min)
+
+### Organize files:
+
+```
+C-UX-Scenarios/Functional-Components/
+└── components/
+    ├── button.md
+    ├── input.md
+    ├── card.md
+    └── ...
+```
+
+### Update component index:
+
+```markdown
+# Component Library
+
+## Core Components
+- [Button](components/button.md) - Action triggers
+- [Input](components/input.md) - Text entry
+- [Card](components/card.md) - Content containers
+
+## Status
+| Component | Status | Usage |
+|-----------|--------|-------|
+| Button | Complete | 7 instances |
+| Input | Complete | 12 instances |
+| Card | Complete | 4 instances |
+```
+
+---
+
+## What You've Created
+
+### Component documentation with:
+
+- Description and purpose
+- Variants for different use cases
+- States with triggers and visuals
+- Props with types and defaults
+- Usage rules
+- Accessibility requirements
+
+### Updated page specifications:
+
+- Reference components instead of inline definitions
+- Only specify instance-specific details
+- Consistent terminology
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Wait for 2+ usages before extracting
+- Keep components generic enough to reuse
+- Document usage rules clearly
+- Update all page specs to reference components
+
+**DON'T:**
+
+- Extract everything
+- Make components too specific
+- Forget to document states
+- Leave page specs with outdated inline definitions
+
+---
+
+## Common Questions
+
+**Q: What if a component has a unique state in one place?**
+A: Document it as a variant or extension. Or question whether it's really the same component.
+
+**Q: Should I extract a pattern that's only used once?**
+A: No. Wait for the second usage. Once is an instance, twice or more is a pattern.
+
+**Q: What about third-party library components (Mode 3)?**
+A: Document your customizations and token overrides, not the full component spec.
+
+---
+
+## You've Completed Module 12!
+
+**Your reusable patterns are documented.** You have:
+- Components extracted from specifications
+- Consistent terminology across pages
+- A foundation for design system growth
+
+---
+
+## Next Module
+
+**[Module 13: Design System →](../module-13-design-system/module-13-design-system-overview.md)**
+
+Choose your design system approach.
+
+---
+
+[← Back to Lesson 2](lesson-02-component-anatomy.md) | [Back to Module Overview](module-12-functional-components-overview.md)
+
+*Part of Module 12: Functional Components*
diff --git a/docs/learn/module-13-design-system/lesson-01-understanding-modes.md b/docs/learn/module-13-design-system/lesson-01-understanding-modes.md
new file mode 100644
index 000000000..465880675
--- /dev/null
+++ b/docs/learn/module-13-design-system/lesson-01-understanding-modes.md
@@ -0,0 +1,274 @@
+# Module 13: Design System
+
+## Lesson 1: Understanding the Four Modes
+
+**How component management affects your workflow**
+
+---
+
+## What Are Design System?
+
+When you set up WDS, you chose a mode for handling design components.
+
+This choice affects:
+- How Freya works with you
+- Where components are documented
+- How visuals are generated
+- What you deliver to developers
+
+---
+
+## The Four Modes
+
+| Mode | Description | Best For |
+|------|-------------|----------|
+| **1. None** | No design system | Quick projects, one-offs |
+| **2. Building** | System grows from work | First project for client |
+| **3. Library** | External library + tokens | Using shadcn/Radix/MUI |
+| **4. Existing** | Import from previous | Second+ project, same client |
+
+Each mode has different implications for how you work.
+
+---
+
+## Mode 1: None
+
+### What It Means
+
+No formal design system. Styling is ad-hoc.
+
+### How Freya Works
+
+- Styles defined inline in page specifications
+- No component extraction
+- Each element is self-contained
+
+### Example
+
+```markdown
+### Submit Button
+- Type: Button
+- Style: Blue background (#0066FF), white text, 14px rounded
+- States: Default, Hover (darker), Loading (spinner), Disabled (gray)
+- Label: "Create Free Account"
+```
+
+Everything is specified inline. No separate component document.
+
+### Best For
+
+- Landing pages
+- Quick prototypes
+- One-time projects
+- Tight deadlines
+
+### Trade-off
+
+Consistency is manual. If you want the same button elsewhere, you copy-paste.
+
+---
+
+## Mode 2: Building
+
+### What It Means
+
+Design system grows organically from your work.
+
+As you design, patterns emerge. When they appear 3+ times, you extract them as components.
+
+### How Freya Works
+
+She notices patterns:
+
+> "This button appears in three specifications. Should we extract it as a component?"
+
+You say yes → Goes into `C-UX-Scenarios/Functional-Components/`
+
+### Example
+
+After extraction:
+
+```markdown
+### Submit Button
+- Component: Button (primary, lg)
+- Label: "Create Free Account"
+```
+
+The component definition lives separately. Page specs reference it.
+
+### The Evolution
+
+```
+Project 1: Mode 2 (Building)
+    ↓
+You create components
+    ↓
+Project 2: Mode 4 (Existing)
+    ↓
+You reuse what you built
+```
+
+Your work compounds. Each project builds on the last.
+
+### Best For
+
+- First project for new client
+- Greenfield products
+- When brand is still forming
+
+---
+
+## Mode 3: Component Library
+
+### What It Means
+
+Using an external library (shadcn, Radix, MUI, etc.) with your branding.
+
+The library provides base components. You apply your tokens on top.
+
+### How Freya Works
+
+She references library components:
+
+> "This matches shadcn's Button component. Use the default variant with primary color?"
+
+### Example
+
+```markdown
+### Submit Button
+- Component: shadcn/Button
+- Variant: default
+- Size: lg
+- Class: Custom styles from tokens
+- Label: "Create Free Account"
+```
+
+```yaml
+# tokens/colors.yaml - Your brand applied to library
+colors:
+  primary: "#0066FF"  # Your blue
+  destructive: "#DC2626"  # Your red
+```
+
+### Best For
+
+- Speed to market
+- Consistent base components
+- Teams familiar with the library
+- When you don't need custom patterns
+
+### Trade-off
+
+You get the library's patterns, not your own. Customization has limits.
+
+---
+
+## Mode 4: Existing
+
+### What It Means
+
+Import design system from a previous project.
+
+You've built components before. Now you reuse them.
+
+### How Freya Works
+
+She loads your existing components:
+
+> "You have a Button component from the Acme project. Use it here?"
+
+You can extend with new variants:
+
+```markdown
+### Submit Button
+- Component: Button
+- Variant: "outline" (NEW)
+```
+
+### Best For
+
+- Second+ project for same client
+- Product families
+- Brand consistency across projects
+
+### The Power
+
+Your work compounds. Each project starts with a foundation.
+
+---
+
+## Mode Selection Flow
+
+```
+New Project Setup
+        ↓
+Do you need reusable components?
+        ↓
+    No → Mode 1: None
+        ↓
+    Yes → Do you have an existing system?
+              ↓
+          Yes → Mode 4: Existing
+              ↓
+          No → External library or custom?
+                    ↓
+                External → Mode 3: Library
+                    ↓
+                Custom → Mode 2: Building
+```
+
+---
+
+## Changing Modes
+
+You can upgrade modes as projects evolve:
+
+**Mode 1 → Mode 2**
+
+Start with no system, extract components as patterns emerge.
+
+**Mode 2 → Mode 4**
+
+Complete first project, import system to second project.
+
+**Mode 3 → Mode 2**
+
+Start with library, add custom components as needs grow.
+
+---
+
+## What Each Mode Creates
+
+| Mode | Output |
+|------|--------|
+| None | Inline styles only |
+| Building | `D-Design-System/` folder grows |
+| Library | `D-Design-System/tokens/` only |
+| Existing | `D-Design-System/` extended |
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Building when Library works | Evaluate existing options first |
+| None when project will grow | Anticipate future needs |
+| Existing when brand changed | Start fresh with Building |
+| Over-engineering early | Start None, upgrade later |
+
+---
+
+## What's Next
+
+Understanding your mode helps you work with Freya effectively. In the tutorial, you'll review your mode choice and ensure you're using it correctly.
+
+---
+
+**[Continue to Tutorial: Apply Your Mode →](tutorial-13.md)**
+
+---
+
+[← Back to Module Overview](module-13-design-system-overview.md)
+
+*Part of Module 13: Design System*
diff --git a/docs/learn/module-13-design-system/module-13-design-system-overview.md b/docs/learn/module-13-design-system/module-13-design-system-overview.md
new file mode 100644
index 000000000..4d5e4f297
--- /dev/null
+++ b/docs/learn/module-13-design-system/module-13-design-system-overview.md
@@ -0,0 +1,157 @@
+# Module 13: Design System
+
+**Time: 30 min | Agent: Freya | Phase: Design | Focus: Systems**
+
+---
+
+## What Is a Design System?
+
+A design system is a collection of reusable components — buttons, input fields, cards, navigation elements — that share consistent styling and behavior across your product.
+
+Large organizations spend months building comprehensive design systems with hundreds of components before writing a single line of product code. That works when you have a dedicated team and a long timeline.
+
+Most projects don't.
+
+---
+
+## The WDS Approach: Build As You Go
+
+In WDS, the design system grows naturally from your work.
+
+As you sketch scenarios, write specifications, and define storyboards, you encounter the same elements over and over — a text field here, a button there, a card layout that keeps appearing. Instead of designing each one from scratch every time, you extract it into a shared component.
+
+```
+Scenario P01: Homepage
+  → You specify a search widget
+  → It goes into your component library
+
+Scenario P04: Dashboard
+  → You need a search widget again
+  → It's already there. Reuse it.
+
+Scenario P07: Settings
+  → You need search again, slightly different
+  → Add a variant to the existing component
+```
+
+Each component you extract becomes a puzzle piece. Over time, your collection grows into a treasure chest of ready-made building blocks. Every new page starts a little better because half the pieces already exist.
+
+---
+
+## Design Stays With the Component
+
+This is the key insight: **as soon as you add visual design to a component, it's saved**.
+
+The next time that component appears on a new page, it already looks right. No re-styling. No guessing. The page looks better out of the box because the pieces are already designed.
+
+---
+
+## All Design Is Code
+
+In WDS, your design system lives as code — not as Figma files collecting dust.
+
+You don't need a separate component library in Figma if you don't want one. Every component is stored as a specification in your project, and the styling is saved alongside it.
+
+When you want to edit a component visually:
+
+```
+1. Open the component in Figma
+   → Use the html.to.design plugin to import it
+
+2. Make your changes in Figma
+   → Adjust colors, spacing, typography
+
+3. Sync back to code
+   → Use the Figma MCP to push changes back
+
+4. The WDS agent handles naming
+   → Keeps everything connected automatically
+```
+
+This means your design system is always in sync with your code. No handoff gaps. No "the Figma file says one thing but the code says another."
+
+---
+
+## Design System Paths
+
+Not every project starts from zero. WDS supports three paths:
+
+### Dynamic (Default)
+
+The default WDS approach. Your design system grows one component at a time as you design. Where the components come from depends on your project:
+
+**A: Build on a raw component library**
+
+You start from an external library like shadcn, Radix, or MUI. When you need a button, you pick one from the library, apply your branding, and it becomes part of your design system. Next page needs a card? Pick one, brand it, done.
+
+**B: Make them as you go**
+
+No library — you design each component from scratch as patterns emerge. When something appears twice, you extract it into a shared component.
+
+Most projects use a mix of both. The source doesn't matter. What matters is that each component is picked up **when you need it**, branded to your project, and stored for reuse.
+
+Freya helps by noticing patterns:
+
+> "This button appears in three specifications. Should we extract it as a component?"
+
+You say yes → it goes into `C-UX-Scenarios/Functional-Components/`
+
+Over time, your components accumulate. And on your next project for the same client? The design system already exists. You import it, reuse it, extend it.
+
+```
+Project 1: Dynamic — you pick and build components as you go
+    ↓
+Project 2: You reuse what you built + add new components
+    ↓
+Project 3: Your library keeps growing
+```
+
+Your work compounds. Each project builds on the last.
+
+### None
+
+No design system at all. Each page is self-contained with inline styling. Best for landing pages, quick prototypes, and tight deadlines.
+
+**Trade-off:** Consistency is manual. Reuse requires copy-paste.
+
+---
+
+## The 5-Activity Workflow
+
+In the WDS workflow (Phase 7), the design system is managed through a menu-driven approach:
+
+```
+[C] Create Design System    — Build from scratch or from component library
+[I] Import Design System    — Capture an existing system from a live product
+[V] View Components         — Preview components in a disposable localhost app
+[E] Edit Components         — Open components in Figma for visual refinement
+[B] Browse Design System    — Explore tokens, relationships, and components
+```
+
+The [B] Browse activity generates a disposable localhost application that lets you search tokens by intent ("I need a calm background color"), view relationships between design tokens, and browse the component catalog — like an Airtable-like interface for your design system.
+
+---
+
+## Lessons
+
+### [Lesson 1: Understanding the Four Modes](lesson-01-understanding-modes.md)
+How component management affects your workflow
+
+---
+
+## Tutorial
+
+### [Tutorial 13: Apply Your Mode](tutorial-13.md)
+Hands-on guide to working effectively in your design system mode
+
+---
+
+## Next Module
+
+**[Module 14: Agentic Development →](../module-14-agentic-development/module-14-agentic-development-overview.md)**
+
+Generate working prototypes from your specifications.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-13-design-system/tutorial-13.md b/docs/learn/module-13-design-system/tutorial-13.md
new file mode 100644
index 000000000..c0891a813
--- /dev/null
+++ b/docs/learn/module-13-design-system/tutorial-13.md
@@ -0,0 +1,344 @@
+# Tutorial 13: Apply Your Mode
+
+**Hands-on guide to working effectively in your design system mode**
+
+---
+
+## Overview
+
+This tutorial helps you verify your mode choice and work effectively within it.
+
+**Time:** 15-20 minutes
+**Prerequisites:** Visual designs completed (Module 13)
+**Agent:** Freya
+**What you'll do:** Review and optimize your design system approach
+
+---
+
+## Before You Start
+
+**Know your mode:**
+
+- Mode 1: None (inline styling)
+- Mode 2: Building (extracting components)
+- Mode 3: Library (using external library)
+- Mode 4: Existing (importing previous system)
+
+**If unsure, ask Freya:**
+> "What design system mode are we using for this project?"
+
+---
+
+## Mode 1: None — Tutorial
+
+### Verify inline specifications are complete:
+
+**Check each page spec:**
+
+```markdown
+### Submit Button
+- Style: bg #0066FF, text white, 16px, rounded 6px
+- Padding: 14px vertical, 24px horizontal
+- States: hover (darken 10%), active (scale 98%), loading (spinner), disabled (opacity 50%)
+- Label: "Create Free Account"
+```
+
+### Consistency check:
+
+**Freya asks:**
+> "I notice you have similar buttons on 3 pages. Their styling is slightly different:
+> - P01: rounded 6px
+> - P02: rounded 8px
+> - P03: rounded 6px
+>
+> Should these be consistent?"
+
+**Resolve inconsistencies manually** since there's no central component.
+
+### When to upgrade:
+
+If you find yourself fixing the same inconsistency repeatedly, consider upgrading to Mode 2.
+
+---
+
+## Mode 2: Building — Tutorial
+
+### Review extracted components:
+
+**Freya summarizes:**
+> "Your design system has grown to include:
+>
+> **Components:**
+> - Button (3 variants, 5 states)
+> - Input (3 types, 4 states)
+> - Card (2 variants)
+>
+> **Tokens:**
+> - 6 colors defined
+> - Typography scale
+> - Spacing scale
+>
+> All page specs reference these components."
+
+### Check for missing patterns:
+
+**Freya:**
+> "Looking at your specs, I see a repeated pattern that isn't extracted yet:
+>
+> Form Field Group (label + input + error message) appears 8 times.
+>
+> Should we extract this as a component?"
+
+**You decide:**
+> "Yes, let's extract it."
+
+**Freya creates:**
+```markdown
+# FormField Component
+
+## Description
+Container for label, input, helper text, and error message.
+Provides consistent spacing and error handling.
+
+## Props
+| Prop | Type | Description |
+|------|------|-------------|
+| label | string | Field label |
+| input | Input | The input component |
+| helper | string | Helper text (optional) |
+| error | string | Error message (optional) |
+
+## States
+- Default: Label + input visible
+- With helper: Helper text below input
+- Error: Error message replaces helper, input bordered red
+```
+
+### Update specs to use new component:
+
+**Before:**
+```markdown
+### Email Section
+- Label: "Email" (above, 14px, #374151)
+- Input: email type, placeholder "you@example.com"
+- Helper: none
+- Error: "Please enter a valid email" (when invalid)
+```
+
+**After:**
+```markdown
+### Email Section
+- Component: FormField
+- Label: "Email"
+- Input: Input (email)
+- Placeholder: "you@example.com"
+- Error: "Please enter a valid email"
+```
+
+---
+
+## Mode 3: Library — Tutorial
+
+### Verify library component usage:
+
+**Freya checks:**
+> "You're using shadcn components. Let me verify your usage:
+>
+> **Correctly used:**
+> - Button (default, destructive, outline variants)
+> - Input (with FormField wrapper)
+> - Card (default)
+>
+> **Token overrides:**
+> - Primary color: #0066FF (applied)
+> - Border radius: 6px (applied)
+> - Font: Inter (applied)
+>
+> **Custom additions:**
+> - TaskCard (extends shadcn/Card) — documented
+> - StrengthIndicator — custom component
+>
+> Everything looks aligned."
+
+### Check token application:
+
+```yaml
+# D-Design-System/tokens/colors.yaml
+colors:
+  background: "#FFFFFF"
+  foreground: "#111827"
+  primary: "#0066FF"
+  primary-foreground: "#FFFFFF"
+  secondary: "#F3F4F6"
+  secondary-foreground: "#374151"
+  destructive: "#DC2626"
+  destructive-foreground: "#FFFFFF"
+  muted: "#F9FAFB"
+  muted-foreground: "#6B7280"
+```
+
+### Document custom components:
+
+If you created components beyond the library, document them:
+
+```markdown
+# StrengthIndicator (Custom)
+
+## Description
+Password strength feedback component.
+Not from shadcn — custom for this project.
+
+## Props
+| Prop | Type | Description |
+|------|------|-------------|
+| strength | number | 0-4 strength level |
+
+## Visual
+- 4 bars, filling based on strength
+- Colors: red (1), orange (2), yellow (3), green (4)
+```
+
+---
+
+## Mode 4: Existing — Tutorial
+
+### Review imported components:
+
+**Freya:**
+> "Importing design system from Acme Project v2...
+>
+> **Available components:**
+> - Button (4 variants)
+> - Input (5 types)
+> - Card, Modal, Toast
+> - Form patterns
+>
+> **Token values:**
+> - Brand colors (Acme palette)
+> - Typography (Inter scale)
+> - Spacing (8px base)
+>
+> Ready to use. Any extensions needed?"
+
+### Extend for new project:
+
+**You say:**
+> "This project needs a new Button variant: 'outline-primary' — blue border, transparent background."
+
+**Freya extends:**
+```markdown
+# Button Component (Extended)
+
+## New Variant: outline-primary
+- Border: 1px solid #0066FF
+- Background: transparent
+- Text: #0066FF
+- Hover: Background #0066FF/10%
+
+Added for: New Project
+Reason: Secondary CTAs need brand color visibility
+```
+
+### Track extensions:
+
+```markdown
+# Design System Extensions — New Project
+
+## New Variants
+- Button: outline-primary
+
+## New Components
+- None yet
+
+## Token Overrides
+- None (using Acme palette)
+```
+
+---
+
+## All Modes: Final Check
+
+### Verify alignment:
+
+| Check | Action |
+|-------|--------|
+| All page specs use correct component references | Review each spec |
+| No orphan inline styles (Mode 2-4) | Search for inline definitions |
+| Tokens applied consistently | Check visual prototypes |
+| New patterns documented | Add to design system |
+
+### Document your mode:
+
+Add to project README or design system index:
+
+```markdown
+# Design System
+
+## Mode: Building (Mode 2)
+
+## Components
+See: C-UX-Scenarios/Functional-Components/
+
+## Tokens
+See: D-Design-System/tokens/
+
+## Usage
+All page specifications reference components from this system.
+Do not use inline styles for elements that have component definitions.
+```
+
+---
+
+## What You've Accomplished
+
+### By mode:
+
+**Mode 1:** Verified all inline specs are complete and consistent
+
+**Mode 2:** Components extracted, patterns identified, specs updated
+
+**Mode 3:** Library components correctly used, tokens applied, customs documented
+
+**Mode 4:** System imported, extensions added, tracking in place
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Review mode choice periodically
+- Extract patterns when they repeat 3+ times
+- Document deviations and extensions
+- Keep tokens in sync with visuals
+
+**DON'T:**
+
+- Mix approaches (inline + components randomly)
+- Forget to update specs when extracting
+- Over-engineer for small projects
+- Ignore library conventions in Mode 3
+
+---
+
+## You've Completed Module 13!
+
+**Your design system mode is optimized.** You understand:
+- How your mode works
+- Where components live
+- How to extend the system
+- How to maintain consistency
+
+---
+
+## Next Module
+
+**[Module 14: Agentic Development →](../module-14-agentic-development/module-14-agentic-development-overview.md)**
+
+Generate working prototypes from your specifications.
+
+---
+
+[← Back to Lesson 1](lesson-01-understanding-modes.md) | [Back to Module Overview](module-13-design-system-overview.md)
+
+*Part of Module 13: Design System*
diff --git a/docs/learn/module-14-agentic-development/lesson-01-iterative-building.md b/docs/learn/module-14-agentic-development/lesson-01-iterative-building.md
new file mode 100644
index 000000000..adf253c74
--- /dev/null
+++ b/docs/learn/module-14-agentic-development/lesson-01-iterative-building.md
@@ -0,0 +1,182 @@
+# Module 14: Agentic Development
+
+## Lesson 1: The Development Agent Dialog
+
+**How the process is organized**
+
+---
+
+## Every Session Starts with a Plan
+
+When you ask Freya or Idunn to develop something, the first thing the agent does is create an **Agent Dialog**.
+
+This isn't documentation after the fact. It's the plan *before* anything is built.
+
+The agent reads your input — a specification, a concept, an inspiration image, a rough idea — and creates:
+
+1. **Scope** — What are we building? What's the boundary?
+2. **Tasks** — Ordered steps to get there
+3. **Requirements** — Constraints we must respect (brand, accessibility, technical)
+4. **Test protocol** — How we'll verify each step is done right
+
+Then the agent starts executing. One step at a time.
+
+---
+
+## The Agent Dialog Document
+
+```markdown
+# Agent Dialog: Signup Form
+
+## Meta
+- Date: 2026-02-10
+- Input: P02-signup-form.md (specification)
+- Agent: Idunn
+- Status: In Progress
+
+## Scope
+Build the signup form as a working prototype from the specification.
+Includes: form layout, validation, error states, loading states.
+Excludes: backend integration, email verification flow.
+
+## Tasks
+1. [x] Create form layout with all fields
+2. [x] Add real-time validation
+3. [ ] Implement error states
+4. [ ] Add loading and success states
+5. [ ] Responsive adjustments
+6. [ ] Accessibility pass
+
+## Requirements
+- Must match specification P02 exactly
+- Inter font, #0066FF primary
+- Mobile-first, max-width 400px
+- WCAG AA contrast compliance
+
+## Test Protocol
+- [ ] All text matches spec
+- [ ] All states render correctly
+- [ ] Tab navigation works
+- [ ] Touch targets 44px+
+- [ ] Contrast ratios pass
+
+## Log
+### Step 1: Form layout (completed)
+- Created form with email, password, submit
+- Matches spec layout
+- Decision: Used flexbox for vertical stacking
+
+### Step 2: Validation (completed)
+- Added blur-based validation
+- Decision: Blur instead of keypress (less jarring)
+- Spec impact: Updated storyboard to clarify trigger
+
+### Step 3: Error states (in progress)
+- ...
+```
+
+---
+
+## Why Start with the Dialog?
+
+### It forces clarity
+
+Before building, you know exactly what you're building and how you'll know it's done.
+
+### It enables restart
+
+AI conversations are ephemeral. The dialog is permanent. If you lose context, start a new session, or come back next week — load the dialog. Everything is there.
+
+### It tracks decisions
+
+"Why did we use blur validation?" The answer is in the log, not in someone's memory.
+
+### It shows progress
+
+At any point you can see: what's done, what's next, what changed.
+
+---
+
+## The Log Is the Heartbeat
+
+As you execute each step, the agent logs:
+
+- **What was built** — the output
+- **Decisions made** — and the reasoning
+- **Spec impacts** — did anything in the spec change?
+- **Issues found** — unexpected problems
+
+This log is what makes the dialog a living document, not a static plan.
+
+---
+
+## Plans Change
+
+After completing a step, you and the agent re-evaluate:
+
+- Did this step reveal something new?
+- Should priorities change?
+- Do we need to add tasks?
+- Should we remove tasks that are no longer relevant?
+- Did the scope shift?
+
+**Example:** You planned to build the password strength indicator. But after implementing the form, you realize the field is too small to show it on mobile. New task: rethink the indicator placement. Old task: build indicator as-is → removed.
+
+The plan is not a contract. It's a compass.
+
+---
+
+## Types of Agentic Sessions
+
+The same Agent Dialog structure works for all types:
+
+| Type | Example | Agent |
+|------|---------|-------|
+| **Concept exploration** | "Dream up a dashboard layout for dog trainers" | Freya |
+| **Proof of concept** | "Can we do infinite scroll with this data model?" | Idunn |
+| **Prototype** | "Build a working signup form from this spec" | Idunn |
+| **Design inspiration** | "Generate 3 visual directions for the landing page" | Freya |
+| **Production code** | "Implement the complete registration scenario" | Idunn |
+
+The scope and depth change. The process doesn't.
+
+---
+
+## Session Continuity
+
+### Starting a new session
+
+Load the Agent Dialog into your new conversation:
+
+```
+"I'm continuing the signup form implementation.
+Here's the current Agent Dialog with plan and log:
+
+[Paste dialog.md content]
+
+We completed steps 1-3. Next is step 4: loading states."
+```
+
+The agent picks up from the log, not from memory.
+
+### Handing off between agents
+
+Freya dreamed up a component. Now Idunn needs to build it.
+
+The Agent Dialog travels with the work. Idunn reads Freya's dialog and continues where she left off.
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn how to evaluate results effectively and give feedback that keeps the work on track.
+
+---
+
+**[Continue to Lesson 2: Evaluation and Feedback →](lesson-02-documenting-decisions.md)**
+
+---
+
+[← Back to Module Overview](module-14-agentic-development-overview.md)
+
+*Part of Module 14: Agentic Development*
diff --git a/docs/learn/module-14-agentic-development/lesson-02-documenting-decisions.md b/docs/learn/module-14-agentic-development/lesson-02-documenting-decisions.md
new file mode 100644
index 000000000..6b02f4199
--- /dev/null
+++ b/docs/learn/module-14-agentic-development/lesson-02-documenting-decisions.md
@@ -0,0 +1,188 @@
+# Module 14: Agentic Development
+
+## Lesson 2: Evaluation and Feedback
+
+**Staying in control as the agent builds**
+
+---
+
+## The Step Is Done. Now What?
+
+The agent completed a step. You have output — code, a component, a visual.
+
+Now is the most important moment: **evaluation**.
+
+This is where you, the designer, earn your keep. The AI builds fast. You decide if what it built is right.
+
+---
+
+## The Evaluation Cycle
+
+After every step:
+
+### 1. Compare to Intent
+
+Does the output match what you asked for?
+
+- Check against the specification
+- Check against the test protocol
+- Look at it with fresh eyes — not just technically correct, but does it *feel* right?
+
+### 2. Give Feedback
+
+Tell the agent specifically what's wrong or right. The more precise your feedback, the better the next iteration.
+
+### 3. Update the Plan
+
+Based on what you learned, adjust:
+
+- **Reprioritize** — this task turned out to be more important
+- **Add tasks** — something new emerged
+- **Remove tasks** — this is no longer needed
+- **Split tasks** — this was too big, break it down
+- **Shuffle order** — the sequence should change
+
+---
+
+## Giving Effective Feedback
+
+### Bad Feedback
+
+> "This doesn't look right."
+
+The agent doesn't know what "right" means. It will guess, probably wrong.
+
+### Good Feedback
+
+> "The spacing between the form fields is too tight. The spec says 16px between fields, this looks like 8px. Also, the submit button should be full-width, not centered at 200px."
+
+Specific. Referenced to spec. Actionable.
+
+### Better Feedback
+
+> "Two issues:
+> 1. Field spacing: spec says 16px gap, implementation has 8px. Fix to 16px.
+> 2. Submit button: spec says full-width (100%), implementation is 200px centered. Fix to 100%.
+>
+> Everything else looks correct. Proceed to next step after fixing."
+
+Numbered. Clear priority. Confirms what's correct too.
+
+---
+
+## What to Evaluate
+
+### Against Specification
+
+| Check | Question |
+|-------|----------|
+| Content | Does text match spec exactly? |
+| Layout | Are elements positioned correctly? |
+| States | Are all states present and correct? |
+| Behavior | Do interactions work as specified? |
+| Styling | Do colors, fonts, spacing match tokens? |
+
+### Against Intent
+
+Not everything is in the spec. Use your design judgment:
+
+- Does the visual hierarchy feel right?
+- Is the flow natural?
+- Would a user understand this immediately?
+- Does it match the persona's needs?
+
+### Against Quality
+
+- Accessibility: contrast, focus states, touch targets
+- Responsiveness: does it work on all sizes?
+- Performance: is it smooth?
+
+---
+
+## Re-evaluating the Plan
+
+After evaluation, open the Agent Dialog and update the task list.
+
+**Before step 3:**
+```markdown
+## Tasks
+1. [x] Create form layout
+2. [x] Add validation
+3. [ ] Implement error states
+4. [ ] Loading and success states
+5. [ ] Responsive adjustments
+6. [ ] Accessibility pass
+```
+
+**After step 3 revealed mobile layout issues:**
+```markdown
+## Tasks
+1. [x] Create form layout
+2. [x] Add validation
+3. [x] Implement error states
+4. [ ] Fix mobile layout for error messages    ← NEW
+5. [ ] Loading and success states
+6. [ ] Responsive adjustments
+7. [ ] Accessibility pass
+8. [ ] Revisit password strength on mobile     ← NEW (from step 2 learning)
+```
+
+The plan grows and shrinks. That's normal.
+
+---
+
+## When Output Is Wrong
+
+Three common situations:
+
+### 1. Spec Divergence
+
+The output doesn't match the spec.
+
+**Action:** Point to the specific spec section. Ask the agent to fix it.
+
+> "The spec says the error message appears below the field, but it's rendering as a toast notification. Fix to inline below-field as per spec section 4.2."
+
+### 2. Spec Was Wrong
+
+Building revealed the spec needs updating.
+
+**Action:** Update the spec first, then continue building.
+
+> "The spec says inline validation on keypress, but that's too aggressive. Updating spec to blur-based validation. Continue with updated approach."
+
+### 3. Better Idea
+
+The agent or you discovered a better approach during building.
+
+**Action:** Document the improvement, update spec, continue.
+
+> "The agent suggested a shake animation on error instead of just red text. That's better UX. Updating spec to include shake. Document as intentional improvement."
+
+---
+
+## The Evaluation Mindset
+
+Think of yourself as a creative director reviewing work:
+
+- **Be specific** — point to exact elements
+- **Be decisive** — approve or reject, don't waffle
+- **Be efficient** — one round of feedback per step, not five
+- **Confirm what's right** — not just what's wrong
+- **Think strategically** — does this serve the user, the persona, the business goal?
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn what to do when things go wrong — when the agent can't solve the problem and you need to troubleshoot or escalate.
+
+---
+
+**[Continue to Lesson 3: When You Get Stuck →](lesson-03-when-you-get-stuck.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-iterative-building.md) | [Back to Module Overview](module-14-agentic-development-overview.md)
+
+*Part of Module 14: Agentic Development*
diff --git a/docs/learn/module-14-agentic-development/lesson-03-when-you-get-stuck.md b/docs/learn/module-14-agentic-development/lesson-03-when-you-get-stuck.md
new file mode 100644
index 000000000..d820aa4d7
--- /dev/null
+++ b/docs/learn/module-14-agentic-development/lesson-03-when-you-get-stuck.md
@@ -0,0 +1,213 @@
+# Module 14: Agentic Development
+
+## Lesson 3: When You Get Stuck
+
+**Because AI doesn't always get it right**
+
+---
+
+## It Will Happen
+
+You give clear feedback. The agent makes a change. It's still wrong. You clarify. Another change. Still wrong. Or worse — it fixes one thing and breaks another.
+
+This is normal. It happens to everyone. The question is: what do you do?
+
+---
+
+## Recognize the Loop
+
+The most common trap:
+
+```
+You: "Fix the spacing"
+Agent: Changes spacing, breaks alignment
+You: "Now fix the alignment"
+Agent: Fixes alignment, reverts spacing
+You: "The spacing is wrong again"
+Agent: ...
+```
+
+If you've gone back and forth more than **3 times** on the same issue, you're in a loop. Stop.
+
+---
+
+## Troubleshooting Strategies
+
+### 1. Start Fresh on the Step
+
+Sometimes the agent has accumulated too many conflicting changes. The context is muddled.
+
+**Action:** Roll back to the last working state. Ask the agent to redo the step from scratch with clear, complete instructions.
+
+> "Let's start this step over. Here's the last working version: [paste code]. Now implement the error states with these exact requirements: [list all requirements in one message]."
+
+One comprehensive prompt beats five incremental fixes.
+
+### 2. Break the Problem Down
+
+The step might be too big. The agent is trying to do too much at once.
+
+**Action:** Split the step into smaller pieces.
+
+Instead of:
+> "Add all error states"
+
+Try:
+> "Add just the email validation error. Red border, error message below the field, text: 'Please enter a valid email'."
+
+One thing. Verify. Next thing.
+
+### 3. Show, Don't Tell
+
+Sometimes words aren't enough. Show the agent what you mean.
+
+**Action:** Provide visual reference, code snippets, or examples.
+
+> "The error message should look like this:
+> ```html
+> <span class="error" style="color: #DC2626; font-size: 14px; margin-top: 4px;">
+>   Please enter a valid email
+> </span>
+> ```
+> Apply this pattern to all validation errors."
+
+Concrete examples eliminate ambiguity.
+
+### 4. Check Your Own Spec
+
+Sometimes the problem is the spec, not the agent.
+
+**Action:** Re-read your specification with fresh eyes. Is it actually clear? Could it be interpreted differently?
+
+Common spec issues that confuse agents:
+- Contradictory requirements
+- Vague descriptions ("appropriate size", "good spacing")
+- Missing state definitions
+- Unclear interaction triggers
+
+Fix the spec, then resume.
+
+---
+
+## When to Change Approach
+
+Some problems resist iteration. Signs you need a different approach:
+
+| Signal | What it means |
+|--------|---------------|
+| Same error 3+ times | The agent doesn't understand the problem |
+| Fixes create new bugs | The approach is structurally wrong |
+| The output keeps getting worse | Too many patches on a bad foundation |
+| You can't explain what's wrong | You might need to rethink the design |
+
+**Action:** Step back. Look at the bigger picture. Maybe the component needs a different structure. Maybe the layout approach is wrong. Sometimes the answer is to redesign the step, not debug it.
+
+---
+
+## When to Ask a Developer
+
+This is the hardest moment for a designer working with AI: admitting the agent can't solve it.
+
+### Signs You Need Human Help
+
+- **Technical limitation** — the agent hits a framework or API issue it can't resolve
+- **Performance problem** — it works but it's too slow, and optimizing is beyond the spec
+- **Integration issue** — the component works in isolation but breaks in the real app
+- **Build/deploy error** — something in the toolchain, not the design
+- **State management** — complex data flow that needs architectural thinking
+
+### How to Ask
+
+Don't come empty-handed. Bring your Agent Dialog:
+
+> "I've been building the signup form. Here's my Agent Dialog with everything we tried.
+>
+> The issue: error messages work on desktop but disappear on mobile. The agent tried 4 different approaches (logged in the dialog). None worked.
+>
+> I think it's a CSS overflow issue but I'm not sure. Can you take a look?"
+
+The dialog shows what you've tried. The developer doesn't start from zero.
+
+### What to Document
+
+When a developer fixes the issue, add it to your Agent Dialog:
+
+```markdown
+### Step 4: Error states on mobile (resolved with developer help)
+- Issue: Error messages clipped by overflow:hidden on parent container
+- Root cause: Parent component sets overflow:hidden for scroll behavior
+- Fix: Moved error messages outside the scrollable container
+- Developer: Marcus helped identify the CSS issue
+- Learning: Check parent overflow properties when elements disappear
+```
+
+This learning carries forward. Next time the agent (or you) will know.
+
+---
+
+## Common Stuck Points for Designers
+
+Issues that frequently trip up designers working with AI:
+
+### CSS That Won't Behave
+
+The layout looks right in one viewport, breaks in another. AI agents are surprisingly bad at responsive edge cases.
+
+**Tips:**
+- Give explicit breakpoints, not vague "make it responsive"
+- Test each breakpoint separately
+- Use browser dev tools to inspect
+
+### State Management
+
+The button should be disabled when the form is invalid. But it's always enabled. Or always disabled.
+
+**Tips:**
+- Describe state transitions explicitly: "Button starts disabled. Becomes enabled when email is valid AND password is 8+ characters."
+- Test each transition individually
+
+### Animations and Transitions
+
+The agent adds an animation. It's janky. You ask for smooth. Still janky.
+
+**Tips:**
+- Provide exact CSS transition values: "transition: opacity 200ms ease-in-out"
+- Some animations need requestAnimationFrame — this is where a developer helps
+
+### Accessibility
+
+The contrast passes but the focus ring is invisible. Or screen readers announce things in the wrong order.
+
+**Tips:**
+- Use browser accessibility tools (DevTools → Accessibility panel)
+- Tab through everything manually
+- Test with actual screen reader if possible
+
+---
+
+## The Right Mindset
+
+Getting stuck doesn't mean failure. It means you're pushing into real product development.
+
+The value of a designer in agentic development isn't that you can build everything yourself. It's that you:
+
+1. **Know what right looks like** — your eye catches what the agent misses
+2. **Can articulate the problem** — your feedback makes the agent better
+3. **Know when to escalate** — you don't waste time on what needs human expertise
+4. **Document everything** — the next person (or the next session) benefits from your experience
+
+---
+
+## What's Next
+
+Before the tutorial, two more practical lessons: choosing your code format and keeping it safe with Git.
+
+---
+
+**[Continue to Lesson 4: Working with Code →](lesson-04-working-with-code.md)**
+
+---
+
+[← Back to Lesson 2](lesson-02-documenting-decisions.md) | [Back to Module Overview](module-14-agentic-development-overview.md)
+
+*Part of Module 14: Agentic Development*
diff --git a/docs/learn/module-14-agentic-development/lesson-04-working-with-code.md b/docs/learn/module-14-agentic-development/lesson-04-working-with-code.md
new file mode 100644
index 000000000..0944db44d
--- /dev/null
+++ b/docs/learn/module-14-agentic-development/lesson-04-working-with-code.md
@@ -0,0 +1,304 @@
+# Module 14: Agentic Development
+
+## Lesson 4: Choosing Your Code Format
+
+**Understanding what the agent produces and which technology fits your needs**
+
+---
+
+## The Agent Writes Code. Which Kind?
+
+When you ask an agent to build something, one of the first decisions is: what technology should it use? This choice affects how fast you can iterate, how easy it is to share, and how close the output is to production.
+
+You don't need to become an expert. But you need to understand the options well enough to make good decisions — or at least ask the right questions.
+
+---
+
+## The Most Common Stack: React + Tailwind
+
+Most modern web projects use some version of this combination. If you're building production code, this is likely what you'll work with.
+
+**React** handles structure and behavior — you build reusable components that manage their own state.
+
+**Tailwind CSS** handles styling — instead of writing CSS in separate files, you apply utility classes directly to elements.
+
+**Next.js** ties it all together — routing between pages, server features, and deployment.
+
+```jsx
+function SignupForm() {
+  const [email, setEmail] = useState('')
+  const [error, setError] = useState('')
+
+  function handleSubmit() {
+    if (!email.includes('@')) {
+      setError('Please enter a valid email')
+    }
+  }
+
+  return (
+    <div className="max-w-md p-8">
+      <h1 className="text-2xl font-bold mb-4">Create Account</h1>
+      <input
+        type="email"
+        value={email}
+        onChange={(e) => setEmail(e.target.value)}
+        className="w-full border rounded p-3 mb-4"
+        placeholder="Email"
+      />
+      {error && <span className="text-red-600 text-sm">{error}</span>}
+      <button
+        onClick={handleSubmit}
+        disabled={!email}
+        className="bg-blue-600 text-white px-6 py-3 rounded w-full disabled:opacity-50"
+      >
+        Sign Up
+      </button>
+    </div>
+  )
+}
+```
+
+Notice how everything — structure, styling, and behavior — lives in one component file. This is what modern web development looks like.
+
+| | |
+|---|---|
+| **Pros** | Industry standard. Components are reusable. Real interactivity. Deploys easily to Vercel. The agent is very good at generating this stack. |
+| **Cons** | Requires a development environment (Node.js, package manager). Can't just open a file in the browser. Errors can be cryptic. Steeper learning curve. |
+| **Best for** | Production projects. Interactive prototypes. Building within an existing codebase. |
+
+---
+
+## Component Libraries and Your Design System
+
+In Module 13, you built a design system — tokens for colors, typography, spacing, and component definitions. In code, these come to life through **component libraries**.
+
+A component library is a collection of pre-built, styled components (buttons, inputs, cards, modals) that you use as building blocks. Instead of writing a button from scratch every time, you import one:
+
+```jsx
+import { Button } from '@/components/ui/button'
+import { Input } from '@/components/ui/input'
+
+function SignupForm() {
+  return (
+    <div className="max-w-md p-8">
+      <Input type="email" placeholder="Email" />
+      <Button variant="primary">Sign Up</Button>
+    </div>
+  )
+}
+```
+
+### Popular component libraries
+
+| Library | What it is |
+|---|---|
+| **shadcn/ui** | Copy-paste components built on Tailwind. You own the code. Highly customizable. Currently the most popular choice. |
+| **Radix UI** | Accessible, unstyled primitives. You add your own styling. The foundation under shadcn/ui. |
+| **Material UI (MUI)** | Google's design system as React components. Opinionated look and feel. |
+| **Chakra UI** | Utility-based components with built-in accessibility. |
+
+### How this connects to your design system
+
+Your design tokens (Module 13) define the rules. The component library implements them:
+
+| Design token | Code implementation |
+|---|---|
+| Primary color: `#0066FF` | `--primary: #0066FF` in your Tailwind config |
+| Font: Inter, 16px base | `fontFamily: { sans: ['Inter'] }` in config |
+| Spacing: 8px scale | `spacing: { 1: '8px', 2: '16px', ... }` |
+| Button: primary variant | `<Button variant="primary">` uses all the above |
+
+When the agent builds, it should use your component library and respect your design tokens. Include your design system in the Agent Dialog requirements:
+
+> "Use our design system tokens. Primary #0066FF, Inter font, 8px spacing scale. Use shadcn/ui components where applicable."
+
+---
+
+## For Prototyping: HTML + Tailwind
+
+When you don't need a full framework — just a quick visual prototype — use static HTML with Tailwind via CDN.
+
+```html
+<!DOCTYPE html>
+<html>
+<head>
+  <script src="https://cdn.tailwindcss.com"></script>
+</head>
+<body>
+  <div class="max-w-md mx-auto p-8 mt-16">
+    <h1 class="text-2xl font-bold mb-4">Create Account</h1>
+    <input type="email" placeholder="Email"
+      class="w-full border rounded p-3 mb-4">
+    <button class="bg-blue-600 text-white px-6 py-3 rounded w-full">
+      Sign Up
+    </button>
+  </div>
+</body>
+</html>
+```
+
+One file. Double-click to open. Instant prototype.
+
+| | |
+|---|---|
+| **Pros** | Zero setup. One file. Consistent styling with utility classes. Easy to share. Fast iteration. |
+| **Cons** | No real interactivity without adding JavaScript. Not production code. Tailwind CDN is for prototyping only. |
+| **Best for** | Rapid exploration. Client reviews. Testing layouts and visual direction before committing to a framework. |
+
+---
+
+## The Simplest Option: HTML + CSS + JavaScript
+
+The foundation of the web. Every browser understands these three languages natively. No framework, no library, no build step.
+
+- **HTML** — the structure (what elements exist and how they're organized)
+- **CSS** — the visual styling (colors, fonts, spacing, layout)
+- **JavaScript** — the behavior (what happens when you click, type, or scroll)
+
+These can be combined in a single `.html` file for quick explorations, or split into separate files for organized work:
+
+```html
+<!-- structure -->
+<div class="signup-form">
+  <h1>Create Account</h1>
+  <input type="email" id="email" placeholder="Email">
+  <button id="submit-btn">Sign Up</button>
+  <span class="error" id="email-error"></span>
+</div>
+```
+
+```css
+/* appearance */
+.signup-form { max-width: 400px; padding: 32px; font-family: Inter, sans-serif; }
+.signup-form button { background: #0066FF; color: white; padding: 12px 24px; }
+.error { color: #DC2626; font-size: 14px; display: none; }
+```
+
+```javascript
+// behavior
+document.getElementById('submit-btn').addEventListener('click', function() {
+  const email = document.getElementById('email').value
+  const error = document.getElementById('email-error')
+  if (!email.includes('@')) {
+    error.textContent = 'Please enter a valid email'
+    error.style.display = 'block'
+  }
+})
+```
+
+| | |
+|---|---|
+| **Pros** | No setup. No dependencies. Universal. You can read the structure, styles, and behavior separately. Opens in any browser. |
+| **Cons** | Everything is manual. No components or reusability. Gets messy in larger projects. More code to wire things together. |
+| **Best for** | Learning the basics. Quick one-off prototypes. When you want full control with no abstractions. |
+
+---
+
+## Other Frameworks
+
+| Technology | When you'll see it |
+|---|---|
+| **Svelte / SvelteKit** | Simpler alternative to React. Less boilerplate. Growing in popularity. |
+| **Vue / Nuxt** | Another React alternative. Popular in some teams and regions. |
+| **TypeScript** | JavaScript with type safety. Production projects often require it. The agent handles it well. |
+
+You don't choose these — your project does. If you're joining an existing codebase, you use what's already there. If you're starting fresh, the agent can help you pick.
+
+---
+
+## Static vs. Executable: Where They Live
+
+### Static prototypes
+
+Placed in the scenario folder alongside their specifications. This keeps the visual output next to the spec it was built from:
+
+```
+docs/C-Scenarios/S01-User-Registration/
+├── scenario-overview.md
+├── P01-landing-page/
+│   ├── specification.md
+│   └── prototype.html          ← Static prototype
+├── P02-signup-form/
+│   ├── specification.md
+│   └── prototype.html          ← Static prototype
+└── shared/
+    ├── styles.css              ← Shared styles across pages
+    └── interactions.js         ← Shared behavior
+```
+
+### Executable code
+
+Organized in the root of the repository, following the project's framework structure:
+
+```
+my-project/
+├── src/
+│   ├── components/
+│   │   ├── SignupForm.tsx
+│   │   └── ui/                 ← Component library
+│   ├── pages/
+│   │   ├── index.tsx
+│   │   └── signup.tsx
+│   └── styles/
+│       └── globals.css
+├── docs/                       ← Specs still live here
+├── package.json
+└── ...
+```
+
+---
+
+## Choosing the Right Format
+
+| Situation | Format | Why |
+|-----------|--------|-----|
+| Exploring a layout idea | HTML + Tailwind | Fast, disposable, zero setup |
+| Reviewing with a client | Static HTML | Easy to share, no setup for viewer |
+| Rapid component iteration | HTML + Tailwind | Consistent styling, quick changes |
+| Building a production feature | React + Tailwind | Ships directly into the codebase |
+| Testing real form validation | React | Needs real state management |
+| Designing a new page | Static first | Iterate fast, then migrate |
+| Adding to an existing app | Match the existing stack | Must fit the codebase |
+
+Many projects use both categories: static HTML for exploration, framework code for implementation. Start light, go heavy when you need to.
+
+---
+
+## Practical Tips
+
+### For static prototypes
+
+- Ask the agent: "Build this as a single HTML file I can open in my browser"
+- Use Tailwind CDN for fast styling without setup
+- Share by sending the file — email, Slack, cloud drive
+- Place prototypes in the scenario folder next to the specification
+
+### For executable code
+
+- Ask the agent: "Build this as a component in our [framework] project using our design system"
+- Make sure your development environment is running before you start
+- Deploy to a preview URL (Vercel, Netlify) when you need to share
+- Keep the Agent Dialog updated with the branch and commit information
+
+### When to ask a developer
+
+- You're not sure which technology the project uses
+- The development server won't start
+- You get build errors you don't understand
+- You need to set up a new project from scratch
+
+---
+
+## What's Next
+
+Whether you're producing static HTML or executable code, you need a way to keep your work safe, organized, and shareable. That's where Git comes in.
+
+---
+
+**[Continue to Lesson 5: Git Discipline →](lesson-05-git-discipline.md)**
+
+---
+
+[← Back to Lesson 3](lesson-03-when-you-get-stuck.md) | [Back to Module Overview](module-14-agentic-development-overview.md)
+
+*Part of Module 14: Agentic Development*
diff --git a/docs/learn/module-14-agentic-development/lesson-05-git-discipline.md b/docs/learn/module-14-agentic-development/lesson-05-git-discipline.md
new file mode 100644
index 000000000..8a8c0194f
--- /dev/null
+++ b/docs/learn/module-14-agentic-development/lesson-05-git-discipline.md
@@ -0,0 +1,349 @@
+# Module 14: Agentic Development
+
+## Lesson 5: Git Discipline
+
+**Keeping your work safe, organized, and shareable**
+
+---
+
+## Why Git Matters
+
+Every piece of code you create with an agent should be version controlled. Git is the safety net that lets you experiment without fear. If something breaks, you can go back. If you want to try a different approach, you can branch off. If you're ready to share, you can publish.
+
+Without Git, one bad agent session can wipe out hours of work. With Git, you can always undo.
+
+---
+
+## When to Use What
+
+Not every situation needs the full Git ceremony. It depends on where you are in the project and whether you're working alone or with a team.
+
+### Working alone, early in the project
+
+When you're the only designer and you're still writing specifications, exploring concepts, and building early prototypes — **working directly on main is fine.**
+
+Specifications are documents. They change constantly in early phases. Creating branches for every spec edit adds friction without adding value. Commit your work to main, push regularly, and move fast.
+
+```
+git add .
+git commit -m "Add signup form specification and prototype"
+git push
+```
+
+This is simple and effective. You have a history of everything you've done, and you can undo anything.
+
+### Working on code that matters
+
+As soon as you're building executable code, features, or anything that could break an existing project — **use branches.**
+
+Branches protect the stable version of your project. Your experiments happen in isolation. When they work, you merge them in. When they don't, you throw them away. No harm done.
+
+### Working with others
+
+When anyone else touches the same codebase — **always use branches and pull requests.**
+
+This isn't optional. It's how teams avoid overwriting each other's work.
+
+---
+
+## Let the Agent Handle Git
+
+You don't have to type Git commands yourself. The agent can create branches, make commits, and even create pull requests as part of the Agent Dialog flow.
+
+**Tell the agent at the start:**
+
+> "Create a branch for this work. Commit after each completed step. When we're done, create a pull request."
+
+The agent will:
+1. Create a branch with a descriptive name
+2. Commit after each step with a clear message
+3. Push the branch when you say so
+4. Create a PR with a summary when you're ready
+
+**Trade-off:** You have less manual control over exactly what gets committed and when. But for most design work, this is perfectly acceptable. The convenience outweighs the loss of control.
+
+**When to take back control:** If you're working in a shared codebase or production project, review what the agent commits before pushing. A quick `git status` and `git diff` before each push keeps you informed.
+
+---
+
+## The Complete Process (Step by Step)
+
+For when you need to understand what's happening — or when you want to handle Git yourself.
+
+### Step 1: Check where you are
+
+```
+git status
+```
+
+This shows which branch you're on and if there are any changes.
+
+```
+On branch main
+nothing to commit, working tree clean
+```
+
+### Step 2: Get the latest version
+
+```
+git pull
+```
+
+This downloads any changes others have pushed. Always do this before starting new work.
+
+### Step 3: Create a branch
+
+```
+git checkout -b feature/signup-form-prototype
+```
+
+You've created a new branch and switched to it. All your work happens here.
+
+**Naming tips:**
+- `feature/signup-form` — building something new
+- `fix/mobile-navigation` — fixing a problem
+- `explore/dashboard-layout` — trying an idea
+
+### Step 4: Work and save as you go
+
+After each completed step in your Agent Dialog, commit:
+
+```
+git add .
+git commit -m "Add signup form layout with all fields from spec"
+```
+
+**How often:** After every completed step. Step 1 done? Commit. Step 2 done? Commit. These are your save points.
+
+**Good commit messages:**
+- "Add form layout with all fields from spec"
+- "Style signup form with design tokens"
+- "Add blur-based validation for email and password"
+
+**Bad commit messages:**
+- "update"
+- "stuff"
+- "wip"
+
+### Step 5: Push your branch
+
+```
+git push -u origin feature/signup-form-prototype
+```
+
+Your branch now exists online. Others can see it. After the first push, just type `git push`.
+
+**When to push:**
+- End of a work session (backup)
+- When you want feedback
+- Before creating a pull request
+
+### Step 6: Create a pull request
+
+When you're done and the Agent Dialog shows all tests passing:
+
+**Using the command line:**
+```
+gh pr create --title "Add signup form prototype" --body "Built from spec P02. See Agent Dialog for details."
+```
+
+**Using GitHub:** Go to your repository, click "Pull requests", click "New pull request", select your branch.
+
+**What goes in the PR:**
+- What you built (reference the spec)
+- What to look for in review
+- Link to the Agent Dialog
+- Any known limitations
+
+### Step 7: Merge and clean up
+
+When approved, merge the PR on GitHub. Then locally:
+
+```
+git checkout main
+git pull
+git branch -d feature/signup-form-prototype
+```
+
+You're back on main with your changes included.
+
+---
+
+## Working with Your Team
+
+### Roles in the codebase
+
+In a WDS team, different people touch the codebase in different ways:
+
+| Role | What they do in the repo |
+|---|---|
+| **Designer (you)** | Write specifications, create prototypes, build visual designs |
+| **Developer** | Build production features, set up infrastructure, review code |
+| **Product owner** | Review specifications and prototypes, approve PRs |
+
+### Communicating through Git
+
+Git isn't just version control — it's communication.
+
+**Your commit messages** tell the team what changed:
+> "Add error states to signup form per spec P02 section 4"
+
+**Your PR descriptions** give reviewers context:
+> "This implements the signup form prototype. All states from the spec are present. Validation triggers on blur. Touch targets verified at 48px."
+
+**Your branch names** show what's being worked on:
+> `feature/signup-form-prototype` tells everyone at a glance what this branch is about.
+
+### Avoiding conflicts
+
+Conflicts happen when two people change the same file at the same time. To minimize them:
+
+- **Communicate** — let the team know what you're working on
+- **Keep branches short-lived** — merge frequently, don't let branches sit for weeks
+- **Pull before you push** — always get the latest changes before pushing yours
+- **Stay in your lane** — work on the files related to your task, not random cleanups
+
+### When conflicts happen anyway
+
+```
+git pull origin main
+```
+
+Git marks the conflicts in your files:
+
+```
+<<<<<<< HEAD
+Your version
+=======
+Their version
+>>>>>>> main
+```
+
+**What to do:**
+1. Open the file
+2. Decide which version to keep (or combine both)
+3. Delete the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
+4. Save, stage, and commit
+
+**When to ask for help:** If the conflict is in code you don't understand, ask a developer. Show them the Agent Dialog so they have context.
+
+### Code reviews
+
+When a developer reviews your PR, they might:
+
+- **Approve** — your work is merged
+- **Request changes** — they want adjustments
+- **Comment** — they have questions or suggestions
+
+Don't take change requests personally. Reviews improve code quality and catch issues you might miss. Make the changes on your branch, commit, push — the PR updates automatically.
+
+---
+
+## Connecting Git to the Agent Dialog
+
+Your Agent Dialog meta section should include the branch:
+
+```markdown
+## Meta
+- Date: 2026-02-10
+- Input: P02-signup-form.md
+- Agent: Idunn
+- Branch: feature/signup-form-prototype
+- Status: In Progress
+```
+
+And your log should note commits:
+
+```markdown
+### Step 1: Form layout (completed)
+- Created semantic HTML form structure
+- All elements from spec present
+- Commit: "Add form layout with all fields from spec"
+```
+
+This way, if you need to go back to any step, you know exactly which commit to find.
+
+---
+
+## When Things Go Wrong
+
+### "I made changes on the wrong branch"
+
+If you haven't committed yet:
+
+```
+git stash
+git checkout feature/correct-branch
+git stash pop
+```
+
+This moves your uncommitted changes to the right branch.
+
+### "The agent broke something and I want to go back"
+
+Find the last good commit:
+
+```
+git log --oneline
+```
+
+Restore a specific file to that state:
+
+```
+git checkout e4f5g6h -- src/components/SignupForm.html
+```
+
+### "I want to undo the last commit"
+
+```
+git reset --soft HEAD~1
+```
+
+Removes the last commit but keeps all the changes in your files.
+
+---
+
+## Quick Reference Card
+
+| What you want to do | Command |
+|---|---|
+| Check which branch you're on | `git status` |
+| Switch to main | `git checkout main` |
+| Get latest changes | `git pull` |
+| Create a new branch | `git checkout -b feature/name` |
+| See what changed | `git status` |
+| Stage files | `git add .` |
+| Commit | `git commit -m "message"` |
+| Push to remote | `git push` |
+| See commit history | `git log --oneline` |
+| Undo last commit (keep changes) | `git reset --soft HEAD~1` |
+| Stash changes temporarily | `git stash` / `git stash pop` |
+| Delete a merged branch | `git branch -d branch-name` |
+
+---
+
+## The Golden Rules
+
+1. **Alone + specs = work on main.** Don't overcomplicate early phases.
+2. **Code that matters = use branches.** Protect the stable version.
+3. **Working with others = branches + PRs.** Always.
+4. **Commit after every step.** These are your save points.
+5. **Push at the end of every session.** Don't lose work.
+6. **Let the agent help.** It can handle Git for you in the dialog.
+7. **When in doubt, ask a developer.** They untangle Git faster than Google.
+
+---
+
+## What's Next
+
+In the tutorial, you'll run through a complete agentic development session — from creating the Agent Dialog through evaluation, feedback, and handling a stuck moment.
+
+---
+
+**[Continue to Tutorial: Your First Agentic Session →](tutorial-14.md)**
+
+---
+
+[← Back to Lesson 4](lesson-04-working-with-code.md) | [Back to Module Overview](module-14-agentic-development-overview.md)
+
+*Part of Module 14: Agentic Development*
diff --git a/docs/learn/module-14-agentic-development/module-14-agentic-development-overview.md b/docs/learn/module-14-agentic-development/module-14-agentic-development-overview.md
new file mode 100644
index 000000000..bfc5e0dd1
--- /dev/null
+++ b/docs/learn/module-14-agentic-development/module-14-agentic-development-overview.md
@@ -0,0 +1,251 @@
+# Module 14: Agentic Development
+
+**Time: 60 min | Agents: Freya + Idunn | Phase: Design-Build**
+
+---
+
+## What Is Agentic Development?
+
+Agentic development is every process where you use an AI agent to transform your ideas into coded form.
+
+It can produce:
+
+- **Concepts** — quick explorations to test an idea
+- **Proof of concepts** — does this approach work at all?
+- **Prototypes** — working versions to evaluate and refine
+- **Production code** — final implementation for delivery
+
+It works in both directions:
+
+- **Inspiration → Specification** — Ask the agent to suggest or dream up a component, section, page, scenario, or complete app. Use the output as input for your specifications.
+- **Specification → Code** — Feed the agent your specifications and generate working code that matches.
+
+Whether you're exploring possibilities or building the final product, the process is the same.
+
+---
+
+## The 7-Activity Menu
+
+Agentic development is **menu-driven**, not linear. When you enter Phase 5, you choose what you need:
+
+```
+[P] Prototyping           — Build throwaway prototypes to validate ideas
+[D] Development           — Write production code from approved specs
+[F] Bugfixing             — Systematically fix bugs in existing code
+[E] Evolution             — Add features to existing products
+[A] Analysis              — Investigate codebase, architecture, patterns
+[R] Reverse Engineering   — Capture existing product as WDS specifications
+[T] Acceptance Testing    — Verify implementation against specs
+```
+
+Each activity has its own workflow with dedicated steps. The core agentic loop (plan → execute → evaluate → update) applies to all of them — the context differs.
+
+---
+
+## The Agent Dialog
+
+Every agentic development session starts with an **Agent Dialog** — a structured document that organizes the work.
+
+Before writing a single line of code, the agent creates:
+
+1. **Scope** — What are we building?
+2. **Tasks** — What steps will get us there?
+3. **Requirements** — What constraints must we respect?
+4. **Test protocol** — How will we know it's right?
+
+This is your plan. It evolves as you work.
+
+---
+
+## The Agentic Development Loop
+
+```
+┌──────────────┐
+│ Create plan  │  ← Agent Dialog: scope, tasks, requirements, tests
+└──────┬───────┘
+       │
+       ▼
+┌──────────────┐
+│ Execute step │  ← Build one thing
+└──────┬───────┘
+       │
+       ▼
+┌──────────────┐
+│   Evaluate   │  ← Does it match? What did we learn?
+└──────┬───────┘
+       │
+       ▼
+┌──────────────┐
+│ Update plan  │  ← Reprioritize, add, remove, shuffle
+└──────┬───────┘
+       │
+       └──────────► Next step
+```
+
+After each step, you re-evaluate the plan. Priorities shift. New tasks appear. Others become irrelevant. The plan is alive.
+
+---
+
+## The Agent Tests Its Own Work
+
+The evaluate step isn't just you looking at the screen. The agent actively verifies its own output.
+
+Using **Puppeteer MCP**, the agent opens a browser, navigates to the prototype, and checks the acceptance criteria — while you watch.
+
+```
+┌──────────────┐
+│ Execute step │  ← Agent builds the feature
+└──────┬───────┘
+       │
+       ▼
+┌──────────────┐
+│ Agent opens  │  ← Puppeteer navigates to the page
+│   browser    │
+└──────┬───────┘
+       │
+       ▼
+┌──────────────┐
+│ Agent checks │  ← Reads text, clicks buttons, checks states,
+│  criteria    │     verifies styling, takes screenshots
+└──────┬───────┘
+       │
+       ▼
+┌──────────────┐
+│ Agent reports│  ← "5 of 6 criteria pass. Error color mismatch."
+└──────┬───────┘
+       │
+       ▼
+┌──────────────┐
+│ You decide   │  ← Fix it? Update spec? Move on?
+└──────────────┘
+```
+
+The agent narrates what it finds:
+
+> "Opening signup form at localhost:3000/signup..."
+> "Headline says 'Start in 2 minutes' — matches spec. ✓"
+> "Clicking submit with empty fields..."
+> "Error message: 'Please enter a valid email' — matches spec. ✓"
+> "Error color is #EF4444 — spec says #DC2626. ✗ Mismatch."
+> "Submit button touch target: 48px — meets 44px minimum. ✓"
+
+**The agent handles the measurable criteria.** Does the text match? Is the touch target big enough? Does the error state trigger?
+
+**You handle the qualitative judgment.** Does the flow feel natural? Is the visual hierarchy right? Would a real user understand this?
+
+Together, nothing gets missed. Functional testing happens during development — not after.
+
+---
+
+## Everything Is Logged
+
+Every step is logged. Every action is noted. Every decision is recorded.
+
+This means you can **restart the conversation at any time**. New session? Load the dialog. The agent picks up where you left off.
+
+```
+docs/F-Agent-Dialogs/
+└── 2026-02-10-signup-form/
+    ├── dialog.md           ← Plan, steps, status
+    ├── decisions.md        ← What was decided and why
+    └── changes.md          ← What changed from spec
+```
+
+---
+
+## Who Does What?
+
+Both Freya and Idunn can do agentic development:
+
+| Agent | Activities | When to use |
+|-------|-----------|-------------|
+| **Freya** | [P] Prototyping, [A] Analysis | Design exploration — dream up visuals, components, page layouts. Investigate and understand existing products. |
+| **Idunn** | [D] Development, [F] Bugfixing, [E] Evolution, [R] Reverse Engineering, [T] Acceptance Testing | Implementation — generate working code from specifications. Fix bugs, add features, test against specs. |
+
+The process is the same. The domain differs.
+
+---
+
+## What You'll Learn
+
+### Lesson 1: The Development Agent Dialog
+
+How the process is organized. Creating plans, logging steps, structuring sessions so you can restart at any time.
+
+### Lesson 2: Evaluation and Feedback
+
+After each step: evaluate, reprioritize, shuffle. How to give effective feedback to AI agents and keep the work on track.
+
+### Lesson 3: When You Get Stuck
+
+Sometimes the agent makes change after change and can't find the problem. When to troubleshoot, when to pivot, and when to ask a developer for help.
+
+### Lesson 4: Choosing Your Code Format
+
+Output formats, technology stacks, component libraries, and how to choose between static prototypes and executable code.
+
+### Lesson 5: Git Discipline
+
+Keeping your work safe with version control. When to branch, how to commit, working with your team, and letting the agent handle Git for you.
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Jumping in without a plan | Start with Agent Dialog every time |
+| Not logging steps | Everything gets logged, no exceptions |
+| Keeping a stale plan | Re-evaluate after every step |
+| Fighting the AI for too long | Know when to ask for help |
+| Building everything at once | One step at a time |
+
+---
+
+## Practice
+
+Pick one specification and run the full loop:
+
+1. Create an Agent Dialog with scope, tasks, and test protocol
+2. Execute one step
+3. Evaluate the result
+4. Update the plan
+5. Repeat
+
+---
+
+## Lessons
+
+### [Lesson 1: The Development Agent Dialog](lesson-01-iterative-building.md)
+How the process is organized
+
+### [Lesson 2: Evaluation and Feedback](lesson-02-documenting-decisions.md)
+Staying in control as the agent builds
+
+### [Lesson 3: When You Get Stuck](lesson-03-when-you-get-stuck.md)
+Because AI doesn't always get it right
+
+### [Lesson 4: Choosing Your Code Format](lesson-04-working-with-code.md)
+Understanding what the agent produces and which technology fits your needs
+
+### [Lesson 5: Git Discipline](lesson-05-git-discipline.md)
+Keeping your work safe, organized, and shareable
+
+---
+
+## Tutorial
+
+### [Tutorial 14: Your First Agentic Session](tutorial-14.md)
+Hands-on guide to running a complete agentic development loop
+
+---
+
+## Next Module
+
+**[Module 15: Visual Design →](../module-15-visual-design/module-15-visual-design-overview.md)**
+
+Add soul and visual polish to your prototypes.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-14-agentic-development/tutorial-14.md b/docs/learn/module-14-agentic-development/tutorial-14.md
new file mode 100644
index 000000000..71de386b6
--- /dev/null
+++ b/docs/learn/module-14-agentic-development/tutorial-14.md
@@ -0,0 +1,340 @@
+# Tutorial 14: Your First Agentic Session
+
+**Hands-on guide to running a complete agentic development loop**
+
+---
+
+## Overview
+
+This tutorial walks you through a complete agentic development session — creating an Agent Dialog, building from specification, evaluating results, and handling a stuck moment.
+
+**Time:** 45-60 minutes
+**Prerequisites:** Design system completed (Module 13)
+**Agent:** Idunn (or Freya for design exploration)
+**What you'll create:** Working prototype with documented Agent Dialog
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- A page specification from your project
+- Your design tokens (if applicable)
+- Access to your AI coding assistant
+
+**The agent will help you:**
+
+- Create the Agent Dialog
+- Build step by step
+- Track decisions
+- Handle problems
+
+---
+
+## Step 1: Start the Agent Dialog (5 min)
+
+### Give the agent your specification:
+
+**You say:**
+> "I want to build a working prototype of the signup form from spec P02-signup-form.md. Start by creating an Agent Dialog with scope, tasks, requirements, and test protocol."
+
+### The agent creates the dialog:
+
+```markdown
+# Agent Dialog: Signup Form Prototype
+
+## Meta
+- Date: 2026-02-10
+- Input: P02-signup-form.md
+- Agent: Idunn
+- Status: In Progress
+
+## Scope
+Build the signup form as a working HTML/CSS prototype.
+Includes: form layout, validation states, error states, loading state.
+Excludes: backend integration, actual form submission.
+
+## Tasks
+1. [ ] Create form layout with all fields
+2. [ ] Style with design tokens
+3. [ ] Add validation behavior
+4. [ ] Implement error states
+5. [ ] Add loading state on submit
+6. [ ] Responsive adjustments
+7. [ ] Accessibility check
+
+## Requirements
+- Match specification P02 exactly
+- Inter font, primary #0066FF
+- Mobile-first, max-width 400px
+- WCAG AA contrast compliance
+- All states from spec must be present
+
+## Test Protocol
+- [ ] All text matches spec word-for-word
+- [ ] Form renders correctly on mobile
+- [ ] Tab navigation reaches all fields
+- [ ] Error messages appear on blur
+- [ ] Loading spinner shows on submit
+- [ ] Touch targets 44px minimum
+```
+
+**Review the plan.** Does it cover everything? Adjust before proceeding.
+
+---
+
+## Step 2: Execute First Step (5 min)
+
+### Build the form layout:
+
+**The agent builds:**
+
+```html
+<div class="signup-form">
+  <h1>Start in 2 minutes</h1>
+  <p class="subheadline">No credit card required. Cancel anytime.</p>
+  <form>
+    <div class="form-field">
+      <label for="email">Email</label>
+      <input type="email" id="email" placeholder="you@example.com">
+    </div>
+    <div class="form-field">
+      <label for="password">Password</label>
+      <input type="password" id="password">
+      <span class="helper">At least 8 characters</span>
+    </div>
+    <button type="submit">Create Free Account</button>
+  </form>
+  <p class="terms">By continuing, you agree to our Terms and Privacy Policy</p>
+  <p class="login-link">Already have an account? Log in</p>
+</div>
+```
+
+### The agent logs the step:
+
+```markdown
+## Log
+
+### Step 1: Form layout (completed)
+- Created semantic HTML form structure
+- All elements from spec present
+- Decision: Used form-field wrapper for consistent spacing
+```
+
+---
+
+## Step 3: Evaluate and Give Feedback (5 min)
+
+### Compare to spec:
+
+**Check each element:**
+
+| Element | Spec | Output | Status |
+|---------|------|--------|--------|
+| Headline | "Start in 2 minutes" | Match | Pass |
+| Subheadline | "No credit card..." | Match | Pass |
+| Email field | With placeholder | Present | Pass |
+| Password field | With helper text | Present | Pass |
+| Submit button | "Create Free Account" | Match | Pass |
+| Terms text | Present | Present | Pass |
+| Login link | Present | Present | Pass |
+
+### Give feedback:
+
+> "Layout looks correct. All elements match spec. One issue: the password field is missing the show/hide toggle from the spec. Add that before moving to step 2."
+
+### Agent fixes and updates log:
+
+```markdown
+### Step 1: Form layout (completed, revised)
+- Added password show/hide toggle
+- All elements from spec now present
+```
+
+---
+
+## Step 4: Continue Building (15 min)
+
+### Execute steps 2-5:
+
+Work through each step in the plan:
+
+**Step 2: Styling**
+> "Apply the design tokens. Primary #0066FF, Inter font, 16px base, 8px spacing scale."
+
+**Evaluate:** Does it match the visual direction? Adjust tokens if needed.
+
+**Step 3: Validation**
+> "Add blur-based validation. Email: check format. Password: check 8+ characters."
+
+**Evaluate:** Does validation trigger correctly? Are messages clear?
+
+**Step 4: Error states**
+> "Add error states per spec: red border, error message below field."
+
+**Evaluate:** Do errors show and clear correctly?
+
+**Step 5: Loading**
+> "Add loading spinner on submit. Disable button and fields during load."
+
+**Evaluate:** Is the loading state clear? Can the user still interact with anything they shouldn't?
+
+---
+
+## Step 5: Handle a Stuck Moment (5 min)
+
+### A common issue:
+
+The loading spinner shows, but the button text doesn't change. You ask the agent to fix it. It changes the button text but now the spinner disappears.
+
+**Recognize the loop.** You've gone back and forth twice.
+
+### Apply the strategy:
+
+> "Let's approach this differently. I want both: the spinner AND the text 'Creating account...' inside the button. Here's the exact HTML I want:
+>
+> ```html
+> <button disabled>
+>   <span class="spinner"></span>
+>   Creating account...
+> </button>
+> ```
+>
+> Make the spinner 16px, inline with the text, with 8px gap."
+
+**Concrete example breaks the loop.**
+
+---
+
+## Step 6: Update the Plan (3 min)
+
+### Review and adjust:
+
+After building, your plan has evolved:
+
+```markdown
+## Tasks
+1. [x] Create form layout with all fields
+2. [x] Style with design tokens
+3. [x] Add validation behavior
+4. [x] Implement error states
+5. [x] Add loading state on submit
+6. [ ] Fix password toggle animation       ← ADDED (toggle feels sluggish)
+7. [ ] Responsive adjustments
+8. [ ] Accessibility check
+```
+
+New task emerged from building. That's normal.
+
+---
+
+## Step 7: Run the Test Protocol (5 min)
+
+### Verify everything:
+
+Go through the test protocol from the Agent Dialog:
+
+```markdown
+## Test Protocol
+- [x] All text matches spec word-for-word
+- [x] Form renders correctly on mobile
+- [x] Tab navigation reaches all fields
+- [x] Error messages appear on blur
+- [x] Loading spinner shows on submit
+- [ ] Touch targets 44px minimum          ← ISSUE: Submit button is 40px
+```
+
+### Fix the issue:
+
+> "Submit button touch target is 40px, needs to be 44px. Increase padding."
+
+### Update log:
+
+```markdown
+### Test Protocol Check
+- All pass except touch target on submit button
+- Fixed: increased button padding from 12px to 14px (48px total height)
+- All tests pass
+```
+
+---
+
+## Step 8: Finalize the Dialog (5 min)
+
+### Complete the Agent Dialog:
+
+```markdown
+## Meta
+- Date: 2026-02-10
+- Input: P02-signup-form.md
+- Agent: Idunn
+- Status: Complete
+
+## Summary
+Built working signup form prototype matching specification.
+7 steps completed, 1 task added during development.
+1 stuck moment resolved with concrete HTML example.
+1 test failure fixed (touch target sizing).
+All tests passing.
+```
+
+### Save the dialog:
+
+```
+docs/F-Agent-Dialogs/
+└── 2026-02-10-signup-form/
+    └── dialog.md
+```
+
+---
+
+## What You've Created
+
+- **Working prototype** matching your specification
+- **Complete Agent Dialog** with plan, log, decisions, and test results
+- **Reusable context** for future sessions or handoff
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Always start with an Agent Dialog
+- Evaluate after every step
+- Give specific, numbered feedback
+- Update the plan as you learn
+- Log everything
+
+**DON'T:**
+
+- Jump in without a plan
+- Let the agent build everything before reviewing
+- Give vague feedback ("make it better")
+- Fight the same issue more than 3 times
+- Skip the test protocol
+
+---
+
+## You've Completed Module 14!
+
+**You can now run agentic development sessions.** You know how to:
+- Structure work with Agent Dialogs
+- Evaluate and give effective feedback
+- Handle stuck moments
+- Keep plans alive and updated
+
+---
+
+## Next Module
+
+**[Module 15: Visual Design →](../module-15-visual-design/module-15-visual-design-overview.md)**
+
+Add soul and visual polish to your prototypes.
+
+---
+
+[← Back to Lesson 5](lesson-05-git-discipline.md) | [Back to Module Overview](module-14-agentic-development-overview.md)
+
+*Part of Module 14: Agentic Development*
diff --git a/docs/learn/module-15-visual-design/lesson-01-making-it-visible.md b/docs/learn/module-15-visual-design/lesson-01-making-it-visible.md
new file mode 100644
index 000000000..b6b41177d
--- /dev/null
+++ b/docs/learn/module-15-visual-design/lesson-01-making-it-visible.md
@@ -0,0 +1,216 @@
+# Module 15: Visual Design
+
+## Lesson 1: Making It Visible
+
+**From specification to visual reality**
+
+---
+
+## The Transition
+
+You have specifications. Complete, detailed, unambiguous.
+
+But they're not visible yet.
+
+This is where specifications become something you can see, click, and experience.
+
+---
+
+## Why This Matters
+
+### For You
+
+You can validate your specifications visually. Does it actually look right? Does the hierarchy work? Does it feel good?
+
+### For Stakeholders
+
+They can see what's being built. Visual prototypes are easier to review than documents.
+
+### For Developers
+
+Visual references reduce ambiguity. Code follows the visual more precisely.
+
+### For Users
+
+You can test with real people. Visuals enable usability testing before development.
+
+---
+
+## The Visual Design Loop
+
+```
+Spec → Generate → Review → Refine → Generate → Approve
+```
+
+It's iterative. Your first visual is rarely final.
+
+1. **Spec** — Start with your complete specification
+2. **Generate** — Create a visual version
+3. **Review** — Compare to specification
+4. **Refine** — Adjust based on feedback
+5. **Generate** — Create improved version
+6. **Approve** — Lock in the final visual
+
+---
+
+## What You're Designing
+
+For each page:
+
+### Layout
+
+Where elements are positioned. The spatial organization.
+
+### Visual Hierarchy
+
+What draws attention first, second, third. The flow of importance.
+
+### Typography
+
+Font choices, sizes, weights. The text treatment.
+
+### Colors
+
+From your palette or brand guidelines. The emotional impact.
+
+### Spacing
+
+Rhythm and breathing room. The visual cadence.
+
+### States
+
+Hover, active, error — all the behavioral states visualized.
+
+---
+
+## Design Tokens
+
+If you're in Design System Mode 2-4, you're working with tokens:
+
+```yaml
+colors:
+  primary: "#0066FF"
+  primary-hover: "#0052CC"
+  secondary: "#6B7280"
+  error: "#DC2626"
+  success: "#16A34A"
+
+typography:
+  heading-1: "Inter, 32px, 700"
+  heading-2: "Inter, 24px, 600"
+  body: "Inter, 16px, 400"
+  small: "Inter, 14px, 400"
+
+spacing:
+  xs: "4px"
+  sm: "8px"
+  md: "16px"
+  lg: "24px"
+  xl: "32px"
+```
+
+Tokens ensure consistency. Every blue button uses the same blue.
+
+---
+
+## Tools for Visual Design
+
+### AI Generation (Stitch, html.to.design)
+
+Give your specification to AI. It generates HTML/CSS.
+
+```
+"Generate a signup form based on this spec. Use Inter font,
+primary color #0066FF, 16px base font size."
+```
+
+Output: Working prototype in minutes.
+
+### Figma
+
+Refine AI output. Polish the details.
+
+- Import from generated HTML
+- Adjust spacing, colors, typography
+- Create component variants
+- Export assets for development
+
+### Browser Preview
+
+View your prototypes live. Click through. Test on devices.
+
+---
+
+## Entry Points
+
+Multiple ways to start visual design:
+
+| Starting Point | Approach |
+|----------------|----------|
+| Specification only | Generate with AI |
+| Rough sketch | AI refines into visual |
+| Inspiration image | AI extracts and applies style |
+| Existing brand | Apply tokens to generated output |
+
+You don't have to start from scratch. Build on what you have.
+
+---
+
+## The Match Test
+
+Your visual must match your specification exactly.
+
+If there's a difference:
+- Update the specification to match the visual, OR
+- Update the visual to match the specification
+
+**Never leave mismatches.** They create ambiguity.
+
+---
+
+## Design All States
+
+Don't just design the happy path:
+
+- **Default** — Initial state
+- **Loading** — While data loads
+- **Empty** — When no content exists
+- **Error** — When something fails
+- **Success** — When action completes
+- **Disabled** — When interaction is blocked
+- **Hover/Active** — Interactive feedback
+
+Each state needs a visual representation.
+
+---
+
+## Responsive Considerations
+
+Design for your primary platform first.
+
+**If mobile-first:**
+- Start with mobile layout
+- Elements stack vertically
+- Touch targets 44px minimum
+- Then adapt for tablet/desktop
+
+**If desktop-first:**
+- Start with desktop layout
+- Multiple columns allowed
+- Then simplify for smaller screens
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn specific techniques for generating and refining visuals — working with AI tools and maintaining consistency.
+
+---
+
+**[Continue to Lesson 2: Visual Design Techniques →](lesson-02-visual-techniques.md)**
+
+---
+
+[← Back to Module Overview](module-15-visual-design-overview.md)
+
+*Part of Module 15: Visual Design*
diff --git a/docs/learn/module-15-visual-design/lesson-02-visual-techniques.md b/docs/learn/module-15-visual-design/lesson-02-visual-techniques.md
new file mode 100644
index 000000000..cb66cb443
--- /dev/null
+++ b/docs/learn/module-15-visual-design/lesson-02-visual-techniques.md
@@ -0,0 +1,334 @@
+# Module 15: Visual Design
+
+## Lesson 2: Visual Design Techniques
+
+**Practical methods for generating and refining visuals**
+
+---
+
+## Three Methods
+
+In WDS, visual design happens through three categories of tools. You'll likely use a combination depending on the task.
+
+### 1. Figma — Precision Design
+
+Figma is where you go for pixel-level control. In WDS, you don't live in Figma — but you visit it when the agent can't get the details right.
+
+**How you get code into Figma:**
+
+**code.to.design** — a plugin that imports your HTML prototypes directly into Figma as editable layers. Your working prototype becomes a Figma file you can manipulate with all the precision Figma offers. When you're done, export back to code.
+
+**How Figma talks to your agent:**
+
+**Figma MCP** — connects your AI coding agent directly to Figma. The agent can read your Figma designs, extract styles, colors, spacing, and typography, and apply them to code — without you manually exporting or copying values.
+
+**Best for:**
+- Fine-tuning visual details the agent can't get right
+- Establishing the visual language for a project
+- Working with brand elements that need a designer's eye
+- Exploring visual directions before committing to code
+- Handing off precise specifications to developers
+
+---
+
+### 2. Image Generators — Visual Assets and Inspiration
+
+AI image generation creates visual assets — hero photos, card images, persona illustrations, mood boards — that feed into your designs. These aren't working code or editable layouts. They're image assets.
+
+**Nanobanana MCP (Gemini 2.5 Flash / Gemini 3 Pro)** — generates images directly from your AI coding agent and saves them to your repository. We've tested this extensively and learned what it does well and what it doesn't.
+
+**What NB does well:**
+- **Image assets** — Hero photos, card images, seasonal photos, persona illustrations
+- **Mood visualization** — Captures atmosphere and visual direction
+- **Style transfer** — Reference images influence the generated style
+- **Quick exploration** — Fast to generate multiple visual directions
+
+**What NB does NOT do well (critical limitations):**
+- **All text is garbled** — AI-rendered text is never readable. Never trust it.
+- **Logos cannot be reproduced** — Generates "inspired by" versions, not the real logo
+- **Cannot edit results** — If something is wrong, you regenerate entirely. You cannot move, resize, or adjust elements.
+- **Wireframe labels leak into mockups** — Annotation text bleeds through in edit mode
+- **2x2 grids flatten** — Multi-row layouts are a consistent weak point
+- **Broad edits cause section loss** — Unfocused instructions drop entire sections
+
+**NB is an asset production tool, not a design tool.** The images are excellent as placeholders and visual references, but you cannot iterate on them the way you can with code or Figma. For wireframing, use Excalidraw. For production mockups, use Stitch or code generation.
+
+**Best for:**
+- Hero photos, card images, seasonal visuals, background images
+- Persona illustrations for Trigger Map documents
+- Mood boards and visual direction exploration
+- Placeholder imagery during prototyping
+
+For detailed guidance on AI wireframe generation (and why we recommend against it for iterative design), see [Module 09, Lesson 6: AI Wireframe Generation](../module-09-conceptual-sketching/lesson-06-ai-wireframe-generation.md).
+
+---
+
+### 3. UI Generators — Working Interfaces from Prompts
+
+UI generators produce working interfaces — real HTML/CSS/React that you can interact with in the browser. This is the core WDS workflow.
+
+**AI code generation (Claude, GPT, etc.)** — the agent generates working code directly from your specifications. You give it a spec, it builds a prototype. You click buttons, fill in forms, see hover states. This is real code, not a picture.
+
+```
+You: "Build the signup form from spec P02. Use our design tokens.
+      Primary #0066FF, Inter font, 8px spacing scale."
+
+Agent: Creates working HTML/CSS with all elements,
+       states, and interactions from the spec.
+
+You: Open in browser. Review. Give feedback.
+```
+
+**Google Stitch** — Google's AI UI design tool that generates real HTML/CSS code from text prompts or wireframe images. Available as an API with MCP server integration. Produces production-quality layouts with readable text, proper structure, and Figma export. 350 standard + 50 experimental generations per month.
+
+**Best for:**
+- Building working prototypes from specifications
+- Iterating on layout, structure, and behavior
+- Creating the production foundation
+- Testing interactions and responsive behavior
+
+---
+
+## This Is Evolving
+
+We are actively exploring these techniques as tools and capabilities develop rapidly. New image generation models, UI-specific generators, and Figma integrations appear regularly.
+
+**What we've tested:**
+- **Nanobanana MCP** for image generation — excellent for image assets (hero photos, card images, persona illustrations). Not suitable for wireframes or mockups due to garbled text, non-editable output, and layout limitations. See [Module 09, Lesson 6](../module-09-conceptual-sketching/lesson-06-ai-wireframe-generation.md) for detailed findings.
+- **code.to.design** for Figma round-trips — established workflow
+- **Figma MCP** for reading designs into code — works
+- **AI code generation** (Claude, GPT) for UI building — core WDS workflow
+- **Google Stitch** for UI generation — API and MCP available, generates real HTML/CSS
+
+**Recommended tool roles (as of February 2026):**
+
+| Tool | Role | Why |
+|------|------|-----|
+| **Excalidraw** | Wireframes | Editable, fast iteration, user can drag and resize |
+| **Nano Banana** | Image assets | Hero photos, card images, illustrations, mood visuals |
+| **Google Stitch** | Production mockups | Real HTML/CSS output, readable text, Figma export |
+| **Figma** | Final polish | Pixel-level refinement, design system management |
+| **AI code gen** | Prototypes | Working interactive prototypes from specs |
+
+**Share your experience:** If you discover techniques that work well, or tools we haven't covered, share them in the Discord forum **#UX-design-channel**. This course evolves based on what the community learns together.
+
+---
+
+## Prompting for Visual Output
+
+Whether you're generating code, images, or Figma designs, the quality of your output depends on the quality of your input.
+
+### Prompt Structure for Code Generation
+
+```
+Generate [element type] based on this specification:
+
+[Paste your specification]
+
+Visual requirements:
+- Font: [font family]
+- Primary color: [hex code]
+- Background: [color/style]
+- Size: [dimensions or responsive]
+
+Focus on: [what's most important]
+```
+
+### Example
+
+```
+Generate a signup form based on this specification:
+
+## Signup Form
+- Email field (required, validates email format)
+- Password field (required, 8+ chars, show/hide toggle)
+- Submit button: "Create Free Account"
+- Terms link below
+- Login link for existing users
+
+Visual requirements:
+- Font: Inter
+- Primary color: #0066FF
+- Background: White with subtle gray (#F9FAFB)
+- Size: Mobile-first (max-width 400px)
+
+Focus on: Clean, minimal, low friction
+```
+
+### Prompt Tips for Image Generation
+
+When generating visual concepts or mood boards:
+
+- Describe the feeling, not just the elements ("warm, inviting, professional" not just "signup form")
+- Reference styles ("in the style of Stripe's marketing pages")
+- Specify what you'll use the image for ("mood board for the onboarding flow")
+- Include constraints ("mobile-first, accessible, brand colors #0066FF and #1A1A2E")
+
+---
+
+## Refining Generated Output
+
+AI output is a starting point, not a final product. Regardless of which method you used, here's what to check and refine.
+
+### Spacing
+
+- AI often under- or over-spaces
+- Adjust for visual rhythm
+- Ensure breathing room around elements
+
+### Typography
+
+- Check font weights
+- Verify line heights
+- Adjust size hierarchy
+
+### Colors
+
+- Verify contrast ratios
+- Check hover states
+- Ensure consistency with tokens
+
+### Touch Targets
+
+- Buttons 44px minimum
+- Adequate spacing between tap targets
+- Test on actual devices
+
+---
+
+## Designing States
+
+Each interactive element needs its states designed:
+
+### Default
+
+The initial appearance. What users see on load.
+
+### Hover
+
+Feedback on mouseover:
+- Slight color change (10% darker)
+- Subtle shadow or elevation
+- Cursor change
+
+### Active/Pressed
+
+Feedback on click:
+- Darker than hover
+- Slight scale down (98%)
+- Pressed appearance
+
+### Focus
+
+For keyboard navigation — must be visible:
+- Outline (2px solid)
+- Offset from element
+- Sufficient contrast
+
+### Disabled
+
+When interaction is blocked:
+- Reduced opacity (50-60%)
+- No hover effects
+- Cursor: not-allowed
+
+### Loading
+
+During async operations:
+- Spinner or skeleton
+- Reduced interactivity
+- Progress indication
+
+### Error
+
+When something fails:
+- Error color (usually red)
+- Clear message
+- Recovery path visible
+
+---
+
+## Accessibility in Visual Design
+
+### Color Contrast
+
+- Text on background: 4.5:1 minimum (WCAG AA)
+- Large text (18px+): 3:1 minimum
+- UI components: 3:1 minimum
+
+**Tools:** Contrast checkers in Figma, browser extensions
+
+### Focus Visibility
+
+- Focus rings must be visible
+- 3:1 contrast against background
+- Don't hide on mouse use
+
+### Touch Targets
+
+- Minimum 44x44px for touch
+- 24x24px for precise mouse input
+- Adequate spacing between targets
+
+---
+
+## Consistency Patterns
+
+### Token Application
+
+Apply tokens consistently:
+
+```css
+/* All primary buttons use same color */
+.btn-primary {
+  background: var(--color-primary);
+  color: var(--color-text-on-primary);
+}
+
+/* All headings use same scale */
+h1 { font: var(--type-heading-1); }
+h2 { font: var(--type-heading-2); }
+
+/* All spacing uses same scale */
+.card { padding: var(--space-lg); }
+.stack > * + * { margin-top: var(--space-md); }
+```
+
+### Component Reuse
+
+Same component, same styling:
+- Buttons look identical across pages
+- Inputs behave the same everywhere
+- Cards have consistent structure
+
+---
+
+## Visual Design Checklist
+
+For each page:
+
+- [ ] Layout matches specification
+- [ ] Visual hierarchy correct (primary element dominates)
+- [ ] Typography applied from tokens
+- [ ] Colors from palette/brand
+- [ ] Spacing consistent (uses token scale)
+- [ ] All states designed (default, hover, loading, error, etc.)
+- [ ] Contrast ratios pass WCAG
+- [ ] Touch targets adequate
+- [ ] Responsive behavior defined
+
+---
+
+## What's Next
+
+In the tutorial, you'll generate and refine visuals for your own specifications, working through the design loop until you have polished, validated prototypes.
+
+---
+
+**[Continue to Tutorial: Create Your Visuals →](tutorial-15.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-making-it-visible.md) | [Back to Module Overview](module-15-visual-design-overview.md)
+
+*Part of Module 15: Visual Design*
diff --git a/docs/learn/module-15-visual-design/module-15-visual-design-overview.md b/docs/learn/module-15-visual-design/module-15-visual-design-overview.md
new file mode 100644
index 000000000..640744a16
--- /dev/null
+++ b/docs/learn/module-15-visual-design/module-15-visual-design-overview.md
@@ -0,0 +1,338 @@
+# Module 15: Visual Design
+
+**Time: 60 min | Agent: Freya | Phase: Design | Focus: Visual**
+
+---
+
+## The Big Shift
+
+In WDS, visual design lives in the codebase.
+
+There is no ambitious Figma structure or Photoshop file to maintain. WDS is specifications and code centric. Your design artifacts are working prototypes, not static mockups.
+
+This doesn't mean you never open Figma. It means Figma is a tool you reach for when you need it — not where your design lives.
+
+---
+
+## Designing with Soul
+
+LLMs are remarkably good at generating functional, clean, well-structured interfaces. They are remarkably weak at creative, visionary, and emotionally resonant design.
+
+An AI agent can build a signup form that follows every best practice. But it won't dream up the visual language that makes your product feel like *yours*. It won't make the bold typographic choice, the unexpected color palette, the playful micro-interaction that gives a product its soul.
+
+**As of February 2026, we recommend having a visual designer set the visual language as you develop the product.** This doesn't mean you need a designer on every screen. It means someone with a design eye should establish:
+
+- The overall aesthetic direction
+- Brand expression in the UI
+- Typographic personality
+- Color relationships beyond "primary, secondary, error"
+- The small details that make good design feel great
+
+Once the visual language is set, the agent can apply it consistently. But the language itself needs a human author.
+
+---
+
+## Visual Design Is Not a Step — It's a Layer
+
+In traditional workflows, visual design is a phase you reach after wireframing. In WDS, visual design can enter the project at any point where it adds value.
+
+Here is the full WDS process. At each step, you can choose to introduce visual design — or not.
+
+```
+  WDS Process                        Visual Design Can Enter As...
+  ───────────                        ────────────────────────────
+
+  Project Setup ──────────────────── Brand references, mood boards,
+       │                             design system inspiration,
+       │                             existing visual identity
+       ▼
+  Outline Scenarios
+       │
+       ▼
+  Conceptual Sketching ──────────── Visual concepts instead of
+       │                             wireframe-level sketches,
+       │                             AI-generated inspiration
+       ▼
+  Storyboarding ─────────────────── Designed visualizations with
+       │                             visual fidelity from the start,
+       │                             styled storyboard frames
+       ▼
+  Specifications ────────────────── Visual references and inspiration
+       │                             images embedded directly in specs,
+       │                             color and typography decisions
+       ▼
+  Components + Design System ────── Component-level visual design,
+       │                             design tokens, patterns,
+       │                             branded component library
+       ▼
+  Prototyping ───────────────────── Visual polish applied directly
+       │                             to working code, styled
+       │                             prototypes from the start
+       ▼
+  ★ Visual Design Phase ★ ──────── Prototypes opened in Figma or
+       │                             refined with design tools,
+       │                             soul added to working code,
+       │                             final visual refinement
+       ▼
+  Delivery
+```
+
+The more visual design you introduce early, the less you need to do in this phase. Some projects arrive here with prototypes that already look finished. Others arrive with functional wireframes that need a full visual pass. Both are valid.
+
+---
+
+## How Visual Design Works at Each Step
+
+### At project setup
+
+You establish the visual direction before any design work begins. Mood boards, brand guidelines, reference sites, inspiration collections. These inform every decision downstream.
+
+> "Here's our brand. Here's the feeling we want. Here are three sites that nail the aesthetic."
+
+### At conceptual sketching
+
+Instead of rough wireframes, you create visual concepts. AI can generate styled layouts from a description. You use these to explore direction — not as final designs, but as visual thinking.
+
+> "Generate three visual directions for the landing page based on this brief."
+
+### At storyboarding
+
+Your storyboard frames can carry visual fidelity. Instead of gray boxes, the frames show colors, typography, and imagery. This helps stakeholders react to the experience, not just the structure.
+
+### At specifications
+
+You embed visual references directly in your specs. A color note here, a typography decision there, an inspiration screenshot attached. The spec carries visual intent alongside functional requirements.
+
+### At component + design system level
+
+Your design tokens (colors, fonts, spacing) are defined. Your component library carries the visual identity. Everything built from this point inherits the design automatically.
+
+### At prototyping
+
+When the agent builds a prototype using your design system, it already looks designed. You review and refine — adjusting what the agent didn't get right, adding details that need a human eye.
+
+### At the visual design phase (this module)
+
+This is the dedicated pass where you ensure everything has the right soul. Open prototypes in Figma, refine details the agent missed, adjust visual hierarchy, add polish. Then bring it back to code.
+
+---
+
+## Your Level of Control
+
+**You maintain 100% control over the final design.**
+
+AI generates. You direct. The degree to which you intervene is up to you:
+
+| Comfort Level | Approach |
+|---------------|----------|
+| Full control | Generate → Open in Figma → Refine every detail → Export back to code |
+| Collaborative | Generate → Adjust in code → Open specific elements in Figma → Return to code |
+| AI-forward | Generate → Review → Refine with AI prompts → Final polish in code |
+
+There is no wrong approach. Use whatever gives you confidence in the result.
+
+---
+
+## Tools
+
+### AI Code Generation
+
+The agent generates HTML/CSS from your specifications. You review the output in your browser and refine through the Agent Dialog process (Module 14).
+
+### Figma
+
+Reach for Figma when you need to:
+
+- Add soul that AI didn't capture
+- Fine-tune visual details pixel by pixel
+- Work with brand elements that need a designer's eye
+- Explore visual directions before committing to code
+
+You interact with Figma through two tools:
+
+**code.to.design** — imports your HTML prototypes directly into Figma as editable layers. Refine in Figma, then export back to code. Round-trip as many times as you need.
+
+**Figma MCP** — connects your AI coding agent directly to Figma. The agent can read your Figma designs, extract styles, and apply them to code — without you manually exporting or copying values.
+
+### AI Visual Tools — What We've Learned
+
+Different AI tools serve different purposes in visual design. Here's what works based on real project testing:
+
+| Tool | Best For | Limitation |
+|------|----------|------------|
+| **Excalidraw** | Wireframes, layout iteration | Manual, no AI generation |
+| **Nano Banana** | Image assets (hero photos, card images, personas) | Cannot render text, output is non-editable |
+| **Google Stitch** | Production HTML/CSS mockups | Requires Google Cloud setup |
+| **Figma** | Final visual polish, pixel-level refinement | Manual, slower |
+| **AI code gen** | Interactive prototypes | May need visual refinement |
+
+**Nano Banana is an asset production tool, not a design tool.** It generates excellent placeholder images but cannot produce wireframes or mockups suitable for iterative design. All text is garbled, output cannot be edited. For the full analysis, see [Module 09, Lesson 6: AI Wireframe Generation](../module-09-conceptual-sketching/lesson-06-ai-wireframe-generation.md).
+
+**Recommended workflow for page design:**
+1. **Excalidraw** — Sketch and iterate on layout (editable, user controls)
+2. **Nano Banana** — Generate image assets (hero photos, card images, seasonal visuals)
+3. **Stitch or code gen** — Generate production HTML/CSS from approved wireframe
+
+### AI Asset Generation (Phase 6 Pipeline)
+
+WDS Phase 6 provides a full **creative production pipeline** for generating visual assets with AI:
+
+```
+[W] Wireframes       — Structural layouts from page specs
+[P] Page Designs     — Full page compositions
+[U] UI Elements      — Buttons, cards, forms, components
+[I] Icons            — Icon sets matching your design system
+[M] Images           — Photos, illustrations, backgrounds
+[V] Videos           — Motion content and animations
+[C] Content          — Strategic text (5-model framework)
+[E] Export to Figma  — Push assets to Figma
+```
+
+Each activity uses **style libraries** — predefined design styles (minimal, corporate, brutalist, organic, playful, editorial) and content styles (photorealistic, illustration, watercolor, isometric, flat design, etc.) with prompt keywords for consistent AI generation.
+
+**Batch mode** generates all assets of a type in one session, using earlier results as reference images for visual consistency across the set.
+
+---
+
+## The Freya Method
+
+Freya connects visuals to strategy:
+
+> "This visual is beautiful, but does it match Felix's need for simplicity?"
+> "The color contrast here might cause accessibility issues."
+> "Your spec says primary CTA — but visually the secondary button draws more attention."
+
+She keeps visuals aligned with intent — whether you're working in code or Figma.
+
+---
+
+## What to Design
+
+### For Each Page
+
+1. **Layout** — Position of elements
+2. **Visual hierarchy** — What draws attention first
+3. **Typography** — Font choices, sizes, weights
+4. **Colors** — From your palette or brand
+5. **Spacing** — Rhythm and breathing room
+6. **States** — Hover, active, error, etc.
+
+### Don't Forget
+
+- Empty states
+- Loading states
+- Error states
+- Mobile responsive (if applicable)
+
+---
+
+## Design Tokens
+
+If using Design System (Modes 2-4), extract tokens:
+
+```yaml
+colors:
+  primary: "#0066FF"
+  secondary: "#6B7280"
+  error: "#DC2626"
+
+typography:
+  heading: "Inter, 24px, 700"
+  body: "Inter, 16px, 400"
+
+spacing:
+  sm: "8px"
+  md: "16px"
+  lg: "24px"
+```
+
+Tokens ensure consistency across all visuals — in code and in Figma.
+
+---
+
+## Output
+
+Visual prototypes for each page, living in the codebase:
+
+```
+C-UX-Scenarios/
+└── S01-User-Registration/
+    ├── scenario-overview.md
+    ├── P01-signup-form.md
+    ├── P01-signup-form.html    ← Visual prototype
+    └── P02-welcome-screen.md
+```
+
+---
+
+## What You'll Learn
+
+### Lesson 1: Making It Visible
+
+From specification to visual reality. The visual design loop — generate, review, refine. Working with design tokens, applying visual direction to prototypes, and choosing when to work in code versus Figma.
+
+### Lesson 2: Visual Design Techniques
+
+Three methods for creating visual output: Figma round-trips with code.to.design, AI image generation for concepts and inspiration, and AI UI generation for styled prototypes. How to prompt for visual output, refine generated results, design all states, and maintain consistency.
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Design before spec | Spec first, always |
+| Living in Figma | Code is home, Figma is a visit |
+| Ignoring states | Design all states |
+| Inconsistent styling | Use design tokens |
+| Forgetting accessibility | Check contrast, sizes |
+| Over-designing | Keep it simple |
+
+---
+
+## The Test
+
+Does your visual match your specification exactly?
+
+If there's a difference, update either the spec or the visual. Never leave mismatches.
+
+---
+
+## Practice
+
+Take one specification from Module 11:
+
+1. Generate visual prototype with AI
+2. Review against spec
+3. Refine — in code or via Figma round-trip
+4. Verify all states are designed
+5. Confirm: does it match the spec?
+
+---
+
+## Lessons
+
+### [Lesson 1: Making It Visible](lesson-01-making-it-visible.md)
+From specification to visual reality
+
+### [Lesson 2: Visual Design Techniques](lesson-02-visual-techniques.md)
+Practical methods for generating and refining visuals
+
+---
+
+## Tutorial
+
+### [Tutorial 15: Create Your Visuals](tutorial-15.md)
+Hands-on guide to generating and refining visual designs
+
+---
+
+## Next Module
+
+**[Module 16: Design Delivery →](../module-16-design-delivery/module-16-design-delivery-overview.md)**
+
+Package and deliver your design.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-15-visual-design/tutorial-15.md b/docs/learn/module-15-visual-design/tutorial-15.md
new file mode 100644
index 000000000..9deefa788
--- /dev/null
+++ b/docs/learn/module-15-visual-design/tutorial-15.md
@@ -0,0 +1,377 @@
+# Tutorial 15: Create Your Visuals
+
+**Hands-on guide to generating and refining visual designs**
+
+---
+
+## Overview
+
+This tutorial walks you through generating visual prototypes from your specifications.
+
+**Time:** 40-50 minutes
+**Prerequisites:** Working prototypes (Module 14), Components documented (Module 12)
+**Agent:** Freya
+**What you'll create:** Visual prototypes for your key pages
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- Your page specifications
+- Your component documentation
+- Design tokens (if using Design System Mode 2-4)
+- Access to Figma or browser preview
+
+**Freya will help you:**
+
+- Generate initial visuals
+- Review against specifications
+- Identify refinements needed
+- Ensure accessibility compliance
+
+---
+
+## Step 1: Choose Your First Page (2 min)
+
+### Start with a key page:
+
+**You say:**
+> "Let's create visuals for the signup form (P02) from S01-User-Registration. Here's my specification."
+
+**Share your specification with Freya.**
+
+**Freya acknowledges:**
+> "I have your signup form specification. Let's generate a visual prototype and refine it."
+
+---
+
+## Step 2: Define Visual Requirements (3 min)
+
+### Establish design tokens:
+
+**Freya asks:**
+> "What are your visual requirements? Font family, primary color, and base sizing?"
+
+**You respond:**
+> "Inter font, primary color #0066FF, 16px base, white background with light gray accents (#F9FAFB)."
+
+**Freya notes:**
+```
+Visual tokens:
+- Font: Inter
+- Primary: #0066FF
+- Background: #FFFFFF
+- Accent/muted: #F9FAFB
+- Text: #111827
+- Error: #DC2626
+- Base size: 16px
+- Spacing scale: 8px increments
+```
+
+---
+
+## Step 3: Generate Initial Visual (5 min)
+
+### Freya generates prototype:
+
+> "Generating signup form prototype based on your specification..."
+
+**Freya produces:**
+```html
+<!-- Signup Form Prototype -->
+<div style="max-width: 400px; margin: 0 auto; padding: 24px; font-family: Inter, sans-serif;">
+  <h1 style="font-size: 24px; font-weight: 600; margin-bottom: 8px;">
+    Start in 2 minutes
+  </h1>
+  <p style="color: #6B7280; margin-bottom: 24px;">
+    No credit card required. Cancel anytime.
+  </p>
+
+  <form>
+    <div style="margin-bottom: 16px;">
+      <label style="display: block; margin-bottom: 4px;">Email</label>
+      <input type="email" placeholder="you@example.com"
+             style="width: 100%; padding: 12px; border: 1px solid #D1D5DB; border-radius: 6px;">
+    </div>
+
+    <div style="margin-bottom: 24px;">
+      <label style="display: block; margin-bottom: 4px;">Password</label>
+      <input type="password"
+             style="width: 100%; padding: 12px; border: 1px solid #D1D5DB; border-radius: 6px;">
+      <span style="color: #6B7280; font-size: 14px;">At least 8 characters</span>
+    </div>
+
+    <button style="width: 100%; padding: 14px; background: #0066FF; color: white; border: none; border-radius: 6px; font-size: 16px; font-weight: 500; cursor: pointer;">
+      Create Free Account
+    </button>
+  </form>
+
+  <p style="margin-top: 16px; font-size: 14px; color: #6B7280; text-align: center;">
+    By continuing, you agree to our <a href="#">Terms</a> and <a href="#">Privacy Policy</a>
+  </p>
+
+  <p style="margin-top: 24px; text-align: center;">
+    Already have an account? <a href="#">Log in</a>
+  </p>
+</div>
+```
+
+> "Preview this in your browser and let me know what needs adjustment."
+
+---
+
+## Step 4: Review Against Specification (5 min)
+
+### Compare visual to spec:
+
+**Freya:**
+> "Let's verify the visual matches your specification. Checking each element..."
+
+**Checklist:**
+
+| Element | Spec | Visual | Status |
+|---------|------|--------|--------|
+| Headline | "Start in 2 minutes" | ✓ | Match |
+| Subheadline | "No credit card required" | ✓ | Match |
+| Email field | Required, placeholder | ✓ | Match |
+| Password field | 8+ chars, helper text | ✓ | Match |
+| Submit button | "Create Free Account" | ✓ | Match |
+| Terms link | Present | ✓ | Match |
+| Login link | Present | ✓ | Match |
+
+### Identify gaps:
+
+**Freya:**
+> "I notice a few things:
+> 1. Password show/hide toggle is missing from the visual
+> 2. Strength indicator not shown
+> 3. Error states not visualized yet
+>
+> Should we add these?"
+
+**You respond:**
+> "Yes, add the show/hide toggle. Skip strength indicator for MVP. We need error states too."
+
+---
+
+## Step 5: Refine the Visual (10 min)
+
+### Add missing elements:
+
+**Freya updates:**
+> "Adding password toggle and generating error states..."
+
+**Password field with toggle:**
+```html
+<div style="position: relative;">
+  <input type="password" style="...">
+  <button type="button" style="position: absolute; right: 12px; top: 50%; transform: translateY(-50%); background: none; border: none; cursor: pointer;">
+    👁️ <!-- Eye icon -->
+  </button>
+</div>
+```
+
+**Error state:**
+```html
+<div style="margin-bottom: 16px;">
+  <label style="display: block; margin-bottom: 4px;">Email</label>
+  <input type="email"
+         style="... border-color: #DC2626;">
+  <span style="color: #DC2626; font-size: 14px;">
+    Please enter a valid email
+  </span>
+</div>
+```
+
+### Design all states:
+
+- Default (empty form)
+- Filling (content entered)
+- Error (validation failed)
+- Submitting (loading state)
+- Success (before redirect)
+
+---
+
+## Step 6: Check Accessibility (5 min)
+
+### Verify contrast and sizing:
+
+**Freya:**
+> "Running accessibility checks..."
+
+**Results:**
+| Check | Result |
+|-------|--------|
+| Button text contrast | 8.6:1 ✓ Pass |
+| Input text contrast | 13.4:1 ✓ Pass |
+| Helper text contrast | 4.8:1 ✓ Pass |
+| Error text contrast | 5.3:1 ✓ Pass |
+| Focus visible | ⚠️ Need to add |
+| Touch targets | ✓ 44px+ |
+
+### Add focus states:
+
+**Freya:**
+> "Adding focus styles for keyboard navigation..."
+
+```css
+input:focus {
+  outline: 2px solid #0066FF;
+  outline-offset: 2px;
+}
+
+button:focus {
+  outline: 2px solid #0066FF;
+  outline-offset: 2px;
+}
+```
+
+---
+
+## Step 7: Generate Responsive Variations (5 min)
+
+### Create tablet/desktop versions:
+
+**Freya:**
+> "Your base is mobile-first. For larger screens, do you want any layout changes?"
+
+**You respond:**
+> "Center the form on desktop with max-width 400px. Add some padding around it."
+
+**Freya generates:**
+```css
+@media (min-width: 768px) {
+  .signup-container {
+    max-width: 400px;
+    margin: 64px auto;
+    padding: 32px;
+    background: white;
+    border-radius: 8px;
+    box-shadow: 0 1px 3px rgba(0,0,0,0.1);
+  }
+}
+```
+
+---
+
+## Step 8: Save and Document (5 min)
+
+### Save the visual prototype:
+
+**Options:**
+1. **HTML file** — Save in scenario folder
+2. **Figma import** — Use html.to.design
+3. **Screenshots** — Capture each state
+
+```
+C-UX-Scenarios/
+└── S01-User-Registration/
+    ├── P02-signup-form/
+    │   ├── specification.md
+    │   ├── visual-prototype.html
+    │   └── states/
+    │       ├── default.png
+    │       ├── error.png
+    │       ├── loading.png
+    │       └── success.png
+```
+
+### Document visual decisions:
+
+```markdown
+## Visual Notes
+
+### Design Tokens Applied
+- Primary button: #0066FF
+- Error: #DC2626
+- Text: #111827
+- Muted text: #6B7280
+
+### Deviations from Spec
+- Strength indicator removed (MVP scope)
+- Added subtle shadow on desktop
+
+### Accessibility
+- All contrast ratios pass WCAG AA
+- Focus states visible
+- Touch targets 44px+
+```
+
+---
+
+## Step 9: Move to Next Page (Optional)
+
+### Repeat for remaining pages:
+
+**Freya:**
+> "Signup form visual is complete. The next pages in S01 are:
+> - P01-landing-page
+> - P03-welcome-screen
+>
+> Which would you like to visualize next?"
+
+Continue the process for each page in your scenarios.
+
+---
+
+## What You've Created
+
+### For each page:
+
+- **Visual prototype** — Working HTML/CSS
+- **State screenshots** — All states visualized
+- **Responsive variations** — Mobile + desktop
+- **Accessibility verified** — Contrast, focus, targets
+
+### Ready for:
+
+- Stakeholder review
+- Usability testing
+- Developer handoff
+- Design delivery
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Start with specification, not visuals
+- Check against spec after every generation
+- Design all states, not just default
+- Verify accessibility before approving
+- Document deviations
+
+**DON'T:**
+
+- Skip error states
+- Ignore responsive behavior
+- Approve without contrast check
+- Leave spec-visual mismatches
+
+---
+
+## You've Completed Module 15!
+
+**Your specifications are now visible.** You have:
+- Working prototypes
+- All states designed
+- Accessibility verified
+- Responsive behavior defined
+
+---
+
+## Next Module
+
+**[Module 16: Design Delivery →](../module-16-design-delivery/module-16-design-delivery-overview.md)**
+
+Package and deliver your design.
+
+---
+
+[← Back to Lesson 2](lesson-02-visual-techniques.md) | [Back to Module Overview](module-15-visual-design-overview.md)
+
+*Part of Module 15: Visual Design*
diff --git a/docs/learn/module-16-design-delivery/lesson-01-validation-packaging.md b/docs/learn/module-16-design-delivery/lesson-01-validation-packaging.md
new file mode 100644
index 000000000..66984dc03
--- /dev/null
+++ b/docs/learn/module-16-design-delivery/lesson-01-validation-packaging.md
@@ -0,0 +1,340 @@
+# Module 16: Design Delivery
+
+## Lesson 1: Validation and Packaging
+
+**Ensuring everything is complete and packaging for handoff**
+
+---
+
+## Two Steps Before Handoff
+
+Before any design work leaves your hands, it goes through two steps:
+
+1. **Validate** — Is everything complete? Are there gaps?
+2. **Package** — Create the DD file and test scenario
+
+Gaps found during development are expensive. Gaps found during validation are cheap.
+
+---
+
+## Step 1: Validate
+
+### The Completeness Check
+
+Before creating a Design Delivery, verify the flow is truly complete. Freya helps run this audit.
+
+**Is it a complete flow?**
+
+- [ ] Entry point is clear (where does the user start?)
+- [ ] Exit point is clear (where does the user end up?)
+- [ ] Every screen in between is fully specified
+- [ ] The flow delivers real user value on its own
+
+**Are all pages specified?**
+
+- [ ] All elements documented with Object IDs
+- [ ] All states defined (default, hover, loading, error, empty)
+- [ ] All content written — no placeholder text, no "lorem ipsum"
+- [ ] All interactions described (what happens when user clicks, types, scrolls)
+- [ ] Error states handled with specific error messages
+- [ ] Loading states defined
+- [ ] Empty states defined
+
+**Is it traceable?**
+
+- [ ] Every element connects to the Trigger Map
+- [ ] Personas referenced
+- [ ] Driving forces addressed
+- [ ] Features linked
+- [ ] Business goals traceable
+
+**Is it unambiguous?**
+
+- [ ] Consistent terminology throughout
+- [ ] No vague descriptions ("appropriate", "suitable", "nice")
+- [ ] Accessibility considered (contrast, touch targets, focus order)
+- [ ] Visual design matches specification
+
+**Is it testable?**
+
+- [ ] Acceptance criteria defined for every interaction
+- [ ] Success states clear
+- [ ] Error conditions specified with exact messages
+- [ ] Expected behaviors documented
+
+---
+
+### The Freya Audit
+
+Ask Freya to audit your specifications. She reads through every page in the flow and flags issues:
+
+> "Auditing S01-User-Registration..."
+
+> "Page P02 is missing the error state for network timeout."
+
+> "Element signup-button has no Object ID — should be 'signup-submit-btn'."
+
+> "This spec says 'appropriate error message' — what's the actual text?"
+
+> "Page P03 references a 'Continue' button but the specification doesn't describe what happens when it's clicked."
+
+She finds gaps before developers do.
+
+### Common Gaps
+
+| Gap Type | Example | Fix |
+|----------|---------|-----|
+| Missing state | No loading state for form submission | Add loading specification |
+| Vague content | "Show error message" | Write exact error text |
+| No Object ID | Button without identifier | Add consistent ID |
+| Disconnected | Feature not linked to Trigger Map | Add connection |
+| Missing edge case | What if network fails? | Document recovery path |
+| Incomplete flow | Signup works but no email verification | Add verification screens |
+
+---
+
+## Step 2: Create the Design Delivery
+
+Once validation passes, create the DD file. This is the contract that tells development exactly what to build.
+
+### The DD-XXX.yaml File
+
+Each delivery follows the standard template. Here's what goes into each section:
+
+```yaml
+delivery:
+  id: "DD-001"
+  name: "User Registration"
+  type: "user_flow"           # user_flow | feature | component
+  status: "ready"             # ready | in_progress | blocked
+  priority: "high"            # high | medium | low
+```
+
+**Delivery metadata.** The ID follows the format DD-001, DD-002, etc. Status should be "ready" when you're done validating.
+
+---
+
+```yaml
+description: |
+  First-time user signup flow from landing page
+  through registration to welcome dashboard.
+  Includes email/password signup, real-time validation,
+  and immediate access to the product.
+```
+
+**What this delivery contains.** One paragraph that gives development the full picture.
+
+---
+
+```yaml
+user_value:
+  problem: "Users need to create an account to access the product"
+  solution: "Simple email + password signup with immediate access"
+  success_criteria:
+    - "User can register in under 2 minutes"
+    - "Zero confusion on required fields"
+    - "Immediate access after registration"
+```
+
+**Why this matters.** Developers build better when they understand the user problem they're solving.
+
+---
+
+```yaml
+design_artifacts:
+  scenarios:
+    - id: "01-user-registration"
+      path: "C-UX-Scenarios/01-user-registration/"
+      screens: ["landing", "signup-form", "email-verification", "welcome"]
+
+  user_flows:
+    - name: "Registration Flow"
+      path: "C-UX-Scenarios/flows/registration.excalidraw"
+      entry: "landing"
+      exit: "welcome"
+
+  design_system:
+    components:
+      - "Button (primary, secondary, loading)"
+      - "Input (text, email, password with toggle)"
+      - "FormField (label, input, helper, error)"
+    path: "D-Design-System/"
+```
+
+**What's included.** References to your scenarios, user flows, and components. These are paths to the actual files — not copies of the content.
+
+---
+
+```yaml
+technical_requirements:
+  platform:
+    frontend: "next.js"
+    backend: "supabase"
+
+  integrations:
+    - name: "authentication-api"
+      purpose: "User registration and session management"
+      required: true
+    - name: "email-service"
+      purpose: "Verification emails"
+      required: true
+
+  data_models:
+    - name: "User"
+      fields: ["email", "password_hash", "created_at", "verified"]
+```
+
+**What development needs.** Platform info comes from the PRD's technical foundation (Phase 3). If no PRD exists yet, describe what you know.
+
+---
+
+```yaml
+acceptance_criteria:
+  functional:
+    - "User can enter email and password"
+    - "Real-time validation shows errors on blur"
+    - "Submit button disabled when form is invalid"
+    - "Loading state shown during submission"
+    - "Redirect to welcome screen on success"
+    - "Welcome screen shows user's email"
+
+  non_functional:
+    - "Form submission completes under 2 seconds"
+    - "WCAG AA contrast compliance on all elements"
+    - "Touch targets minimum 44px"
+    - "Works on mobile viewports (320px+)"
+
+  edge_cases:
+    - "Duplicate email → 'This email is already registered'"
+    - "Network error → 'Check your connection' with retry button"
+    - "Server error → 'Something went wrong. Please try again.'"
+    - "Refresh during submission → no duplicate account created"
+    - "Back button from welcome → clean signup form"
+```
+
+**How to verify.** Every criterion must be testable — a tester can read this list and check each item without asking you.
+
+---
+
+```yaml
+testing_guidance:
+  user_testing:
+    - "Can a new user complete registration without help?"
+    - "Does the validation feel helpful or annoying?"
+
+  qa_testing:
+    - "Test all error states trigger correctly"
+    - "Verify email verification flow end-to-end"
+    - "Test on mobile (iOS Safari, Android Chrome)"
+
+estimated_complexity:
+  size: "small"
+  effort: "1-2 weeks"
+  risk: "low"
+  dependencies: []
+```
+
+**Testing approach and effort estimate.** Helps development plan their work.
+
+---
+
+## Create the Test Scenario
+
+Alongside the DD file, create a test scenario file (TS-XXX.yaml) that defines:
+
+- Happy path tests (the normal user journey)
+- Error state tests (what goes wrong and how to verify handling)
+- Edge case tests (unusual but important situations)
+- Design system validation (components render correctly)
+- Accessibility tests (keyboard, screen reader, contrast)
+
+This file is used by testers in Module 17 to verify the implementation matches your design.
+
+---
+
+## The Handoff Dialog
+
+Before marking a delivery as handed off, sit down with the development team (or the BMad architect agent) for a 20-30 minute handoff dialog.
+
+**What you cover:**
+
+- Walk through the user flow
+- Highlight key interactions and states
+- Discuss technical requirements
+- Agree on epic breakdown (how to split the work)
+- Answer questions
+- Identify risks or unknowns
+
+**Document the dialog** in a handoff log (`DD-XXX-handoff-log.md`):
+
+```markdown
+# Handoff Log: DD-001 User Registration
+
+## Date: 2026-02-15
+## Duration: 25 minutes
+## Participants: Mårten (designer), Marcus (developer)
+
+## Key Discussion Points
+- Agreed on email-first registration (no social login in v1)
+- Password strength indicator: nice-to-have, not blocking
+- Mobile: must work on 320px viewport
+
+## Epic Breakdown
+1. Form UI + validation (3 days)
+2. Auth API integration (2 days)
+3. Email verification flow (2 days)
+4. Welcome screen + redirect (1 day)
+
+## Questions Resolved
+- Q: Real-time validation on every keystroke?
+  A: No, on blur. Spec updated.
+
+## Action Items
+- [ ] Marcus: Set up auth API endpoint
+- [ ] Mårten: Add 320px viewport to test scenario
+```
+
+---
+
+## Reference, Don't Duplicate
+
+The DD file **references** your design artifacts. It doesn't copy them.
+
+```yaml
+design_artifacts:
+  scenarios:
+    - id: "01-user-registration"
+      path: "C-UX-Scenarios/01-user-registration/"    # ← reference
+```
+
+This means:
+- When specs update, the delivery stays current
+- Single source of truth maintained
+- No sync issues between documents
+
+---
+
+## After Handoff
+
+Once delivered:
+
+- Mark the DD status as `in_development`
+- The development team (or BMad agents) builds from the DD and referenced artifacts
+- You continue designing the next flow
+- When development is complete, you test the implementation (Module 17)
+
+---
+
+## What's Next
+
+In the tutorial, you'll run the validation checklist on your own specifications and create your delivery package.
+
+---
+
+**[Continue to Tutorial: Create Your Delivery →](tutorial-16.md)**
+
+---
+
+[← Back to Module Overview](module-16-design-delivery-overview.md)
+
+*Part of Module 16: Design Delivery*
diff --git a/docs/learn/module-16-design-delivery/module-16-design-delivery-overview.md b/docs/learn/module-16-design-delivery/module-16-design-delivery-overview.md
new file mode 100644
index 000000000..c333c538e
--- /dev/null
+++ b/docs/learn/module-16-design-delivery/module-16-design-delivery-overview.md
@@ -0,0 +1,178 @@
+# Module 16: Design Delivery
+
+**Time: 45 min | Agent: Freya | Phase: UX Design [H] Handover | Focus: Delivery**
+
+---
+
+## Where Design Meets Development
+
+You've designed complete flows — scenarios, specifications, prototypes, visual design. Now you package them for development.
+
+In the BMad method, design deliveries are the bridge between your design work and the development team (or development agents). Each delivery is a **complete, testable flow** — not a single widget or half-finished page, but a full user journey from entry to exit.
+
+---
+
+## What Is a Design Delivery?
+
+A Design Delivery (DD) is a YAML file that acts as a **contract between design and development**. It packages everything needed to build one complete flow:
+
+- What you're delivering and why it matters
+- Which scenarios, pages, and components are included
+- What technical requirements exist
+- How to validate the implementation
+- How complex the work is
+
+The DD file doesn't contain the actual design work — it **references** your scenarios, specifications, and design system. One source of truth, no duplication.
+
+---
+
+## Where Deliveries Live
+
+Design deliveries sit alongside the PRD in the `E-PRD` folder:
+
+```
+E-PRD/
+├── 10-PRD.md                              ← Master PRD document
+├── design-deliveries/
+│   ├── DD-001-user-registration.yaml      ← Complete flow: signup → welcome
+│   ├── DD-001-handoff-log.md              ← Notes from handoff dialog
+│   ├── DD-002-dashboard.yaml              ← Complete flow: login → dashboard
+│   └── DD-002-handoff-log.md
+└── test-scenarios/
+    ├── TS-001-user-registration.yaml      ← Tests for DD-001
+    └── TS-002-dashboard.yaml              ← Tests for DD-002
+```
+
+### How this connects to the PRD
+
+The master PRD (`10-PRD.md`) has a **Section 4: Functional Requirements** that grows as you complete deliveries. Each DD adds its functional requirements to this section, building up the complete product specification over time.
+
+The PRD provides the technical foundation (architecture, APIs, data models). The DD files provide the design specification. Together they give development everything needed to build.
+
+---
+
+## The Rule: Complete and Testable
+
+A design delivery must be a **complete, testable flow**. This means:
+
+- **Complete:** Entry point to exit point, every screen specified
+- **Testable:** A tester can verify it works without asking you questions
+- **Valuable:** It delivers real user and business value on its own
+
+**Good delivery scope:**
+- User registration flow (landing → signup → email verification → welcome)
+- Dashboard experience (login → dashboard → key actions)
+- Checkout flow (cart → payment → confirmation)
+
+**Bad delivery scope:**
+- Just the signup form (not a complete flow)
+- A button component (not a flow at all)
+- Half the dashboard with placeholder pages
+
+If a flow isn't complete, go back to the design activities in Phase 4 and finish it.
+
+---
+
+## The Delivery Process
+
+In the WDS workflow, design delivery is the **[H] Handover** activity within Phase 4 (UX Design). When Freya detects that a flow is complete, she initiates the handover:
+
+```
+Step 1: Detect completion — Is the flow complete and testable?
+    ↓
+Step 2: Create Design Delivery (DD-XXX.yaml)
+    ↓
+Step 3: Create Test Scenario (TS-XXX.yaml)
+    ↓
+Step 4: Handoff Dialog (20-30 min with development team)
+    ↓
+Step 5: Hand off (mark as in_development)
+    ↓
+Step 6: Continue with next flow (return to design activity)
+```
+
+**This is iterative.** You don't deliver everything at once. As soon as one flow is complete, package it and hand it off. Then start the next flow while development builds the first one.
+
+---
+
+## Parallel Work
+
+The delivery model enables parallel work:
+
+```
+Week 1: Design Flow 1
+Week 2: Hand off Flow 1 → Dev builds Flow 1
+        Design Flow 2
+Week 3: Hand off Flow 2 → Dev builds Flow 2
+        Test Flow 1 (Module 17)
+        Design Flow 3
+```
+
+You design the next flow while development builds the current one. Testing validates what was built last. Everyone stays productive.
+
+---
+
+## What You'll Learn
+
+### Lesson 1: Validation and Packaging
+
+The validation checklist, the Freya audit, creating the DD file and test scenario, the handoff dialog, and what makes a delivery ready.
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Delivering incomplete flows | Check: entry to exit, every screen specified |
+| Missing acceptance criteria | Write them before delivery — testable, specific |
+| Vague specifications | Run Freya's audit: no "appropriate" or "suitable" |
+| Duplicating content in DD | Reference artifacts, don't copy them |
+| Delivering too late | Hand off as soon as a flow is complete |
+| Skipping the handoff dialog | 20-30 minutes prevents weeks of misunderstanding |
+
+---
+
+## The Test
+
+Can a developer who has never seen this project build this flow correctly from your DD file and the artifacts it references?
+
+If no, it's not ready.
+
+---
+
+## Practice
+
+For one completed flow:
+
+1. Run through the validation checklist
+2. Fill any gaps
+3. Create the DD-XXX.yaml file
+4. Write acceptance criteria
+5. Create the test scenario
+
+---
+
+## Lessons
+
+### [Lesson 1: Validation and Packaging](lesson-01-validation-packaging.md)
+Ensuring everything is complete and packaging for handoff
+
+---
+
+## Tutorial
+
+### [Tutorial 16: Create Your Delivery](tutorial-16.md)
+Hands-on guide to validating specifications and packaging for handoff
+
+---
+
+## Next Module
+
+**[Module 17: Usability Testing →](../module-17-usability-testing/module-17-usability-testing-overview.md)**
+
+Test your design with real users.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-16-design-delivery/tutorial-16.md b/docs/learn/module-16-design-delivery/tutorial-16.md
new file mode 100644
index 000000000..457d96e12
--- /dev/null
+++ b/docs/learn/module-16-design-delivery/tutorial-16.md
@@ -0,0 +1,411 @@
+# Tutorial 16: Create Your Delivery
+
+**Hands-on guide to validating specifications and packaging for handoff**
+
+---
+
+## Overview
+
+This tutorial walks you through validating your complete design work and creating a delivery package for implementation.
+
+**Time:** 30-40 minutes
+**Prerequisites:** All design work completed (Modules 08-15)
+**Agent:** Freya
+**What you'll create:** Validated specifications and delivery package
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- All your scenario outlines
+- All your page specifications
+- All your visual prototypes
+- Your component documentation (if applicable)
+
+**Freya will help you:**
+
+- Audit specifications for gaps
+- Create delivery documents
+- Write acceptance criteria
+- Prepare for handoff
+
+---
+
+## Step 1: Run the Validation Audit (10 min)
+
+### Start the audit:
+
+**You say:**
+> "Please audit my specifications for S01-User-Registration. Check for completeness, traceability, and quality."
+
+**Freya audits:**
+> "Auditing S01-User-Registration..."
+
+### Review findings:
+
+**Freya reports:**
+```
+## Audit Results: S01-User-Registration
+
+### Completeness
+✓ All 3 pages specified
+✓ All elements documented
+⚠️ P02: Missing "rate limited" error state
+✓ Content written (no lorem ipsum)
+✓ Interactions described
+
+### Traceability
+✓ Connected to Trigger Map
+✓ Persona: Felix
+✓ Feature: F03-Quick-Signup
+⚠️ P03 welcome screen: No business goal reference
+
+### Quality
+✓ Object IDs assigned
+⚠️ Inconsistent terminology: "sign up" vs "signup"
+✓ Accessibility considered
+
+### Testability
+⚠️ No acceptance criteria document yet
+```
+
+### Resolve issues:
+
+**Freya:**
+> "I found 4 issues. Let's resolve them:
+>
+> 1. **Rate limited error** — What message should show?"
+
+**You respond:**
+> "'Too many attempts. Please wait 5 minutes before trying again.'"
+
+**Freya:**
+> "2. **P03 business goal** — What goal does the welcome screen serve?"
+
+**You respond:**
+> "User activation — converting signup to first meaningful action."
+
+**Freya:**
+> "3. **Terminology** — Should we use 'signup' or 'sign up'?"
+
+**You respond:**
+> "'Sign up' as two words for the action verb, 'Signup' as one word for the noun/form name."
+
+**Freya updates specifications with fixes.**
+
+---
+
+## Step 2: Create Delivery Overview (5 min)
+
+### Generate delivery document:
+
+**Freya:**
+> "Creating delivery overview for DD01-User-Registration..."
+
+```markdown
+# DD01: User Registration
+
+## Summary
+First-time user signup flow enabling new users to create an account
+and reach the welcome dashboard.
+
+## Business Context
+- Persona: Felix the Full-Stack
+- Driving Force: "Want to try before committing"
+- Goal: Reduce friction in user acquisition
+
+## Scenarios Included
+- S01-User-Registration
+
+## Pages
+
+| ID | Page | Spec | Visual | Status |
+|----|------|------|--------|--------|
+| P01 | Landing Page | ✓ | ✓ | Ready |
+| P02 | Signup Form | ✓ | ✓ | Ready |
+| P03 | Welcome Screen | ✓ | ✓ | Ready |
+
+## Components Used
+- Button (primary, secondary, ghost)
+- Input (text, email, password)
+- FormField (wrapper component)
+
+## Technical Dependencies
+- Supabase Auth (authentication)
+- Supabase Database (user storage)
+- Email service (optional verification)
+
+## Design System
+- Mode: Building
+- Tokens: See D-Design-System/tokens/
+- Components: See C-UX-Scenarios/Functional-Components/
+
+## Implementation Notes
+- Mobile-first responsive design
+- Real-time form validation
+- Password strength indicator
+- Form data preserved on error
+- Keyboard accessible throughout
+```
+
+---
+
+## Step 3: Write Acceptance Criteria (10 min)
+
+### Define testable requirements:
+
+**Freya guides:**
+> "Let's write acceptance criteria. Starting with the happy path..."
+
+**Work through each category:**
+
+### Happy Path
+
+```markdown
+## Happy Path
+
+### Landing Page
+- [ ] "Start Free" button is visible above fold
+- [ ] Clicking "Start Free" navigates to signup form
+- [ ] Login link navigates to login page
+
+### Signup Form
+- [ ] Form displays email and password fields
+- [ ] Form displays "Create Free Account" button
+- [ ] Button is disabled until form is valid
+- [ ] Entering valid email removes email error
+- [ ] Entering 8+ character password enables button
+- [ ] Clicking submit shows loading state
+- [ ] Successful submit navigates to welcome screen
+
+### Welcome Screen
+- [ ] Displays user's email address
+- [ ] Shows clear next step guidance
+- [ ] Provides navigation to main app
+```
+
+### Error Handling
+
+```markdown
+## Error Handling
+
+### Validation Errors
+- [ ] Empty email: "Email is required"
+- [ ] Invalid email format: "Please enter a valid email"
+- [ ] Empty password: "Password is required"
+- [ ] Password < 8 chars: "Password must be at least 8 characters"
+
+### Server Errors
+- [ ] Duplicate email: "This email is already registered. Log in instead →"
+- [ ] Server error: "Something went wrong. Please try again."
+- [ ] Network error: "Connection lost. Please check your internet."
+- [ ] Rate limited: "Too many attempts. Please wait 5 minutes."
+
+### Error Recovery
+- [ ] Form data preserved after error
+- [ ] User can edit and resubmit
+- [ ] Duplicate email links to login flow
+```
+
+### Accessibility
+
+```markdown
+## Accessibility
+
+### Keyboard Navigation
+- [ ] All interactive elements focusable
+- [ ] Focus order matches visual order
+- [ ] Focus visible on all elements
+- [ ] Enter/Space activates buttons
+- [ ] Tab moves through form fields
+
+### Screen Reader
+- [ ] All inputs have visible labels
+- [ ] Errors announced when they appear
+- [ ] Button states announced (loading, disabled)
+- [ ] Form submission result announced
+
+### Visual
+- [ ] Color contrast passes WCAG AA
+- [ ] Text resizable to 200% without breaking
+- [ ] Touch targets minimum 44px
+```
+
+---
+
+## Step 4: Organize Delivery Package (5 min)
+
+### Create folder structure:
+
+**Freya:**
+> "Organizing delivery package..."
+
+```
+E-PRD/Design-Deliveries/
+└── DD01-User-Registration/
+    ├── delivery-overview.md
+    ├── acceptance-criteria.md
+    ├── scenarios/
+    │   └── S01-User-Registration/
+    │       └── [references to C-UX-Scenarios/S01/]
+    └── components/
+        └── [references to C-UX-Scenarios/Functional-Components/]
+```
+
+### Verify all links work:
+
+**Freya checks:**
+> "Verifying all specification references...
+> - ✓ P01 landing page spec accessible
+> - ✓ P02 signup form spec accessible
+> - ✓ P03 welcome screen spec accessible
+> - ✓ Visual prototypes accessible
+> - ✓ Component docs accessible
+>
+> Delivery package is complete."
+
+---
+
+## Step 5: Final Review (5 min)
+
+### The Developer Test:
+
+**Freya asks:**
+> "Can a developer who has never seen this project build it correctly from this delivery package?"
+
+**Review checklist:**
+
+- [ ] All pages specified completely
+- [ ] All states documented
+- [ ] All content finalized
+- [ ] All error messages defined
+- [ ] Acceptance criteria testable
+- [ ] Visual prototypes match specs
+- [ ] Dependencies listed
+- [ ] No ambiguous requirements
+
+### Sign off:
+
+**Freya:**
+> "Delivery package DD01-User-Registration is validated and ready for handoff to Idunn.
+>
+> Summary:
+> - 3 pages specified
+> - 47 acceptance criteria
+> - 0 outstanding issues
+> - 4 components referenced
+>
+> Design phase complete for this scenario."
+
+---
+
+## Step 6: Handoff to Idunn (2 min)
+
+### Prepare handoff message:
+
+**Freya generates:**
+```markdown
+# Design Handoff: DD01-User-Registration
+
+## For: Idunn (Implementation)
+## From: Freya (Design)
+## Date: [Today]
+
+## Delivery Package
+Location: E-PRD/Design-Deliveries/DD01-User-Registration/
+
+## What's Included
+- Complete specifications for 3 pages
+- Visual prototypes (HTML)
+- Component documentation
+- Acceptance criteria (47 items)
+
+## Dependencies Needed
+- Supabase Auth configured
+- User table in database
+- Email service (optional)
+
+## Priority
+This is the primary user acquisition flow.
+Recommend implementing before other scenarios.
+
+## Questions?
+Specifications should be complete. If anything is unclear,
+the specification needs updating rather than verbal clarification.
+
+---
+Design phase complete. Ready for implementation.
+```
+
+---
+
+## What You've Created
+
+### Delivery Package:
+
+- **Delivery overview** — Summary for developers
+- **Acceptance criteria** — Testable requirements
+- **Organized references** — Links to all specs and visuals
+
+### Validated:
+
+- All specifications complete
+- All gaps resolved
+- All content finalized
+- All criteria testable
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Run the audit before declaring complete
+- Resolve all gaps before delivery
+- Write specific acceptance criteria
+- Reference, don't duplicate
+
+**DON'T:**
+
+- Skip validation ("it's probably fine")
+- Leave vague requirements
+- Forget accessibility criteria
+- Package without final review
+
+---
+
+## You've Completed the Design & Delivery Phase!
+
+**Congratulations!** You've completed:
+
+**Design (Modules 7-13):**
+- ✅ Module 07: Design Phase Introduction
+- ✅ Module 08: Outline Scenarios
+- ✅ Module 09: Conceptual Sketching
+- ✅ Module 10: Storyboarding
+- ✅ Module 11: Conceptual Specifications
+- ✅ Module 12: Functional Components
+- ✅ Module 13: Design System
+
+**Build & Deliver (Modules 14-16):**
+- ✅ Module 14: Agentic Development
+- ✅ Module 15: Visual Design & Assets
+- ✅ Module 16: Design Delivery
+
+**Your design work is complete and handed off for implementation.**
+
+---
+
+## Next: Validate & Evolve
+
+**[Module 17: Usability Testing →](../module-17-usability-testing/module-17-usability-testing-overview.md)**
+
+Test your design with real users.
+
+---
+
+[← Back to Lesson 1](lesson-01-validation-packaging.md) | [Back to Module Overview](module-16-design-delivery-overview.md)
+
+*Part of Module 16: Design Delivery*
diff --git a/docs/learn/module-17-usability-testing/lesson-01-spec-verification.md b/docs/learn/module-17-usability-testing/lesson-01-spec-verification.md
new file mode 100644
index 000000000..947bf32b2
--- /dev/null
+++ b/docs/learn/module-17-usability-testing/lesson-01-spec-verification.md
@@ -0,0 +1,243 @@
+# Module 17: Usability Testing
+
+## Lesson 1: The Test Scenario
+
+**Preparing everything before the user arrives**
+
+---
+
+## Why Planning Matters More Now
+
+When building takes an afternoon, you can't afford to spend a week planning a test. But you also can't afford to waste a test session because you weren't prepared.
+
+The test scenario is your script. It ensures every participant gets the same experience, every task is clear, and you know exactly what to observe. Create it once, use it for every session.
+
+---
+
+## Pick One Flow
+
+Don't test the whole product. Test one flow.
+
+A flow is a complete user journey with a beginning and an end:
+- Creating an account
+- Booking an appointment
+- Finding and purchasing a product
+- Changing account settings
+
+**Good test candidates:**
+- The primary journey (what most users do first)
+- A flow you're uncertain about
+- A flow with many steps or decision points
+- A flow that's critical for business goals
+
+---
+
+## Write the Tasks
+
+Tasks are what you'll ask the participant to do. They describe a goal — not a path.
+
+### Good Tasks
+
+- "You want to try this product. Go ahead and create an account."
+- "You received an email about your upcoming appointment. Find the details."
+- "You want to stop receiving email notifications. See if you can figure out how."
+
+Each task:
+- Describes what the user wants to achieve
+- Doesn't say where to click or what to look for
+- Uses language a real user would think in
+- Is completable in 2-5 minutes
+
+### Bad Tasks
+
+- "Test the signup form" — What should they actually do?
+- "Click the blue button and fill in your email" — You're giving them the answer
+- "Navigate to Settings, then Notifications, then toggle Email off" — Step-by-step instructions aren't a test
+
+3-5 tasks per session is enough. More than that and participants get tired, which affects the quality of later tasks.
+
+---
+
+## Select Participants
+
+### How Many
+
+3-5 people per test round. Research shows 5 users find approximately 85% of usability problems. Three is the minimum for spotting patterns.
+
+### Who
+
+They should match your personas — or at least be reasonably close. If your persona is a dog trainer with moderate tech comfort, don't test on software developers.
+
+**Where to find them:**
+- Existing users of similar products
+- Friends or colleagues who match the persona's profile
+- People from your professional network
+- Community groups related to your product's domain
+
+**Who to avoid:**
+- Yourself (you already know how it works)
+- Other designers on the project (same problem)
+- Anyone who has seen the specifications or design
+- People who will tell you what you want to hear instead of what they actually think
+
+### When to Recruit
+
+**Before you start building.** This is the key insight.
+
+Send a message while the prototype is still being built:
+
+> "Hi! I'm working on a product and would love 20 minutes of your time to try it out sometime this week. No preparation needed. Would you be available?"
+
+When the prototype is ready, they're ready. No delay.
+
+---
+
+## Prepare the Materials
+
+### The Introduction Script
+
+Write it down. Read it the same way to every participant:
+
+```
+"Thanks for helping me with this. A few things before we start:
+
+I'm testing the design, not you. There are no wrong answers
+and you can't do anything wrong.
+
+I'll give you a few tasks to try. Please think out loud as you
+go — tell me what you're looking at, what you're thinking,
+what you expect to happen.
+
+I won't be able to help you during the tasks. If you get stuck,
+that's valuable information for me. Just do what you would do
+if I weren't here.
+
+Any questions before we start?"
+```
+
+Same words, same tone, every time. This removes you as a variable.
+
+### Task Cards
+
+Write each task on a separate card or in a separate message. Present them one at a time. The participant should only see the current task.
+
+```
+Task 1:
+"You've heard about [product name] and want to try it.
+Go ahead and create an account."
+```
+
+### The Observation Sheet
+
+Prepare a simple sheet for each session:
+
+```markdown
+# Usability Test: [Flow Name]
+## Participant: P[#]
+## Date:
+## Location:
+## Device:
+
+### Task 1: [Task name]
+- Started:
+- Completed: Yes / No
+- Time:
+- Notes:
+
+### Task 2: [Task name]
+- Started:
+- Completed: Yes / No
+- Time:
+- Notes:
+
+### Task 3: [Task name]
+- Started:
+- Completed: Yes / No
+- Time:
+- Notes:
+
+### Post-session notes:
+```
+
+### Recording Setup
+
+Decide how you'll record and test it before the session.
+
+**At their location (preferred):**
+- Phone camera capturing screen + hands
+- Screen recording on their device (ask permission first)
+- Both if possible — screen for details, camera for reactions
+
+**Remote (when necessary):**
+- Video call with screen sharing and recording
+- Less ideal than contextual, but far better than no testing
+
+**Always ask permission to record.** Explain that it's for your review only and won't be shared.
+
+---
+
+## The Complete Test Scenario Document
+
+Put it all together:
+
+```markdown
+# Test Scenario: User Registration Flow
+
+## Flow Under Test
+User registration from landing page through account creation
+to welcome dashboard.
+
+## Prototype
+[URL or file path to the prototype]
+
+## Participants
+- 3-5 people matching Felix persona (moderate tech comfort)
+- Recruited: [date]
+- Sessions scheduled: [dates]
+
+## Introduction Script
+[The script above]
+
+## Tasks
+1. "You've heard about [product] and want to try it.
+   Go ahead and create an account."
+
+2. "You just created your account. Take a look around —
+   what can you do here?"
+
+3. "You want to change your email notification preferences.
+   See if you can find where to do that."
+
+## What to Observe
+- Can they find the registration CTA?
+- Do they understand the form fields?
+- Do error messages help them recover?
+- Do they know what to do after registration?
+- Can they navigate to settings?
+
+## Recording Method
+Phone camera + screen recording
+
+## Post-Session Questions
+- What stood out to you?
+- Was anything confusing or unexpected?
+- If you could change one thing, what would it be?
+```
+
+This document is your preparation. When you arrive at the participant's location, you know exactly what to do.
+
+---
+
+## What's Next
+
+The scenario is ready. In the next lesson, you'll learn how to conduct the session — and why not helping is the hardest part of the job.
+
+---
+
+**[Continue to Lesson 2: Conducting the Test →](lesson-02-test-results.md)**
+
+---
+
+[← Back to Module Overview](module-17-usability-testing-overview.md)
+
+*Part of Module 17: Usability Testing*
diff --git a/docs/learn/module-17-usability-testing/lesson-02-test-results.md b/docs/learn/module-17-usability-testing/lesson-02-test-results.md
new file mode 100644
index 000000000..2b84b1b89
--- /dev/null
+++ b/docs/learn/module-17-usability-testing/lesson-02-test-results.md
@@ -0,0 +1,240 @@
+# Module 17: Usability Testing
+
+## Lesson 2: Conducting the Test
+
+**The session, the silence, and the replay**
+
+---
+
+## Consistency Is Everything
+
+Every participant must get the same test. Same introduction. Same tasks. Same conditions.
+
+If you explain the interface to participant 2 but not participant 1, you can't compare their results. If you give participant 3 a hint because they're struggling, their "success" is meaningless.
+
+The test scenario from Lesson 1 is your script. Follow it.
+
+---
+
+## Arrive and Set Up
+
+### At Their Location (Preferred)
+
+You go to them. Their home, their office, their desk. They use their own device, their own browser, their own chair.
+
+Set up your recording before they sit down:
+- Position your phone camera where it captures the screen and their hands
+- Start screen recording on their device (with permission)
+- Make sure everything is working before they start
+
+### Remote (When Necessary)
+
+Start the video call. Ask them to share their screen. Begin recording.
+
+Remote is less ideal — you miss body language, environmental context, and the natural pace of their interaction. But it's infinitely better than not testing.
+
+---
+
+## Read the Introduction
+
+Read your introduction script exactly as written. Same words every time.
+
+```
+"Thanks for helping me with this. A few things before we start:
+
+I'm testing the design, not you. There are no wrong answers
+and you can't do anything wrong.
+
+I'll give you a few tasks to try. Please think out loud as you
+go — tell me what you're looking at, what you're thinking,
+what you expect to happen.
+
+I won't be able to help you during the tasks. If you get stuck,
+that's valuable information for me. Just do what you would do
+if I weren't here.
+
+Any questions before we start?"
+```
+
+Answer any questions about the process. Don't answer questions about the product.
+
+---
+
+## Present the Task
+
+Give them one task at a time. Read it aloud. Hand them the card or send the message.
+
+> "You've heard about [product name] and want to try it. Go ahead and create an account."
+
+Then stop talking.
+
+---
+
+## The Silence
+
+This is the hardest part of usability testing. You must not help.
+
+### Don't Help
+
+The user clicks the wrong thing. You know the right answer. You want to say "try the button on the left." **Don't.**
+
+Their wrong click is your data. It tells you the design failed to guide them. If you help, you lose that information.
+
+### Don't Discuss
+
+They say "is this where I'm supposed to go?" You want to confirm or redirect. **Don't.**
+
+Say: "What do you think?" or "What would you do if I weren't here?"
+
+### Don't Explain
+
+They're confused by a label. You want to explain what it means. **Don't.**
+
+If the label needs explaining, the label is wrong. That's a finding.
+
+### Deflect Questions
+
+They will ask you questions. It's natural. They want to do well. Deflect every one:
+
+| They say | You say |
+|----------|---------|
+| "Is this right?" | "There's no right or wrong. What do you think?" |
+| "Should I click here?" | "Go ahead and do whatever feels natural." |
+| "What does this mean?" | "What do you expect it to mean?" |
+| "Am I doing this correctly?" | "You're doing great. Just keep going." |
+| "I'm stuck, can you help?" | "What would you try if I weren't here?" |
+
+### When It's Painful
+
+You will watch someone struggle for 30 seconds on something that takes 2 seconds if you explain it. It will feel wrong. It will feel rude. Do it anyway.
+
+That 30-second struggle is the most valuable data you'll collect. It reveals exactly where the design fails.
+
+**The only exception:** If the user is genuinely distressed — frustrated to the point of being upset — move to the next task. Say: "Let's skip this one and try the next task." Note it as a critical finding: task abandoned due to user frustration.
+
+---
+
+## What to Observe
+
+While they work, take notes on your observation sheet. Use timestamps.
+
+### Behavioral Signals
+
+- **Hesitation** — They pause before clicking. What are they deciding between?
+- **Scanning** — Their eyes search the page. What are they looking for that isn't obvious?
+- **Backtracking** — They go back. Their expectation didn't match reality.
+- **Misclicks** — They click the wrong element. What did they think it would do?
+- **Speed** — Fast and confident, or slow and uncertain?
+
+### Verbal Signals
+
+Listen for think-aloud comments:
+
+- "Oh, I expected..." — Their mental model doesn't match the design
+- "Where is the..." — Navigation or visual hierarchy problem
+- "What does this mean?" — Label or messaging failure
+- "I think I need to..." — They're guessing, not knowing
+- "Oh!" — Surprise, positive or negative
+
+### Completion
+
+For each task, note:
+- Did they complete it? Yes / No
+- How long did it take?
+- How many wrong paths did they try?
+- Did they seem confident or uncertain at the end?
+
+---
+
+## Between Tasks
+
+Brief pause. "How was that?" Listen to any immediate reaction. Keep it to 30 seconds.
+
+Don't explain what they "should have done." Don't reveal the intended path. Don't discuss the design.
+
+Present the next task card.
+
+---
+
+## After All Tasks
+
+### Quick Debrief (2 minutes)
+
+Ask open questions:
+
+- "What stood out to you?"
+- "Was anything confusing or unexpected?"
+- "If you could change one thing, what would it be?"
+
+These questions sometimes surface things you didn't observe. But keep it brief — the real value was in watching their behavior.
+
+---
+
+## The Retrospective Replay
+
+This is the most powerful part of the session.
+
+### How It Works
+
+After the tasks and debrief, play the recording back to the participant. Watch it together.
+
+At key moments — hesitations, wrong clicks, confusion — pause and ask:
+
+- "What were you thinking here?"
+- "I noticed you paused — what was going on?"
+- "You went back here — what did you expect to find?"
+- "You clicked this — what did you think it would do?"
+
+### Why It Works
+
+During the tasks, the user is focused on performing. They can't fully explain their thinking in the moment, even with think-aloud.
+
+In the replay, the pressure is off. They see their own behavior from the outside and can articulate what was actually happening in their head. This produces insights you can't get any other way.
+
+> "Oh yeah, here I was looking for a 'Sign Up' link in the menu because that's where I usually find it on other sites. I didn't realize the big button was for registration."
+
+That explanation is worth more than 10 minutes of guessing at what went wrong.
+
+### When to Use the Replay
+
+- **Always** for formal sessions on critical flows
+- **Optional** for guerrilla tests or quick checks
+- **Skip** if the participant is short on time — ask if they have 10 more minutes
+
+---
+
+## Close the Session
+
+Thank them sincerely. They gave you their time and their honesty.
+
+A coffee, a gift card, or a genuine thank you — acknowledge their contribution. They helped make the product better.
+
+---
+
+## Guerrilla Testing
+
+Not every test needs the full process.
+
+**The 5-minute test:** Grab someone nearby. Show them the prototype. "Can you sign up for an account?" Watch what happens. No recording, no replay, just observation.
+
+Guerrilla testing is imperfect. The participant probably doesn't match your persona. There's no recording to review. But it catches obvious problems you've become blind to.
+
+**Use it:** During development, between build steps, for quick sanity checks.
+
+**Don't use it:** For critical flows, when persona match matters, when you need evidence for stakeholders.
+
+---
+
+## What's Next
+
+You have recordings and observation notes. In the next lesson, you'll turn them into findings that connect back to your specifications and drive real design improvements.
+
+---
+
+**[Continue to Lesson 3: Acting on Findings →](lesson-03-acting-on-findings.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-spec-verification.md) | [Back to Module Overview](module-17-usability-testing-overview.md)
+
+*Part of Module 17: Usability Testing*
diff --git a/docs/learn/module-17-usability-testing/lesson-03-acting-on-findings.md b/docs/learn/module-17-usability-testing/lesson-03-acting-on-findings.md
new file mode 100644
index 000000000..3dfc495bc
--- /dev/null
+++ b/docs/learn/module-17-usability-testing/lesson-03-acting-on-findings.md
@@ -0,0 +1,253 @@
+# Module 17: Usability Testing
+
+## Lesson 3: Acting on Findings
+
+**Turning observations into design improvements**
+
+---
+
+## Review the Recordings
+
+Don't process findings from memory. Watch the recordings.
+
+On the second viewing, you see what you missed. The hesitation you didn't notice. The comment you brushed past. The pattern across multiple users that wasn't visible during any single session.
+
+### What to Look For
+
+**Patterns** — Did multiple users struggle at the same point? That's a design problem, not a user problem.
+
+**Surprises** — Did users do something you didn't expect? They found a path you didn't design for, or ignored the path you did.
+
+**Quotes** — Exact words users said. "I don't know what this means" is more powerful than "users found the label confusing."
+
+**Completion** — Did they finish the task? How long did it take? Did they need to backtrack?
+
+### Timestamp Key Moments
+
+As you review, note timestamps for:
+
+- First confusion point
+- Misclicks or wrong paths
+- Moments of hesitation (3+ seconds)
+- Verbal reactions ("Oh!", "Hmm...", "Wait...")
+- Task abandonment
+- Successful completion
+
+These timestamps become your evidence when presenting findings.
+
+---
+
+## Document the Findings
+
+For each usability issue, document:
+
+```markdown
+## Finding: [Short description]
+
+**Severity:** Critical | Major | Minor
+**Observed in:** [# of # participants]
+**Task:** [Which task triggered this]
+**Timestamp:** [Recording reference]
+
+### What happened
+[Describe the behavior — what the user did, not what they should have done]
+
+### Why it matters
+[Connect to persona, driving force, or business goal]
+
+### Root cause
+[What in the design caused this? Be specific — page, element, interaction]
+
+### Recommendation
+[What to change in the specification]
+```
+
+### Example
+
+```markdown
+## Finding: Users don't see the registration CTA
+
+**Severity:** Critical
+**Observed in:** 4 of 5 participants
+**Task:** "You want to create an account. Go ahead."
+**Timestamp:** P1 0:23, P2 0:31, P3 0:18, P4 0:45
+
+### What happened
+Users scrolled past the registration button. Three looked at the
+navigation menu first. One tried clicking the logo. Only after
+20-40 seconds did they find the CTA below the fold.
+
+### Why it matters
+Felix needs simple paths with no hunting (driving force: efficiency).
+If the primary action is hidden, first-time users will bounce.
+
+### Root cause
+Page P01 (landing): The CTA "Create Free Account" sits below a
+large hero image. Visual hierarchy prioritizes the image over
+the action.
+
+### Recommendation
+Move CTA above the fold. Increase visual weight — larger button,
+contrasting color, or positioned within the hero section instead
+of below it. Update spec P01 section 3.
+```
+
+---
+
+## Connect to Your Design System
+
+Usability findings don't exist in isolation. They connect back to everything you've built:
+
+### Trace to Specifications
+
+Every finding should point to a specific page, element, or interaction in your specs. If you can't point to the spec, the finding is too vague.
+
+> "Users were confused" → **Too vague**
+> "Users didn't see the CTA on P01 because it's below the fold" → **Actionable**
+
+### Trace to Trigger Maps
+
+Your trigger maps describe the driving forces behind user actions. When testing reveals problems, check if the driving force was addressed:
+
+> Finding: Users abandon at step 2 of registration.
+> Trigger map says: Felix is motivated by speed — "I want this done fast."
+> Connection: Step 2 feels unnecessary. Can we combine steps 1 and 2?
+
+### Trace to Personas
+
+Does the finding affect all users, or is it persona-specific?
+
+> Finding works for tech-savvy users but fails for the less technical persona → Different fix needed than a universal change.
+
+---
+
+## Prioritize What to Fix
+
+Not every finding needs immediate action.
+
+### Critical
+
+Users **cannot complete the task.** The flow is broken.
+
+- Fix before next test round
+- Update spec immediately
+- Rebuild in next agentic session
+
+### Major
+
+Users **complete the task but with significant difficulty.** Hesitation, confusion, wrong paths.
+
+- Fix in current iteration
+- Update spec
+- May need design rethinking, not just tweaks
+
+### Minor
+
+Users **notice something but it doesn't block them.** Small friction, slightly confusing labels.
+
+- Fix when convenient
+- Log for future reference
+- Sometimes resolves itself when major issues are fixed
+
+### Not a Problem
+
+Users did something unexpected but it **worked fine.** Their path was different from what you designed, but the outcome was correct.
+
+- Document it — you learned something about user behavior
+- Consider if the "designed" path is actually needed
+- Don't fix what isn't broken
+
+---
+
+## Update Your Specifications
+
+This is where the cycle closes. Findings become spec changes.
+
+```markdown
+## Spec Update Log: Usability Round 1
+
+### P01 Landing Page
+- **Changed:** CTA moved from below hero to within hero section
+  - Reason: 4/5 users missed it below the fold
+  - Finding: "Users don't see the registration CTA"
+
+### P02 Signup Form
+- **Changed:** Combined steps 1 and 2 into single form
+  - Reason: 3/5 users hesitated at step transition
+  - Finding: "Step 2 feels unnecessary"
+
+### P03 Welcome Screen
+- **No changes.** All users navigated successfully.
+```
+
+Update the spec. Then rebuild. Then test again.
+
+---
+
+## The Iterate Cycle
+
+```
+Round 1: Test prototype
+  → 3 critical, 2 major findings
+  → Update specs → Rebuild
+
+Round 2: Test updated prototype
+  → 0 critical, 1 major, 2 minor findings
+  → Update specs → Rebuild
+
+Round 3: Test refined prototype
+  → 0 critical, 0 major, 1 minor finding
+  → Ship it
+```
+
+Each round should have fewer and less severe findings. If severity increases between rounds, something went wrong in the redesign.
+
+**Two to three rounds** is typical for a critical flow. One round is enough for simpler features.
+
+---
+
+## Presenting Findings
+
+Sometimes you need to convince stakeholders that changes are necessary.
+
+### Use Evidence, Not Opinion
+
+- **Weak:** "I think the CTA should be bigger"
+- **Strong:** "4 of 5 test participants couldn't find the CTA within 30 seconds. Here are the recordings."
+
+### Show, Don't Tell
+
+Play the relevant 30 seconds of recording. Seeing a real user struggle is more persuasive than any report.
+
+### Connect to Business Impact
+
+- "Users can't find the registration button → fewer signups → less revenue"
+- "Users abandon at step 2 → 60% drop-off in the funnel"
+
+---
+
+## The Freya Method
+
+Freya helps structure your findings:
+
+> "You found 5 issues. Let me help prioritize. Finding #1 blocks the primary task for 4 of 5 users — that's critical. Findings #3 and #4 might resolve themselves once #1 is fixed."
+
+> "This finding connects to the trigger map: Felix's driving force is efficiency. The three-step process contradicts that. Recommend consolidating."
+
+> "Update spec P01 section 3 based on finding #1. I'll note the change in the spec update log."
+
+---
+
+## What's Next
+
+In the tutorial, you'll plan a usability test for one of your flows and walk through the complete process.
+
+---
+
+**[Continue to Tutorial: Plan Your Usability Test →](tutorial-17.md)**
+
+---
+
+[← Back to Lesson 2](lesson-02-test-results.md) | [Back to Module Overview](module-17-usability-testing-overview.md)
+
+*Part of Module 17: Usability Testing*
diff --git a/docs/learn/module-17-usability-testing/module-17-usability-testing-overview.md b/docs/learn/module-17-usability-testing/module-17-usability-testing-overview.md
new file mode 100644
index 000000000..8dc38c052
--- /dev/null
+++ b/docs/learn/module-17-usability-testing/module-17-usability-testing-overview.md
@@ -0,0 +1,231 @@
+# Module 17: Usability Testing
+
+**Time: 45 min | Agent: Freya | Phase: Validation**
+
+---
+
+## The New Economics of Testing
+
+Usability testing hasn't changed. But everything around it has.
+
+When every phase of design took weeks, a couple of days of testing and a couple of days processing results didn't feel like much. Now, when a complete product can be built in an afternoon, spending two days testing on humans suddenly feels relatively very expensive.
+
+This doesn't make usability testing less valuable. It makes planning more important.
+
+The answer isn't to skip testing. It's to **test early** and **plan ahead**. Line up your test group before you start building. When the prototype is ready, they're ready. No waiting. No scheduling back and forth.
+
+---
+
+## The Whiteport Rule
+
+**If a feature or change isn't worth showing to 5 users and 1 domain expert for feedback, then it's not worth building in the first place.**
+
+This is the simplest filter for what deserves your time. If you can't justify 20 minutes of testing for a feature, ask yourself why you're spending hours building it.
+
+Every feature you ship will be used by real people. If you're not willing to watch 5 of them try it, you're shipping blind.
+
+---
+
+## Spec Conformity Is Not Usability
+
+In Module 14, the agent verifies that the implementation matches the specification — using Puppeteer to check every element, state, and interaction. That's functional testing. It answers: **did we build what we designed?**
+
+Usability testing answers a different question: **did we design the right thing?**
+
+A form can match the spec perfectly and still confuse users. A flow can implement every acceptance criterion and still feel wrong. Numbers pass. Humans struggle.
+
+| What you assumed | What testing reveals |
+|------------------|---------------------|
+| Users will see the CTA first | Users look at the image, miss the CTA |
+| The error message is clear | Users don't understand "invalid format" |
+| The flow is intuitive | Users expect "Back" to go to the previous page, not the dashboard |
+| Three steps is simple enough | Users abandon at step 2 |
+
+These are things no specification can predict. You have to watch real people use the product.
+
+---
+
+## Test on Their Turf
+
+The gold standard for usability testing is **contextual testing** — testing the product on the user's own devices, in their own environment. At their home. In their office. On their phone, their laptop, their browser.
+
+This gives the most reliable results because the user isn't distracted by being in a test session. They're using a product in context, the way they actually would.
+
+Compared to a lab setting or a video call with screen sharing, contextual testing reveals:
+
+- How the product fits into their real workflow
+- What distracts them in their actual environment
+- Whether the design works on their specific device and screen size
+- Their natural behavior — not their "I'm being tested" behavior
+
+---
+
+## Think-Aloud: The Core Method
+
+### Contextual Think-Aloud
+
+The user talks through what they're doing as they do it:
+
+> "I'm looking for where to sign up... I see this button but I'm not sure if that's it... OK I'll click it... Now it wants my email..."
+
+You observe and take notes. You don't help. You don't guide. You listen.
+
+### Retrospective Think-Aloud
+
+The session is recorded. Afterward, you watch the recording together with the user:
+
+> "Here I was confused because I didn't know if my password was saved. I waited for a confirmation but nothing happened."
+
+Retrospective think-aloud is powerful because the user isn't splitting attention between doing and explaining. They perform naturally first, then reflect.
+
+### Which to Use
+
+| Method | When | Trade-off |
+|--------|------|-----------|
+| Contextual think-aloud | Quick tests, guerrilla testing | User splits attention between doing and explaining |
+| Retrospective think-aloud | Formal sessions, critical flows | Takes longer but gives richer insight |
+| Both combined | When you have time | Best results |
+
+---
+
+## Record Everything
+
+Always record the session. Always.
+
+When you're running the test, you're focused on the user — their body language, their hesitation, what they say. You miss things. Recording lets you review the tape and spot what you didn't catch the first time.
+
+A recorded session gives you:
+
+- Exact moments of confusion (timestamp them)
+- Quotes you can use to justify design changes
+- Evidence for stakeholders who weren't there
+- Details you missed because you were watching the user's face, not the screen
+
+---
+
+## Plan Ahead
+
+The biggest usability testing failure is not having testers ready when the prototype is.
+
+**Before you start building:**
+
+1. Identify 3-5 people who match your personas
+2. Ask them if they're available for a 20-minute session this week (or next)
+3. Get their confirmation
+
+**When the prototype is ready:**
+
+4. Send them the link or visit them
+5. Run the test
+6. Process results the same day while it's fresh
+
+Total overhead: one message before, one session after. Testing doesn't slow you down — because you planned for it.
+
+---
+
+## When to Test
+
+```
+  WDS Stage                     What to Test
+  ─────────                     ────────────
+
+  Storyboards ─────────────── Does the flow make sense?
+       │                       Are we solving the right problem?
+       ▼
+  Prototypes ──────────────── Can users complete the task?
+       │                       Where do they hesitate?
+       ▼
+  Production ──────────────── Does it work in the real context?
+                               How does it perform with real data?
+```
+
+**Prototypes are the sweet spot.** The design is real enough to test, cheap enough to change.
+
+---
+
+## The Freya Method
+
+Freya connects usability findings to your design strategy:
+
+> "Three of five users struggled to find the registration link. This connects to Felix's driving force — he needs simple paths with no hunting."
+
+> "Users understood the error messages but didn't know how to fix the problem. The spec tells them what's wrong but not what to do."
+
+> "The flow works technically, but users feel uncertain at step 2. They need a progress indicator or reassurance."
+
+She maps observations to personas, driving forces, and business goals — turning individual findings into design decisions.
+
+---
+
+## What You'll Learn
+
+### Lesson 1: The Test Scenario
+
+How to prepare for a usability test — picking the flow, writing tasks that reveal real behavior, selecting participants, preparing materials, and creating the test scenario document.
+
+### Lesson 2: Conducting the Test
+
+How to run the session — presenting the same information to every participant, observing in silence, deflecting questions, recording everything, and using the retrospective replay to unlock deeper insights.
+
+### Lesson 3: Acting on Findings
+
+How to review recordings, document usability issues, connect them back to specifications and trigger maps, prioritize what to fix, and feed learning into the next iteration.
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| No testers lined up when prototype is ready | Plan ahead — recruit before you start building |
+| Testing in a lab or conference room | Go to their environment, their devices |
+| Helping users when they struggle | Observe silently — the struggle is the data |
+| Not recording | Always record, you'll miss things live |
+| Asking "do you like it?" | Watch behavior, don't ask for opinions |
+| Fixing symptoms | Trace issues to root causes in specifications |
+| Testing too much at once | One flow per session, 3-5 tasks maximum |
+
+---
+
+## Practice
+
+Pick one flow from your project:
+
+1. Define 3 tasks a user should be able to complete
+2. Find one person who matches your persona
+3. Give them the prototype on their own device
+4. Watch them attempt the tasks — don't help
+5. Record the session
+6. Review the recording — what did you miss the first time?
+
+---
+
+## Lessons
+
+### [Lesson 1: The Test Scenario](lesson-01-spec-verification.md)
+Preparing everything before the user arrives
+
+### [Lesson 2: Conducting the Test](lesson-02-test-results.md)
+The session, the silence, and the replay
+
+### [Lesson 3: Acting on Findings](lesson-03-acting-on-findings.md)
+Turning observations into design improvements
+
+---
+
+## Tutorial
+
+### [Tutorial 17: Plan Your Usability Test](tutorial-17.md)
+Hands-on guide to preparing and running a usability test session
+
+---
+
+## Next Module
+
+**[Module 18: Product Evolution →](../module-18-product-evolution/module-18-product-evolution-overview.md)**
+
+Products don't end at launch.
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
diff --git a/docs/learn/module-17-usability-testing/tutorial-17.md b/docs/learn/module-17-usability-testing/tutorial-17.md
new file mode 100644
index 000000000..47225fff7
--- /dev/null
+++ b/docs/learn/module-17-usability-testing/tutorial-17.md
@@ -0,0 +1,301 @@
+# Tutorial 17: Plan Your Usability Test
+
+**Hands-on guide to preparing and running a usability test session**
+
+---
+
+## Overview
+
+This tutorial walks you through planning a usability test for one of your flows. You'll define tasks, recruit participants, run a session, and document findings.
+
+**Time:** 30 minutes for planning, 20 minutes per test session
+**Prerequisites:** A working prototype (Module 14) or delivered implementation (Module 16)
+**Agent:** Freya
+**What you'll create:** Test plan, observation notes, and findings document
+
+---
+
+## Before You Start
+
+**You'll need:**
+
+- A working prototype or implementation of one flow
+- Access to 1-3 people who roughly match your personas
+- A way to record (phone camera, screen recording, or video call)
+
+**Freya will help you:**
+
+- Define good test tasks
+- Prepare the session structure
+- Analyze findings afterward
+- Connect findings to specs and trigger maps
+
+---
+
+## Step 1: Choose the Flow (5 min)
+
+Pick one flow to test. Not the whole product — one flow.
+
+**Good choices:**
+- The primary user journey (signup, onboarding, first action)
+- A flow you're uncertain about
+- A flow with many interaction steps
+
+**You say to Freya:**
+> "I want to plan a usability test for the user registration flow. Help me define test tasks."
+
+**Freya responds:**
+> "Good choice — registration is the first impression. Let's define tasks that test the complete journey without leading the participant."
+
+---
+
+## Step 2: Define Tasks (5 min)
+
+Write 3-5 tasks. Each task should:
+- Describe a goal, not a path
+- Be something a real user would actually need to do
+- Be completable in 2-5 minutes
+
+**Freya suggests:**
+
+```markdown
+## Test Tasks: User Registration Flow
+
+### Task 1: Create an account
+"You've heard about [product name] and want to try it.
+Go ahead and create an account."
+
+### Task 2: Understand what you signed up for
+"You just created your account. What can you do now?
+Take a look around."
+
+### Task 3: Find your account settings
+"You want to change your email notification preferences.
+See if you can find where to do that."
+```
+
+**Review the tasks.** Are they realistic? Do they avoid leading the user? Adjust if needed.
+
+---
+
+## Step 3: Prepare the Session (5 min)
+
+### Create a session template:
+
+```markdown
+# Usability Test Session
+
+## Flow: User Registration
+## Date: [Date]
+## Participant: [Name or P1, P2, etc.]
+## Location: [Their home / office / remote]
+## Recording: [Yes/No, method]
+
+## Introduction Script
+"Thanks for helping me test this. I'm testing the design,
+not you — there are no wrong answers. Please think out loud
+as you go. I won't be able to help during the tasks."
+
+## Tasks
+1. Create an account
+2. Understand what you signed up for
+3. Find account settings
+
+## Observation Notes
+[To be filled during session]
+
+## Post-Session Questions
+- What stood out to you?
+- Was anything confusing or unexpected?
+- If you could change one thing, what would it be?
+```
+
+### Recruit participants:
+
+Send a message to 3-5 people:
+
+> "Hi! I'm working on a product and would love 20 minutes of your time to try it out. No preparation needed — just use it and tell me what you think. Available this week?"
+
+---
+
+## Step 4: Run the Session (20 min per participant)
+
+### Start recording.
+
+### Read the introduction script.
+
+### Give Task 1. Observe silently.
+
+Take notes:
+
+```markdown
+## Observation Notes — P1
+
+### Task 1: Create an account
+- 0:00 — Looks at the page, scrolls down
+- 0:12 — Scrolls back up, looking for something
+- 0:18 — "Where do I sign up?"
+- 0:23 — Finds button, clicks it
+- 0:35 — Fills in email quickly
+- 0:42 — Pauses at password field, reads helper text
+- 0:55 — Submits form
+- 1:02 — "Oh, it worked. That was easy."
+- Completed: Yes
+- Time: 1:02
+- Issues: Didn't see CTA immediately (18 seconds searching)
+```
+
+### Give Task 2. Observe.
+
+### Give Task 3. Observe.
+
+### Ask post-session questions. Note answers.
+
+### Stop recording. Thank them.
+
+---
+
+## Step 5: Review and Analyze (15 min)
+
+### Watch the recording
+
+After all sessions are done, review the recordings. Look for patterns.
+
+**You say to Freya:**
+> "I tested the registration flow with 3 participants. Here are my observation notes. Help me identify patterns and create findings."
+
+### Freya analyzes:
+
+> "Pattern 1: All three participants took 15-20 seconds to find the registration button. This is a critical visibility issue — the CTA is below the fold."
+
+> "Pattern 2: Two participants hesitated at the password field. They weren't sure about the requirements. The helper text says '8+ characters' but they expected to see the full requirements before typing."
+
+> "Participant 3 completed everything smoothly — they match the tech-savvy persona. The issues appear persona-specific: less tech-comfortable users struggled more."
+
+---
+
+## Step 6: Document Findings (10 min)
+
+### Create the findings document:
+
+```markdown
+# Usability Findings: User Registration Flow
+## Test Date: 2026-02-15
+## Participants: 3
+## Method: Contextual think-aloud
+
+## Finding 1: Registration CTA not visible
+**Severity:** Critical
+**Observed in:** 3 of 3 participants
+**Task:** Create an account
+**Timestamps:** P1 0:18, P2 0:22, P3 0:08
+
+### What happened
+All participants scrolled or searched before finding the
+registration button. Average time to find: 16 seconds.
+
+### Root cause
+P01 landing page: CTA is below the hero image.
+Visual hierarchy prioritizes imagery over action.
+
+### Recommendation
+Move CTA into hero section. Update spec P01 section 3.
+
+---
+
+## Finding 2: Password requirements unclear
+**Severity:** Major
+**Observed in:** 2 of 3 participants
+**Task:** Create an account
+**Timestamps:** P1 0:42, P2 0:38
+
+### What happened
+Users paused at password field. Helper text says "8+ characters"
+but users expected to see full requirements (uppercase, number, etc.)
+before typing.
+
+### Root cause
+P02 signup form: Helper text is minimal. Requirements only
+appear as error messages after the user types a password
+that doesn't meet them.
+
+### Recommendation
+Show full password requirements below the field from the start.
+Update spec P02 section 4.
+
+---
+
+## Summary
+- 1 critical finding (CTA visibility)
+- 1 major finding (password clarity)
+- 0 minor findings
+- Next step: Update specs, rebuild, test again
+```
+
+---
+
+## Step 7: Update Specs and Plan Next Round (5 min)
+
+### Update specifications:
+
+Based on findings, update the relevant page specs. Document what changed and why.
+
+### Plan the next test:
+
+> "After rebuilding with these changes, I'll test again with 3 new participants to verify the fixes work."
+
+---
+
+## What You've Created
+
+- **Test plan** with defined tasks and session structure
+- **Observation notes** from real user sessions
+- **Findings document** with severity, evidence, and recommendations
+- **Spec updates** based on evidence, not opinion
+- **Plan for next round** of testing
+
+---
+
+## Tips for Success
+
+**DO:**
+
+- Test on the user's own device in their own environment
+- Record every session
+- Observe silently during tasks
+- Process findings the same day
+- Connect findings to specs and personas
+
+**DON'T:**
+
+- Help the user when they struggle
+- Test with people who've seen the design before
+- Skip the recording
+- Wait a week to process findings (you'll forget details)
+- Change the design based on one user's opinion
+
+---
+
+## You've Completed Module 17!
+
+**You can now plan and run usability tests.** You've learned to:
+- Define tasks that reveal real usability issues
+- Observe without guiding
+- Record and review sessions
+- Document findings with evidence
+- Connect findings back to specifications
+- Plan iterative test rounds
+
+---
+
+## Next Module
+
+**[Module 18: Product Evolution →](../module-18-product-evolution/module-18-product-evolution-overview.md)**
+
+Products don't end at launch. Learn how to evolve them.
+
+---
+
+[← Back to Lesson 3](lesson-03-acting-on-findings.md) | [Back to Module Overview](module-17-usability-testing-overview.md)
+
+*Part of Module 17: Usability Testing*
diff --git a/docs/learn/module-18-product-evolution/lesson-01-continuous-improvement.md b/docs/learn/module-18-product-evolution/lesson-01-continuous-improvement.md
new file mode 100644
index 000000000..8de9b4a58
--- /dev/null
+++ b/docs/learn/module-18-product-evolution/lesson-01-continuous-improvement.md
@@ -0,0 +1,255 @@
+# Module 18: Product Evolution
+
+## Lesson 1: The Evolution Cycle
+
+**Running WDS in miniature for every change**
+
+---
+
+## One Change, Full Discipline
+
+A product evolution change — whether it's a new feature, a modification, a fix, or an optimization — follows the same WDS process you've learned throughout this course. The difference is scope. Instead of building a whole product, you're improving one part of it.
+
+The Product Evolution Agent Dialog organizes this cycle. It's the same Agent Dialog from Module 14, with one addition: **context** — what exists today and why it needs to change.
+
+---
+
+## Step 1: Receive and Connect
+
+### Something triggers the change
+
+Changes come from:
+- **User feedback** — "The password requirements aren't clear"
+- **Usability testing** — "3 of 5 users couldn't find the settings page"
+- **Analytics** — "40% drop-off at step 2 of checkout"
+- **Business need** — "We need to support a new payment method"
+- **Bug report** — "Error message shows wrong text on mobile"
+
+### Connect to the Trigger Map
+
+Before doing anything else, trace the change to your strategy:
+
+- **Which persona** does this serve?
+- **Which driving force** does it address?
+- **Which business goal** does it advance?
+
+If it doesn't connect, apply the Whiteport Rule: if it's not worth showing to 5 users and 1 domain expert, it shouldn't be built.
+
+> Change: "Users report password requirements unclear"
+> Persona: Felix — wants quick, frictionless onboarding
+> Driving force: Efficiency — don't waste my time
+> Business goal: Reduce signup abandonment
+
+Connected. Proceed.
+
+---
+
+## Step 2: Start the Agent Dialog
+
+Create the dialog with context about what exists and what needs to change:
+
+```markdown
+# Agent Dialog: Password Requirements Clarity
+
+## Meta
+- Date: 2026-03-15
+- Type: Feature modification
+- Input: User feedback + usability test findings
+- Agent: Idunn
+- Branch: fix/password-requirements
+- Status: In Progress
+
+## Context
+Current state: Password field shows "At least 8 characters" as helper
+text. Full requirements only appear as error messages after the user
+submits a password that doesn't meet them.
+
+Problem: Users don't know the requirements until they fail.
+3 of 5 usability test participants hesitated at the password field.
+
+Trigger Map: Felix — efficiency driving force.
+Business: Signup funnel shows 15% drop-off at password step.
+
+## Scope
+Change: Show password requirements upfront, before the user types.
+Keep: Password strength indicator, validation behavior.
+Don't touch: Other form fields, submission flow.
+```
+
+The context section is what makes evolution dialogs different from greenfield. You're not starting from nothing — you're describing what's there and what needs to be different.
+
+---
+
+## Step 3: Review and Update the Specification
+
+### Read the current spec
+
+Before changing anything, read the existing specification for the affected page or flow. Understand what was designed and why.
+
+> "Current spec P02-signup-form.md says:
+> Password field helper text: 'At least 8 characters'
+> Validation: On blur, check 8+ chars, 1 number, 1 letter
+> Error: 'Password must be at least 8 characters with a number and letter'"
+
+### Update the specification
+
+Make the change in the spec first. The spec is the source of truth.
+
+```markdown
+#### Password Field (updated v1.2)
+- Helper text: "8+ characters, including a number and letter"
+- Requirements: Shown below field at all times (not just on error)
+- Validation: On blur (unchanged)
+- Strength indicator: Appears on typing (unchanged)
+```
+
+### Add to the changelog
+
+```markdown
+### v1.2 (2026-03-15)
+- Changed: Password helper text shows full requirements upfront
+- Reason: User feedback — 3/5 users confused by hidden requirements
+- Connection: Felix — efficiency driving force
+```
+
+---
+
+## Step 4: Build the Change
+
+The agent implements from the updated spec — exactly as in Module 14.
+
+### Tasks in the Agent Dialog:
+
+```markdown
+## Tasks
+1. [x] Review current specification
+2. [x] Update specification with change
+3. [ ] Implement helper text update
+4. [ ] Agent verifies against updated spec (Puppeteer)
+5. [ ] Verify unchanged functionality still works
+6. [ ] Update design system if needed
+```
+
+### The agent builds and verifies:
+
+> "Updating password field helper text..."
+> "Opening signup form at localhost:3000/signup..."
+> "Helper text reads '8+ characters, including a number and letter' — matches updated spec. ✓"
+> "Requirements visible before typing — confirmed. ✓"
+> "Entering short password, blurring... error message appears correctly. ✓"
+> "Strength indicator still functions on typing. ✓"
+> "Email field unchanged — verified. ✓"
+
+Build, verify, evaluate — same loop, smaller scope.
+
+---
+
+## Step 5: Test
+
+### Functional testing
+
+The agent verifies with Puppeteer during development (Module 14). By the time you finish building, functional testing is already done.
+
+### Usability testing
+
+Apply the Whiteport Rule. Is this change worth showing to 5 users?
+
+For a password requirements update — probably yes, because the original problem came from usability testing. You want to verify the fix actually works. But you might run a quick guerrilla test instead of a full session.
+
+For a color fix or typo correction — probably no. Functional verification is enough.
+
+---
+
+## Step 6: Deliver and Document
+
+### Create the delivery
+
+For changes that go through development review, create a DD (Module 16). For small changes you implement yourself, document in the Agent Dialog.
+
+### Close the dialog
+
+```markdown
+## Meta
+- Status: Complete
+
+## Summary
+Updated password field to show requirements upfront.
+Spec updated to v1.2. All tests passing.
+One guerrilla test confirmed improvement.
+
+## Log
+### Step 1: Review spec (completed)
+- Current spec clear but requirements hidden until error
+- Identified gap between spec intent and user experience
+
+### Step 2: Update spec (completed)
+- Helper text now includes full requirements
+- Changelog updated with reason and connection
+
+### Step 3: Implement (completed)
+- Updated helper text component
+- Requirements now render on page load
+- Commit: "Show password requirements upfront per spec v1.2"
+
+### Step 4: Verify (completed)
+- Puppeteer confirmed: text matches, requirements visible,
+  validation still works, other fields unchanged
+
+### Step 5: Test (completed)
+- Guerrilla test: 1 user completed signup without hesitation
+  at password field (previously 3/5 hesitated)
+```
+
+---
+
+## The Cycle Scales
+
+The same cycle works for everything:
+
+| Change Size | What You Do |
+|-------------|-------------|
+| **Typo fix** | Check spec → Fix → Verify → Commit |
+| **Small modification** | Connect → Update spec → Build → Verify → Document |
+| **New feature** | Full WDS cycle: Trigger map → Scenario → Spec → Build → Test → Deliver |
+| **Major redesign** | Full WDS cycle with sketching, storyboarding, and formal usability testing |
+
+Small changes skip steps. Large changes use every step. The discipline is the same — you just apply as much process as the change requires.
+
+---
+
+## Avoiding Spec Drift
+
+Over time, specs and reality can diverge. This is the biggest risk in brownfield development.
+
+### Prevention
+
+- **Update specs with every change.** No exceptions.
+- **Version your specs.** Changelogs show what changed and why.
+- **Let the agent verify.** Puppeteer catches drift automatically.
+
+### Recovery
+
+If specs are already out of date:
+
+1. Audit the current implementation
+2. Update specs to match reality
+3. Document intentional differences
+4. Resume the evolution cycle from there
+
+This is normal in brownfield. Don't feel guilty — just fix it and move forward.
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn the discipline of updating specifications before touching code — and how the agent projects those changes into the codebase.
+
+---
+
+**[Continue to Lesson 2: Update the Spec — Project the Code →](lesson-02-update-spec-project-code.md)**
+
+---
+
+[← Back to Module Overview](module-18-product-evolution-overview.md)
+
+*Part of Module 18: Product Evolution*
diff --git a/docs/learn/module-18-product-evolution/lesson-02-update-spec-project-code.md b/docs/learn/module-18-product-evolution/lesson-02-update-spec-project-code.md
new file mode 100644
index 000000000..f16f6fb97
--- /dev/null
+++ b/docs/learn/module-18-product-evolution/lesson-02-update-spec-project-code.md
@@ -0,0 +1,229 @@
+# Module 18: Product Evolution
+
+## Lesson 2: Update the Spec — Project the Code
+
+**The specification changes first. The code follows.**
+
+---
+
+## Spec First, Always
+
+In greenfield, the specification is the blueprint. You write it, then you build from it.
+
+In brownfield, the specification is also the record. It describes what exists today. When you change the product, you change the spec first — then project that change into the code.
+
+This is the single most important discipline in product evolution. Skip it, and specs drift from reality. Within months, nobody knows what's current. The spec says one thing, the product does another, and every future change becomes guesswork.
+
+---
+
+## Reading the Current Spec
+
+Before you change anything, read what's there.
+
+**You say to the agent:**
+> "Read the current specification for the signup form — P02-signup-form.md."
+
+**The agent reads and summarizes:**
+> "Current password field spec:
+> - Label: 'Password'
+> - Helper text: 'At least 8 characters'
+> - Validation: On blur — 8+ chars, 1 number, 1 letter
+> - Error message: 'Password must be at least 8 characters with a number and letter'
+> - Strength indicator: Appears on typing"
+
+Now you know exactly what exists. You know the designed intent, the states, the validation rules. You're not guessing from looking at the live product — you're reading the source of truth.
+
+### What if the spec doesn't match reality?
+
+This happens. Code changes sneak in without spec updates. A developer fixes something in production. A quick patch that was never documented.
+
+When you find drift:
+
+1. **Note it** — Document the discrepancy in the Agent Dialog
+2. **Decide** — Does reality match the original intent, or has it drifted in a useful direction?
+3. **Update the spec** — Make the spec match what should be true, whether that's the current state or the intended change
+4. **Then proceed** — Now you're working from an accurate baseline
+
+Don't pretend drift doesn't exist. Acknowledge it, fix the spec, and move forward.
+
+---
+
+## Making the Spec Change
+
+The change you're making gets written into the specification before a single line of code changes.
+
+### What to update
+
+**The element itself** — New values, new behavior, new states.
+
+```markdown
+#### Password Field (v1.2)
+- Label: "Password"
+- Helper text: "8+ characters, including a number and letter"
+- Requirements: Shown below field at all times
+- Validation: On blur — check 8+ chars, 1 number, 1 letter
+- Error: Red border + message
+- Strength indicator: Appears on typing
+```
+
+**The changelog** — What changed, why, and where it connects to strategy.
+
+```markdown
+### Changelog
+#### v1.2 (2026-03-15)
+- Changed: Password helper text shows full requirements upfront
+- Reason: Usability testing — 3/5 users confused by hidden requirements
+- Connection: Felix — efficiency driving force
+```
+
+**The version number** — Increment it. Every change gets a version. This creates a trail you can follow backward through the product's history.
+
+### What to preserve
+
+Mark unchanged elements explicitly. This prevents the agent — or a future reader — from wondering whether something was intentionally kept or accidentally missed.
+
+```markdown
+- Validation: On blur (unchanged)
+- Strength indicator: Appears on typing (unchanged)
+- Email field: Not affected by this change
+```
+
+The word "unchanged" is documentation. It says: we looked at this, we decided to keep it.
+
+---
+
+## Projecting into Code
+
+With the spec updated, the agent builds from it. This is the same agentic development loop from Module 14 — but the starting point is an existing codebase, not a blank project.
+
+### The agent reads the updated spec
+
+**You say:**
+> "Implement the spec change for the password field. The updated spec is P02-signup-form.md v1.2."
+
+The agent reads the spec, finds the changed elements, and identifies what code to modify.
+
+### The agent finds the current implementation
+
+> "Found password field component at src/components/SignupForm/PasswordField.tsx"
+> "Current helper text: 'At least 8 characters'"
+> "Requirements display: Conditional — only shown on validation error"
+
+### The agent makes the change
+
+> "Updating helper text to '8+ characters, including a number and letter'"
+> "Changing requirements display from conditional to always visible"
+> "Preserving: validation logic, strength indicator, error styling"
+
+### The agent verifies with Puppeteer
+
+> "Opening localhost:3000/signup..."
+> "Helper text: '8+ characters, including a number and letter' — matches spec v1.2. ✓"
+> "Requirements visible before typing — confirmed. ✓"
+> "Blur validation still triggers. ✓"
+> "Strength indicator still works. ✓"
+> "Email field unchanged. ✓"
+
+The updated spec is the acceptance criteria. The agent checks each element against what the spec now says. Pass or fail — no ambiguity.
+
+---
+
+## The Scope Boundary
+
+The Agent Dialog defines what changes and what doesn't. The spec update makes this concrete.
+
+When the agent is working, it has a clear boundary:
+
+- **Changed elements** — Implement exactly as the updated spec describes
+- **Unchanged elements** — Verify they still work, but don't modify them
+- **Out of scope** — Don't touch. Don't even look at.
+
+This is how you prevent a small change from snowballing. The password field helper text changes. The email field doesn't. The form layout doesn't. The submission flow doesn't.
+
+If the agent discovers something out of scope that needs attention — a bug, a related improvement, an inconsistency — it logs it in the Agent Dialog for a future cycle. It doesn't fix it now.
+
+```markdown
+## Notes
+- Noticed: Submit button text could be clearer ("Create Account" vs "Sign Up")
+- Not in scope for this dialog — log for future evaluation
+```
+
+Discipline means doing one thing well, not three things halfway.
+
+---
+
+## Version History as Product Memory
+
+Over time, your specifications accumulate changelogs. This is your product's memory.
+
+```markdown
+### Changelog
+#### v1.3 (2026-04-20)
+- Added: Password visibility toggle
+- Reason: Accessibility audit finding
+- Connection: All personas — universal usability
+
+#### v1.2 (2026-03-15)
+- Changed: Password helper text shows full requirements upfront
+- Reason: Usability testing — 3/5 users confused
+- Connection: Felix — efficiency driving force
+
+#### v1.1 (2026-02-01)
+- Added: Password strength indicator
+- Reason: Security requirement from domain expert review
+- Connection: Business — reduce weak password incidents
+
+#### v1.0 (2026-01-15)
+- Initial specification
+```
+
+Every entry answers three questions:
+1. **What** changed?
+2. **Why** did it change?
+3. **Who** does it serve?
+
+When a new team member asks "why does the password field work this way?" — the answer is in the changelog. When someone proposes a change that was already tried and reverted — the history shows it. When you need to understand how a feature evolved — you read the versions, not the git log.
+
+The spec changelog is the design decision record. Git tracks what code changed. The spec tracks why.
+
+---
+
+## When to Write a New Spec vs. Update an Existing One
+
+### Update the existing spec when:
+
+- You're modifying an element that's already specified
+- The change affects behavior, content, or appearance of a documented component
+- The page or flow already has a specification
+
+This is most evolution work. You're changing what's there.
+
+### Create a new spec when:
+
+- You're adding a completely new page or flow
+- The new feature has no existing specification to extend
+- The scope is large enough that adding to an existing spec would make it unwieldy
+
+New specs follow the same format from Module 11. They just happen to live alongside existing ones.
+
+### Never skip the spec
+
+Even for a "quick fix." Even for "just a text change." If it changes what the user sees or experiences, it belongs in a specification.
+
+The cost of updating a spec is minutes. The cost of spec drift is hours — spent later, by someone who doesn't remember why things are the way they are.
+
+---
+
+## What's Next
+
+In the tutorial, you'll run a complete evolution cycle — from receiving feedback to closing the Agent Dialog with a verified change.
+
+---
+
+**[Continue to Tutorial: Evolve Your Product →](tutorial-18.md)**
+
+---
+
+[← Back to Lesson 1](lesson-01-continuous-improvement.md) | [Module Overview](module-18-product-evolution-overview.md)
+
+*Part of Module 18: Product Evolution*
diff --git a/docs/learn/module-18-product-evolution/module-18-product-evolution-overview.md b/docs/learn/module-18-product-evolution/module-18-product-evolution-overview.md
new file mode 100644
index 000000000..c92a97984
--- /dev/null
+++ b/docs/learn/module-18-product-evolution/module-18-product-evolution-overview.md
@@ -0,0 +1,253 @@
+# Module 18: Product Evolution
+
+**Time: 30 min | Agent: Freya + Idunn | Phase: Continuous**
+
+---
+
+## Greenfield and Brownfield
+
+In software development, there are two starting points:
+
+**Greenfield** — Building something from scratch. No existing code, no existing users, no constraints from previous decisions. You start with a blank page. This is what the course has been about so far.
+
+**Brownfield** — Working with something that already exists. There's a live product, real users, existing code, accumulated design decisions, and technical debt. You're not starting from zero — you're improving what's there.
+
+Most of your career will be brownfield. Products don't end at launch. They evolve.
+
+---
+
+## This Is Where You Start
+
+If you already have a product in production and want to improve it, this module is your entry point.
+
+You don't need to rebuild everything from scratch using WDS. You can adopt the methodology incrementally, one change at a time.
+
+Every improvement — a new feature, a redesign, a fix — becomes an opportunity to apply creative discipline. Over time, the product accumulates specifications, traceability, and design system components. The brownfield becomes greener with every iteration.
+
+---
+
+## WDS in Miniature
+
+Here is the key insight: **product evolution follows the exact same WDS process, just compressed.**
+
+Every change you make to a living product walks through the same steps you learned in this course — but smaller, faster, and focused on a single improvement.
+
+Here is the full WDS process and how each module maps to an evolution cycle:
+
+### Strategy (Where does this change come from?)
+
+**Product Brief (Module 4)** — You don't write a new brief for every change. But the original brief still anchors your decisions. When someone requests a feature, check: does it align with the product's purpose? If there is no brief, write one now. It's never too late.
+
+**Trigger Map (Module 6)** — Every change should trace to a persona, a driving force, or a business goal. If it doesn't connect, question whether it should happen. The trigger map is your filter against feature creep.
+
+### Design (What does the change look like?)
+
+**Scenarios (Module 8)** — For larger changes, outline the scenario. What's the user journey? Where does the user start, what do they do, where do they end up?
+
+**Sketching & Storyboarding (Modules 9-10)** — For complex features, sketch the concept before specifying. For smaller changes, you can skip straight to specification.
+
+**Specifications (Module 11)** — Update the existing specification, or create a new one. Every element, every state, every interaction — documented. This is the source of truth.
+
+**Components (Module 12-13)** — Does this change require new components? Can existing ones be reused? The design system grows with the product.
+
+### Build (How do we implement it?)
+
+**Agentic Development (Module 14)** — Start an Agent Dialog. The agent builds the change from the specification while verifying with Puppeteer.
+
+**Visual Design (Module 15)** — Does the change need visual polish? Apply the same design layer process — code first, Figma when needed.
+
+**Design Delivery (Module 16)** — Package the change as a DD. Same format, same handoff process, smaller scope.
+
+### Validate (Does it work?)
+
+**Usability Testing (Module 17)** — Is the change worth testing with users? Apply the Whiteport Rule: if it's not worth showing to 5 users and 1 domain expert, it shouldn't be built. If it is worth building, test it.
+
+---
+
+## The Product Evolution Agent Dialog
+
+The Agent Dialog is the container for every change. In greenfield, it organizes a build session. In brownfield, it organizes an evolution cycle.
+
+The structure is identical:
+
+```markdown
+# Agent Dialog: [Change Name]
+
+## Meta
+- Date: 2026-03-15
+- Type: Evolution (feature | modification | fix | optimization)
+- Input: User feedback / analytics / business request
+- Agent: Idunn
+- Branch: fix/password-requirements
+- Status: In Progress
+
+## Context
+What exists today and why it needs to change.
+Trigger Map connection: which persona, driving force, business goal.
+
+## Scope
+What we're changing. What we're not touching.
+
+## Tasks
+1. [ ] Review current specification
+2. [ ] Update specification with change
+3. [ ] Implement change
+4. [ ] Agent verifies against updated spec
+5. [ ] Test with users (if applicable)
+6. [ ] Create DD for the change
+7. [ ] Update design system (if applicable)
+
+## Requirements
+- Must not break existing functionality
+- Must maintain design system consistency
+- Must connect to trigger map
+
+## Test Protocol
+- [ ] Changed functionality works as specified
+- [ ] Unchanged functionality still works
+- [ ] All states handled
+- [ ] Accessible
+```
+
+Same structure. Same discipline. The steps are the same — the scope is smaller.
+
+---
+
+## The 6-Activity Kaizen Cycle
+
+Phase 8 is **menu-driven** — each improvement cycle picks the activity it needs:
+
+```
+[A] Analyze Product      — Understand what exists, identify targets
+[S] Scope Improvement    — Define the change, write the scenario
+[D] Design Solution      — Design the change (borrows from Phase 4)
+[I] Implement            — Build the change (borrows from Phase 5)
+[T] Acceptance Test      — Verify against specs (borrows from Phase 5)
+[P] Deploy               — Package and deliver (borrows from Phase 4)
+```
+
+This is a **Kaizen cycle** — continuous, incremental improvement. After deploying one change, you return to [A] Analyze for the next opportunity.
+
+---
+
+## Types of Evolution
+
+### Feature Additions → [A] → [S] → [D] → [I] → [T] → [P]
+
+A new capability that didn't exist before. This is the closest to greenfield within brownfield — you're adding something new to an existing product.
+
+**Full cycle through all 6 activities.**
+
+### Feature Modifications → [A] → [S] → [D] → [I] → [T] → [P]
+
+An existing capability needs to change. User feedback, business pivot, or better idea.
+
+**Same cycle, but [A] Analyze focuses on the existing implementation and [S] Scope defines what changes vs what stays.**
+
+### Bug Fixes → [A] → [I] → [T] → [P]
+
+Something doesn't work as specified.
+
+**Shortened cycle — skip [S] Scope and [D] Design if the spec is correct. Go straight to implementation.**
+
+### Optimizations → [A] → [S] → [I] → [T] → [P]
+
+Same functionality, better experience. Faster, smoother, more accessible.
+
+**Skip [D] Design unless the optimization changes the visual. Focus on implementation and verification.**
+
+---
+
+## The Design System Grows
+
+Every evolution cycle is an opportunity to strengthen the design system.
+
+New component? Add it to the system. New pattern? Document it. Better approach to an existing component? Update the definition.
+
+Over time, the product accumulates:
+
+- Complete specifications for every page and flow
+- A growing component library
+- Documented decisions and rationale
+- Version history showing how the product evolved
+- Test results showing what works and what was changed
+
+The brownfield becomes as well-documented as a greenfield project — one change at a time.
+
+---
+
+## What You'll Learn
+
+### Lesson 1: The Evolution Cycle
+
+How to run a complete evolution cycle using the Product Evolution Agent Dialog — from receiving feedback through implementation and delivery. The same WDS steps, compressed for a single change.
+
+### Lesson 2: Update the Spec — Project the Code
+
+The discipline of changing the specification before touching code. How to read the current spec, make the change, version it, and project it into the codebase through the agent. Preventing spec drift in brownfield development.
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Skipping specification updates | Always update specs — even for small changes |
+| No trigger map connection | Every change serves a persona or business goal |
+| Fixing without understanding | Investigate root cause before changing code |
+| Letting specs drift from reality | Spec and implementation stay synchronized |
+| Not testing changes | Apply the Whiteport Rule |
+| Treating evolution as less rigorous | Same discipline, smaller scope |
+
+---
+
+## Lessons
+
+### [Lesson 1: The Evolution Cycle](lesson-01-continuous-improvement.md)
+Running WDS in miniature for every change
+
+### [Lesson 2: Update the Spec — Project the Code](lesson-02-update-spec-project-code.md)
+The specification changes first. The code follows.
+
+---
+
+## Tutorial
+
+### [Tutorial 18: Evolve Your Product](tutorial-18.md)
+Hands-on guide to running a complete evolution cycle
+
+---
+
+## Course Complete
+
+You've learned the full WDS methodology:
+
+1. **Strategy** — Product Brief, Trigger Map, Platform Requirements
+2. **Design** — Scenarios, Sketches, Storyboards, Specifications, Components, Design System
+3. **Build** — Agentic Development, Visual Design, Design Delivery
+4. **Validate** — Usability Testing
+5. **Evolve** — Product Evolution (this module)
+
+Whether you're starting from a blank page or improving a live product, the process is the same. The scope changes. The discipline doesn't.
+
+---
+
+## What's Next?
+
+- **Apply to a real project** — The only way to truly learn is to do
+- **Join the community** — [Discord](https://discord.gg/whiteport)
+- **Contribute** — WDS is open source
+- **Teach others** — Spread creative discipline
+
+**You are the linchpin.**
+
+---
+
+*Part of the WDS Course: From Designer to Linchpin*
+
+**[← Back to Course Overview](../00-course-overview/00-course-overview.md)**
+
+---
+
+*Created by Mårten Angner and the Whiteport team*
+*Part of the BMad Method ecosystem*
diff --git a/docs/learn/module-18-product-evolution/tutorial-18.md b/docs/learn/module-18-product-evolution/tutorial-18.md
new file mode 100644
index 000000000..3c18bc230
--- /dev/null
+++ b/docs/learn/module-18-product-evolution/tutorial-18.md
@@ -0,0 +1,293 @@
+# Tutorial 18: Evolve Your Product
+
+**Hands-on guide to running a complete evolution cycle**
+
+---
+
+## Overview
+
+This tutorial walks you through a product evolution cycle — from receiving user feedback to closing the Agent Dialog with a verified change.
+
+**Time:** 20-30 minutes
+**Prerequisites:** Understanding of WDS workflow (Modules 4-17)
+**Agent:** Idunn
+**What you'll practice:** The complete evolution cycle using the Product Evolution Agent Dialog
+
+---
+
+## The Change Request
+
+You've received this feedback from usability testing (Module 17):
+
+> "3 of 5 users hesitated at the password field. They didn't know the full requirements until they submitted and got an error. One user tried three times before getting it right."
+
+Your task: fix this using the evolution cycle.
+
+---
+
+## Step 1: Connect to Strategy (3 min)
+
+### Trace the feedback
+
+**You say to the agent:**
+> "We have usability feedback about password requirements. Help me connect this to our Trigger Map."
+
+**The agent analyzes:**
+> "Looking at your Trigger Map...
+>
+> Persona: Felix — values speed and efficiency
+> Driving force: 'Don't waste my time with unclear processes'
+> Business goal: Reduce signup abandonment (currently 15% drop-off at password step)
+>
+> This directly opposes Felix's core driving force. Proceed."
+
+### Apply the Whiteport Rule
+
+Is this worth showing to 5 users and 1 domain expert? Yes — the problem was found by testing with users. The fix should be verified the same way.
+
+---
+
+## Step 2: Create the Evolution Agent Dialog (5 min)
+
+**You say:**
+> "Create an Agent Dialog for this evolution. Type: feature modification. Context: password field requirements are hidden until error."
+
+**The agent creates:**
+
+```markdown
+# Agent Dialog: Password Requirements Clarity
+
+## Meta
+- Date: 2026-03-15
+- Type: Feature modification
+- Input: Usability test findings (Round 1)
+- Agent: Idunn
+- Branch: fix/password-requirements
+- Status: In Progress
+
+## Context
+Current: Password field shows "At least 8 characters" as helper text.
+Full requirements (8+ chars, 1 number, 1 letter) only appear as error
+messages after submission.
+
+Problem: Users don't know requirements until they fail. 3/5 users
+hesitated. 1 user needed 3 attempts.
+
+Trigger Map: Felix — efficiency driving force.
+Business: 15% drop-off at password step.
+
+## Scope
+Change: Show full requirements upfront before user types.
+Keep: Strength indicator, blur validation, error styling.
+Don't touch: Email field, form layout, submission flow.
+
+## Tasks
+1. [ ] Review current spec P02-signup-form.md
+2. [ ] Update spec with new requirements display
+3. [ ] Implement the change
+4. [ ] Verify with Puppeteer
+5. [ ] Verify unchanged functionality
+6. [ ] Quick guerrilla test
+7. [ ] Close dialog
+
+## Requirements
+- Must not change form layout or other fields
+- Requirements text must be clear without jargon
+- Must maintain WCAG AA compliance
+- Spec updated before implementation
+
+## Test Protocol
+- [ ] Helper text shows full requirements
+- [ ] Requirements visible before user types
+- [ ] Blur validation still triggers correctly
+- [ ] Error messages still appear on invalid input
+- [ ] Strength indicator still works
+- [ ] Email field unchanged
+- [ ] Touch targets maintained
+```
+
+**Review the dialog.** Does it cover everything? Adjust before proceeding.
+
+---
+
+## Step 3: Review and Update Spec (5 min)
+
+### Read current specification
+
+**The agent reads P02-signup-form.md:**
+> "Current password field spec:
+> - Label: 'Password'
+> - Helper text: 'At least 8 characters'
+> - Validation: On blur — 8+ chars, 1 number, 1 letter
+> - Error: 'Password must be at least 8 characters with a number and letter'
+> - Strength indicator: Appears on typing"
+
+### Update the specification
+
+**You say:**
+> "Update the spec: helper text should read '8+ characters, including a number and letter'. Requirements visible at all times, not just on error. Add changelog entry."
+
+**The agent updates P02-signup-form.md:**
+
+```markdown
+#### Password Field (v1.2)
+- Label: "Password"
+- Helper text: "8+ characters, including a number and letter"
+- Requirements: Shown below field at all times
+- Validation: On blur — check 8+ chars, 1 number, 1 letter
+- Error: Red border + "Password must be at least 8 characters
+  with a number and letter"
+- Strength indicator: Appears on typing
+```
+
+```markdown
+### Changelog
+#### v1.2 (2026-03-15)
+- Changed: Password helper text shows full requirements upfront
+- Reason: Usability testing — 3/5 users confused by hidden requirements
+- Connection: Felix — efficiency driving force
+```
+
+**The agent logs:**
+> "Tasks 1 and 2 complete. Spec updated to v1.2."
+
+---
+
+## Step 4: Implement and Verify (5 min)
+
+### Build the change
+
+**You say:**
+> "Implement the spec change. Then verify with Puppeteer."
+
+**The agent builds:**
+> "Updating password field component..."
+> "Helper text changed from 'At least 8 characters' to '8+ characters, including a number and letter'..."
+> "Requirements now render on page load instead of on error..."
+
+### Agent verifies with Puppeteer
+
+> "Opening signup form at localhost:3000/signup..."
+> "Helper text: '8+ characters, including a number and letter' — matches spec v1.2. ✓"
+> "Requirements visible before typing — confirmed. ✓"
+> "Entering 'short', blurring... error message appears. ✓"
+> "Entering valid password... strength indicator appears. ✓"
+> "Checking email field... unchanged. ✓"
+> "Touch target on submit button: 48px. ✓"
+> "6 of 6 criteria pass."
+
+**You evaluate:** Does it look right? Does the helper text feel clear? Is the visual hierarchy maintained?
+
+---
+
+## Step 5: Quick Usability Check (5 min)
+
+### Guerrilla test
+
+Grab someone nearby. Don't explain anything. Just say:
+
+> "Can you create an account on this?"
+
+Watch what happens at the password field. Do they hesitate? Do they read the requirements? Do they get it right the first time?
+
+**Result:**
+> User entered password on first attempt without hesitation. Read the requirements text, typed a valid password. Done.
+
+Compare to the original finding: 3 of 5 hesitated, 1 needed 3 attempts.
+
+One guerrilla test isn't statistically significant — but combined with the original finding, it confirms the direction is right.
+
+---
+
+## Step 6: Close the Dialog (3 min)
+
+### Commit and document
+
+**The agent commits:**
+> "Show password requirements upfront per spec v1.2"
+
+**Close the Agent Dialog:**
+
+```markdown
+## Meta
+- Status: Complete
+
+## Summary
+Updated password field to show requirements upfront.
+Spec updated to v1.2. Puppeteer verified 6/6 criteria.
+Guerrilla test confirmed improvement.
+
+## Log
+### Step 1: Review spec (completed)
+- Read P02-signup-form.md v1.1
+- Identified: requirements hidden until error
+
+### Step 2: Update spec (completed)
+- Helper text: "8+ characters, including a number and letter"
+- Requirements visible at all times
+- Changelog entry added with reason and connection
+
+### Step 3: Implement (completed)
+- Updated helper text component
+- Requirements render on page load
+- Commit: "Show password requirements upfront per spec v1.2"
+
+### Step 4: Verify (completed)
+- Puppeteer: 6/6 criteria pass
+- Helper text matches, requirements visible, validation works,
+  strength indicator works, email field unchanged
+
+### Step 5: Test (completed)
+- Guerrilla test: user completed password on first attempt
+- Original problem: 3/5 hesitated, 1 needed 3 attempts
+```
+
+---
+
+## What You've Practiced
+
+The complete evolution cycle:
+
+1. **Connected** feedback to Trigger Map and business goal
+2. **Created** an Evolution Agent Dialog with context
+3. **Updated** the specification before touching code
+4. **Built** from the updated spec
+5. **Verified** with Puppeteer during development
+6. **Tested** with a quick guerrilla session
+7. **Documented** everything in the Agent Dialog
+
+Same WDS process. Smaller scope. Full discipline.
+
+---
+
+## You've Completed the WDS Course!
+
+**Congratulations.** You've learned the full methodology:
+
+1. **Strategy** — Product Brief, Trigger Map, Platform Requirements
+2. **Design** — Scenarios, Sketches, Storyboards, Specifications, Components, Design System
+3. **Build** — Agentic Development, Visual Design, Design Delivery
+4. **Validate** — Usability Testing
+5. **Evolve** — Product Evolution
+
+Whether you're starting from a blank page or improving a live product, the process is the same. The scope changes. The discipline doesn't.
+
+**You are the linchpin.**
+
+---
+
+## What's Next?
+
+- **Apply to a real project** — The only way to truly learn is to do
+- **Join the community** — [Discord](https://discord.gg/whiteport)
+- **Contribute** — WDS is open source
+- **Teach others** — Spread creative discipline
+
+---
+
+**[← Back to Lesson 2](lesson-02-update-spec-project-code.md)** | **[← Back to Module Overview](module-18-product-evolution-overview.md)** | **[Back to Course Overview](../00-course-overview/00-course-overview.md)**
+
+---
+
+*Created by Mårten Angner and the Whiteport team*
+*Part of Module 18: Product Evolution*
diff --git a/docs/learn/widgets/W01-task-list.md b/docs/learn/widgets/W01-task-list.md
new file mode 100644
index 000000000..7f518df23
--- /dev/null
+++ b/docs/learn/widgets/W01-task-list.md
@@ -0,0 +1,31 @@
+# Widget W01: Task List
+
+**Example widget specification for the WDS course**
+
+---
+
+## Coming Soon
+
+This is an example widget specification referenced from [Module 11: Conceptual Specifications](../module-11-conceptual-specifications/lesson-02-section-widget-specifications.md). It will demonstrate a complete widget specification for a task list component.
+
+---
+
+## Widget Overview
+
+| Property | Value |
+|----------|-------|
+| **ID** | W01 |
+| **Name** | Task List Widget |
+| **Type** | Interactive List |
+| **Context** | Dashboard Section |
+
+## Functionality
+
+- Displays user's assigned tasks
+- Allows status updates (tap to toggle)
+- Supports filtering by status and date
+- Infinite scroll with loading indicator
+
+---
+
+*This is a teaching example for the WDS course.*
diff --git a/docs/learn/widgets/W02-calendar.md b/docs/learn/widgets/W02-calendar.md
new file mode 100644
index 000000000..d7927b242
--- /dev/null
+++ b/docs/learn/widgets/W02-calendar.md
@@ -0,0 +1,31 @@
+# Widget W02: Calendar
+
+**Example widget specification for the WDS course**
+
+---
+
+## Coming Soon
+
+This is an example widget specification referenced from [Module 11: Conceptual Specifications](../module-11-conceptual-specifications/lesson-02-section-widget-specifications.md). It will demonstrate a complete widget specification for a calendar component.
+
+---
+
+## Widget Overview
+
+| Property | Value |
+|----------|-------|
+| **ID** | W02 |
+| **Name** | Calendar Widget |
+| **Type** | Interactive Calendar |
+| **Context** | Dashboard Section |
+
+## Functionality
+
+- Shows weekly view by default
+- Displays scheduled tasks and events
+- Allows drag-to-reschedule interactions
+- Supports day, week, and month views
+
+---
+
+*This is a teaching example for the WDS course.*
diff --git a/docs/learn/widgets/W02-product-card.md b/docs/learn/widgets/W02-product-card.md
new file mode 100644
index 000000000..ad3188b00
--- /dev/null
+++ b/docs/learn/widgets/W02-product-card.md
@@ -0,0 +1,31 @@
+# Widget W02: Product Card
+
+**Example widget specification for the WDS course**
+
+---
+
+## Coming Soon
+
+This is an example widget specification referenced from [Module 11: Conceptual Specifications](../module-11-conceptual-specifications/lesson-02-section-widget-specifications.md). It will demonstrate a complete widget specification for a product card component.
+
+---
+
+## Widget Overview
+
+| Property | Value |
+|----------|-------|
+| **ID** | W03 |
+| **Name** | Product Card Widget |
+| **Type** | Template Card |
+| **Context** | Product Grid Section |
+
+## Functionality
+
+- Template rendered N times from product data
+- Adapts to container width (responsive)
+- Shows product image, title, price, and action button
+- Hover state reveals additional details
+
+---
+
+*This is a teaching example for the WDS course.*
diff --git a/docs/learn/widgets/W03-quick-add.md b/docs/learn/widgets/W03-quick-add.md
new file mode 100644
index 000000000..36028772e
--- /dev/null
+++ b/docs/learn/widgets/W03-quick-add.md
@@ -0,0 +1,31 @@
+# Widget W03: Quick Add
+
+**Example widget specification for the WDS course**
+
+---
+
+## Coming Soon
+
+This is an example widget specification referenced from [Module 11: Conceptual Specifications](../module-11-conceptual-specifications/lesson-02-section-widget-specifications.md). It will demonstrate a complete widget specification for a quick-add component.
+
+---
+
+## Widget Overview
+
+| Property | Value |
+|----------|-------|
+| **ID** | W04 |
+| **Name** | Quick Add Widget |
+| **Type** | Floating Action |
+| **Context** | Global Overlay |
+
+## Functionality
+
+- Floating action button (bottom-right)
+- Opens task creation modal on tap
+- Persists across page scroll
+- Accessible via keyboard shortcut
+
+---
+
+*This is a teaching example for the WDS course.*
diff --git a/docs/models/models-guide.md b/docs/models/models-guide.md
index f59455d42..e1cccba6f 100644
--- a/docs/models/models-guide.md
+++ b/docs/models/models-guide.md
@@ -286,7 +286,7 @@ Want to dive deeper? Each model guide includes books, articles, videos, and webs
 ## Related Documentation
 
 - **[WDS Method Guides](../method/)** - How Whiteport applies these models
-- **[Learn WDS Course](../learn-wds/)** - Step-by-step learning path
+- **[Learn WDS Course](../learn/)** - Step-by-step learning path
 - **[Examples](../examples/)** - See models in action
 - **[Getting Started](../getting-started/)** - Quick start with WDS
 
diff --git a/docs/models/smart-goals-model.md b/docs/models/smart-goals-model.md
index e39dbc155..8d6793688 100644
--- a/docs/models/smart-goals-model.md
+++ b/docs/models/smart-goals-model.md
@@ -275,8 +275,8 @@ SMART goals are now standard practice in:
 
 **Related WDS Resources:**
 - [Phase 2: Trigger Mapping Guide](../method/phase-2-trigger-mapping-guide.md)
-- [Module 05: Trigger Mapping](../learn-wds/module-05-trigger-mapping/module-05-overview.md)
-- [Lesson 3: The Five Workshops](../learn-wds/module-05-trigger-mapping/lesson-03-five-workshops.md)
+- [Module 05: Trigger Mapping](../learn/module-05-trigger-mapping/module-05-overview.md)
+- [Lesson 3: The Five Workshops](../learn/module-05-trigger-mapping/lesson-03-five-workshops.md)
 
 ---
 
diff --git a/package.json b/package.json
index 3d2c52e16..d534aab23 100644
--- a/package.json
+++ b/package.json
@@ -32,7 +32,7 @@
     "src/module.yaml",
     "src/module-help.csv",
     "docs/getting-started/",
-    "docs/learn-wds/",
+    "docs/learn/",
     "docs/method/",
     "docs/models/",
     "docs/tools/"
diff --git a/tools/cli/lib/installer.js b/tools/cli/lib/installer.js
index 27b03c3bd..df354a173 100644
--- a/tools/cli/lib/installer.js
+++ b/tools/cli/lib/installer.js
@@ -248,7 +248,7 @@ class Installer {
    */
   async copyLearningMaterial(projectDir) {
     const learnDir = path.join(projectDir, '_wds-learn');
-    const learningDirs = ['getting-started', 'learn-wds', 'method', 'models', 'tools'];
+    const learningDirs = ['getting-started', 'learn', 'method', 'models', 'tools'];
     const excludeDirs = new Set(['course-explainers', 'Webinars']);
 
     for (const dir of learningDirs) {