wotann 0.5.0 → 0.5.39

package/skills/wotann-imports/incremental-implementation.md

@@ -0,0 +1,241 @@
+---
+name: incremental-implementation
+description: Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
+---
+
+# Incremental Implementation
+
+## Overview
+
+Build in thin vertical slices — implement one piece, test it, verify it, then expand. Avoid implementing an entire feature in one pass. Each increment should leave the system in a working, testable state. This is the execution discipline that makes large features manageable.
+
+## When to Use
+
+- Implementing any multi-file change
+- Building a new feature from a task breakdown
+- Refactoring existing code
+- Any time you're tempted to write more than ~100 lines before testing
+
+**When NOT to use:** Single-file, single-function changes where the scope is already minimal.
+
+## The Increment Cycle
+
+```
+┌──────────────────────────────────────┐
+│                                      │
+│   Implement ──→ Test ──→ Verify ──┐  │
+│       ▲                           │  │
+│       └───── Commit ◄─────────────┘  │
+│              │                       │
+│              ▼                       │
+│          Next slice                  │
+│                                      │
+└──────────────────────────────────────┘
+```
+
+For each slice:
+
+1. **Implement** the smallest complete piece of functionality
+2. **Test** — run the test suite (or write a test if none exists)
+3. **Verify** — confirm the slice works as expected (tests pass, build succeeds, manual check)
+4. **Commit** -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)
+5. **Move to the next slice** — carry forward, don't restart
+
+## Slicing Strategies
+
+### Vertical Slices (Preferred)
+
+Build one complete path through the stack:
+
+```
+Slice 1: Create a task (DB + API + basic UI)
+    → Tests pass, user can create a task via the UI
+
+Slice 2: List tasks (query + API + UI)
+    → Tests pass, user can see their tasks
+
+Slice 3: Edit a task (update + API + UI)
+    → Tests pass, user can modify tasks
+
+Slice 4: Delete a task (delete + API + UI + confirmation)
+    → Tests pass, full CRUD complete
+```
+
+Each slice delivers working end-to-end functionality.
+
+### Contract-First Slicing
+
+When backend and frontend need to develop in parallel:
+
+```
+Slice 0: Define the API contract (types, interfaces, OpenAPI spec)
+Slice 1a: Implement backend against the contract + API tests
+Slice 1b: Implement frontend against mock data matching the contract
+Slice 2: Integrate and test end-to-end
+```
+
+### Risk-First Slicing
+
+Tackle the riskiest or most uncertain piece first:
+
+```
+Slice 1: Prove the WebSocket connection works (highest risk)
+Slice 2: Build real-time task updates on the proven connection
+Slice 3: Add offline support and reconnection
+```
+
+If Slice 1 fails, you discover it before investing in Slices 2 and 3.
+
+## Implementation Rules
+
+### Rule 0: Simplicity First
+
+Before writing any code, ask: "What is the simplest thing that could work?"
+
+After writing code, review it against these checks:
+- Can this be done in fewer lines?
+- Are these abstractions earning their complexity?
+- Would a staff engineer look at this and say "why didn't you just..."?
+- Am I building for hypothetical future requirements, or the current task?
+
+```
+SIMPLICITY CHECK:
+✗ Generic EventBus with middleware pipeline for one notification
+✓ Simple function call
+
+✗ Abstract factory pattern for two similar components
+✓ Two straightforward components with shared utilities
+
+✗ Config-driven form builder for three forms
+✓ Three form components
+```
+
+Three similar lines of code is better than a premature abstraction. Implement the naive, obviously-correct version first. Optimize only after correctness is proven with tests.
+
+### Rule 0.5: Scope Discipline
+
+Touch only what the task requires.
+
+Do NOT:
+- "Clean up" code adjacent to your change
+- Refactor imports in files you're not modifying
+- Remove comments you don't fully understand
+- Add features not in the spec because they "seem useful"
+- Modernize syntax in files you're only reading
+
+If you notice something worth improving outside your task scope, note it — don't fix it:
+
+```
+NOTICED BUT NOT TOUCHING:
+- src/utils/format.ts has an unused import (unrelated to this task)
+- The auth middleware could use better error messages (separate task)
+→ Want me to create tasks for these?
+```
+
+### Rule 1: One Thing at a Time
+
+Each increment changes one logical thing. Don't mix concerns:
+
+**Bad:** One commit that adds a new component, refactors an existing one, and updates the build config.
+
+**Good:** Three separate commits — one for each change.
+
+### Rule 2: Keep It Compilable
+
+After each increment, the project must build and existing tests must pass. Don't leave the codebase in a broken state between slices.
+
+### Rule 3: Feature Flags for Incomplete Features
+
+If a feature isn't ready for users but you need to merge increments:
+
+```typescript
+// Feature flag for work-in-progress
+const ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true';
+
+if (ENABLE_TASK_SHARING) {
+  // New sharing UI
+}
+```
+
+This lets you merge small increments to the main branch without exposing incomplete work.
+
+### Rule 4: Safe Defaults
+
+New code should default to safe, conservative behavior:
+
+```typescript
+// Safe: disabled by default, opt-in
+export function createTask(data: TaskInput, options?: { notify?: boolean }) {
+  const shouldNotify = options?.notify ?? false;
+  // ...
+}
+```
+
+### Rule 5: Rollback-Friendly
+
+Each increment should be independently revertable:
+
+- Additive changes (new files, new functions) are easy to revert
+- Modifications to existing code should be minimal and focused
+- Database migrations should have corresponding rollback migrations
+- Avoid deleting something in one commit and replacing it in the same commit — separate them
+
+## Working with Agents
+
+When directing an agent to implement incrementally:
+
+```
+"Let's implement Task 3 from the plan.
+
+Start with just the database schema change and the API endpoint.
+Don't touch the UI yet — we'll do that in the next increment.
+
+After implementing, run `npm test` and `npm run build` to verify
+nothing is broken."
+```
+
+Be explicit about what's in scope and what's NOT in scope for each increment.
+
+## Increment Checklist
+
+After each increment, verify:
+
+- [ ] The change does one thing and does it completely
+- [ ] All existing tests still pass (`npm test`)
+- [ ] The build succeeds (`npm run build`)
+- [ ] Type checking passes (`npx tsc --noEmit`)
+- [ ] Linting passes (`npm run lint`)
+- [ ] The new functionality works as expected
+- [ ] The change is committed with a descriptive message
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'll test it all at the end" | Bugs compound. A bug in Slice 1 makes Slices 2-5 wrong. Test each slice. |
+| "It's faster to do it all at once" | It *feels* faster until something breaks and you can't find which of 500 changed lines caused it. |
+| "These changes are too small to commit separately" | Small commits are free. Large commits hide bugs and make rollbacks painful. |
+| "I'll add the feature flag later" | If the feature isn't complete, it shouldn't be user-visible. Add the flag now. |
+| "This refactor is small enough to include" | Refactors mixed with features make both harder to review and debug. Separate them. |
+
+## Red Flags
+
+- More than 100 lines of code written without running tests
+- Multiple unrelated changes in a single increment
+- "Let me just quickly add this too" scope expansion
+- Skipping the test/verify step to move faster
+- Build or tests broken between increments
+- Large uncommitted changes accumulating
+- Building abstractions before the third use case demands it
+- Touching files outside the task scope "while I'm here"
+- Creating new utility files for one-time operations
+
+## Verification
+
+After completing all increments for a task:
+
+- [ ] Each increment was individually tested and committed
+- [ ] The full test suite passes
+- [ ] The build is clean
+- [ ] The feature works end-to-end as specified
+- [ ] No uncommitted changes remain

