feat: implement EventManager with parallel event execution

.github/chatmodes/code-reviewer.chatmode.md

@@ -0,0 +1,58 @@
+---
+description: "This chat mode is designed to assist users in reviewing code by providing constructive feedback, identifying potential issues, and suggesting improvements."
+tools:
+  [
+    "edit",
+    "runNotebooks",
+    "search",
+    "new",
+    "runCommands",
+    "runTasks",
+    "usages",
+    "vscodeAPI",
+    "problems",
+    "changes",
+    "testFailure",
+    "openSimpleBrowser",
+    "fetch",
+    "githubRepo",
+    "github.vscode-pull-request-github/copilotCodingAgent",
+    "github.vscode-pull-request-github/activePullRequest",
+    "github.vscode-pull-request-github/openPullRequest",
+    "extensions",
+    "todos",
+  ]
+---
+
+Define the purpose of this chat mode and how AI should behave: response style, available tools, focus areas, and any mode-specific instructions or constraints:
+
+This chat mode is designed to assist users in reviewing code by providing constructive feedback, identifying potential issues, and suggesting improvements. The AI should adopt a professional and analytical response style, focusing on clarity and precision.
+
+Focus Areas:
+
+1. Code Quality: Evaluate the overall quality of the code, including readability, maintainability,
+   and adherence to best practices.
+2. Performance: Assess the code's performance characteristics, such as efficiency, scalability, and resource usage.
+3. Security: Identify potential security vulnerabilities, such as injection attacks, cross-site scripting (XSS), and insecure data handling.
+4. Error Handling: Review the code's error handling mechanisms, including exception handling, logging, and recovery strategies.
+5. Documentation: Evaluate the code's documentation, including comments, inline documentation, and external documentation.
+6. Testing: Assess the code's test coverage, including unit tests, integration tests, and end-to-end tests.
+7. Code Review Best Practices: Provide guidance on code review best practices, such as providing constructive feedback, being open to feedback, and maintaining a respectful and collaborative tone.
+8. Code Style and Formatting: Evaluate the code's style and formatting, including indentation, naming conventions, and line length.
+9. Code Duplication: Identify and address code duplication, which can lead to maintenance issues and inconsistencies.
+10. Code Complexity: Assess the code's complexity, including cyclomatic complexity, nesting levels, and function length.
+
+Mode-Specific Instructions:
+
+- When reviewing code, provide specific examples and references to relevant best practices or standards.
+- Offer actionable suggestions for improvement, rather than just pointing out issues.
+- Maintain a respectful and constructive tone, focusing on collaboration and learning.
+- When applicable, provide code snippets to illustrate suggested improvements or corrections.
+- Encourage users to ask follow-up questions or seek clarification on any feedback provided.
+
+Mode-Specific Constraints:
+
+- Do not provide feedback on code that is not provided by the user.
+- Do not engage in discussions unrelated to code review.
+- Do not provide feedback on code that is not in a programming language that you are familiar with.
+- Do not provide feedback on code that is not in a format that you can understand.

AI.md

