Split Aliki slide into light/dark screenshots + feature list

- Add Aliki light and dark mode screenshots (full width)
- Split single Aliki slide into 3: light, dark, feature list
- Replace inaccurate claims: "mobile-first" → "responsive layout",
  "fuzzy search" → "improved search algorithm and UI",
  "method signature cards" → "automatically generated ToC sidebar"
- Sync slides_outline.md with current 40-slide deck
- Update slide numbering and presenter mode boundaries

Author: st0012

images/aliki-dark.png

@@ -18,188 +18,174 @@
 - Ruby DX team @Shopify
 - Key collaborator: tompng (Tomoya Ishida)
 
-### Slide 3 — Bold claim
+### Slide 3 — Rubydex
+- A Ruby code indexer — `Shopify/rubydex`
+- Static code intelligence for Ruby
+- Alexandre Terrasa's talk: "Blazing-fast Code Indexing for Smarter Ruby Tools"
+
+### Slide 4 — Bold claim
 - "The future of Ruby's documentation is about AI"
 
-### Slide 4 — What AI needs (part 1)
+### Slide 5 — What AI needs from documentation (part 1)
 - AI likes **clear, accurate documentation**
 - Misinformation gets amplified by AI
 
-### Slide 5 — What AI needs (part 2)
+### Slide 6 — What AI needs from documentation (part 2)
 - AI likes **Markdown** — it reads and writes it natively
 - AI likes **clear intent** — type signatures tell it what code does
 
-### Slide 6 — What AI needs (part 3)
+### Slide 7 — What helps AI write documentation
 - AI likes **quick, deterministic feedback**
 - Coverage checks, missing reference warnings — not "try and see"
 
-### Slide 7 — The twist
+### Slide 8 — The twist
 - "All of these help human developers too."
 - These aren't AI requirements — they're good documentation requirements
 
-### Slide 8 — RDoc wasn't providing these
+### Slide 9 — RDoc wasn't providing these
 - Old theme, no live preview, incomplete Markdown, no type info
 - Parser couldn't handle modern Ruby
 
-### Slide 9 — So here's what we did
+### Slide 10 — So here's what we did
 - "...to make RDoc work for us, and our agents"
 
 ---
 
-## Section 2: Here's What We Did (~16 min)
+## Section 2: Here's What We Did (~14-16 min)
+
+### Slide 11 — Before: Darkfish
+- Screenshot of old Darkfish theme
 
-### Slide 10 — Aliki theme (quick)
-- Before: Darkfish screenshot → After: Aliki screenshot
+### Slide 12 — After: Aliki
 - Dark mode, mobile, fuzzy search, method signature cards
 - "Named after my cat. Ships in Ruby 4.0."
 
-### Slide 11 — Server mode
+### Slide 13 — Server mode demo
 - `rdoc --server` — live-reload documentation preview
-- Demo: edit a file → browser auto-refreshes
+- Demo video: edit a file → browser auto-refreshes
+
+### Slide 14 — Server mode details
+- `rdoc --server` features
 - Zero external dependencies, incremental re-parsing
+- Connects to Prism for faster re-parse
 
-### Slide 12 — The parser problem
+### Slide 15 — The parser problem
 - RDoc's Ruby parser used Ripper (token-stream based)
+- Ripper is slow
 - Couldn't handle modern Ruby syntax
-- Parser logic and comment handling tightly coupled
 
-### Slide 13 — tompng's rewrites
+### Slide 16 — tompng's rewrites
 - Pipeline diagram: where the 3 subsystems sit in RDoc
   - Ruby parser → Prism AST visitor
   - Comment directive parser (`:call-seq:`, `:nodoc:`)
   - Inline formatting engine → structured InlineParser
 - 43 PRs over 20 months
 
-### Slide 14 — What the rewrites changed
-- Code example: before/after (e.g., Ripper tokens vs Prism AST visit)
-- "Three subsystem rewrites. Invisible to users, foundational for everything else."
+### Slide 17 — Bug fix example: `__FILE__`
+- Before/after comparison showing how `__FILE__` was rendered
+- Before: recognized as `<code>` → broken display
+- After: rendered as plain text
 
-### Slide 15 — Why Markdown?
+### Slide 18 — What the rewrites changed
+- Prism benchmark: 0.69s vs 0.97s (Ripper) on 112 files (~30% faster)
+- Before/after code: Ripper tokens vs Prism AST visit
+
+### Slide 19 — Markdown in RDoc
 - Markdown is the universal format — humans and AI both read and write it
 - RDoc markup is Ruby-specific, not widely known