package/skills/wotann-imports/security-threat-model.md

@@ -0,0 +1,81 @@
+---
+name: "security-threat-model"
+description: "Repository-grounded threat modeling that enumerates trust boundaries, assets, attacker capabilities, abuse paths, and mitigations, and writes a concise Markdown threat model. Trigger only when the user explicitly asks to threat model a codebase or path, enumerate threats/abuse paths, or perform AppSec threat modeling. Do not trigger for general architecture summaries, code review, or non-security design work."
+---
+
+# Threat Model Source Code Repo
+
+Deliver an actionable AppSec-grade threat model that is specific to the repository or a project path, not a generic checklist. Anchor every architectural claim to evidence in the repo and keep assumptions explicit. Prioritizing realistic attacker goals and concrete impacts over generic checklists.
+
+## Quick start
+
+1) Collect (or infer) inputs:
+- Repo root path and any in-scope paths.
+- Intended usage, deployment model, internet exposure, and auth expectations (if known).
+- Any existing repository summary or architecture spec.
+- Use prompts in `references/prompt-template.md` to generate a repository summary.
+- Follow the required output contract in `references/prompt-template.md`. Use it verbatim when possible.
+
+## Workflow
+
+### 1) Scope and extract the system model
+- Identify primary components, data stores, and external integrations from the repo summary.
+- Identify how the system runs (server, CLI, library, worker) and its entrypoints.
+- Separate runtime behavior from CI/build/dev tooling and from tests/examples.
+- Map the in-scope locations to those components and exclude out-of-scope items explicitly.
+- Do not claim components, flows, or controls without evidence.
+
+### 2) Derive boundaries, assets, and entry points
+- Enumerate trust boundaries as concrete edges between components, noting protocol, auth, encryption, validation, and rate limiting.
+- List assets that drive risk (data, credentials, models, config, compute resources, audit logs).
+- Identify entry points (endpoints, upload surfaces, parsers/decoders, job triggers, admin tooling, logging/error sinks).
+
+### 3) Calibrate assets and attacker capabilities
+- List the assets that drive risk (credentials, PII, integrity-critical state, availability-critical components, build artifacts).
+- Describe realistic attacker capabilities based on exposure and intended usage.
+- Explicitly note non-capabilities to avoid inflated severity.
+
+
+### 4) Enumerate threats as abuse paths
+- Prefer attacker goals that map to assets and boundaries (exfiltration, privilege escalation, integrity compromise, denial of service).
+- Classify each threat and tie it to impacted assets.
+- Keep the number of threats small but high quality.
+
+### 5) Prioritize with explicit likelihood and impact reasoning
+- Use qualitative likelihood and impact (low/medium/high) with short justifications.
+- Set overall priority (critical/high/medium/low) using likelihood x impact, adjusted for existing controls.
+- State which assumptions most influence the ranking.
+
+### 6) Validate service context and assumptions with the user
+- Summarize key assumptions that materially affect threat ranking or scope, then ask the user to confirm or correct them.
+- Ask 1–3 targeted questions to resolve missing context (service owner and environment, scale/users, deployment model, authn/authz, internet exposure, data sensitivity, multi-tenancy).
+- Pause and wait for user feedback before producing the final report.
+- If the user declines or can’t answer, state which assumptions remain and how they influence priority.
+
+### 7) Recommend mitigations and focus paths
+- Distinguish existing mitigations (with evidence) from recommended mitigations.
+- Tie mitigations to concrete locations (component, boundary, or entry point) and control types (authZ checks, input validation, schema enforcement, sandboxing, rate limits, secrets isolation, audit logging).
+- Prefer specific implementation hints over generic advice (e.g., "enforce schema at gateway for upload payloads" vs "validate inputs").
+- Base recommendations on validated user context; if assumptions remain unresolved, mark recommendations as conditional.
+
+### 8) Run a quality check before finalizing
+- Confirm all discovered entrypoints are covered.
+- Confirm each trust boundary is represented in threats.
+- Confirm runtime vs CI/dev separation.
+- Confirm user clarifications (or explicit non-responses) are reflected.
+- Confirm assumptions and open questions are explicit.
+- Confirm that the format of the report matches closely the required output format defined in prompt template: `references/prompt-template.md`
+- Write the final Markdown to a file named `<repo-or-dir-name>-threat-model.md` (use the basename of the repo root, or the in-scope directory if you were asked to model a subpath).
+
+
+## Risk prioritization guidance (illustrative, not exhaustive)
+- High: pre-auth RCE, auth bypass, cross-tenant access, sensitive data exfiltration, key or token theft, model or config integrity compromise, sandbox escape.
+- Medium: targeted DoS of critical components, partial data exposure, rate-limit bypass with measurable impact, log/metrics poisoning that affects detection.
+- Low: low-sensitivity info leaks, noisy DoS with easy mitigation, issues requiring unlikely preconditions.
+
+## References
+
+- Output contract and full prompt template: `references/prompt-template.md`
+- Optional controls/asset list: `references/security-controls-and-assets.md`
+
+Only load the reference files you need. Keep the final result concise, grounded, and reviewable.