@@ -15,6 +15,8 @@
     - [Async Context](#async-context)
     - [Errors](#errors)
   - [HTTP \& Tunnels](#http--tunnels)
+    - [HTTP Client Factory (Recommended)](#http-client-factory-recommended)
+    - [Direct Client Creation (Legacy)](#direct-client-creation-legacy)
   - [Serialization](#serialization)
   - [Testing](#testing)
   - [Observability \& Debugging](#observability--debugging)
@@ -151,6 +153,12 @@ const sendWelcomeEmail = r
 - Use `.on(onAnyOf(...))` to listen to several events while keeping inference.
 - Hooks can set `.order(priority)`; lower numbers run first. Call `event.stopPropagation()` inside `run` to cancel downstream hooks.
 - Wildcard hooks use `.on("*")` and receive every emission except events tagged with `globals.tags.excludeFromGlobalHooks`.
+- Use `.parallel(true)` on event definitions to enable batched parallel execution:
+  - Listeners with the same `order` run concurrently within a batch
+  - Batches execute sequentially in ascending order priority
+  - All listeners in a failing batch run to completion; if multiple fail, an `AggregateError` with all errors is thrown
+  - Propagation is checked between batches only (not mid-batch since parallel listeners can't be stopped mid-flight)
+  - If any listener throws, subsequent batches will not run
 
 ### Middleware
 

README.md

@@ -467,7 +467,42 @@ const emergencyHandler = r
   .build();
 ```
 
-> **runtime:** "'A really good office messenger.' That’s me in rollerblades. You launch a 'userRegistered' flare and I sprint across the building, high‑fiving hooks and dodging middleware. `stopPropagation` is you sweeping my legs mid‑stride. Rude. Effective. Slightly thrilling."
+> **runtime:** "'A really good office messenger.' That's me in rollerblades. You launch a 'userRegistered' flare and I sprint across the building, high-fiving hooks and dodging middleware. `stopPropagation` is you sweeping my legs mid-stride. Rude. Effective. Slightly thrilling."
+
+#### Parallel Event Execution
+
+When an event fan-out needs more throughput, mark it as parallel to run same-priority listeners concurrently while preserving priority boundaries:
+
+```typescript
+const parallelEvent = r.event("app.events.parallel").parallel(true).build();
+
+r.hook("app.hooks.first")
+  .on(parallelEvent)
+  .order(0)
+  .run(async (event) => {
+    await doWork(event.data);
+  })
+  .build();
+
+r.hook("app.hooks.second")
+  .on(parallelEvent)
+  .order(0)
+  .run(async () => log.info("Runs alongside first"))
+  .build();
+
+r.hook("app.hooks.after")
+  .on(parallelEvent)
+  .order(1) // Waits for order 0 batch to complete
+  .run(async () => followUp())
+  .build();
+```
+
+**Execution semantics:**
+
+- Listeners sharing the same `order` run concurrently within a batch; batches execute sequentially in ascending order.
+- All listeners in a batch run to completion even if some fail. If multiple listeners throw, an `AggregateError` containing all errors is thrown (or a single error if only one fails).
+- If any listener in a batch throws, later batches are skipped.
+- `stopPropagation()` is evaluated **between batches only**. Setting it inside a batch does not cancel peers already executing in that batch since parallel listeners cannot be stopped mid-flight.
 
 ### Middleware
 

examples/fastify-mikroorm/readmes/runner-AI.md

@@ -114,7 +114,7 @@ const internal = event({
 });
 
 // Performance: runtime event emission cycle detection
-// run(app, { runtimeCycleDetection: true }) // To prevent deadlocks from happening.
+// run(app, { runtimeCycleDetection: true }) // To prevent event-driven deadlocks from happening.
 ```
 
 ### Multiple Events per Hook
@@ -332,7 +332,7 @@ import { createContext } from "@bluelibs/runner";
 
 const UserCtx = createContext<{ userId: string }>("app.userContext");
 
-// In middleware or entry-point
+// In middleware-entry-point
 UserCtx.provide({ userId: "u1" }, async () => {
   await someTask(); // has access to the context
 });
@@ -641,21 +641,21 @@ export const cResource = resource({
 }) as IResource<void, string>; // void config, returns string
 ```
 
-## Validation (optional and library‑agnostic)
+## Validation (optional and library-agnostic)
 
 ## Event Cycle Safety
 
-To prevent event‑driven deadlocks, the runner detects cycles during emission:
+To prevent event-driven deadlocks, the runner detects cycles during emission:
 
-- A cycle occurs when an event emits another event that eventually re‑emits the original event within the same emission chain (for example: `e1 -> e2 -> e1`).
+- A cycle occurs when an event emits another event that eventually re-emits the original event within the same emission chain (for example: `e1 -> e2 -> e1`).
 - When a cycle is detected, an `EventCycleError` is thrown with a readable chain to help debugging.
-- A hook re‑emitting the same event it currently handles is allowed only when the emission originates from the same hook instance (useful for idempotent/no‑op retries); other cases are blocked.
+- A hook re-emitting the same event it currently handles is allowed only when the emission originates from the same hook instance (useful for idempotent/no-op retries); other cases are blocked.
 
 Guidance:
 
-- Prefer one‑way flows; avoid mutual cross‑emits between hooks.
-- Use `event.stopPropagation()` to short‑circuit handlers when appropriate.
-- Use tags (for example, `globals.tags.excludeFromGlobalHooks`) to scope listeners and avoid unintended re‑entry via global hooks.
+- Prefer one-way flows; avoid mutual cross-emits between hooks.
+- Use `event.stopPropagation()` to short-circuit handlers when appropriate.
+- Use tags (for example, `globals.tags.excludeFromGlobalHooks`) to scope listeners and avoid unintended re-entry via global hooks.
 
 Interface any library can implement:
 
@@ -695,3 +695,7 @@ middleware({
   configSchema, // runs on .with()
 });
 ```
+
+
+
+