diff --git a/DA Milestones/Project Spotlight/Q2 2026/scalus_spotlight_questions_q2_2026.md b/DA Milestones/Project Spotlight/Q2 2026/scalus_spotlight_questions_q2_2026.md
new file mode 100644
index 0000000..40effc6
--- /dev/null
+++ b/DA Milestones/Project Spotlight/Q2 2026/scalus_spotlight_questions_q2_2026.md	
@@ -0,0 +1,72 @@
+# Project Spotlight: Scalus
+
+**Project:** Scalus  
+**Format:** Cardano Project Spotlight, Recorded Conversation  
+**Quarter:** Q2 2026  
+**Official Site:** [scalus.org](https://scalus.org/)  
+**GitHub:** [github.com/scalus3/scalus](https://github.com/scalus3/scalus)  
+**X / Twitter:** [@Scalus3](https://x.com/Scalus3)
+
+---
+
+## Introductions
+
+- Can you start by introducing yourself, your background, and your role in the project?
+- For anyone watching who is hearing about Scalus for the first time, what is it in your own words?
+- What problem were you trying to solve when you started building it?
+- What brought you to Cardano specifically?
+
+---
+
+## What Scalus Is
+
+- Your team describes Scalus as a full smart contract development platform, not just a language. Can you walk us through what that platform includes?
+- What kind of developer naturally gravitates toward Scalus? Who is it built for?
+- One thing developers often ask about is whether they can use a single codebase across their full stack. How does Scalus approach that, and how far along is that vision today?
+
+---
+
+## Technical Architecture
+
+- Scalus compiles a subset of Scala 3 to Untyped Plutus Core. What does working within that subset feel like day to day for a developer?
+- Script size and execution budgets are a real concern on Cardano. How does Scalus help developers stay within those limits?
+- You ship a Cardano L1 node emulator as part of the platform, and you export it to JavaScript and TypeScript. What does that mean for teams that aren't using Scala at all?
+- Since Scalus sits between what a developer writes and what executes on-chain, how do developers build confidence that the compiled output faithfully represents their intent, and has the compiler itself been through any kind of security review?
+
+---
+
+## Developer Experience
+
+- Walk us through a typical development loop in Scalus: you've written a validator, now what? How do you test it, profile it, and debug it before you're ready to deploy?
+- Scalus supports IDE debugging with breakpoints and stepping through validator logic. What does that experience actually look like in practice?
+- What does the path to a local devnet look like? How does the YaciDevKit integration fit into that workflow?
+- For a developer who knows Scala but has never touched Cardano, what's the fastest path from zero to a deployed contract?
+
+---
+
+## Open Source, Community & Funding
+
+- Having gone through Project Catalyst, could you tell us how that experience has been, how has it shaped your roadmap and what it has enabled you to do that you couldn't have otherwise?
+- Scalus is Apache-2.0 licensed. What does that licensing choice say about how you want others to use and build on Scalus, and are there any formal partnerships or integrations in place today?
+- What's your strategy for ensuring the long-term sustainability of Scalus and its products?
+- What resources exist for developers today, whether that's documentation, starter templates, Discord, or mentorship?
+- For someone who wants to contribute, what does a good first contribution look like and where does the project most need help right now?
+
+---
+
+## Real-World Use & Ecosystem Fit
+
+- What is being built with Scalus today? Are there live protocols or dApps that developers can look at as a reference?
+- What ready-made resources does Scalus ship so developers don't have to start from scratch every time?
+- Where do you see Scalus fitting in the broader Cardano tooling stack alongside things like MeshJS, TX3, and other SDK-level tools?
+
+---
+
+## Roadmap & Closing
+
+- What's the one thing on your roadmap that you're most excited about and why?
+- Is there anything about Scalus that you think the Cardano community consistently underestimates or gets wrong?
+
+---
+
+_These questions are prepared for the Q2 2026 Developer Experience Working Group Project Spotlight series._
diff --git a/website/blog/2026-06-08-building-cardano-mcp-server.md b/website/blog/2026-06-08-building-cardano-mcp-server.md
index c561b48..fe815ec 100644
--- a/website/blog/2026-06-08-building-cardano-mcp-server.md
+++ b/website/blog/2026-06-08-building-cardano-mcp-server.md
@@ -259,4 +259,4 @@ Some governance metadata anchor URLs point to PDF documents, not CIP-100 JSON-LD
 - **Koios API**: [api.koios.rest](https://api.koios.rest)
 - **CIP-1694 spec**: [github.com/cardano-foundation/CIPs/tree/master/CIP-1694](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1694)
 - **Model Context Protocol**: [modelcontextprotocol.io](https://modelcontextprotocol.io)
-- **Session Notes**: [Session 18 — Working Group](../docs/working-group/sessions/q2-2026/18-cardano-mcp-server/session-notes/readme.md)
+- **Session Notes**: [Session 19 — Working Group](../docs/working-group/sessions/q2-2026/19-cardano-mcp-server/session-notes/readme.md)
diff --git a/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/_category_.json b/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/_category_.json
new file mode 100644
index 0000000..a98d40a
--- /dev/null
+++ b/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/_category_.json
@@ -0,0 +1,8 @@
+{
+  "label": "Session 18: AI in Cardano Dev Workflow",
+  "position": 18,
+  "link": {
+    "type": "generated-index",
+    "description": "How to use AI effectively for Cardano development."
+  }
+}
diff --git a/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/recordings/readme.md b/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/recordings/readme.md
new file mode 100644
index 0000000..6606461
--- /dev/null
+++ b/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/recordings/readme.md
@@ -0,0 +1,40 @@
+---
+title: "Session 18: Using AI in Your Cardano Dev Workflow - Recordings"
+sidebar_label: Recordings
+slug: /working-group/q2-2026/sessions/18-ai-dev-workflow/recordings
+---
+
+# Session 18: Using AI in Your Cardano Dev Workflow - Recordings
+
+- *(Recording coming soon. It will be linked here once published.)*
+
+{/*
+  TODO: When the recording is published, replace the line above with the block
+  below and fill in YOUR_VIDEO_ID.
+
+  ## Recording 1
+
+  🎥 **Using AI in Your Cardano Dev Workflow**
+
+  <iframe
+    src="https://www.youtube.com/embed/YOUR_VIDEO_ID"
+    title="Session 18: Using AI in Your Cardano Dev Workflow"
+    width="100%"
+    height="480"
+    allow="autoplay"
+    allowfullscreen
+    style={{border: 0, borderRadius: '12px', boxShadow: '0 16px 40px rgba(1, 40, 170, 0.18)'}}
+  />
+
+  - **Status**: Recording available above.
+  - **Highlights**:
+    - Why Cardano (eUTxO) is uniquely challenging for AI.
+    - Plan-first orchestration and grounding in `plutus.json`.
+    - MCP (Model Context Protocol) and skills for live, version-accurate context.
+    - Test-driven validator generation.
+    - AI verification gates in CI for maintainers; local models for token savings.
+*/}
+
+---
+
+*This recording belongs to the Q2 2026 Developer Experience Working Group.*
diff --git a/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/session-notes/readme.md b/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/session-notes/readme.md
new file mode 100644
index 0000000..e1d7603
--- /dev/null
+++ b/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/session-notes/readme.md
@@ -0,0 +1,205 @@
+---
+title: "Session 18: Using AI in Your Cardano Dev Workflow - Notes"
+sidebar_label: Session Notes
+slug: /working-group/q2-2026/sessions/18-ai-dev-workflow/session-notes
+---
+
+# Using AI in Your Cardano Dev Workflow
+
+AI coding tools are now standard in the developer toolkit. However, using them effectively on Cardano presents unique challenges compared to Web2 or account-based blockchain ecosystems. This session outlines a repeatable workflow for building **correct, secure, and cost-efficient** Cardano applications using AI, and it covers the tooling (MCP servers, skills, local models) that closes the gap between a generic AI assistant and a Cardano-aware one.
+
+:::warning A Caveat Up Front
+AI is not yet ready to build a full smart contract from a single prompt without friction. Expect to iterate across several prompts. The goal of this workflow is to reduce that number and to keep the developer firmly in control of correctness and security.
+:::
+
+---
+
+## The Workflow at a Glance
+
+The rest of these notes expand on this loop. The headline shift is from *generation* (asking AI to write code) to *orchestration* (grounding, planning, and auditing around the AI).
+
+```mermaid
+flowchart LR
+  A["Ground context<br/>blueprint · MCP · reference repos"] --> B["Plan<br/>design spec · implementation plan"]
+  B --> C["Generate via TDD<br/>docs → tests → validator"]
+  C --> D["Audit<br/>ExUnits · signatories · double satisfaction"]
+  D -->|fails review| B
+  D -->|passes review| E["Submit / Ship"]
+```
+
+---
+
+## 1. Why Cardano is Uniquely Challenging for AI
+
+Standard AI workflows often fail in the Cardano context for two main reasons.
+
+### The Mental Model Mismatch
+Most AI models are trained on account-based logic (common in other blockchain ecosystems and Web2 backends). Cardano's **eUTxO model** is a different paradigm.
+- **The Pitfall**: AI often tries to "mutate state" or assumes a running program, whereas Cardano smart contracts are **validators**: pure functions that verify state transitions. The off-chain code builds the transaction; the validator only says yes or no.
+
+### Knowledge Cutoffs & Ecosystem Velocity
+The Cardano toolchain moves fast, and there are several programming paradigms for building on it. Toolkits and languages have all evolved well beyond their initial versions:
+
+- **Off-chain / SDKs**: Mesh, Lucid Evolution, Blaze
+- **On-chain languages**: Aiken, Plutus / Plinth, plus higher-level approaches like TX3 and Scalus
+- **The Pitfall**: Because Ethereum, ERC-20, and Web3 content has been on the internet far longer, models have far more (and more confident) training data for account-based logic than for Cardano. AI will happily generate code for outdated APIs without warning.
+
+:::tip The Core Habit: Version Grounding
+Instead of prompting from scratch, anchor your prompt in your actual source files. Use your `plutus.json` blueprint and pin specific library versions (for example `@meshsdk/core@^1.0.0`) so the AI has the correct context rather than a guess from its training data.
+:::
+
+---
+
+## 2. Plan Before You Prompt: Systematic Orchestration
+
+The most impactful shift is moving from **generation** to **orchestration**. Rather than asking the AI to "write code," ask it to "build a plan" first. Planning is roughly 90% of the job.
+
+### Decompose the Feature First
+Before a single line of validator or off-chain logic is written, use AI to answer these five architectural questions:
+1. **Actors**: Who is involved (User, Merchant, Protocol)?
+2. **UTxOs**: What is being consumed and produced?
+3. **Logic**: What should the validator check to allow spending?
+4. **Datum**: What structure represents the contract state?
+5. **Redeemers**: What actions is the validator expected to handle?
+
+Writing the plan first surfaces ambiguities (for example, "what happens if a user cancels mid-period?") at the design phase rather than the deployment phase.
+
+### Draft a Design Specification Document
+A practical habit: have the LLM draft a **design specification document** before any validator code. This forces a shared understanding of what the code is supposed to do, and it makes the later mistakes (the LLM will make some) easy to spot and correct. Once the spec exists, asking for a validator or an SDK endpoint becomes far more reliable.
+
+### Use "Plan Mode"
+Modern tools can generate an **implementation plan file** before touching code: an overview of every file to be added or edited, often with an interaction schema you can visualize. Review and edit this plan (remove, add, reshape) before allowing the tool to write code. It is normal to spend 30+ minutes on a single planning pass. Some assistants (for example Gemini) already write an implementation plan by default, and they get better at it when you train them with your conventions.
+
+---
+
+## 3. Grounding AI in Your Codebase
+
+AI accuracy correlates directly with context quality. Anchor prompts in these "Ground Truths":
+
+### A. The Plutus Blueprint (`plutus.json`)
+The blueprint is the ultimate source of truth for hashes and schemas. Paste the relevant validator section into your prompt to eliminate hallucinated field names and type errors. Ultimately, it is the `plutus.json` that confirms whether you built the thing correctly.
+
+### B. Library Specificity
+Specify exact versions to prevent API mixing.
+- **Good**: "Build this transaction using `@meshsdk/core@^1.0.0` (or `lucid-evolution`, `blaze`)."
+- **Bad**: "Use a Cardano SDK." (Vague prompts waste iterations and tokens while the model guesses at the tool.)
+
+### C. The Design Specification
+If you have a design doc, feed it to the AI first. This ensures the AI understands the "why" before it attempts the "how."
+
+### D. Open-Source Reference Repositories
+Point the AI at an existing validator, datum, or repository with similar functionality and ask it to follow those patterns for your use case. In practice, feeding relevant open-source Aiken / Plutus / Plinth repositories (for example the many validator patterns published by teams like Anastasia Labs) is one of the highest-leverage grounding moves. Often a single instruction ("refer to this link and follow how it was implemented") is enough for the model to find and reuse the right pattern.
+
+---
+
+## 4. MCP: Model Context Protocol
+
+A recurring theme: how do we stop the AI reading **outdated** documentation? The strongest answer today is **MCP (Model Context Protocol)**.
+
+### What it is
+MCP lets an AI tool talk to external tools and documentation **directly**, instead of you pasting a GitHub link every time. Think of it as an API built for documentation: when configured for a library at a specific version, the assistant requests live, version-accurate information rather than relying on stale training data.
+
+### Example: Mesh
+Mesh ships a strong AI integration. From its site you can:
+- **Install skills** directly (a library of Mesh skills the assistant can request from).
+- **Add an MCP server** so the assistant queries the latest Mesh documentation and best practices live.
+- **Download a skills file** that bundles Mesh instructions for offline use.
+
+With the MCP configured, a prompt like "integrate wallet connection in my app" causes the assistant to read the Mesh documentation first and generate code that follows Mesh's actual API, instead of emitting generic TypeScript that ignores the SDK.
+
+### Scope: project vs user vs global
+Skills and MCP servers can be configured for a **single project**, for a **specific user**, or **globally** on your machine (a shared library every project can link to). Choose based on whether the context is project-specific or something you always want available.
+
+### When to use which grounding mechanism
+
+| Mechanism | Best for | Pros | Cons |
+|---|---|---|---|
+| **MCP server** | Live, version-accurate docs while coding | Always current; no manual pasting; best practices baked in | Requires internet; needs API key / setup |
+| **Downloadable skill file** | Offline or fixed-context work | Works without internet; portable | Can drift out of date; manual refresh |
+| **Pasting repo links / snippets** | One-off grounding | Zero setup | Manual; easy to under-specify; mixes versions |
+
+:::note
+MCP needs an internet connection because each request behaves like an API call. A downloaded skills file is the offline fallback.
+:::
+
+---
+
+## 5. Skills, Rules, and Test-Driven Generation
+
+Beyond grounding, you can encode *how you want the AI to work* using rules, skills, and sub-agents (supported by tools such as Claude Code, Cursor, and Kiro).
+
+### Rules
+Rules constrain behavior across a project or globally. Useful examples raised in the session:
+- Keep commits clean (for example, do not add unrelated "co-authored-by" trailers).
+- "Code like a human": do not dump huge diffs; cap how much code is produced at once.
+
+### Test-Driven Development with AI
+A workflow that materially reduces the number of prompts needed:
+1. Have the LLM draft the **design specification** (see Section 2).
+2. Start with **empty / stub validators**.
+3. Write (or have the LLM write) the **tests** first, based on the spec and the validator's intended behavior.
+4. Only then ask the LLM to implement the **validator**, using the tests and documentation as context.
+5. Run the tests; feed failures back.
+
+Encoding this exact loop as a reusable **skill** (for example a personal "Aiken on-chain" skill) means the assistant already knows to check for documentation, generate tests, and then implement, with accumulated rules from past errors making it sharper over time. None of this yet produces a correct validator in one prompt, but it has been enough to write a significant smart contract in a single day.
+
+---
+
+## 6. Where AI Falls Short (The Reality Check)
+
+:::warning Security & Cost Warning
+AI-generated on-chain code should always be reviewed by a developer before production use.
+:::
+
+| Pitfall | What goes wrong | How to mitigate |
+|---|---|---|
+| **Code bloat / ExUnits** | AI re-implements built-ins and writes verbose validators that inflate execution budget and script size. Cardano caps transaction size (~16 KB), and every byte of a validator counts. | Profile against actual execution units; ask the AI to prefer built-ins; review for redundancy. |
+| **Missing signatory checks** | Validator allows unauthorized users to spend a UTxO. | Explicitly verify required signers in the validator and in review. |
+| **Double satisfaction** | An attacker crafts a transaction that satisfies one validator check while siphoning value to a second output (for example minting without pinning the policy ID or quantity, so an extra output drains assets). | Check outputs specifically (address, quantity, policy ID); never validate value generically across outputs. |
+| **Account-based "shadows"** | AI assumes mutable state and edits values in place. | In eUTxO, state is consumed and recreated as a new output. If code mutates state, stop and re-examine the architecture. |
+
+---
+
+## 7. For Maintainers: AI Verification Gates
+
+As AI increases the *volume* of contributions, maintainers face more PRs of uneven quality (it is easy for a contributor to hand an issue to an AI and push the result without understanding the context). Manual review does not scale to that volume.
+
+The recommended response is to add an **AI verification layer to CI**, on top of the usual format and lint checks in the GitHub workflow:
+- Keep new PRs in **draft** until automated checks pass.
+- Let an AI review step spend real time (even up to an hour) checking that the change meets the issue's requirements and respects repository context, before a human reviews.
+- Combine with existing automated verification (formatting, type checks, tests) so maintainers receive fewer low-quality PRs.
+
+This protects maintainer time and keeps quality high as contribution volume rises.
+
+---
+
+## 8. Saving on Tokens: Local Models & Emerging Tools
+
+Token cost is currently the biggest practical constraint. A few directions explored in the session:
+
+- **Local LLMs**: Running models such as **Qwen** and **Gemma** locally for simpler tasks keeps token spend down. Accuracy is not yet on par with hosted frontier models for on-chain work, so the next step is wiring local models to MCP servers to improve code accuracy.
+- **Git Nexus**: A tool that lets you use the LLM of your choice with your own skills, connects to a number of MCP servers out of the box, and builds Obsidian-style mind maps of your project. Useful for visualizing a codebase. (Mentioned as a lead to explore, not yet battle-tested.)
+
+---
+
+## Open Questions & Action Items for the Ecosystem
+
+These came up live and are worth carrying forward as DevEx work:
+
+- **Cardano on-chain repositories do not yet ship MCP servers.** As developers increasingly rely on MCP to code quickly, the absence of MCP servers for our on-chain repos is a real onboarding gap. Providing them would let developers build against current, correct context instead of stale documentation.
+- **Track the Cardano MCP proposal** (Leon Nation has a Cardano MCP proposal in progress) and consider how DevEx can support or align with it.
+- **Maintainer tooling**: standardize an AI verification step across DevEx repositories.
+
+---
+
+## Key Takeaways
+
+- **Orchestrate, don't just generate**: you are the architect; the AI is the builder. Planning is ~90% of the job.
+- **Ground everything**: anchor prompts in `plutus.json`, pinned library versions, design specs, and reference repos. Prefer **MCP servers** for live, version-accurate context.
+- **Generate via TDD**: spec, then tests on empty validators, then the validator. Encode the loop as a reusable skill.
+- **Audit before shipping**: review every AI-generated validator for **ExUnit cost**, **signatory checks**, and **double satisfaction**.
+- **Plan for scale**: add AI verification gates in CI so maintainers are not buried by high-volume, low-context PRs.
+
+---
+
+*These notes belong to the Q2 2026 Developer Experience Working Group.*
diff --git a/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/session-resources/readme.md b/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/session-resources/readme.md
new file mode 100644
index 0000000..9c1b4dc
--- /dev/null
+++ b/website/docs/working-group/sessions/q2-2026/18-ai-dev-workflow/session-resources/readme.md
@@ -0,0 +1,46 @@
+---
+title: "Session 18: Using AI in Your Cardano Dev Workflow - Resources"
+sidebar_label: Session Resources
+slug: /working-group/q2-2026/sessions/18-ai-dev-workflow/session-resources
+---
+
+# Session 18: Using AI in Your Cardano Dev Workflow - Resources
+
+Curated tools and references for building on Cardano with AI assistance.
+
+## AI Coding Assistants
+
+- **[Claude Code](https://www.anthropic.com/claude-code)**: CLI/agent assistant with support for skills, rules, and sub-agents.
+- **[Cursor](https://cursor.com)**: AI-native editor with rules and MCP support.
+- **[Kiro](https://kiro.dev)**: Agentic IDE used in the live demo for adding skills and MCP servers (per project, per user, or global).
+- **[Gemini](https://gemini.google.com)**: Often produces an implementation plan before writing code.
+
+## MCP & Skills
+
+- **[Model Context Protocol](https://modelcontextprotocol.io)**: The open standard that lets assistants query live, version-accurate documentation and tools.
+- **[Mesh SDK](https://meshjs.dev)**: Ships installable skills, an MCP server, and a downloadable skills file for AI-assisted Mesh development.
+- **[Aiken](https://aiken-lang.org)**: On-chain language used in the test-driven validator workflow described in the notes.
+
+## Cardano SDKs & Languages Referenced
+
+- **Off-chain / SDKs**: [Mesh](https://meshjs.dev), [Lucid Evolution](https://github.com/Anastasia-Labs/lucid-evolution), [Blaze](https://github.com/butaneprotocol/blaze-cardano)
+- **On-chain**: [Aiken](https://aiken-lang.org), [Plutus / Plinth](https://github.com/IntersectMBO/plutus), plus higher-level approaches [TX3](https://github.com/txpipe/tx3) and [Scalus](https://scalus.org)
+
+## Local Models (Token Savings)
+
+- **[Ollama](https://ollama.com)**: Run open models locally.
+- **[Qwen](https://github.com/QwenLM)** and **[Gemma](https://ai.google.dev/gemma)**: Open models suitable for simpler, lower-cost tasks.
+
+## Emerging Tools
+
+- **Git Nexus**: Bring-your-own-LLM tool that connects multiple MCP servers and builds Obsidian-style mind maps of a codebase. (Mentioned as a lead to explore.)
+
+## Security & Cost Concepts
+
+- **[CIP-30 (Wallet Bridge)](https://cips.cardano.org/cips/cip30/)**: How dApps talk to wallets.
+- **[CIP-68 (Datum Metadata Standard)](https://cips.cardano.org/cip/CIP-0068)**: Datum metadata token standard, useful when modeling on-chain state.
+- **Double satisfaction & common vulnerabilities**: Review every AI-generated validator for signatory checks, output pinning (address, quantity, policy ID), and execution-unit cost before production.
+
+---
+
+*These resources belong to the Q2 2026 Developer Experience Working Group.*
diff --git a/website/docs/working-group/sessions/q2-2026/18-cardano-mcp-server/_category_.json b/website/docs/working-group/sessions/q2-2026/18-cardano-mcp-server/_category_.json
deleted file mode 100644
index d7eb781..0000000
--- a/website/docs/working-group/sessions/q2-2026/18-cardano-mcp-server/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
-    "label": "Session 18: Building a Production-Grade MCP Server for Cardano",
-    "position": 18
-}
diff --git a/website/docs/working-group/sessions/q2-2026/19-cardano-mcp-server/_category_.json b/website/docs/working-group/sessions/q2-2026/19-cardano-mcp-server/_category_.json
new file mode 100644
index 0000000..f760f9c
--- /dev/null
+++ b/website/docs/working-group/sessions/q2-2026/19-cardano-mcp-server/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Session 19: Building a Production-Grade MCP Server for Cardano",
+    "position": 19
+}
diff --git a/website/docs/working-group/sessions/q2-2026/18-cardano-mcp-server/session-notes/readme.md b/website/docs/working-group/sessions/q2-2026/19-cardano-mcp-server/session-notes/readme.md
similarity index 98%
rename from website/docs/working-group/sessions/q2-2026/18-cardano-mcp-server/session-notes/readme.md
rename to website/docs/working-group/sessions/q2-2026/19-cardano-mcp-server/session-notes/readme.md
index 3b4634f..e019f25 100644
--- a/website/docs/working-group/sessions/q2-2026/18-cardano-mcp-server/session-notes/readme.md
+++ b/website/docs/working-group/sessions/q2-2026/19-cardano-mcp-server/session-notes/readme.md
@@ -1,10 +1,10 @@
 ---
-title: "Session 18: Building a Production-Grade MCP Server for Cardano - Notes"
+title: "Session 19: Building a Production-Grade MCP Server for Cardano - Notes"
 sidebar_label: Session Notes
-slug: /working-group/q2-2026/sessions/18-cardano-mcp-server/session-notes
+slug: /working-group/q2-2026/sessions/19-cardano-mcp-server/session-notes
 ---
 
-# Session 18: Building a Production-Grade MCP Server for Cardano
+# Session 19: Building a Production-Grade MCP Server for Cardano
 
 In this session we walked through **[Cardano MCP](https://github.com/lidonation/Cardano-mcp)** — a purpose-built [Model Context Protocol](https://modelcontextprotocol.io) server that gives AI assistants like Claude live, idiomatic access to the Cardano blockchain. By the end you will understand how the server is structured, how to register it in your editor, and how to query UTxOs, governance proposals, and smart contract datums without leaving your coding session.
 
diff --git a/website/docs/working-group/sessions/q2-2026/18-cardano-mcp-server/session-resources/readme.md b/website/docs/working-group/sessions/q2-2026/19-cardano-mcp-server/session-resources/readme.md
similarity index 94%
rename from website/docs/working-group/sessions/q2-2026/18-cardano-mcp-server/session-resources/readme.md
rename to website/docs/working-group/sessions/q2-2026/19-cardano-mcp-server/session-resources/readme.md
index 95a59e0..2619afe 100644
--- a/website/docs/working-group/sessions/q2-2026/18-cardano-mcp-server/session-resources/readme.md
+++ b/website/docs/working-group/sessions/q2-2026/19-cardano-mcp-server/session-resources/readme.md
@@ -1,10 +1,10 @@
 ---
-title: "Session 18: Building a Production-Grade MCP Server for Cardano - Resources"
+title: "Session 19: Building a Production-Grade MCP Server for Cardano - Resources"
 sidebar_label: Session Resources
-slug: /working-group/q2-2026/sessions/18-cardano-mcp-server/session-resources
+slug: /working-group/q2-2026/sessions/19-cardano-mcp-server/session-resources
 ---
 
-# Session 18: Building a Production-Grade MCP Server for Cardano - Resources
+# Session 19: Building a Production-Grade MCP Server for Cardano - Resources
 
 Curated references for building and extending the Cardano MCP server: tool registration, multi-API strategy, CIP-1694 governance integration, and IPFS metadata enrichment.
 
diff --git a/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/_category_.json b/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/_category_.json
new file mode 100644
index 0000000..d906826
--- /dev/null
+++ b/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/_category_.json
@@ -0,0 +1,8 @@
+{
+  "label": "Session 20: Building a Production Cardano SDK",
+  "position": 20,
+  "link": {
+    "type": "generated-index",
+    "description": "End-to-end walkthrough of production SDK practices on Cardano: from Aiken validators to a demo dApp, using the DCU Toolkit as the case study."
+  }
+}
diff --git a/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/recordings/readme.md b/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/recordings/readme.md
new file mode 100644
index 0000000..dda9ab6
--- /dev/null
+++ b/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/recordings/readme.md
@@ -0,0 +1,41 @@
+---
+title: "Session 20: Building a Production Cardano SDK: From Validators to dApp - Recordings"
+sidebar_label: Recordings
+slug: /working-group/q2-2026/sessions/20-cardano-production-sdk/recordings
+---
+
+# Session 20: Building a Production Cardano SDK: From Validators to dApp - Recordings
+
+- *(Recording coming soon. It will be linked here once published.)*
+
+{/*
+  TODO: When the recording is published, replace the line above with the block
+  below and fill in YOUR_VIDEO_ID.
+
+  ## Recording 1 (2026/06/11)
+
+  🎥 **Building a Production Cardano SDK: From Validators to dApp**
+
+  <iframe
+    src="https://www.youtube.com/embed/YOUR_VIDEO_ID"
+    title="Session 20: Building a Production Cardano SDK: From Validators to dApp"
+    width="100%"
+    height="480"
+    allow="autoplay"
+    allowfullscreen
+    style={{border: 0, borderRadius: '12px', boxShadow: '0 16px 40px rgba(1, 40, 170, 0.18)'}}
+  />
+
+  - **Status**: Recording available above.
+  - **Highlights**:
+    - How societies save in groups, where trust breaks (documented cases across four countries), and the experiment: what happens when the treasurer is a validator?
+    - The three-layer architecture: Aiken validators, the Effect-based SDK, and the demo dApp.
+    - CIP-68 token pairs for on-chain identity.
+    - ProgramRunner execution modes (unsafeRun / safeRun / program) and the typed error taxonomy.
+    - Live demo: a full 3-wallet ROSCA lifecycle on Preprod.
+    - The recipe: applying the same method to your own SDK.
+*/}
+
+---
+
+*This recording belongs to the Q2 2026 Developer Experience Working Group.*
diff --git a/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/session-notes/readme.md b/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/session-notes/readme.md
new file mode 100644
index 0000000..86e8868
--- /dev/null
+++ b/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/session-notes/readme.md
@@ -0,0 +1,251 @@
+---
+title: "Session 20: Building a Production Cardano SDK: From Validators to dApp - Notes"
+sidebar_label: Session Notes
+slug: /working-group/q2-2026/sessions/20-cardano-production-sdk/session-notes
+---
+
+# Building a Production Cardano SDK: From Validators to dApp
+
+## Introduction
+
+This session continues the offchain and SDK building track started in Session 14. Where Session 14 walked through the structure of an offchain repository, this session goes end to end through the **practices of building and shipping a production-grade SDK**, using an open-source case study: the [DCU Toolkit](https://github.com/tx-meta/dcu-kit) (Decentralized Credit Unions), an MVP infrastructure for cooperative finance on Cardano under active development, together with a demo web application built on top of it. We cover why the product exists, how the three layers fit together, and what it takes to ship an SDK that other developers can actually build on.
+
+:::tip If you remember one thing from this session
+On Cardano, **your application builds the transaction; the validator only says yes or no.** Smart contracts here are not running programs that hold your logic. They are pure functions that approve or reject a state transition. Everything in this session (the SDK, the endpoints, the UI) is layers of convenience around that one idea. If you keep this mental model, the rest of the ecosystem stops being confusing.
+:::
+
+---
+
+## How Societies Save, and Where Trust Breaks
+
+Long before formal banking reached most of the world, communities built their own financial infrastructure: rotating savings groups known as Chamas in East Africa, Tontines in West Africa, Susu in Ghana and the Caribbean, Chit funds in India, Hui in China, and Tandas in Latin America. This is not a niche. According to the World Bank's Global Findex data, [419 million adults worldwide save "semi-formally" in small groups](https://www.findevgateway.org/blog/2022/09/path-financial-inclusion-must-include-saving-small-groups), and the model is the subject of an [extensive academic literature](https://www.sciencedirect.com/science/article/pii/S2772655X23000393) precisely because it works so well at community scale.
+
+These systems run on social trust, and when that trust breaks, the people who lose are those least able to absorb the loss. The pattern is documented on every continent: forensic audits of a national cooperative umbrella body in [Kenya (2024)](https://www.capitalfm.co.ke/business/2025/05/kuscco-audit-reveals-billions-lost-in-mismanagement-report-tabled-in-parliament/), the Saradha collapse in [India (2013)](https://www.business-standard.com/about/what-is-saradha-scam) whose [trials continue a decade later](https://theprint.in/judiciary/saradha-scam-trials-13-yrs-on-bengals-biggest-financial-fraud-stuck-in-a-stalemate-in-courts/2906320/), central-bank interventions and state repayment programs in [Ghana (2015-16)](https://presidency.gov.gh/index.php/briefing-room/news-style-2/1512-customers-of-failed-savings-and-loans-microfinance-institutions-to-receive-payments-from-monday-president-akufo-addo), and frozen accounts for millions in [Nigeria (2016)](https://www.cnn.com/2016/12/14/africa/mmm-ponzi-scheme-nigeria). These are mentioned not to dwell on any institution, but because they share one shape with the case that is never reported anywhere, the group treasurer who quietly disappears with the pot: the **same structural failure** of funds held by a trusted intermediary with no enforceable rules.
+
+> **The DCU Toolkit is an experiment: what happens when the treasurer is a validator?**
+
+### Fraud Vector to On-Chain Guarantee
+
+How the experiment encodes each failure mode as a validator check:
+
+| What goes wrong today | What the toolkit encodes |
+|---|---|
+| Treasurer absconds with the pot | Funds locked in a Treasury UTxO; payouts enforced by the validator |
+| Organizer rug-pulls the group | `creator_bond` forfeited if the group is deleted while members are active |
+| Member defaults mid-cycle | `collateral_rounds` locked at join; pro-rata pots so the cycle never stalls |
+| Fake identities, no audit trail | CIP-68 membership token pairs; full history on chain |
+
+---
+
+## Why Blockchain, and Why Cardano?
+
+The fair question every developer should ask: **why not just a database and an auditor?**
+
+### Why the existing fixes keep failing
+
+- **Regulation and audits are post-hoc.** In the cases above, the institutions were regulated, audited, or both; the forensic findings arrived after the money was gone. Oversight reconstructs a failure; it does not prevent one.
+- **An app with a database relocates the trust, it does not remove it.** Whoever operates the server is the new treasurer. The fraud vector is unchanged, only better dressed.
+- **Mobile money solved payments, not custody.** Mobile money rails move funds brilliantly, but the group's pot still sits under the control of a person, and the group's rules still live in their head.
+
+What blockchain changes is the category of guarantee: **custody without a custodian, and rules enforced before the fact instead of audited after it.** The validator is the audit, and it runs before every transaction instead of after the collapse. Add a transparent ledger (no books to cook: every member can verify every contribution and payout) and programmable penalties (bonds and collateral applied impartially, with no committee meeting), and the trusted-intermediary failure mode is removed rather than mitigated. Whether that holds up in real communities, with real usability constraints, is exactly what the experiment is for.
+
+### Why Cardano specifically
+
+| Property | Why it matters for cooperative finance |
+|---|---|
+| **Deterministic eUTxO model** | A transaction's outcome is known *before* submission. No failed transaction ever consumes a saver's fees mid-execution, and validation either fully passes or nothing moves. For people pooling small savings, predictability is the product. |
+| **Local state, not global state** | Each group's treasury is its own UTxO. Groups validate independently and in parallel, with no shared global state to contend over or corrupt. |
+| **Predictable, low fees** | Fees are calculable in advance and small relative to contribution sizes, which is what makes micro-savings groups viable on chain at all. |
+| **Native assets + CIP-68** | Membership and group identities are ledger-native tokens, not balances inside a contract that itself must be trusted. |
+| **Validators are pure functions** | The on-chain code cannot "do" anything: it only approves or rejects. A minimal attack surface for code that guards other people's savings, and it is exactly the mental model this session anchors on. |
+| **Open source by default** | The validators, the SDK, and the spec are public and verifiable. A community does not have to trust the toolkit's authors any more than its treasurer. |
+
+A strong blockchain use case is rarely "we put X on chain." It is a recurring real-world failure, a guarantee no other technology offers, and an execution model that fits the problem's shape. The DCU Toolkit is one open-source experiment in finding out whether this particular failure mode can be made structurally impossible.
+
+---
+
+## What is a ROSCA?
+
+A **Rotating Savings and Credit Association**: a fixed group of members each contribute the same amount per cycle, and each cycle one member receives the entire pooled pot, rotating until everyone has been paid exactly once.
+
+The on-chain mapping:
+- **Members** lock ADA into a Treasury UTxO when they join.
+- **Intervals** advance on a fixed schedule encoded in the Group datum.
+- **Payouts** go to the member whose `assigned_slot` matches the current interval, enforced by the Treasury validator.
+
+---
+
+## Architecture: Three Layers
+
+```mermaid
+flowchart TB
+  subgraph APP["Application Layer"]
+    K["Web app (Next.js)"]
+    EX["Example CLI scripts"]
+    CR["Cron daemon (cycle automation)"]
+  end
+  subgraph SDK["Middleware: @tx-meta/dcu-sdk (TypeScript + Effect)"]
+    EP["17 tx-builder endpoints<br/>account (3) · group (9) · treasury (5)"]
+    PR["ProgramRunner<br/>unsafeRun · safeRun · program"]
+    ERR["12-error taxonomy<br/>typed Data.TaggedError"]
+    LE["Lucid Evolution<br/>Blockfrost / Emulator provider"]
+  end
+  subgraph CHAIN["Onchain: Cardano L1 (Aiken validators)"]
+    AV["Account<br/>CIP-68 membership"]
+    GV["Group<br/>lifecycle + rotation"]
+    TV["Treasury<br/>locked funds + payouts"]
+    SV["Settings<br/>protocol parameters"]
+  end
+  K --> EP
+  EX --> EP
+  CR --> EP
+  EP --> PR --> LE
+  LE --> AV & GV & TV & SV
+```
+
+The session focused on the **middle layer**, since that is where most Cardano application developers will spend their time.
+
+---
+
+## Onchain, Briefly: CIP-68 Pairs
+
+Smart contracts cannot efficiently read data stored in tokens sitting in user wallets, so every identity in the protocol is a **synchronized pair of tokens**:
+
+| Token | Where it lives | What it does |
+|---|---|---|
+| **Reference NFT** `(100)` | Locked at the validator | Holds the datum that contracts can read |
+| **User Auth NFT** `(222)` | The user's wallet | Proves ownership and authorizes transactions |
+
+Both are minted atomically. At validation time the contract reads the reference datum and checks that you hold the auth token, **without ever taking it from your wallet**. The same pattern covers groups: the Group Reference NFT lives at the Group validator, and the Group Auth NFT is admin authority.
+
+Validators in the repo: `account-validator.ak`, `group-validator.ak`, `treasury-validator.ak`, `settings-validator.ak`, plus `always-fails.ak` used to permanently lock deployed reference scripts.
+
+---
+
+## The SDK: Every Endpoint Returns a ProgramRunner
+
+```typescript
+import { createAccount } from "@tx-meta/dcu-sdk";
+
+const [selected_out_ref] = await lucid.wallet().getUtxos();
+
+// 1. Throws on failure (scripts, quick tooling)
+const tx = await createAccount(lucid, { selected_out_ref }).unsafeRun();
+
+// 2. Returns an Either, never throws (production UIs)
+const result = await createAccount(lucid, { selected_out_ref }).safeRun();
+
+// 3. Raw Effect, composes with your own pipeline
+const program = createAccount(lucid, { selected_out_ref }).program();
+```
+
+One API, three execution modes, chosen by the integrator rather than the SDK author. `selected_out_ref` is consumed as entropy for the CIP-68 token name, which guarantees global uniqueness (no two UTxOs ever share a `txHash#index`).
+
+### Why Effect Instead of Plain Promises
+
+For financial transactions, failure handling is the product, not an afterthought:
+- A **12-error taxonomy** of typed `Data.TaggedError`s (missing UTxO, invalid datum, insufficient funds, and so on), each catchable by tag.
+- No uncaught throws: builders fail gracefully and explicitly.
+- Pipelines compose: retry, timeout, and concurrency come for free.
+
+### Anatomy of an Endpoint
+
+```text
+sdk/src/
+├── endpoints/distributePayout.ts   ← one file per operation
+│     Config type → datum/redeemer schemas → tx build → makeReturn()
+├── core/
+│   ├── errors.ts        ← 12-error taxonomy (built FIRST)
+│   ├── types.ts         ← datum + redeemer schemas
+│   ├── plutus.json      ← compiled Aiken blueprint
+│   └── validators/      ← policy IDs derived from the blueprint
+└── index.ts             ← barrel export
+```
+
+Build order when starting any SDK: errors, then types, then validators, then endpoints one at a time, each with its test before the next. This layout is identical across the team's SDKs, so integrators learn it once.
+
+---
+
+## Live Demo: A Full 3-Wallet ROSCA on Preprod
+
+The `sdk/examples/` directory contains one CLI script per endpoint. The demo ran the full lifecycle:
+
+```bash
+pnpm run create-account     # ADMIN, USER1, USER2
+pnpm run create-group       # ADMIN bonds and sets the rules
+pnpm run join-group         # users lock collateral
+pnpm run start-group        # rotation schedule fixed on chain
+pnpm run distribute-payout  # validator pays round 1's member
+pnpm run claim-payout
+```
+
+```mermaid
+sequenceDiagram
+    participant A as Admin
+    participant U as Members
+    participant S as DCU SDK
+    participant T as Treasury Validator
+
+    A->>S: createGroup (bond + rules)
+    U->>S: joinGroup (lock collateral)
+    A->>S: startGroup (schedule frozen on chain)
+    loop Each cycle
+        S->>T: distributePayout tx
+        T->>T: check interval + assigned_slot
+        T->>U: pot to this round's member
+    end
+```
+
+Reference scripts are deployed once per SDK version and permanently locked at an `alwaysFails` address: they are a witness-size optimization and can never move funds.
+
+---
+
+## The Integration Case Study: A Demo Web App
+
+The proof that the SDK works for a real integrator is the demo web application built on top of it. One button, all the layers:
+
+**"Distribute Payout"** → React hook → `distributePayout(lucid, cfg).safeRun()` → tx phase UI → confirmed on chain.
+
+- Typed errors map one-to-one to user-facing messages.
+- `tx-phase` and `tx-progress-bar` components are driven directly by SDK states.
+- Wallet connect, chain-data hooks, and route guards all sit on the same 17 endpoints.
+
+---
+
+## Production Discipline
+
+| CI job | Gates |
+|---|---|
+| Verify SDK | format, lint, types, build, emulator test suite |
+| Verify Aiken | format, build, on-chain unit tests |
+| Verify Design Specs | the Typst design spec must compile |
+
+All three must pass before merge; publishing fires on a GitHub Release, with a CHANGELOG and MIGRATION guide per version. "Production smart contract" means the spec, the validators, and the SDK are versioned and gated together.
+
+---
+
+## The Recipe: Applying This to Your Own SDK
+
+Everything above generalizes. If you are wrapping your own validators in an SDK, this is the method:
+
+1. **Start from the blueprint.** `plutus.json` is the contract between layers; derive policy IDs and script addresses from it, never hardcode them.
+2. **Build the error taxonomy first.** Every endpoint imports from it, and typed failures designed up front are what make a polished UX possible downstream.
+3. **Schemas next.** Datum and redeemer types must mirror the onchain design spec exactly; blueprint alignment is the offchain code's entire job.
+4. **One endpoint at a time, each with its test before the next.** An emulator test suite keeps the loop fast; save Preprod for end-to-end verification.
+5. **Return a runner, not a promise.** Expose throw / Either / Effect modes and let the integrator choose; an SDK should not impose its error-handling style.
+6. **Ship examples as first-class code.** One CLI script per endpoint doubles as living documentation and a manual integration test.
+7. **Version the whole stack together.** Blueprint, SDK, spec, and reference scripts in one release with CI gates on all of them; a recompiled validator must never silently strand your integrators.
+
+---
+
+## Key Takeaways
+
+- **Your app builds the transaction; the validator only approves or rejects.** This is the single mental model every Cardano newcomer should anchor on.
+- **Real-world trust failures are the use case.** Each documented fraud maps to a specific validator check; smart contracts here are not abstract, they are a missing audit running before every transaction.
+- **SDKs drive adoption.** Wrapping validators in a typed, well-documented SDK lets application developers build without reading Plutus or Aiken.
+- **Design the failure paths first.** A typed error taxonomy built before any endpoint is what makes a polished UX possible downstream.
+- **Ship the whole stack.** Blueprint, SDK, examples, docs, and CI gates moving in lockstep is what separates a demo from infrastructure.
+
+---
+
+*These notes belong to the Q2 2026 Developer Experience Working Group.*
diff --git a/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/session-resources/readme.md b/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/session-resources/readme.md
new file mode 100644
index 0000000..e3bbbb0
--- /dev/null
+++ b/website/docs/working-group/sessions/q2-2026/20-cardano-production-sdk/session-resources/readme.md
@@ -0,0 +1,36 @@
+---
+title: "Session 20: Building a Production Cardano SDK: From Validators to dApp - Resources"
+sidebar_label: Session Resources
+slug: /working-group/q2-2026/sessions/20-cardano-production-sdk/session-resources
+---
+
+# Session 20: Building a Production Cardano SDK: From Validators to dApp - Resources
+
+Resources for building production-grade offchain SDKs on Cardano, with the DCU Toolkit as the case study.
+
+## Case Study
+
+- **DCU Toolkit (Onchain + SDK, MVP under active development)**: [tx-meta/dcu-kit](https://github.com/tx-meta/dcu-kit)
+- **DCU SDK on npm**: [@tx-meta/dcu-sdk](https://www.npmjs.com/package/@tx-meta/dcu-sdk)
+- **Example scripts**: one CLI script per endpoint under `sdk/examples/` in the repository, covering the full ROSCA lifecycle on Preprod
+
+## Core Tooling
+
+- **Lucid Evolution SDK**: [Anastasia-Labs/lucid-evolution](https://github.com/Anastasia-Labs/lucid-evolution)
+- **Effect TypeScript Library**: [Effect Documentation](https://effect.website/)
+- **Aiken**: [aiken-lang.org](https://aiken-lang.org)
+
+## Standards Referenced
+
+- **CIP-68 Datum Metadata Standard**: [cips.cardano.org/cip/CIP-0068](https://cips.cardano.org/cip/CIP-0068)
+- **CIP-30 Wallet Connector**: [cips.cardano.org/cip/CIP-0030](https://cips.cardano.org/cip/CIP-0030)
+
+## Background Reading
+
+- **ROSCAs (Rotating Savings and Credit Associations)**: the cooperative finance model (Chamas, SACCOs, Tontines) the toolkit digitizes
+- **Cardano Testnets Faucet** (for following along on Preprod): [docs.cardano.org/cardano-testnets/tools/faucet](https://docs.cardano.org/cardano-testnets/tools/faucet)
+- **Related sessions**: [Session 14: Repository Walkthrough: Offchain and SDK building](../../14-sdk-repo-walkthrough/session-notes/readme.md), [Session 15: dApp Architecture](../../15-dapp-architecture-demo/session-notes/readme.md)
+
+---
+
+*These resources belong to the Q2 2026 Developer Experience Working Group.*
diff --git a/website/docs/working-group/sessions/q2-2026/index.md b/website/docs/working-group/sessions/q2-2026/index.md
index e86e611..c73dddb 100644
--- a/website/docs/working-group/sessions/q2-2026/index.md
+++ b/website/docs/working-group/sessions/q2-2026/index.md
@@ -16,7 +16,9 @@ The Developer Experience (DevEx) Working Group continues to support and empower
 | **15** | **dApp Architecture: From Wallet to Backend** | Modular breakdown of full-stack dApp flow | Workshop |
 | **16** | **UI ↔ Smart Contracts: Wallets, Tx Building, and Submission** | End-to-end dApp interaction patterns + architecture trade-offs | Workshop |
 | **17** | **Default Developer Environment for Cardano** | Working-group debate on what we recommend by default to new builders | Discussion |
-| **18** | **Building a Production-Grade MCP Server for Cardano** | AI tooling for Cardano — UTxOs, governance, smart contracts via MCP | Demo + Discussion |
+| **18** | **Using AI in Your Cardano Dev Workflow** | Systematic approach to AI-driven development | Workshop |
+| **19** | **Building a Production-Grade MCP Server for Cardano** | AI tooling for Cardano — UTxOs, governance, smart contracts via MCP | Demo + Discussion |
+| **20** | **Building a Production Cardano SDK: From Validators to dApp** | End-to-end: Aiken validators, Effect-based SDK, demo dApp (DCU Toolkit case study) | Workshop |
 
 ## Session Details
 
@@ -37,7 +39,7 @@ The Developer Experience (DevEx) Working Group continues to support and empower
 - **Deliverable**: [dApp Architecture Session Notes](./15-dapp-architecture-demo/session-notes/readme.md)
 
 ### Session 16: UI ↔ Smart Contracts: Wallets, Tx Building, and Submission
-- **Objective**: Teach the *practical* ways a UI app interacts with Cardano validators (Aiken/Plutus) using modern wallet + SDK flows, with clear trade-offs and diagrams.
+- **Objective**: Teach the *practical* ways a UI app interacts with Cardano validators (using various Smart Contract languages) using modern wallet + SDK flows, with clear trade-offs and diagrams.
 - **Key Topics**:
   - CIP-30 wallet connector fundamentals (connect, UTxOs, sign, submit)
   - Transaction lifecycle (build → evaluate → sign → submit → confirm)
@@ -54,7 +56,18 @@ The Developer Experience (DevEx) Working Group continues to support and empower
   - Recommended flow debate: what is the *single* environment we point new builders at?
 - **Deliverable**: [Default Developer Environment Session Notes](./17-default-developer-environment/session-notes/readme.md)
 
-### Session 18: Building a Production-Grade MCP Server for Cardano
+### Session 18: Using AI in Your Cardano Dev Workflow
+- **Objective**: Establishing a repeatable, secure workflow for building Cardano apps with AI
+- **Key Topics**:
+  - The Mental Model Mismatch (eUTXO vs Account-based)
+  - Systematic Orchestration (Plan-First Architecture)
+  - Grounding AI in `plutus.json`, specific SDK versions, and reference repos
+  - MCP (Model Context Protocol) and skills for live, version-accurate context
+  - Test-driven validator generation (docs → tests → validator)
+  - AI verification gates in CI for maintainers, plus local models for token savings
+- **Deliverable**: [AI-Augmented Development Methodology](./18-ai-dev-workflow/session-notes/readme.md)
+
+### Session 19: Building a Production-Grade MCP Server for Cardano
 - **Objective**: Demonstrate how to give AI agents deep, idiomatic access to Cardano — UTxOs, native assets, smart contracts, and CIP-1694 governance — using the Model Context Protocol.
 - **Key Topics**:
   - Why Cardano needed a purpose-built MCP server (eUTxO vs account model)
@@ -62,7 +75,18 @@ The Developer Experience (DevEx) Working Group continues to support and empower
   - CIP-1694 governance module and IPFS metadata enrichment
   - Live demo: querying UTxOs, governance proposals, and CBOR datums from inside Claude Code
   - Lessons learned: Zod defaults, IPFS edge cases, Koios tail latencies
-- **Deliverable**: [Session Notes](./18-cardano-mcp-server/session-notes/readme.md) | [Resources](./18-cardano-mcp-server/session-resources/readme.md)
+- **Deliverable**: [Session Notes](./19-cardano-mcp-server/session-notes/readme.md) | [Resources](./19-cardano-mcp-server/session-resources/readme.md)
+
+### Session 20: Building a Production Cardano SDK: From Validators to dApp
+- **Objective**: Walk end to end through the practices of building and shipping a production-grade offchain SDK, from real-world problem to validators, SDK, and demo dApp.
+- **Key Topics**:
+  - Why cooperative finance needs enforceable rules (documented trust failures in savings groups)
+  - Why blockchain, and why Cardano: custody without a custodian, deterministic eUTxO, predictable fees
+  - Three-layer architecture: Aiken validators, Effect-based TypeScript SDK, demo dApp
+  - CIP-68 token pairs, ProgramRunner execution modes, and typed error taxonomies
+  - Live demo: a full 3-wallet ROSCA lifecycle on Preprod
+  - The recipe: applying the same method to your own SDK
+- **Deliverable**: [Session Notes](./20-cardano-production-sdk/session-notes/readme.md) | [Resources](./20-cardano-production-sdk/session-resources/readme.md)
 
 ## Working Group Information
 For operational details, roles, repository structure, and participation guidelines, please see the [Working Group Overview](../../readme.md).