package/skills/wotann-imports/triage.md

@@ -0,0 +1,103 @@
+---
+name: triage
+description: Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.
+---
+
+# Triage
+
+Move issues on the project issue tracker through a small state machine of triage roles.
+
+Every comment or issue posted to the issue tracker during triage **must** start with this disclaimer:
+
+```
+> *This was generated by AI during triage.*
+```
+
+## Reference docs
+
+- [AGENT-BRIEF.md](AGENT-BRIEF.md) — how to write durable agent briefs
+- [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — how the `.out-of-scope/` knowledge base works
+
+## Roles
+
+Two **category** roles:
+
+- `bug` — something is broken
+- `enhancement` — new feature or improvement
+
+Five **state** roles:
+
+- `needs-triage` — maintainer needs to evaluate
+- `needs-info` — waiting on reporter for more information
+- `ready-for-agent` — fully specified, ready for an AFK agent
+- `ready-for-human` — needs human implementation
+- `wontfix` — will not be actioned
+
+Every triaged issue should carry exactly one category role and one state role. If state roles conflict, flag it and ask the maintainer before doing anything else.
+
+These are canonical role names — the actual label strings used in the issue tracker may differ. The mapping should have been provided to you - run `/setup-matt-pocock-skills` if not.
+
+State transitions: an unlabeled issue normally goes to `needs-triage` first; from there it moves to `needs-info`, `ready-for-agent`, `ready-for-human`, or `wontfix`. `needs-info` returns to `needs-triage` once the reporter replies. The maintainer can override at any time — flag transitions that look unusual and ask before proceeding.
+
+## Invocation
+
+The maintainer invokes `/triage` and describes what they want in natural language. Interpret the request and act. Examples:
+
+- "Show me anything that needs my attention"
+- "Let's look at #42"
+- "Move #42 to ready-for-agent"
+- "What's ready for agents to pick up?"
+
+## Show what needs attention
+
+Query the issue tracker and present three buckets, oldest first:
+
+1. **Unlabeled** — never triaged.
+2. **`needs-triage`** — evaluation in progress.
+3. **`needs-info` with reporter activity since the last triage notes** — needs re-evaluation.
+
+Show counts and a one-line summary per issue. Let the maintainer pick.
+
+## Triage a specific issue
+
+1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
+
+2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the issue. Wait for direction.
+
+3. **Reproduce (bugs only).** Before any grilling, attempt reproduction: read the reporter's steps, trace the relevant code, run tests or commands. Report what happened — successful repro with code path, failed repro, or insufficient detail (a strong `needs-info` signal). A confirmed repro makes a much stronger agent brief.
+
+4. **Grill (if needed).** If the issue needs fleshing out, run a `/grill-with-docs` session.
+
+5. **Apply the outcome:**
+   - `ready-for-agent` — post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)).
+   - `ready-for-human` — same structure as an agent brief, but note why it can't be delegated (judgment calls, external access, design decisions, manual testing).
+   - `needs-info` — post triage notes (template below).
+   - `wontfix` (bug) — polite explanation, then close.
+   - `wontfix` (enhancement) — write to `.out-of-scope/`, link to it from a comment, then close ([OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)).
+   - `needs-triage` — apply the role. Optional comment if there's partial progress.
+
+## Quick state override
+
+If the maintainer says "move #42 to ready-for-agent", trust them and apply the role directly. Confirm what you're about to do (role changes, comment, close), then act. Skip grilling. If moving to `ready-for-agent` without a grilling session, ask whether they want to write an agent brief.
+
+## Needs-info template
+
+```markdown
+## Triage Notes
+
+**What we've established so far:**
+
+- point 1
+- point 2
+
+**What we still need from you (@reporter):**
+
+- question 1
+- question 2
+```
+
+Capture everything resolved during grilling under "established so far" so the work isn't lost. Questions must be specific and actionable, not "please provide more info".
+
+## Resuming a previous session
+
+If prior triage notes exist on the issue, read them, check whether the reporter has answered any outstanding questions, and present an updated picture before continuing. Don't re-ask resolved questions.

