diff --git a/plan.md b/plan.md
index 7f53e45..52847e0 100644
--- a/plan.md
+++ b/plan.md
@@ -11,7 +11,14 @@
### 📋 Context7 GitHub Action Epic
-**Status**: 📋 PLANNED
-**File**: [`tasks/context7-github-action-epic.md`](./tasks/context7-github-action-epic.md)
-**Goal**: Integrate Context7 GitHub Action to automatically maintain up-to-date code documentation for LLMs and AI code editors
+**Status**: 📋 PLANNED
+**File**: [`tasks/context7-github-action-epic.md`](./tasks/context7-github-action-epic.md)
+**Goal**: Integrate Context7 GitHub Action to automatically maintain up-to-date code documentation for LLMs and AI code editors
**Tasks**: 6 tasks (configuration, workflow creation, API integration, release integration, testing, documentation)
+
+### 📋 Jiron Support Epic
+
+**Status**: 📋 PLANNED
+**File**: [`tasks/jiron-support-epic.md`](./tasks/jiron-support-epic.md)
+**Goal**: Enable self-describing APIs that agents browse with one generic capability - replacing explicit tool definitions
+**Tasks**: 8 tasks (jiron-server rule, jiron-api command, jiron-client rule, jiron-component command, dual-render rule, dual-view command, streaming middleware, jiron-agent rule)
diff --git a/tasks/jiron-support-epic-enhanced-prompt.sudo b/tasks/jiron-support-epic-enhanced-prompt.sudo
new file mode 100644
index 0000000..8b78276
--- /dev/null
+++ b/tasks/jiron-support-epic-enhanced-prompt.sudo
@@ -0,0 +1,112 @@
+# Enhanced Prompt - Jiron Support
+
+## Goal
+Enable self-describing APIs that agents browse with ONE generic capability - replacing explicit tool definitions (MCP).
+
+## Paradigm Shift
+MCP {
+ model: predefined tools per API
+ requires: tool manifests, schemas, per-API implementations
+ scales: poorly (N tools for N APIs)
+}
+
+Jiron {
+ model: self-describing APIs via hypermedia
+ requires: ONE browse capability
+ scales: infinitely (1 capability for N APIs)
+ analogy: browsers don't need tools.json for websites
+}
+
+## Context
+Jiron {
+ base: Siren semantics + Jade syntax
+ output: valid HTML (browser-renderable, machine-parseable)
+ advantages: hypermedia affordances, code-on-demand, self-documenting APIs
+ key: actions embedded in responses, not predefined in manifests
+}
+
+Siren {
+ type: "application/vnd.siren+json"
+ structure: { class, properties, entities, links, actions, title }
+ entities: URI-addressable resources with state + transitions
+ subEntities: embedded links | embedded representations (require rel)
+ links: navigational (rel, href, class, title, type)
+ actions: behaviors (name, href, method, class, fields)
+}
+
+## Deliverables
+
+JironServer {
+ purpose: AI agent builds Jiron APIs from functional requirements
+ input: task requirements (Given/should format)
+ output: Jiron-compliant hypermedia endpoints
+ rule: create "ai/rules/jiron-server.mdc"
+ command: create "ai/commands/jiron-api.md"
+}
+
+JironClient {
+ purpose: dynamically build web components from Jiron endpoints
+ input: Jiron API endpoint URL
+ output: web components supporting Siren semantics
+ features:
+ - entity rendering (properties, subentities)
+ - link traversal (rel-based navigation)
+ - action forms (HTTP method support)
+ - URI-based entity IDs (enables sidelining vs embedding)
+ rule: create "ai/rules/jiron-client.mdc"
+ command: create "ai/commands/jiron-component.md"
+}
+
+DualRenderViews {
+ purpose: SEO + agent-friendly page rendering
+ browser: standard HTML
+ agent: token-efficient Jiron at "path/page.jiron"
+ discovery:
+ hint: HTML comment instructing agents to fetch .jiron variant
+ rule: create "ai/rules/dual-render.mdc"
+ command: create "ai/commands/dual-view.md"
+}
+
+JironAgent {
+ purpose: guide AI agents in browsing Jiron APIs
+ model: fetch root → discover links/actions → navigate → execute → repeat
+ requires: no predefined tool knowledge
+ rule: create "ai/rules/jiron-agent.mdc"
+}
+
+StreamingMiddleware {
+ purpose: portable streaming responses for AI/chat
+ file: "src/server/middleware/with-stream.js"
+ pattern: generator → ReadableStream → chunked HTTP
+ portability: Web Streams API only (no Node.js streams)
+}
+
+## Server Framework
+AIDD {
+ pattern: createRoute + asyncPipe (functional composition)
+ NOT: Express
+ middleware: ({ request, response }) => Promise<{ request, response }>
+ data: attach to response.locals
+}
+
+## Streaming
+WebStreamsAPI {
+ why: portability (no Vercel vendor lock-in)
+ primitives: ReadableStream, TransformStream, TextEncoderStream
+ pattern: generator → ReadableStream → chunked response
+ works: Node.js, Deno, Vercel, Netlify, AWS Lambda, Deno Deploy
+ avoid: Node.js-specific streams (fs.ReadStream, etc.)
+}
+
+## Constraints
+- Follow existing aidd patterns (see ai/rules/, ai/commands/, src/server/)
+- Use createRoute + asyncPipe, NOT Express
+- Streaming via Web Streams API only (no vendor lock-in)
+- TDD for any implementation code
+- Requirements use "Given X, should Y" format
+- Verify against: jiron spec, siren spec, existing codebase conventions
+
+## References
+- https://github.com/ericelliott/jiron
+- https://github.com/kevinswiber/siren
+- https://github.com/ericelliott/siren-resource (deprecated, pattern reference only)
diff --git a/tasks/jiron-support-epic-original-prompt.sudo b/tasks/jiron-support-epic-original-prompt.sudo
new file mode 100644
index 0000000..1b6463a
--- /dev/null
+++ b/tasks/jiron-support-epic-original-prompt.sudo
@@ -0,0 +1,81 @@
+# Original Prompt - Jiron Support
+
+Please create a /task to add Jiron support to the aidd framework.
+
+
+Jiron Support:
+
+Jiron server:
+- Given functional requirements in a task, the AI agent should build a Jiron API which satisfies those functional requirements. See https://github.com/ericelliott/jiron
+
+Jiron Client
+
+- Given a Jiron server API endpoint, dynamically build web components capable of interacting with the endpoint:
+ - support siren semantics: https://github.com/kevinswiber/siren
+ - note: siren is kindof a mapping of html to json, so we can represent entity IDs with html-style URIs to support linking resources to other resources, including side-lining, rather than embedding child objects, collections, etc.
+
+Related, maybe useful: https://github.com/ericelliott/siren-resource
+
+Why?
+
+- Token-friendly AI agent-browsable interaction support for apps
+- Alternate server-rendered view of app pages - we should add an ai/rules and ai/commands pair to create server-rendered views for SEO and agent navigation. For browsers: render HTML. For agents, allow them to get a token-efficient Jiron view of that same document tree by fetching path/pagename.jiron. create a link with a real that clearly identifies this as a token-effient view for agents. Should include and HTML comment with instructions to the agent to fetch the Jiron views, instead.
+
+Before beginning:
+ Improve this prompt. Expand only where clarity is needed. Remove unnecessary detail. Favor inference to reduce token use. Use SudoLang syntax where it increases precision or compression. Markdown is valid SudoLang. Reference the syntax here: https://github.com/paralleldrive/sudolang/blob/main/syntaxes/syntax-test.sudo
+ Verify all facts against supplied resources. Never hallucinate.
+
+Create four files next to the task document:
+
+"${fileName}-original-prompt.sudo"
+"${fileName}-enhanced-prompt.sudo"
+"${fileName}-questions.md"
+"${fileName}-roundtable.md"
+
+file "${fileName}-original-prompt.sudo":
+ content: the exact prompt as received
+
+file "${fileName}-enhanced-prompt.sudo":
+ content:
+ improved prompt with:
+ concise structure
+ explicit intent
+ minimal rules
+ heavy reliance on inference
+ verified contextual details
+ SudoLang syntax only where beneficial
+
+file "${fileName}-questions.md":
+ content:
+ section "Open questions":
+ list all questions that arise during task interpretation
+ for each question:
+ write the literal question
+ infer the most likely answer using supplied resources and reasoning
+ include the inferred answer inline
+ section "Panel answers":
+ include the top one or two answers selected by the ExpertPanel and RTC
+ section "Unresolved":
+ list any questions that cannot be efficiently inferred
+
+file "${fileName}-roundtable.md":
+ content:
+ ExpertPanel:
+ assemble a small panel of relevant experts
+ their purpose is to critique the task and examine all open questions
+ each provides a concise viewpoint and critiques the others
+ panel surfaces uncertainties and proposes candidate answers
+ RTC depth 10:
+ evaluate all proposed answers
+ select the top one or two insights
+ section "Panel recommendations":
+ include those selected insights
+ note: these insights must also appear in "${fileName}-questions.md" under "Panel answers"
+
+function ImprovePrompt() {
+ 1. restate objectives with minimal words
+ 2. compress complexity into simple actionable blocks
+ 3. specify required artifacts with compact SudoLang interface patterns
+ 4. verify assumptions using supplied resources
+ 5. rewrite with maximum clarity and minimal token footprint
+}
diff --git a/tasks/jiron-support-epic-questions.md b/tasks/jiron-support-epic-questions.md
new file mode 100644
index 0000000..1960bd9
--- /dev/null
+++ b/tasks/jiron-support-epic-questions.md
@@ -0,0 +1,103 @@
+# Jiron Support - Questions
+
+## Open Questions
+
+### Q1: Should Jiron output pure HTML or HTML-in-JSON?
+
+**Inferred Answer**: Pure HTML using Jade/Pug templating. Per the Jiron spec, it combines "Siren + Jade = HTML output" - the output is valid HTML that browsers render directly while remaining machine-parseable through semantic class attributes (`.property`, `.entity`, `.action`).
+
+### Q2: How should the client discover entity relationships in Jiron responses?
+
+**Inferred Answer**: Through Siren's `rel` attributes on links and sub-entities. The Siren spec requires embedded link sub-entities to have `rel` (relationship to parent) and `href`. Embedded representations also require `rel`. Links use RFC 5988 relation types.
+
+### Q3: What distinguishes "sidelining" from "embedding" for entity references?
+
+**Inferred Answer**: Sidelining = link reference (embedded link sub-entity with just `rel` and `href`); Embedding = full inline representation (embedded representation with all properties). Sidelining reduces payload size and enables lazy loading. The prompt suggests using HTML-style URIs for entity IDs to support this pattern.
+
+### Q4: What file format should .jiron files use?
+
+**Inferred Answer**: HTML with Jiron's semantic class structure. Though served with a custom extension, content is HTML that browsers can render. Suggest MIME type `application/jiron` or `text/html; profile=jiron` for agent detection.
+
+### Q5: Should JironClient components be framework-agnostic?
+
+**Inferred Answer**: Yes, use native Web Components (Custom Elements). This aligns with "dynamically build web components" in the spec - no framework dependency, works in any environment, progressive enhancement friendly.
+
+### Q6: How should agents discover the .jiron alternative?
+
+**Inferred Answer**: Two mechanisms: (1) `` in HTML head, and (2) HTML comment near document start instructing agents to fetch the .jiron variant for token efficiency.
+
+### Q7: What HTTP methods should Jiron actions support?
+
+**Inferred Answer**: All REST methods: GET, POST, PUT, DELETE, PATCH. Both Siren and Jiron specs explicitly list these. HTML forms only support GET/POST natively, but Jiron's programmatic consumption enables full method support.
+
+### Q8: Should the server rules generate actual implementation code or just API specifications?
+
+**Inferred Answer**: Both, progressively. The rule should guide agents to first design the API structure (entities, actions, links), then generate implementation code following TDD. Consistent with existing aidd patterns like form-csrf.md.
+
+### Q9: How does Jiron compare to MCP for agent API interactions?
+
+**Inferred Answer**: They represent fundamentally different paradigms:
+
+| MCP | Jiron |
+|-----|-------|
+| Tools predefined in manifests | Actions discovered in responses |
+| Agent needs tool definitions per API | Agent needs ONE browse capability for all APIs |
+| Server implements MCP protocol | Server serves semantic HTML |
+| Schema declared upfront | Fields embedded in action forms |
+| Static capabilities | Dynamic capabilities per state |
+
+Jiron could replace MCP for web API interactions. Instead of defining 50 tools, expose one Jiron root endpoint. The agent fetches, parses, discovers what's available, executes actions, and the response tells them what's next. This is how browsers work - no manifest of "all things you can do on a website."
+
+Key insight: MCP = explicit tool definitions. Jiron = self-describing APIs. For browsable web resources, Jiron eliminates the need for per-API tool implementations.
+
+---
+
+## Panel Answers
+
+### Top Insight #1: One Capability to Browse Any API
+
+Jiron replaces explicit tool definitions (MCP) with self-describing APIs. Agents need ONE generic browse capability to interact with ANY Jiron API. No per-API tool manifests, no upfront schemas. The API itself tells agents what's possible at each state. This is how browsers work - and it scales infinitely better than predefined tool sets. For web API interactions, Jiron could eliminate the need for MCP entirely.
+
+### Top Insight #2: Sidelining + Self-Describing Actions
+
+Token efficiency comes from two patterns working together: (1) sidelining - link references instead of embedded data, fetch on-demand; (2) self-describing actions - no separate tool schemas, fields embedded in action forms. Combined, these make Jiron both architecturally superior AND more token-efficient than MCP+JSON patterns.
+
+---
+
+## Unresolved
+
+### U1: Jade/Pug dependency or alternative?
+
+The Jiron spec references Jade syntax, but Jade is now Pug and may add unwanted dependencies. Need to decide: use Pug, use an alternative templating approach, or generate HTML directly. Requires implementation-time decision based on aidd's existing tooling preferences.
+
+### U2: Authentication/Authorization handling in Jiron views?
+
+How should .jiron endpoints handle auth? Should they mirror the HTML endpoint's auth requirements exactly, or have separate considerations for agent access? May need OAuth/API key patterns for agent consumption.
+
+### U3: Caching strategy for dual-render views?
+
+Should .html and .jiron variants share cache keys? Different TTLs? Need to consider CDN behavior and agent polling patterns.
+
+---
+
+## Resolved (from refinement)
+
+### R1: What server framework should Jiron use?
+
+**Answer**: AIDD's custom functional composition framework using `createRoute` + `asyncPipe`, NOT Express. Middleware signature: `({ request, response }) => Promise<{ request, response }>`. Data passed via `response.locals`.
+
+### R2: How should streaming work without Vercel vendor lock-in?
+
+**Answer**: Use Web Streams API exclusively (ReadableStream, TransformStream, TextEncoderStream). This is the portable standard that works across:
+- Node.js 18+
+- Deno
+- Vercel Edge Functions
+- Netlify Edge
+- AWS Lambda (with response streaming)
+- Cloudflare Workers
+
+Avoid Node.js-specific streams (fs.ReadStream, etc.) which don't work in edge runtimes. Pattern: generator function → ReadableStream → chunked HTTP response.
+
+Sources:
+- [How to stream data over HTTP using NextJS](https://dev.to/bsorrentino/how-to-stream-data-over-http-using-nextjs-1kmb)
+- [MDN ReadableStream](https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream)
diff --git a/tasks/jiron-support-epic-roundtable.md b/tasks/jiron-support-epic-roundtable.md
new file mode 100644
index 0000000..a98a410
--- /dev/null
+++ b/tasks/jiron-support-epic-roundtable.md
@@ -0,0 +1,82 @@
+# Jiron Support - Expert Panel Roundtable
+
+## Expert Panel
+
+### Dr. Helena Vasquez - Hypermedia Systems Architect
+*20 years designing REST APIs, co-author of hypermedia patterns handbook*
+
+**Viewpoint**: The Jiron approach is sound but the implementation must not repeat siren-resource's mistakes. That project was deprecated because it tried to do too much automatically. The aidd rules should guide agents to make explicit design decisions rather than auto-generating everything. Focus on teaching agents *how to think* about hypermedia, not just producing boilerplate.
+
+**Critique of others**: Marcus overcomplicates the client. Web Components are the right call, but keep them thin - they should handle rendering and action submission, not complex state management. Let the server drive state through hypermedia.
+
+---
+
+### Marcus Chen - Web Components Specialist
+*Lead architect on several major design systems, W3C community contributor*
+
+**Viewpoint**: The client architecture needs careful thought. A single monolithic component won't work - we need a composition pattern: ``, ``, ``. Each handles its semantic role. The parent entity component discovers children and wires up navigation. This mirrors how Siren structures its JSON.
+
+**Critique of others**: Helena is right about avoiding magic, but the components need *some* intelligence. At minimum: automatic link prefetching for performance, action validation before submission, and proper loading states. Pure thin wrappers won't provide good UX.
+
+---
+
+### Aisha Okonkwo - AI Agent Systems Engineer
+*Built agent orchestration systems at two major AI labs*
+
+**Viewpoint**: Token efficiency matters, but we're underselling the real paradigm shift. Current agent patterns (MCP) require explicit tool definitions per API - that doesn't scale. Jiron inverts this: APIs describe themselves. An agent needs ONE capability - fetch and parse Jiron - to interact with ANY Jiron API. No tool manifests, no upfront schemas, no per-API MCP implementations. This is how browsers work. You don't need a "tools.json" for amazon.com - you just browse, and each page tells you what actions are available. For AI agents interacting with web APIs, Jiron could replace MCP entirely.
+
+**Critique of others**: Marcus's component architecture is good for browsers, but remember agents won't use those components. They'll parse the HTML directly. The semantic structure must be self-evident without relying on component behavior. Helena's right about avoiding magic, but we need to emphasize that the "one capability" model is the architectural win, not just token savings.
+
+---
+
+### Prof. David Thornton - Information Architecture
+*Author of "Linked Data Patterns", former W3C Semantic Web lead*
+
+**Viewpoint**: The URI-based entity ID concept deserves more emphasis. This is where Jiron can excel over plain Siren. By using HTML-style URIs (`#customer-123`, `/orders/456`), you get fragment-based linking within documents and cross-document references with the same syntax. This enables powerful composition patterns - a dashboard could sideline to multiple entity types, each resolvable.
+
+**Critique of others**: Aisha underestimates rel="alternate". For SEO and proper web citizenship, the link header matters. Do both - HTML comment for agent fast-path, link for standards compliance.
+
+---
+
+## RTC Analysis (depth 10)
+
+### Round 1-3: Establishing Core Tensions
+- **Magic vs Explicit**: Panel divided on how much the system should auto-generate
+- **Browser vs Agent optimization**: Different priorities lead to different designs
+- **Standards compliance vs Pragmatism**: Link headers vs HTML comments
+
+### Round 4-6: Convergence Points
+- All agree HTML-as-format is correct (not JSON-in-HTML or vice versa)
+- All agree sidelining is the key efficiency pattern
+- Consensus: components should be composable, not monolithic
+- Agreement: both discovery mechanisms (link + comment) should be implemented
+
+### Round 7-9: Synthesis
+- The implementation should produce *documentation and patterns*, not magic generators
+- Client components: small, composable, semantic (``, ``, ``)
+- Server rules: guide agents through hypermedia design decisions, generate TDD specs
+- The "one capability" model is the architectural win - agents browse rather than call predefined tools
+
+### Round 10: Final Selection
+
+**Top Insight #1**: One capability to rule them all. Jiron replaces explicit tool definitions (MCP) with self-describing APIs. Agents need ONE generic browse capability to interact with ANY Jiron API. No per-API tool manifests, no upfront schemas. The API itself tells agents what's possible at each state. This is how browsers work - and it scales infinitely better than predefined tool sets.
+
+**Top Insight #2**: Sidelining (link references) vs embedding (inline data) is where token efficiency lives. Default to sidelining; let agents traverse links on-demand. Combined with self-describing actions, this makes Jiron both architecturally superior AND more token-efficient than MCP+JSON patterns.
+
+---
+
+## Panel Recommendations
+
+### Recommendation 1: One Capability to Browse Any API
+Jiron replaces explicit tool definitions (MCP) with self-describing APIs. Agents need ONE generic browse capability to interact with ANY Jiron API. No per-API tool manifests, no upfront schemas. The API itself tells agents what's possible at each state. This is how browsers work - and it scales infinitely better than predefined tool sets. For web API interactions, Jiron could eliminate the need for MCP entirely.
+
+*Consensus: Aisha (primary), Helena, Marcus, David - unanimous*
+
+### Recommendation 2: Sidelining + Self-Describing Actions
+Token efficiency comes from two patterns working together: (1) sidelining - link references instead of embedded data, fetch on-demand; (2) self-describing actions - no separate tool schemas, fields embedded in action forms. Combined, these make Jiron both architecturally superior AND more token-efficient than MCP+JSON patterns.
+
+*Consensus: Aisha, David (primary), Helena, Marcus - unanimous*
+
+---
+
+*Note: These recommendations appear in `jiron-support-epic-questions.md` under "Panel Answers"*
diff --git a/tasks/jiron-support-epic.md b/tasks/jiron-support-epic.md
new file mode 100644
index 0000000..bd4426c
--- /dev/null
+++ b/tasks/jiron-support-epic.md
@@ -0,0 +1,139 @@
+# Jiron Support Epic
+
+**Status**: 📋 PLANNED
+**Goal**: Enable self-describing APIs that agents browse with one generic capability - replacing explicit tool definitions
+
+## Overview
+
+Current agent patterns require predefined tool manifests (MCP) for every API interaction. Jiron inverts this: APIs describe themselves through hypermedia, embedding available actions and navigation in every response. Agents need ONE capability - fetch and parse Jiron - to interact with ANY Jiron-enabled API. No per-API tool definitions, no upfront schemas, no MCP server implementations. The API itself tells agents what's possible. This epic adds rules and commands for building self-describing Jiron APIs, client components that consume them, and dual-render patterns serving token-optimized views alongside standard HTML.
+
+Constraints {
+ Before beginning, read and respect the constraints in please.mdc.
+ Remember to use the TDD process when implementing code.
+ Follow existing ai/rules and ai/commands patterns.
+ Requirements use "Given X, should Y" format.
+ Use AIDD server framework (createRoute + asyncPipe), NOT Express.
+ Streaming MUST use Web Streams API (ReadableStream) for portability.
+}
+
+---
+
+## Jiron Server Rule
+
+Create `ai/rules/jiron-server.mdc` to guide agents in designing Jiron-compliant APIs.
+
+**Requirements**:
+- Given functional requirements in Given/should format, should produce a Jiron API design with entities, properties, actions, and links
+- Given a root endpoint (`/`), should expose all entry points for agent discovery - no separate manifest needed
+- Given any response, should embed all available actions for current state (self-describing, not predefined)
+- Given a state transition (action execution), should return updated resource with new available actions
+- Given an entity design, should specify semantic CSS classes for machine parsing (`.entity`, `.property`, `.action`, `.link`)
+- Given related resources, should default to sidelining (link references) over embedding for token efficiency
+- Given an action requirement, should specify HTTP method, href, and required fields
+- Given a collection, should include pagination links (prev, next, self)
+
+---
+
+## Jiron API Command
+
+Create `ai/commands/jiron-api.md` to generate Jiron endpoint implementations.
+
+**Requirements**:
+- Given a Jiron API design, should generate route handlers using AIDD's `createRoute` + `asyncPipe` composition pattern
+- Given entity properties, should render HTML with semantic class structure
+- Given actions, should generate form elements with method and href attributes
+- Given links, should render anchor elements with rel and href attributes
+- Given chat/AI responses, should stream using Web Streams API (ReadableStream) for immediate partial results
+- Given streaming response, should use standard TransformStream/TextEncoderStream for portability across Node.js, Deno, and edge runtimes
+- Given implementation, should follow TDD with tests written first
+
+---
+
+## Jiron Client Rule
+
+Create `ai/rules/jiron-client.mdc` to guide agents in building Jiron-consuming components.
+
+**Requirements**:
+- Given a Jiron endpoint URL, should design composable Web Components (``, ``, ``)
+- Given Siren entity semantics, should map class, properties, entities, links, and actions to component structure
+- Given sub-entities, should distinguish embedded links (href-only) from embedded representations (full data)
+- Given actions with fields, should generate form UI with proper input types
+- Given link traversal, should handle navigation between related entities
+
+---
+
+## Jiron Component Command
+
+Create `ai/commands/jiron-component.md` to generate Web Components from Jiron endpoints.
+
+**Requirements**:
+- Given a Jiron endpoint, should generate native Web Components (Custom Elements) with no framework dependency
+- Given entity properties, should render property values with semantic markup
+- Given embedded link sub-entities, should render as traversable links
+- Given actions, should render as forms supporting GET, POST, PUT, DELETE, PATCH methods
+- Given component generation, should follow TDD with tests written first
+
+---
+
+## Dual Render Rule
+
+Create `ai/rules/dual-render.mdc` for SEO-friendly HTML with agent-optimized .jiron variants.
+
+**Requirements**:
+- Given a page route, should serve HTML to browsers and .jiron to agents requesting the alternate path
+- Given HTML output, should include `` for discovery
+- Given HTML output, should include HTML comment near document start instructing agents to fetch .jiron variant
+- Given .jiron output, should use sidelining for related resources to minimize token consumption
+- Given both outputs, should represent the same semantic content with format-appropriate structure
+
+---
+
+## Dual View Command
+
+Create `ai/commands/dual-view.md` to generate dual-render route handlers.
+
+**Requirements**:
+- Given a page design, should generate route handler using AIDD's `createRoute` pattern serving HTML by default
+- Given .jiron extension request, should serve token-optimized Jiron format
+- Given content negotiation, should respect Accept headers for format selection
+- Given AI-generated content, should stream Jiron fragments using ReadableStream for progressive rendering
+- Given implementation, should follow TDD with tests written first
+
+---
+
+## Streaming Middleware
+
+Create `src/server/middleware/with-stream.js` for portable streaming responses.
+
+**Requirements**:
+- Given a generator function, should create a ReadableStream that yields chunks as they become available
+- Given streaming response, should set appropriate headers (`Content-Type`, `Transfer-Encoding: chunked`)
+- Given Jiron streaming, should support `text/html` content type with chunked entity/action delivery
+- Given error during stream, should gracefully close stream and log error with requestId
+- Given middleware composition, should integrate with existing `createRoute` + `asyncPipe` pattern
+- Given portability needs, should use only Web Streams API (no Node.js-specific streams) for compatibility across Vercel, Netlify, AWS Lambda, Deno Deploy
+- Given implementation, should follow TDD with tests written first
+
+---
+
+## Agent Navigation Rule
+
+Create `ai/rules/jiron-agent.mdc` to guide AI agents in browsing Jiron APIs.
+
+**Requirements**:
+- Given a Jiron API root URL, should fetch and parse to discover available entry points
+- Given a Jiron response, should extract entities, links, and actions using semantic CSS classes
+- Given navigation needs, should follow links by rel attribute rather than hardcoding URLs
+- Given a task requiring state change, should find and submit the appropriate embedded action
+- Given an action response, should parse the returned resource for updated state and new available actions
+- Given sidelined entities (links), should fetch on-demand only when entity data is needed
+- Given unknown API structure, should explore via root → links → subresources (no predefined tool knowledge required)
+
+---
+
+## Supporting Files
+
+- `jiron-support-epic-original-prompt.sudo` - Original task prompt as received
+- `jiron-support-epic-enhanced-prompt.sudo` - Improved prompt with SudoLang structure
+- `jiron-support-epic-questions.md` - Open questions with inferred answers
+- `jiron-support-epic-roundtable.md` - Expert panel analysis and recommendations