wip

mme · mme · commit 1f4500fa59e7 · 2025-09-23T16:17:01.000+02:00
diff --git a/docs/drafts/activity-events.mdx b/docs/drafts/activity-events.mdx
@@ -16,7 +16,7 @@ AG-UI is extended with **ActivityEvents** and **ActivityMessages** to represent
 ## Status
 
 - **Status**: Draft
-- **Author(s)**: AG-UI Team
+- **Author(s)**: Markus Ecker (markus.ecker@gmail.com)
 
 ## Background
 
@@ -154,10 +154,6 @@ Python SDK additions:
 - **Workflow Systems**: Can surface step-by-step workflow progress as ActivityEvents
 - **Other frameworks**: May emit ActivityEvents freely; AG-UI will serialize them like other events
 
-## Breaking Changes
-
-None. This is an additive change that maintains backward compatibility.
-
 ## Examples and Use Cases
 
 ### Example 1: Web Search Activity
@@ -205,13 +201,6 @@ Each step appears inline with chat, giving users real-time feedback.
 - E2E tests in AG-UI Dojo demonstrating activity rendering
 - Performance benchmarks for high-frequency activity updates
 
-## Open Questions
-
-1. Should we enforce a schema for common activity types (e.g., standardized "PLAN" format)?
-2. How should activities behave across run boundaries?
-3. Should there be a maximum number of patches before requiring a new snapshot?
-4. How do activities interact with message editing/regeneration?
-
 ## References
 
 - [JSON Patch RFC 6902](https://tools.ietf.org/html/rfc6902)
diff --git a/docs/drafts/generative-ui.mdx b/docs/drafts/generative-ui.mdx
@@ -16,7 +16,7 @@ This draft describes an AG-UI extension that addresses **generative user interfa
 ## Status
 
 - **Status**: Draft
-- **Author(s)**: AG-UI Team
+- **Author(s)**: Markus Ecker (markus.ecker@gmail.com)
 
 ## Challenges and Limitations
 
@@ -275,10 +275,6 @@ Python SDK additions:
 - Frameworks emit standard tool calls; client handles UI generation
 - Backward compatible with existing tool-based UI approaches
 
-## Breaking Changes
-
-None. This is an additive change that maintains backward compatibility.
-
 ## Use Cases
 
 ### Dynamic Forms
@@ -301,14 +297,6 @@ Generate different UI layouts based on user preferences or device capabilities.
 - Performance benchmarks comparing single vs. two-step generation
 - Cross-provider compatibility testing
 
-## Open Questions
-
-1. Should we standardize a set of common UI generators?
-2. How to handle UI state management across regenerations?
-3. Should generators support streaming UI updates?
-4. What's the optimal size/capability for the secondary generation model?
-5. How to ensure generated UIs are accessible and follow best practices?
-
 ## References
 
 - [AG-UI Tools Documentation](/concepts/tools)
diff --git a/docs/drafts/interrupts.mdx b/docs/drafts/interrupts.mdx
@@ -16,7 +16,7 @@ Support **human-in-the-loop pauses** (and related mechanisms) natively in AG-UI
 ## Status
 
 - **Status**: Draft
-- **Author(s)**: AG-UI Team
+- **Author(s)**: Markus Ecker (markus.ecker@gmail.com)
 
 ## Overview
 
@@ -210,12 +210,6 @@ Python SDK:
 - Clear indication of pending interrupts
 - History of interrupt/resume actions
 
-## Breaking Changes
-
-None. This is an additive change with backward compatibility:
-- Omitting `outcome` field maintains existing behavior
-- Clients not supporting interrupts can treat them as regular run completions
-
 ## Testing Strategy
 
 - Unit tests for interrupt/resume serialization
@@ -224,15 +218,6 @@ None. This is an additive change with backward compatibility:
 - State consistency tests across interrupt boundaries
 - Performance tests for rapid interrupt/resume cycles
 
-## Open Questions
-
-1. Should we define standard interrupt reasons (enum vs. free string)?
-2. How to handle timeout for unanswered interrupts?
-3. Should interrupts support priority levels?
-4. Can multiple interrupts be pending simultaneously?
-5. How to handle interrupt cancellation?
-6. Should we support batch approval of multiple interrupts?
-
 ## References
 
 - [AG-UI Events Documentation](/concepts/events)
diff --git a/docs/drafts/meta-events.mdx b/docs/drafts/meta-events.mdx
@@ -16,7 +16,7 @@ AG-UI is extended with **MetaEvents**, a new class of events that can occur at a
 ## Status
 
 - **Status**: Draft
-- **Author(s)**: AG-UI Team
+- **Author(s)**: Markus Ecker (markus.ecker@gmail.com)
 
 ## Detailed Specification
 
@@ -215,29 +215,13 @@ Python SDK:
 - Consider permissions for who can create certain meta event types
 - Sanitize payload content to prevent injection attacks
 
-## Breaking Changes
-
-None. This is an additive change:
-- New event type doesn't affect existing event processing
-- Clients not handling MetaEvents can safely ignore them
-- No changes to existing event schemas
-
 ## Testing Strategy
 
 - Unit tests for MetaEvent creation and validation
 - Integration tests with mixed event streams
 - Performance tests with high-volume meta events
 - Security tests for payload validation
 
-## Open Questions
-
-1. Should we define a standard set of metaType values?
-2. How to handle MetaEvent permissions and authorization?
-3. Should MetaEvents support references to multiple entities?
-4. What's the maximum payload size for MetaEvents?
-5. Should we support MetaEvent versioning?
-6. How to handle MetaEvent conflicts (e.g., multiple ratings)?
-
 ## References
 
 - [AG-UI Events Documentation](/concepts/events)
diff --git a/docs/drafts/multimodal-messages.mdx b/docs/drafts/multimodal-messages.mdx
@@ -16,7 +16,7 @@ Evolve AG-UI to support **multimodal input messages** without breaking existing
 ## Status
 
 - **Status**: Draft
-- **Author(s)**: AG-UI Team
+- **Author(s)**: Markus Ecker (markus.ecker@gmail.com)
 
 ## Detailed Specification
 
@@ -231,13 +231,6 @@ Frameworks need to:
 - Sanitize URLs to prevent SSRF attacks
 - Consider content scanning for malicious files
 
-## Breaking Changes
-
-None. This is a backward-compatible change:
-- String content continues to work as before
-- Clients not supporting multimodal content can treat array content as text-only
-- Frameworks can gracefully degrade for unsupported content types
-
 ## Use Cases
 
 ### Visual Question Answering
@@ -263,15 +256,6 @@ Share screenshots for UI/UX feedback or debugging assistance.
 - Performance tests for large binary payloads
 - Security tests for content validation and sanitization
 
-## Open Questions
-
-1. Should we define a maximum size for inline base64 content?
-2. How to handle content type negotiation with different LLM providers?
-3. Should we support streaming for large binary content?
-4. What MIME types should be officially supported?
-5. How to handle content expiration for URL references?
-6. Should we support content compression?
-
 ## References
 
 - [OpenAI Vision API](https://platform.openai.com/docs/guides/vision)
diff --git a/docs/drafts/reasoning.mdx b/docs/drafts/reasoning.mdx
@@ -19,7 +19,7 @@ AG-UI should support **LLM reasoning** without breaking existing apps.
 ## Status
 
 - **Status**: Draft
-- **Author(s)**: AG-UI Team
+- **Author(s)**: Markus Ecker (markus.ecker@gmail.com)
 
 ## Detailed Specification
 
@@ -254,16 +254,7 @@ Meet data retention requirements while preserving reasoning capabilities.
 - Encryption/decryption roundtrip tests
 - Performance tests for reasoning event streaming
 
-## Open Questions
-
-1. Should reasoning messages be included in `MESSAGES_SNAPSHOT` by default?
-2. How to handle partial reasoning in case of interruptions?
-3. Should we support different reasoning visibility levels (none, summary, full)?
-4. What's the maximum size for encrypted reasoning content?
-5. Should reasoning events support metadata (e.g., reasoning type, complexity)?
-
 ## References
 
 - [AG-UI Events Documentation](/concepts/events)
 - [AG-UI Messages Documentation](/concepts/messages)
-- [Chain-of-Thought Prompting](https://arxiv.org/abs/2201.11903)
diff --git a/docs/drafts/serialization.mdx b/docs/drafts/serialization.mdx
@@ -16,7 +16,7 @@ AG-UI adds **stream serialization** to reload chat history and attach to active
 ## Status
 
 - **Status**: Draft
-- **Author(s)**: AG-UI Team
+- **Author(s)**: Markus Ecker (markus.ecker@gmail.com)
 
 ## Detailed Specification
 
@@ -222,14 +222,6 @@ Python SDK:
 - Compression support for serialized streams
 - Indexing strategies for quick access
 
-## Breaking Changes
-
-None. This is an additive change:
-- Existing events remain valid
-- New fields are optional
-- Compaction is opt-in
-- Backward compatible with existing streams
-
 ## Testing Strategy
 
 - Unit tests for compaction algorithm
@@ -238,15 +230,6 @@ None. This is an additive change:
 - Performance benchmarks for large event streams
 - Storage adapter integration tests
 
-## Open Questions
-
-1. Should compaction be automatic or explicit?
-2. What's the optimal compaction strategy for different use cases?
-3. How to handle conflicts in branched conversations?
-4. Should we support custom compaction rules?
-5. How to handle event versioning for long-term storage?
-6. Should we provide built-in storage adapters?
-
 ## References
 
 - [Event Sourcing](https://martinfowler.com/eaaDev/EventSourcing.html)