package/dist/build/deploy-targets/coolify.d.ts

@@ -1,148 +0,0 @@
-/**
- * Coolify deploy adapter.
- *
- * PORT OF: Coolify's public REST API (coollabs.io/docs/api-reference).
- * Coolify is a self-hosted Heroku/Vercel alternative with 40k+ GitHub
- * stars; its API lets us create an "application" from a git repo,
- * trigger a deploy, stream logs, and query status. WOTANN's `wotann
- * build --deploy-to coolify` flag routes here.
- *
- * API SURFACE (used here):
- *   POST /api/v1/applications/public             — create Docker/git app
- *   GET  /api/v1/applications/:uuid              — fetch app detail
- *   POST /api/v1/deploy                          — trigger deploy by uuid
- *   GET  /api/v1/deployments/:uuid               — fetch deploy status
- *   GET  /api/v1/deployments/:uuid/logs          — fetch deploy logs
- *
- * RELATIONSHIP TO EXISTING MODULES:
- *   - src/build/deploy-adapter.ts — the Tier 9 scaffold that owns the
- *     registry of deploy targets. This file is a PLUGGABLE ADAPTER that
- *     matches whatever shape that registry expects; we intentionally
- *     stay decoupled from the registry's module so another agent can
- *     edit the registry without touching us.
- *   - src/providers/cloud-offload/adapter.ts — shared pattern for
- *     closure-scoped state + injected fetcher + typed failures. Coolify
- *     and Dokploy reuse that pattern.
- *
- * QUALITY BARS HONORED:
- *   - QB #6 (honest failures): every public method returns a typed
- *     envelope with explicit `ok` field. HTTP status, error body, and
- *     attempt count surface in failure results.
- *   - QB #7 (per-session state): createCoolifyAdapter() returns a
- *     closure; two adapters never share auth tokens or deployment maps.
- *   - QB #11 (sibling-site scan): the deploy-adapter.ts registry is
- *     owned by another agent; we expose the `DeployTargetAdapter`
- *     interface that registry can adopt verbatim, no coupling.
- *   - QB #13 (env guard): this file does NOT read process.env. Every
- *     knob is injected via CoolifyConfig.
- *   - QB #15 (immutable data): all results are frozen; internal state
- *     rebuild-on-write (no mutable record leakage).
- */
-/**
- * Common contract every deploy-target adapter implements. The Tier 9
- * registry in src/build/deploy-adapter.ts is expected to consume this;
- * we export it from here (and from dokploy.ts) so both adapters stay
- * in lock-step without requiring a shared module we don't own.
- *
- * Two adapters declaring the same interface shape is fine — TypeScript
- * uses structural typing. If the registry later owns a canonical version
- * of this interface, we can slim to a type alias without breaking
- * consumers.
- */
-export interface DeployTargetAdapter {
-    readonly id: string;
-    readonly createAndDeploy: (opts: CreateAndDeployOptions) => Promise<CreateAndDeployResult>;
-    readonly fetchStatus: (deploymentId: string) => Promise<FetchStatusResult>;
-    readonly fetchLogs: (deploymentId: string) => Promise<FetchLogsResult>;
-    readonly cancel: (deploymentId: string) => Promise<CancelResult>;
-    readonly listDeployments: () => readonly DeploymentRecord[];
-}
-export interface CreateAndDeployOptions {
-    readonly appName: string;
-    readonly gitRepo: string;
-    readonly branch: string;
-    readonly projectId?: string;
-    readonly envVars?: Readonly<Record<string, string>>;
-    readonly buildCommand?: string;
-    readonly startCommand?: string;
-}
-export interface DeploymentRecord {
-    readonly id: string;
-    readonly appId: string;
-    readonly status: DeploymentStatus;
-    readonly url?: string;
-    readonly createdAt: number;
-    readonly updatedAt: number;
-}
-export type DeploymentStatus = "pending" | "queued" | "building" | "deploying" | "live" | "failed" | "cancelled";
-export type CreateAndDeployResult = {
-    readonly ok: true;
-    readonly deploymentId: string;
-    readonly appId: string;
-    readonly url?: string;
-    readonly status: DeploymentStatus;
-} | {
-    readonly ok: false;
-    readonly reason: string;
-    readonly httpStatus?: number;
-};
-export type FetchStatusResult = {
-    readonly ok: true;
-    readonly deployment: DeploymentRecord;
-} | {
-    readonly ok: false;
-    readonly reason: string;
-    readonly httpStatus?: number;
-};
-export type FetchLogsResult = {
-    readonly ok: true;
-    readonly logs: string;
-    readonly truncated: boolean;
-} | {
-    readonly ok: false;
-    readonly reason: string;
-    readonly httpStatus?: number;
-};
-export type CancelResult = {
-    readonly ok: true;
-} | {
-    readonly ok: false;
-    readonly reason: string;
-    readonly httpStatus?: number;
-};
-export interface CoolifyConfig {
-    /** Coolify instance base URL (e.g. "https://coolify.example.com"). */
-    readonly apiUrl: string;
-    /** Coolify bearer token. Never logged; never leaked to results. */
-    readonly apiToken: string;
-    /** Optional project UUID — overridden per-call when supplied. */
-    readonly defaultProjectId?: string;
-    /** Injected fetch for testability. Production passes native fetch. */
-    readonly fetcher?: HttpFetcher;
-    /** Clock injection for deterministic tests. */
-    readonly now?: () => number;
-    /** Max retries on 5xx/transport errors. Default 2. */
-    readonly maxRetries?: number;
-    /** Backoff base ms (exponential). Default 200. */
-    readonly retryBackoffMs?: number;
-}
-/** Narrow fetch shape — matches cloud-offload pattern. */
-export type HttpFetcher = (url: string, init: {
-    readonly method: string;
-    readonly headers: Record<string, string>;
-    readonly body?: string;
-}) => Promise<{
-    readonly ok: boolean;
-    readonly status: number;
-    readonly text: () => Promise<string>;
-    readonly json: () => Promise<unknown>;
-}>;
-export declare function createCoolifyAdapter(config: CoolifyConfig): DeployTargetAdapter;
-/**
- * Map Coolify's status strings to the canonical DeploymentStatus enum.
- * Coolify uses a loose set of strings in different endpoints — we
- * normalize aggressively so downstream consumers never see provider
- * leakage.
- */
-export declare function mapCoolifyStatus(raw: string): DeploymentStatus;
-//# sourceMappingURL=coolify.d.ts.map