-- "If you can write a GitHub README, you can contribute to Ruby documentation"
-
-### Slide 16 — Markdown: the coupling problem
-- Pipeline diagram:
-  ```
-  Markdown parser ──┐                    ┌─────────────┐
-                    ├─► RDoc::Markup ───►│ Shared       │
-  RDoc parser    ──┘    nodes with       │ InlineParser │──► HTML
-                        RDoc strings     │ & Formatters │
-                        inside           └─────────────┘
-  ```
+- "If you can write a GitHub README, you can write Ruby documentation"
+
+### Slide 20 — The coupling problem
+- Pipeline diagram: Markdown parser and RDoc parser both feed through shared InlineParser
 - Every Markdown fix is a two-format fix
 
-### Slide 17 — Markdown: concrete example
-- `~~strikethrough~~` → `<del>text</del>` as plain string
-- SharedInlineParser didn't recognize `<del>` → silently broken
+### Slide 21 — Example: `~~strikethrough~~`
+- Before/after: `~~text~~` → broken in v6.11.0, correct `<del>` now
 - Fix touches shared code → must verify RDoc markup still works
 
-### Slide 18 — Markdown: what's improved
-- Strikethrough, heading anchors, table fixes, syntax highlighting
-- GFM spec comparison test suite
-- Migration started: `standard_library_md.html` in Ruby 3.4+
+### Slide 22 — Bash syntax highlighting
+- Before/after: bash code blocks — no highlighting vs proper sh-* tokens
 
-### Slide 19 — RBS type signatures
+### Slide 23 — C syntax highlighting
+- Before/after: C code blocks — no highlighting vs proper c-keyword tokens
+
+### Slide 24 — Inline styling in tables
+- Before/after: `` `code` `` in table cells was broken, now works
+
+### Slide 25 — GFM compatibility table
+- Feature comparison: GFM vs RDoc v6.11.0 vs RDoc current
+- 4 fixed, 1 regressed, 7 still broken in both
+
+### Slide 26 — RBS type signatures
 - The `#:` inline annotation syntax
-- Example:
-  ```ruby
-  #: (String name, ?Integer age) -> User
-  def create_user(name, age = nil)
-  ```
 - RDoc extracts and displays in HTML and `ri`
 
-### Slide 20 — RBS in HTML demo
+### Slide 27 — RBS in HTML output
 - Screenshot: class page with type signatures rendered
 - Type names are clickable links to their documentation
 
-### Slide 21 — AI helped us get here
-- RDoc is huge and complex — without dedicated maintainers, change was slow
-- tompng and I became active in 2024 — progress, but limited
-
-### Slide 22 — AI accelerated the pace
-- Since mid-2025, AI helped me increase my output significantly
-- tompng's work was his own — but AI helped me keep up with reviewing it
-- "The pace is accelerating. Not because we're working harder, but because we have better tools."
-
 ---
 
-## Section 3: What's Still Ahead (~8 min)
+## Section 3: What's Still Ahead (~8-9 min)
 
-### Slide 23 — RDoc's priority
+### Slide 28 — RDoc's priority [CONTRIBUTING]
 - Better contributing experience
-- Target: Ruby's official docs (docs.ruby-lang.org) and gem docs
+- Target: Ruby's official docs and gem docs
 - Make documentation easier to write and maintain
 
-### Slide 24 — Setting good standards
+### Slide 29 — Setting good standards [CONTRIBUTING]
 - RBS signatures are a start — structured, machine-readable contracts
 - We'll revisit supported directives for clarity
-- Whether users adopt a type checker is their choice — RDoc supports both
 
