@probelabs/visor 0.1.107 → 0.1.112

package/dist/docs/rfc/workspace-isolation.md

@@ -0,0 +1,216 @@
+# Isolated Workspace with Full Run Separation
+
+## Goal
+
+Provide **full isolation between parallel visor runs** with human-readable project names. Each run gets its own workspace in `/tmp` containing worktrees for all projects, ensuring no interference between concurrent executions.
+
+## Proposed Structure
+
+```
+/tmp/visor-workspaces/<sessionId>/
+├── visor2/        → worktree of main project (full isolated copy)
+├── tyk-docs/      → worktree of tyk-docs repo (isolated)
+├── tyk-gateway/   → worktree of tyk-gateway repo (isolated)
+└── ...
+```
+
+**Key Design Decisions**:
+- **Workspace ID**: Use `sessionId` (UUID from EngineContext)
+- **Location**: `/tmp/visor-workspaces/` (configurable via `VISOR_WORKSPACE_PATH` env var)
+- **Main project**: Worktree created automatically on run start (not symlink - full isolation)
+- **Checkout projects**: Worktrees with human-readable names (repo name extracted from `owner/repo`)
+- **workingDirectory**: All steps use workspace path as their working directory
+
+## Why /tmp Instead of .visor/?
+
+Git doesn't allow worktrees inside the same repository tree. Since `.visor/` is inside the project, we can't create a worktree of the main project there. Using `/tmp` (external path) solves this:
+- Worktrees can be created for any repo including the main project
+- Full isolation - each run has its own copy of everything
+- Clean separation from the project directory
+
+## Implementation Plan
+
+### 1. Create WorkspaceManager class
+
+**File**: `src/utils/workspace-manager.ts`
+
+```typescript
+export class WorkspaceManager {
+  private sessionId: string;
+  private basePath: string;       // /tmp/visor-workspaces
+  private workspacePath: string;  // /tmp/visor-workspaces/<sessionId>
+  private originalPath: string;   // Original cwd where visor was invoked
+
+  // Singleton per session
+  static getInstance(sessionId: string, originalPath: string, config?: WorkspaceConfig): WorkspaceManager
+
+  // Initialize workspace and create main project worktree
+  async initialize(): Promise<WorkspaceInfo>
+
+  // Add a project (called by git-checkout, creates symlink to worktree)
+  async addProject(projectName: string, worktreePath: string): Promise<string>
+
+  // Get workspace path (for use as workingDirectory)
+  getWorkspacePath(): string
+
+  // Cleanup workspace on run end
+  async cleanup(): Promise<void>
+}
+```
+
+**Key behaviors**:
+- `initialize()`:
+  1. Creates `/tmp/visor-workspaces/<sessionId>/`
+  2. Creates worktree of main project at `<workspace>/<project-name>/`
+  3. Registers cleanup handlers
+- `addProject()`: Creates symlink from human-readable name to actual worktree path
+- `extractProjectName()`: Helper to get repo name from `owner/repo` format
+
+### 2. Initialize workspace at engine startup
+
+**File**: `src/state-machine/context/build-engine-context.ts`
+
+At the start of `buildEngineContextForRun()`:
+1. Create WorkspaceManager instance with `sessionId`
+2. Initialize workspace (creates main project worktree)
+3. Set `context.workingDirectory` to workspace path
+4. Store original path in `context.originalWorkingDirectory`
+
+```typescript
+// In buildEngineContextForRun():
+const workspace = WorkspaceManager.getInstance(sessionId, workingDirectory);
+await workspace.initialize();
+
+return {
+  // ...
+  workingDirectory: workspace.getWorkspacePath(),  // All steps use this
+  originalWorkingDirectory: workingDirectory,       // For reference
+  workspace,  // For git-checkout to add projects
+};
+```
+
+### 3. Integrate git-checkout with workspace
+
+**File**: `src/providers/git-checkout-provider.ts`
+
+After creating worktree, add it to workspace:
+```typescript
+// After worktree creation:
+const workspace = (context as any)?.workspace;
+if (workspace?.isEnabled()) {
+  const projectName = extractProjectName(resolvedRepository);
+  const workspacePath = await workspace.addProject(projectName, worktree.path);
+  output.workspace_path = workspacePath;
+}
+```
+
+### 4. Update types
+
+**File**: `src/types/git-checkout.ts`
+```typescript
+export interface GitCheckoutOutput {
+  // ... existing fields ...
+  workspace_path?: string;  // Path within workspace (human-readable)
+}
+```
+
+**File**: `src/types/engine.ts` (or wherever EngineContext is defined)
+```typescript
+export interface EngineContext {
+  // ... existing fields ...
+  originalWorkingDirectory: string;  // Where visor was invoked
+  workspace?: WorkspaceManager;      // Workspace manager instance
+}
+```
+
+### 5. Handle duplicate project names
+
+When multiple checkouts have the same repo name:
+- First: `tyk-docs`
+- Second: `tyk-docs-2`
+- Or use `description` if provided
+
+### 6. Cleanup integration
+
+**Automatic cleanup on**:
+- Normal run completion
+- SIGINT/SIGTERM
+- Uncaught exceptions
+
+**Cleanup actions**:
+1. Remove main project worktree via `git worktree remove`
+2. Remove workspace directory
+3. Note: git-checkout worktrees are managed separately by WorktreeManager
+
+### 7. Configuration
+
+```typescript
+// Environment variable
+VISOR_WORKSPACE_PATH=/custom/path  // Override base path
+
+// Future: config file option
+workspace:
+  enabled: true
+  base_path: /tmp/visor-workspaces
+  cleanup_on_exit: true
+```
+
+## Files to Create/Modify
+
+| File | Action | Description |
+|------|--------|-------------|
+| `src/utils/workspace-manager.ts` | Create | WorkspaceManager class |
+| `src/state-machine/context/build-engine-context.ts` | Modify | Initialize workspace, set workingDirectory |
+| `src/providers/git-checkout-provider.ts` | Modify | Add projects to workspace |
+| `src/types/git-checkout.ts` | Modify | Add `workspace_path` to output |
+| `src/types/engine.ts` | Modify | Add workspace fields to EngineContext |
+| `tests/unit/workspace-manager.test.ts` | Create | Unit tests |
+
+## Example Flow
+
+```
+1. User runs: visor --check code-review
+   └─ cwd: /home/user/my-project
+
+2. Engine starts:
+   └─ sessionId: abc-123-uuid
+   └─ WorkspaceManager.initialize()
+       └─ Creates: /tmp/visor-workspaces/abc-123-uuid/
+       └─ Creates worktree: /tmp/visor-workspaces/abc-123-uuid/my-project/
+   └─ workingDirectory = /tmp/visor-workspaces/abc-123-uuid/
+
+3. git-checkout step runs:
+   └─ Creates worktree in .visor/worktrees/worktrees/tyk-docs-main-xyz789
+   └─ workspace.addProject("tyk-docs", worktreePath)
+       └─ Creates symlink: /tmp/visor-workspaces/abc-123-uuid/tyk-docs/
+   └─ Output: { path: ".visor/worktrees/...", workspace_path: "/tmp/.../tyk-docs" }
+
+4. AI step runs:
+   └─ workingDirectory = /tmp/visor-workspaces/abc-123-uuid/
+   └─ Sees: my-project/, tyk-docs/
+   └─ Can access all projects with human-readable names
+
+5. Run completes:
+   └─ workspace.cleanup()
+       └─ Removes worktree: my-project/
+       └─ Removes directory: /tmp/visor-workspaces/abc-123-uuid/
+```
+
+## Benefits
+
+1. **Full isolation**: Parallel runs can't interfere (separate workspaces)
+2. **Human-readable paths**: `tyk-docs/` instead of `tyk-tyk-docs-main-ab12cd34/`
+3. **Unified workspace**: All projects for a run accessible from one directory
+4. **Automatic workingDirectory**: All steps operate in isolated scope
+5. **No git-in-git issues**: Workspace is in /tmp, outside any repository
+6. **Clean cleanup**: Just remove the workspace directory
+
+## Trade-offs
+
+1. **Disk usage**: Each run creates a worktree of main project (uses git's efficient storage, but still some overhead)
+
+2. **Startup time**: Small delay to create main project worktree
+
+3. **Windows**: Git worktrees work on Windows, but paths might need adjustment
+
+4. **Debugging**: Workspace is in /tmp - might be cleared on reboot. Consider `cleanup_on_exit: false` option for debugging.

package/dist/docs/router-patterns.md

@@ -0,0 +1,339 @@
+# Router Steps, Transitions, and `depends_on`
+
+This document describes recommended patterns for “router” checks (AI or script steps that classify intent and decide where to go next), and how they should interact with `depends_on`, `transitions`, and loops.
+
+The goal is:
+
+- predictable routing (no accidental loops),
+- a clean mental model for control‑flow vs data dependencies,
+- and good DX for authoring chat‑like and org‑automation workflows.
+
+Examples referenced here:
+
+- `examples/slack-simple-chat.yaml` (Slack org assistant: `ask` → `route-intent` → branches)
+- `docs/recipes.md` (general routing patterns and chat examples)
+
+---
+
+## Concepts: control vs data edges
+
+There are three main “edges” between checks:
+
+- **Data dependency**: `depends_on`
+  - Meaning: “B needs A’s output to compute.”
+  - Engine impact: A is always scheduled before B in the DAG; forward‑run uses this to pull parents into new waves.
+
+- **Control‑flow edge**: `on_success.transitions` / `on_fail.transitions` / `on_finish.transitions` and `goto`
+  - Meaning: “when A finishes (and a condition holds), *schedule* B.”
+  - Engine impact: emits `ForwardRunRequested` events; WavePlanning then plans a subgraph for the target and its dependencies.
+
+- **Guards**: `if` and `assume`
+  - `if`: soft gate. B is *skipped* when the condition is false.
+  - `assume`: hard precondition. If B runs and the condition is false, that’s a contract violation.
+
+Best DX comes from keeping these roles distinct:
+
+- Use `depends_on` for real data prerequisites.
+- Use `transitions` / `goto` for routing and loops.
+- Use `if` / `assume` for gating semantics, not for wiring the graph.
+
+---
+
+## Anti‑pattern: router as both dependency and transition source
+
+**Shape (simplified):**
+
+```yaml
+ask:
+  type: human-input
+  group: chat
+
+route-intent:
+  type: ai
+  group: chat
+  depends_on: [ask]
+  on_success:
+    transitions:
+      - when: "output.intent === 'capabilities'"
+        to: capabilities-answer
+
+capabilities-answer:
+  type: ai
+  group: chat
+  depends_on: [route-intent]
+  if: "outputs['route-intent']?.intent === 'capabilities'"
+  on_success:
+    goto: ask
+```
+
+Here, the router (`route-intent`) is connected to the branch (`capabilities-answer`) **twice**:
+
+- as a data dependency: `capabilities-answer.depends_on: [route-intent]`
+- as a control‑flow source: `route-intent.on_success.transitions → capabilities-answer`
+
+### Why this is a problem
+
+When `route-intent` finishes, `transitions` fire and emit a `ForwardRunRequested(target='capabilities-answer')`.
+
+WavePlanning then:
+
+1. Builds the forward‑run subset starting from the target.
+2. Adds **all transitive dependencies** of that target via `depends_on`.
+   - `capabilities-answer.depends_on: [route-intent]`
+   - `route-intent.depends_on: [ask]`
+3. Schedules a wave that re‑runs `route-intent` (and `ask`), then `capabilities-answer`.
+
+Each time `route-intent` re‑runs, its `transitions` fire again, enqueueing another forward‑run to `capabilities-answer`, which again pulls `route-intent` in as a dependency. This repeats until `routing.max_loops` is hit.
+
+**Symptoms:**
+
+- For a single “what can you do?” message, you may see multiple runs of:
+  - `ask`
+  - `route-intent`
+  - and repeated routing logs, until the loop budget is exceeded.
+- In tests with non‑zero `routing.max_loops`, strict `exactly` expectations on router calls fail (router runs 6+ times instead of once).
+
+This is exactly the pattern we saw in the Slack org‑assistant flow when:
+
+- `route-intent` used `on_success.transitions`, **and**
+- branches like `capabilities-answer` had `depends_on: [route-intent]`, **and**
+- leaf steps used `goto: ask` to close the loop.
+
+---
+
+## Recommended pattern: router as pure control‑plane
+
+### Core idea
+
+Treat router checks as **control‑plane only**:
+
+- Router:
+  - `depends_on` its true *inputs* (e.g. `ask`, context fetch steps).
+  - Uses `on_success.transitions` to select branches.
+- Branches:
+  - **Do not** `depends_on` the router.
+  - Instead, they **read** the router’s output from `outputs['router']` and gate with `if` / `assume`.
+
+This gives a clean, acyclic structure:
+
+```yaml
+ask:
+  type: human-input
+  group: chat
+
+route-intent:
+  type: ai
+  group: chat
+  depends_on: [ask]
+  ai:
+    disableTools: true
+    allowedTools: []
+  schema:
+    type: object
+    properties:
+      intent:
+        type: string
+        enum: [chat, capabilities]
+    required: [intent]
+  on_success:
+    transitions:
+      - when: "output.intent === 'capabilities'"
+        to: capabilities-answer
+      - when: "output.intent === 'chat'"
+        to: chat-answer
+
+capabilities-answer:
+  type: ai
+  group: chat
+  # no depends_on: [route-intent]
+  if: "outputs['route-intent']?.intent === 'capabilities'"
+  ai:
+    disableTools: true
+    allowedTools: []
+  prompt: |
+    Explain briefly what you can help with.
+  on_success:
+    goto: ask
+
+chat-answer:
+  type: ai
+  group: chat
+  # no depends_on: [route-intent]
+  if: "outputs['route-intent']?.intent === 'chat'"
+  prompt: |
+    You are a concise, friendly assistant.
+    Latest user message: {{ outputs['ask'].text }}
+  on_success:
+    goto: ask
+```
+
+**Engine behavior:**
+
+- Initial wave:
+  - DAG: `ask` → `route-intent`
+  - Router runs once, then emits transitions.
+- Forward‑run for `capabilities-answer`:
+  - Only includes the branch and any *real* dependencies the branch declares (e.g. context fetch, project status).
+  - Does **not** pull `route-intent` back in, because the branch no longer `depends_on` it.
+- Loops:
+  - `capabilities-answer` closing to `ask` via `goto: ask` is explicit and controlled.
+  - Router still runs once per loop cycle (when `ask` completes), but is not re‑run just because the branch was targeted by a transition.
+
+This pattern avoids the “router as both dependency and transition source” cycle that caused loops in Slack.
+
+---
+
+## When to use `depends_on` vs `transitions` vs `if` / `assume`
+
+### Use `depends_on` for real data prerequisites
+
+Examples:
+
+```yaml
+project-status-fetch:
+  type: script
+  criticality: external
+  depends_on: [project-intent]
+
+project-status-answer:
+  type: ai
+  depends_on: [project-status-fetch]
+  assume:
+    - "!!outputs['project-status-fetch']?.project"
+```
+
+- `project-status-answer` truly needs `project-status-fetch`’s output to behave; this is a data edge.
+- `assume` documents and enforces a precondition on that data.
+
+### Use `transitions` / `goto` for control‑flow
+
+Examples:
+
+```yaml
+route-intent:
+  type: ai
+  on_success:
+    transitions:
+      - when: "output.intent === 'status'"
+        to: project-status-answer
+      - when: "output.intent === 'deployment'"
+        to: project-deploy-confirm
+
+project-deploy-answer:
+  type: ai
+  on_success:
+    transitions:
+      - when: "output.done === true"
+        to: ask
+      - when: "output.done === false"
+        to: project-deploy-confirm
+```
+
+- Router edges are expressed only via `transitions`.
+- Inner “deployment helper” loop is controlled by transitions on `done`.
+
+### Use `if` and `assume` for semantics, not wiring
+
+Examples:
+
+```yaml
+capabilities-answer:
+  # Soft gate: skip unless router chose 'capabilities'
+  if: "outputs['route-intent']?.intent === 'capabilities'"
+
+project-status-answer:
+  # Hard precondition: fetch must have produced a project
+  assume:
+    - "!!outputs['project-status-fetch']?.project"
+```
+
+Guidelines:
+
+- Use `if` to conditionally *skip* a step when a control field doesn’t match.
+- Use `assume` to assert invariants when the step *does* run.
+- Do **not** rely on `assume` to implement routing; that’s what `transitions` and `if` are for.
+
+---
+
+## Migration: from router‑as‑dependency to router‑as‑control‑plane
+
+If you have existing workflows where:
+
+- router checks use `on_success.transitions`, and
+- branches also `depends_on` the router, and
+- leaf steps loop back via `goto: <entry-step>`,
+
+then you’re in the “double‑edge” pattern and may hit the same kind of loops we saw in Slack.
+
+### Migration steps
+
+1. **Identify router checks**  
+   - Look for AI/script steps that:
+     - read from a single human‑input or transport context, and
+     - fan‑out into multiple branches via `transitions`.
+
+2. **Remove router from branch `depends_on`**  
+   - For each branch:
+     - Remove `depends_on: [router]`.
+     - Keep other dependencies (e.g. context fetch, sub‑routers).
+
+3. **Add `if` / `assume` guards on branches**
+   - Replace router‑dependency semantics with guards:
+
+   ```yaml
+   chat-answer:
+     # was: depends_on: [route-intent]
+     if: "outputs['route-intent']?.intent === 'chat'"
+   ```
+
+4. **Keep explicit loops**
+   - Leave `goto: ask` and inner loops (`project-deploy-confirm` ↔ `project-deploy-answer`) as they are.
+   - The loop behavior remains explicit and is no longer entangled with router dependencies.
+
+5. **Increase `routing.max_loops` and add strict call expectations**
+   - In YAML tests, set a reasonable `routing.max_loops` (e.g. 5–10).
+   - Assert `exactly` call counts for:
+     - router(s),
+     - branches,
+     - entry steps.
+   - This surfaces unintentional loops as test failures instead of silently relying on the loop budget.
+
+---
+
+## Backward compatibility considerations
+
+The recommendations above are **config‑level**; you can adopt them without changing engine semantics.
+
+However, future engine changes to reinforce this model could be backward‑incompatible for configs that rely on the old pattern. For example:
+
+- If we introduce special handling to **avoid re‑running routers** during forward‑runs when the target already depends on them via `transitions`, then:
+  - Workflows that implicitly relied on “router re‑runs as dependents” would see different call counts.
+  - Some side‑effects triggered on every router run might fire fewer times.
+
+To keep migration safe:
+
+- Prefer the “router as control‑plane only” pattern for new workflows.
+- Gradually refactor existing ones (Slack, GitHub, HTTP automations) to:
+  - remove `depends_on` edges from router → branch,
+  - keep `transitions` as the single source of truth for routing,
+  - use `if` / `assume` on branches for intent gating.
+
+Once most configs follow this pattern, engine‑level improvements (e.g. smarter forward‑run for routers) can be introduced with minimal behavioral change for users.
+
+---
+
+## Summary
+
+- **Do**:
+  - Use routers (`route-intent`, `project-intent`, …) as control‑plane steps:
+    - `depends_on` only real inputs,
+    - route with `transitions`.
+  - Keep branches free of router `depends_on`; gate them with `if` / `assume`.
+  - Use `depends_on` only for real data dependencies.
+  - Use `goto`/`transitions` for loops and control‑flow.
+
+- **Avoid**:
+  - Wiring the same edge both via `depends_on` and `transitions`.
+  - Using `assume` as a routing mechanism.
+
+Following this pattern produces clearer configs, avoids accidental router loops, and matches how the state‑machine’s forward‑run planner is intended to be used.***

package/dist/event-bus/types.d.ts

@@ -26,6 +26,20 @@ export type IntegrationEvent = {
         stack?: string;
         name?: string;
     };
+} | {
+    type: 'HumanInputRequested';
+    checkId: string;
+    prompt: string;
+    channel?: string;
+    threadTs?: string;
+    threadKey?: string;
+} | {
+    type: 'SnapshotSaved';
+    checkId: string;
+    channel?: string;
+    threadTs?: string;
+    threadKey?: string;
+    filePath: string;
 } | {
     type: 'CommentPosted';
     threadKey?: string;

package/dist/event-bus/types.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["file:///home/runner/work/visor/visor/src/event-bus/types.ts"],"names":[],"mappings":"AAAA,MAAM,MAAM,gBAAgB,GACxB;IACE,IAAI,EAAE,sBAAsB,CAAC;IAC7B,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,QAAQ,GAAG,aAAa,GAAG,WAAW,GAAG,WAAW,CAAC;IAC7D,UAAU,CAAC,EAAE,SAAS,GAAG,SAAS,GAAG,SAAS,GAAG,SAAS,CAAC;IAC3D,MAAM,CAAC,EAAE;QAAE,KAAK,CAAC,EAAE,MAAM,CAAC;QAAC,OAAO,CAAC,EAAE,MAAM,CAAC;QAAC,IAAI,CAAC,EAAE,MAAM,CAAC;QAAC,WAAW,CAAC,EAAE,GAAG,EAAE,CAAA;KAAE,CAAC;IAClF,cAAc,CAAC,EAAE,MAAM,CAAC;CACzB,GACD;IACE,IAAI,EAAE,kBAAkB,CAAC;IACzB,IAAI,EAAE,MAAM,CAAC;IACb,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,cAAc,CAAC,EAAE,MAAM,CAAC;CACzB,GACD;IACE,IAAI,EAAE,sBAAsB,CAAC;IAC7B,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,OAAO,EAAE,OAAO,CAAC;IACjB,KAAK,CAAC,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,KAAK,CAAC,EAAE,MAAM,CAAC;QAAC,IAAI,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;CAC5D,GACD;IACE,IAAI,EAAE,eAAe,CAAC;IACtB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,OAAO,CAAC;IACjB,KAAK,CAAC,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,KAAK,CAAC,EAAE,MAAM,CAAC;QAAC,IAAI,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;CAC5D,CAAC;AAEN,MAAM,WAAW,aAAa,CAAC,CAAC,GAAG,GAAG;IACpC,EAAE,EAAE,MAAM,CAAC;IACX,OAAO,EAAE,CAAC,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;IAElB,KAAK,EAAE,MAAM,CAAC;IACd,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,OAAO,EAAE,CAAC,CAAC;CACZ;AAED,MAAM,MAAM,QAAQ,GAAG,GAAG,CAAC"}
+{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["file:///home/runner/work/visor/visor/src/event-bus/types.ts"],"names":[],"mappings":"AAAA,MAAM,MAAM,gBAAgB,GACxB;IACE,IAAI,EAAE,sBAAsB,CAAC;IAC7B,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,QAAQ,GAAG,aAAa,GAAG,WAAW,GAAG,WAAW,CAAC;IAC7D,UAAU,CAAC,EAAE,SAAS,GAAG,SAAS,GAAG,SAAS,GAAG,SAAS,CAAC;IAC3D,MAAM,CAAC,EAAE;QAAE,KAAK,CAAC,EAAE,MAAM,CAAC;QAAC,OAAO,CAAC,EAAE,MAAM,CAAC;QAAC,IAAI,CAAC,EAAE,MAAM,CAAC;QAAC,WAAW,CAAC,EAAE,GAAG,EAAE,CAAA;KAAE,CAAC;IAClF,cAAc,CAAC,EAAE,MAAM,CAAC;CACzB,GACD;IACE,IAAI,EAAE,kBAAkB,CAAC;IACzB,IAAI,EAAE,MAAM,CAAC;IACb,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,cAAc,CAAC,EAAE,MAAM,CAAC;CACzB,GACD;IACE,IAAI,EAAE,sBAAsB,CAAC;IAC7B,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,OAAO,EAAE,OAAO,CAAC;IACjB,KAAK,CAAC,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,KAAK,CAAC,EAAE,MAAM,CAAC;QAAC,IAAI,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;CAC5D,GACD;IACE,IAAI,EAAE,qBAAqB,CAAC;IAC5B,OAAO,EAAE,MAAM,CAAC;IAChB,MAAM,EAAE,MAAM,CAAC;IAEf,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB,GACD;IACE,IAAI,EAAE,eAAe,CAAC;IACtB,OAAO,EAAE,MAAM,CAAC;IAChB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,QAAQ,EAAE,MAAM,CAAC;CAClB,GACD;IACE,IAAI,EAAE,eAAe,CAAC;IACtB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,OAAO,CAAC;IACjB,KAAK,CAAC,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,KAAK,CAAC,EAAE,MAAM,CAAC;QAAC,IAAI,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;CAC5D,CAAC;AAEN,MAAM,WAAW,aAAa,CAAC,CAAC,GAAG,GAAG;IACpC,EAAE,EAAE,MAAM,CAAC;IACX,OAAO,EAAE,CAAC,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;IAElB,KAAK,EAAE,MAAM,CAAC;IACd,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,OAAO,EAAE,CAAC,CAAC;CACZ;AAED,MAAM,MAAM,QAAQ,GAAG,GAAG,CAAC"}