package/dist/build/deploy-targets/coolify.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"coolify.d.ts","sourceRoot":"","sources":["../../../src/build/deploy-targets/coolify.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuCG;AAIH;;;;;;;;;;GAUG;AACH,MAAM,WAAW,mBAAmB;IAClC,QAAQ,CAAC,EAAE,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,eAAe,EAAE,CACxB,IAAI,EAAE,sBAAsB,KACzB,OAAO,CAAC,qBAAqB,CAAC,CAAC;IACpC,QAAQ,CAAC,WAAW,EAAE,CAAC,YAAY,EAAE,MAAM,KAAK,OAAO,CAAC,iBAAiB,CAAC,CAAC;IAC3E,QAAQ,CAAC,SAAS,EAAE,CAAC,YAAY,EAAE,MAAM,KAAK,OAAO,CAAC,eAAe,CAAC,CAAC;IACvE,QAAQ,CAAC,MAAM,EAAE,CAAC,YAAY,EAAE,MAAM,KAAK,OAAO,CAAC,YAAY,CAAC,CAAC;IACjE,QAAQ,CAAC,eAAe,EAAE,MAAM,SAAS,gBAAgB,EAAE,CAAC;CAC7D;AAED,MAAM,WAAW,sBAAsB;IACrC,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IACzB,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IACzB,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,QAAQ,CAAC,SAAS,CAAC,EAAE,MAAM,CAAC;IAC5B,QAAQ,CAAC,OAAO,CAAC,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC,CAAC;IACpD,QAAQ,CAAC,YAAY,CAAC,EAAE,MAAM,CAAC;IAC/B,QAAQ,CAAC,YAAY,CAAC,EAAE,MAAM,CAAC;CAChC;AAED,MAAM,WAAW,gBAAgB;IAC/B,QAAQ,CAAC,EAAE,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,MAAM,EAAE,gBAAgB,CAAC;IAClC,QAAQ,CAAC,GAAG,CAAC,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,SAAS,EAAE,MAAM,CAAC;IAC3B,QAAQ,CAAC,SAAS,EAAE,MAAM,CAAC;CAC5B;AAED,MAAM,MAAM,gBAAgB,GACxB,SAAS,GACT,QAAQ,GACR,UAAU,GACV,WAAW,GACX,MAAM,GACN,QAAQ,GACR,WAAW,CAAC;AAEhB,MAAM,MAAM,qBAAqB,GAC7B;IACE,QAAQ,CAAC,EAAE,EAAE,IAAI,CAAC;IAClB,QAAQ,CAAC,YAAY,EAAE,MAAM,CAAC;IAC9B,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,GAAG,CAAC,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,MAAM,EAAE,gBAAgB,CAAC;CACnC,GACD;IACE,QAAQ,CAAC,EAAE,EAAE,KAAK,CAAC;IACnB,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC;CAC9B,CAAC;AAEN,MAAM,MAAM,iBAAiB,GACzB;IAAE,QAAQ,CAAC,EAAE,EAAE,IAAI,CAAC;IAAC,QAAQ,CAAC,UAAU,EAAE,gBAAgB,CAAA;CAAE,GAC5D;IAAE,QAAQ,CAAC,EAAE,EAAE,KAAK,CAAC;IAAC,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAA;CAAE,CAAC;AAElF,MAAM,MAAM,eAAe,GACvB;IAAE,QAAQ,CAAC,EAAE,EAAE,IAAI,CAAC;IAAC,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,SAAS,EAAE,OAAO,CAAA;CAAE,GACzE;IAAE,QAAQ,CAAC,EAAE,EAAE,KAAK,CAAC;IAAC,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAA;CAAE,CAAC;AAElF,MAAM,MAAM,YAAY,GACpB;IAAE,QAAQ,CAAC,EAAE,EAAE,IAAI,CAAA;CAAE,GACrB;IAAE,QAAQ,CAAC,EAAE,EAAE,KAAK,CAAC;IAAC,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAA;CAAE,CAAC;AAIlF,MAAM,WAAW,aAAa;IAC5B,sEAAsE;IACtE,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,mEAAmE;IACnE,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;IAC1B,iEAAiE;IACjE,QAAQ,CAAC,gBAAgB,CAAC,EAAE,MAAM,CAAC;IACnC,sEAAsE;IACtE,QAAQ,CAAC,OAAO,CAAC,EAAE,WAAW,CAAC;IAC/B,+CAA+C;IAC/C,QAAQ,CAAC,GAAG,CAAC,EAAE,MAAM,MAAM,CAAC;IAC5B,sDAAsD;IACtD,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC;IAC7B,kDAAkD;IAClD,QAAQ,CAAC,cAAc,CAAC,EAAE,MAAM,CAAC;CAClC;AAED,0DAA0D;AAC1D,MAAM,MAAM,WAAW,GAAG,CACxB,GAAG,EAAE,MAAM,EACX,IAAI,EAAE;IACJ,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IACzC,QAAQ,CAAC,IAAI,CAAC,EAAE,MAAM,CAAC;CACxB,KACE,OAAO,CAAC;IACX,QAAQ,CAAC,EAAE,EAAE,OAAO,CAAC;IACrB,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,QAAQ,CAAC,IAAI,EAAE,MAAM,OAAO,CAAC,MAAM,CAAC,CAAC;IACrC,QAAQ,CAAC,IAAI,EAAE,MAAM,OAAO,CAAC,OAAO,CAAC,CAAC;CACvC,CAAC,CAAC;AAOH,wBAAgB,oBAAoB,CAAC,MAAM,EAAE,aAAa,GAAG,mBAAmB,CA+O/E;AA8ED;;;;;GAKG;AACH,wBAAgB,gBAAgB,CAAC,GAAG,EAAE,MAAM,GAAG,gBAAgB,CAW9D"}