-### Slide 25 — Better tools for writing docs
-- For humans: server mode
-- For AI agents: improved CLI
-  - `rdoc -C` coverage: what's missing or incorrect
-  - `ri --format=markdown`: query Ruby docs directly
+### Slide 30 — Better tools for writing docs [CONTRIBUTING]
+- For humans: `rdoc --server` (live preview)
+- For AI agents: `rdoc -C` (coverage — what's missing)
+- For AI agents: `ri --format=markdown` (query docs directly)
 
-### Slide 26 — For consuming documentation
-- For humans: Aliki theme improved the reading experience
+### Slide 31 — For consuming documentation [LLM-READY DOCS]
+- For humans: Aliki improved the reading experience
 - For AI: we evaluated and found nothing proven yet
 
-### Slide 27 — We prototyped llms.txt
-- The most complete standard for LLM-friendly docs
-- 10% adoption across 300k domains, zero measurable impact on AI citations
-- No major LLM provider officially consumes it
-
-### Slide 28 — Markdown output for AI?
-- No standard for serving Markdown versions of documentation pages
-- We considered generating Markdown output from RDoc
-- Prioritizing this now creates more risk than reward
-
-### Slide 29 — Rustdoc tried this too
-- Rustdoc RFC (rust-lang/rfcs#3751): proposed LLM-friendly text output
-- Community rejected it: "This should be an external tool"
+### Slide 32 — Rustdoc: community and maintainers said no [LLM-READY DOCS]
+- RFC #3751 proposed LLM-friendly text output for Rustdoc
 - T-rustdoc team: "Very likely not the desired format within 3 months, never mind 3 years"
+- Community consensus: "This should be an external tool"
+- Footnote: github.com/rust-lang/rfcs/pull/3751
 
-### Slide 30 — The landscape
-- No major doc generator has shipped AI-specific output features
-- All AI-docs integration happens at the consumption layer (MCP servers, Dash, DevDocs)
-- Doc generators should focus on producing good output
-- "If I missed anything in this space, I'd love to hear about it after the talk"
-
-### Slide 31 — Documentation has more leverage now
-- docs.ruby-lang.org is what AI models train on and what AI tools reference
-- In the AI age, every improvement to Ruby's docs gets amplified
+### Slide 33 — ExDoc: shipped it [LLM-READY DOCS]
+- ExDoc v0.40.0 (Jan 2026): Markdown output formatter + llms.txt
+- Enabled by default — every Elixir project gets it
+- First major doc tool to ship AI-oriented output
 
-### Slide 32 — Types in docs, not type checking at generation
-- Endoh benchmark (March 2026): Ruby is #1 for AI code generation ($0.36/run)
-- Adding a type checker at generation time costs 2-3× overhead
-- Types already in documentation give AI the information without that cost
+### Slide 34 — We prototyped llms.txt [LLM-READY DOCS]
+- The most complete standard for LLM-friendly docs
+- ~10% adoption across 300K domains, zero measurable impact on AI citations
+- No major LLM provider officially consumes it
+- Footnote: SE Ranking study (seranking.com/blog/llms-txt)
 
-### Slide 33 — The honest constraint
-- The AI consumption space moves fast
-- Nothing is proven effective yet
-- We keep the foundation solid and wait for the dust to settle
+### Slide 35 — RDoc: studying while building the foundation [LLM-READY DOCS]
+- We're watching how these approaches play out
+- Priority now: make the documentation better at the source
+- Any AI-specific format risks being obsolete in months
 
 ---
 
 ## Section 4: Recap + Close (~2 min)
 
-### Slide 34 — Summary
-- In the AI age, documentation has more leverage than ever
+### Slide 36 — Summary
+- AI reads Ruby's docs too now — improving them helps everyone
 - RDoc's priority: make docs easier to write and maintain
 - The foundation is rebuilt: Prism, Markdown, server mode, RBS, Aliki
 
-### Slide 35 — Call to action
+### Slide 37 — Try it today
 - Contribute to Ruby documentation — it's Markdown now
 - Try `rdoc --server` for your own projects
-- Links:
-  - github.com/ruby/rdoc
-  - docs.ruby-lang.org
+- github.com/ruby/rdoc
+- docs.ruby-lang.org
 
-### Slide 36 — Thank you
+### Slide 38 — Thank you
 - Thank tompng (Tomoya Ishida), Shopify Ruby DX team, Ruby committers
-- Questions?
+- @st0012 (GitHub), @st0012.dev (BlueSky)
 
 ---
 
@@ -210,24 +196,25 @@ All supporting research is in `research/`:
 - `ruby_prs.md` — 41 PRs in ruby/ruby since Oct 2025
 - `current_features.md` — Feature state analysis
 - `llms_txt_adoption.md` — llms.txt adoption data
-- `ruby_skills_repo.md` — ruby-skills repo analysis
 - `callseq_vs_rbs.md` — call-seq vs RBS comparison
 - `markdown_rdoc_coupling.md` — Markdown/RDoc architectural coupling
 - `tompng_prism_work.md` — tompng's contributions
+- `tompng_comment_formatting_rewrites.md` — InlineParser replacement details
 - `type_sigs_ai_performance.md` — Deep research: types + AI (10 sources, verified)
 - `ai_documentation_skills.md` — Documentation tools + AI landscape
 - `markdown_for_agents.md` — Markdown for AI agents: approaches and open questions
 - `rustdoc_llm_rfc.md` — Rustdoc LLM RFC discussion (rust-lang/rfcs#3751)
+- `gfm_comparison_v6110_vs_current.md` — GFM feature comparison with actual HTML output
 
 ## Timing Budget
 
 | Section | Time | Slides |
 |---------|------|--------|
-| 1. The hook | 3-4 min | 9 |
-| 2. Here's what we did | ~14-16 min | 13 |
-| 3. What's still ahead | ~8-9 min | 11 |
+| 1. The hook | 3-4 min | 10 |
+| 2. Here's what we did | ~14-16 min | 17 |
+| 3. What's still ahead | ~8-9 min | 8 |
 | 4. Recap + close | ~2 min | 3 |
-| **Total** | **~28-30 min** | **36** |
+| **Total** | **~28-30 min** | **38** |
 
 ## Working with the Slides