testeiya 0.4.5 → 0.5.0

package/skills/testomatio/requirements/wiki-from-code/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: wiki-from-code
+description: >-
+  Builds and refreshes a product wiki from the application source code (implicit requirements).
+  Optionally attaches issue-tracker task/issue/story links.
+  Use when the user asks to build or refresh the wiki/requirements/specification/docs from code, or to catalog existing functionality.
+metadata:
+  author: Testomat.io
+  version: 1.0.0
+---
+
+# Wiki from code
+
+Wiki of **how the product works now**. Bootstrap from code. Refresh when the code changes.
+
+We call this "wiki" as the closest term to what we are building. But user may ask for "requirements" or "specification" or "docs" or something similar.
+
+**Implicit** requirements means inferred from code. **Explicit** requirements means from issues/tasks/docs etc.
+
+Decide audience once:
+
+| Audience | Human wiki |
+| --- | --- |
+| End users (default, preferred) | Behavior and acceptance only. No file paths, types, stack, or protocol internals. |
+| Callers who are not end users (API, job, contract etc.) | Technical entry could be treated as requirements. |
+
+## Modes
+
+Pick one. If unclear, **bootstrap** when `wiki/` is missing, else **refresh**.
+
+| Mode | When |
+| --- | --- |
+| `bootstrap` | First wiki from this repo |
+| `refresh` | Code moved; update implicit pages + catalog |
+
+Default root: `wiki/` (or the user’s path).
+
+Move from **overview** to **details**. Do not write feature pages before the tree exists.
+
+## Steps
+
+```
+- [ ] 1. Catalog (shallow)
+- [ ] 2. Tracker links? (ask; optional)
+- [ ] 3. Overview tree (indexes)
+- [ ] 4. Dive each area (one subagent each)
+- [ ] 5. Validate
+- [ ] 6. Report
+```
+
+Read [references/layout.md](references/layout.md) before writing files.
+
+## Rules
+
+- Current-state code wins any other source (e.g. docs, tests, config, infra, comments, issues etc). Intended, but not implemented (or implemented differently) behavior goes in `mismatches/` only — never a SHOULD heading on a feature page.
+- Name areas and features from the **product** and user perspective, not the stack or code.
+- Capabilities describe *what the product does*. Catalog records *where that lives in the repo*.
+- Pair capabilities and catalog items (use relative path) (`capabilities/{area}/{feature}.md` ↔ `catalog/{area}/{feature}.yaml`). Feature page: after breadcrumb, relative link to the YAML.
+- Tracker links (tasks, issues, stories, etc.) are optional. **Ask** before adding any. Put them in catalog YAML (`issues`), not on feature pages. Do not invent keys or URLs.
+
+## 1. Catalog (shallow)
+
+The **catalog** is what exists in the product: first a shallow area → feature list, then YAML facts in `catalog/`. Code, test, doc, and issue tracker links live here (`sources`, `tests`, `wiki_path`, `issues`).
+
+From **code** map the product into **areas**, each with a **feature list**. That list *is* the catalog of what exists in the product at this step. Do not draft Requirement/Acceptance or YAML yet.
+
+If an area is large, group features into sub-folders at this step. Catalog YAML uses the same relative path as the feature page.
+
+## 2. Tracker links (optional)
+
+**Ask the user** whether to attach issue-tracker links (tasks, issues, stories, etc.) to catalog YAML.
+
+If none of MCP / user-supplied links work: skip with reason. Do not write placeholder tickets.
+
+Write only into catalog YAML (`issues`). Omit the `issues` key when a feature has no match.
+
+## 3. Overview tree
+
+Write only the indexes first ([references/layout.md](references/layout.md)). Give the tree hierarchy when the product is complex enough. If names are ambiguous, **stop and show the list** before diving.
+
+Shared rules live on one page; others link.
+
+## 4. Dive each area
+
+For each feature: catalog YAML first (`catalog/{area}/{feature}.yaml`), then the feature page (Requirement / Acceptance). Stubs, unused wiring, and doc-vs-code gaps go in `mismatches/` with all required source links (layout).
+
+Use `subagent` per area/feature to keep the main agent focused on the helicopter view, subagents focused on the details of one area/feature.
+
+Each subagent gets: area/feature name, allowed paths, audience, [references/layout.md](references/layout.md), "code wins", and whether tracker `issues` are in scope (matched links to write, or omit). Feature pages are Requirement / Acceptance only. Do not rewrite sibling areas except to add the one index line the parent asked for.
+
+Subagent returns: files written, mismatches, open questions. Parent merges links and sitemap; then validates.
+
+Exception: a one-line fix on an existing page already in context — no subagent spawn.
+
+## 5. Validate
+
+```markdown
+Structure
+- [ ] wiki/README.md is a sitemap; every listed link exists
+- [ ] catalog YAML exists for every feature; every wiki_path exists
+- [ ] catalog/README.md indexes every area; each area catalog README lists its YAML
+- [ ] Area (and group) folders named from the product, not from stack/code
+- [ ] Feature pages use the layout heading order (Requirement, Acceptance); breadcrumbs match folder depth; links are relative
+- [ ] Feature pages link to the paired catalog YAML (relative path)
+- [ ] Feature pages are not mega-dumps (one cluster per page)
+- [ ] Feature pages not overloaded with meta info (it is located in catalog YAML)
+- [ ] Tracker links are in catalog YAML (`issues`); omitted when declined or none matched; no invented keys/URLs
+
+Content
+- [ ] Features described from the user perspective, not the stack/code
+- [ ] Catalog is YAML facts, not a second spec
+- [ ] Current-state Requirement matches code
+- [ ] mismatches/ covers disagreements (between code and other sources)
+```
+
+## 6. Report
+
+Where to start from. Results. Mismatches. Huge projects: those three only.
+
+## Next actions
+
+- Explain a capability in QA language → `qa-explain-behavior`
+- Risk scenarios for a capability → `qa-thinking`
+- Test cases for capability/feature → `qa-write-test-cases`

package/skills/testomatio/requirements/wiki-from-code/references/layout.md

@@ -0,0 +1,94 @@
+# Wiki layout
+
+Product-agnostic. Name `{area}` / `{feature}` (and any extra group folders) from **what the product does**, not from the stack. Follow naming rules according to code/language used (kebab-case by default). Same relative path in `capabilities/` and `catalog/`.
+
+Default tree is multiple levels under `capabilities/`. Add sub-folders (with required depth) when the project is complex enough that an area needs a named group. Each with a README.
+
+```
+wiki/
+  README.md                        # front door → roots
+  capabilities/                    # Wiki > Capabilities
+    README.md                      # areas index
+    {area}/                        # Wiki > Capabilities > {Area}
+      README.md                    # features index
+      {feature}.md                 # Wiki > … > {Feature}  — leaf
+      {group}/                     # optional extra nesting
+        README.md
+        {feature}.md
+  catalog/                         # Wiki > Catalog  — list of functionalities
+    README.md                      # areas index
+    {area}/
+      README.md                    # YAML index
+      {feature}.yaml
+      {group}/
+        README.md
+        {feature}.yaml
+  mismatches/                      # optional — create when a disagreement exists
+    README.md
+```
+
+Create `mismatches/` when code disagrees with comments, infra, docs, issues etc.
+
+## Rules
+
+| Rule | Do |
+| --- | --- |
+| Default | `capabilities/{area}/{feature}.md` |
+| Extra depth | New group folder when the area (or group) is too crowded or a cluster needs a name. Any depth. |
+| Split | New sibling `{feature}.md`, a new group folder, or a new `{area}/`. |
+| Share | One page owns a shared rule; others link. Same behavior, two entries → one page. |
+| Growth | New behavior → new leaf + catalog entry + one new index line. Do not thicken an existing leaf into a mega-page. |
+| Overview first | Indexes exist before any leaf is written. |
+
+## Formatting
+
+Every page: `# Title`, then a breadcrumb that matches folders, then the body. Omit empty sections. Relative links only.
+
+**Index** (any `README.md`): title + breadcrumb + a bullet list. No Requirement or Acceptance.
+
+| File | Body |
+| --- | --- |
+| `wiki/README.md` | Roots (`capabilities/`, `catalog/`, `changes/` / `mismatches/` (if present)) |
+| `capabilities/README.md` | Every area: link + purpose (markdown indexes only — not catalog YAML) |
+| `capabilities/{area}/README.md` | Every child feature (or group): link + purpose |
+| Extra group `README.md` | Every child feature (or deeper group): link + purpose |
+| `catalog/README.md` | Every area: link to that area’s catalog README |
+| `catalog/{area}/README.md` | Every child YAML: link + purpose (YAML indexes only — not feature pages) |
+
+**Leaf** (`{feature}.md`): headings in this order only — Requirement, Acceptance. After the breadcrumb, a relative link to the paired catalog YAML. Intended-but-unwired behavior is not a feature heading — it goes in `mismatches/` only. Code and tracker references live in catalog YAML (`sources`, `tests`, `issues`), never on the feature page.
+
+## Catalog YAML
+
+```yaml
+wiki_path: capabilities/{area}/{feature}.md
+entry:
+  - POST /api/v1/orders
+  - UI /checkout
+  - Job SettlePayments
+sources:
+  - path/to/code
+tests:
+  - TestOrSpecFile
+issues:                    # optional; omit the key when none
+  - key: PROJ-123
+    url: https://example.com/browse/PROJ-123
+behaviors:
+  - One as-implemented fact (observable outcome).
+```
+
+`entry` is whatever a human would use to *find* the behavior. Catalog is **implicit** current state. One YAML per feature. If the feature sits in extra folders, the YAML uses the same folders.
+
+`wiki_path` is the pointer from catalog to the feature page. `sources` is the implementation (and product docs that describe it). `issues` is optional tracker links (tasks, issues, stories). `url` is required on each item; `key` when the tracker has a display key. Ask before adding. Omit `issues` when the user declined or nothing matched.
+
+Repo paths (implementation, tests, docs) and tracker links are written only in catalog YAML.
+
+## Mismatch page
+
+Create `mismatches/` when code disagrees with comments, infra, docs, issues/tasks. Index: `mismatches/README.md`.
+
+Every mismatch must link every source that justifies it (omit none that exist):
+
+| Link | What to point at |
+| --- | --- |
+| Implemented | Always — current behavior based on code |
+| Intended | Always — the non-wiki source that disagrees with those files (comment, doc, infra, issue, unused config, or stub) |

package/skills/testomatio/test-management/migrate-to-testomatio/SKILL.md

@@ -11,31 +11,41 @@ metadata:
 
 Migrate test suites from another TMS into Testomat.io via UI import, API migration script, or CSV converter.
 
+## Scope Discovery (Ask First)
+
+- Before picking a strategy, ask the user what must migrate: test cases only, or also run history/results, attachments/screenshots, automation runs, milestones, defects/issues links, custom fields.
+- Do not assume cases-only. Confirm explicitly: "Do you need just test cases, or also runs/results and attachments?"
+- Record the answer and route accordingly: anything beyond test cases forces the API script path (CSV cannot carry it).
+
 ## Pick Strategy
 
 - Identify source: ask for TMS name only if not given.
+- Proactively discover the best fetch method: prefer live API access over CSV export whenever the scope needs it or the dataset is large. CSV is a quick fallback, not the default for complete migrations.
+- Ask for API access early: "Do you have admin/API access to the source instance (URL + API token)?" If yes, use the API script path even when a CSV export also exists.
 - Identify input: live instance with API access, or exported CSV/XLSX file.
 - Route by source:
   - TestRail + API access, >1000 tests or needs attachments/runs: API migration script ([TESTRAIL_MIGRATION.md](./references/TESTRAIL_MIGRATION.md)).
   - TestRail, <1000 tests, no attachments: built-in UI import (CSV or TestRail API option in Imports window).
+  - Testmo + API access, or needs runs/results/attachments: API migration via Testmo REST API ([TESTMO_MIGRATION.md](./references/TESTMO_MIGRATION.md), modeled on the TestRail script).
   - XRay (Jira): migration script producing Testomat.io CSV ([XRAY_MIGRATION.md](./references/XRAY_MIGRATION.md)).
-  - Testmo, QMetry, TestCaseLabs, Allure TestOps export file: CSV converter script ([CSV_MIGRATION.md](./references/CSV_MIGRATION.md)).
+  - Testmo, QMetry, TestCaseLabs, Allure TestOps export file, cases-only, no attachments: CSV converter script ([CSV_MIGRATION.md](./references/CSV_MIGRATION.md)).
   - Qase, QTest, Zephyr, other TMS export file: direct UI CSV import, no script ([CSV_MIGRATION.md](./references/CSV_MIGRATION.md)).
   - Unsupported or broken TMS support: build a custom converter or API script ([CUSTOM_MIGRATION.md](./references/CUSTOM_MIGRATION.md)).
-  - Screenshots or file attachments needed: use the API script path, CSV import cannot create attachments.
+- **CSV limits: CSV/XLSX migrates test cases only. It cannot migrate run results/history, attachments/screenshots, automation runs, or milestones. If the user needs any of these, switch to the API migration path.**
+- Screenshots or file attachments needed: use the API script path, CSV import cannot create attachments.
 - **Never invent converter output columns; converted files always import with format `Testomat.io`.**
 - **API scripts need source credentials plus a Testomat.io General Token; never hardcode tokens, use `.env`.**
 
 ## Scope
 
-- Migration covers test cases; runs, defects, and requirements are optional extras via API.
+- Migration covers test cases by default; runs, results/history, attachments, automation runs, milestones, defects, and requirements are optional extras via API — confirm which the user needs (see Scope Discovery).
 - Upload run results only after test cases are uploaded.
 - User fields with no Testomat.io equivalent are not dropped silently: map them to Labels/Tags or extend the converter script.
 
 ## Workflow
 
 - Create empty Testomat.io project for the import target.
-- Get source access: API credentials (TestRail/XRay path) or export file (CSV path).
+- Get source access: API credentials (TestRail/XRay/Testmo path) or export file (CSV path).
 - Run the routed path:
   - API script path: clone repo to a temp dir, configure `.env`, dry-run, run full migration.
   - CSV path: convert if a converter exists, then import via UI.
@@ -47,6 +57,7 @@ Migrate test suites from another TMS into Testomat.io via UI import, API migrati
 ## References
 
 - [TESTRAIL_MIGRATION.md](./references/TESTRAIL_MIGRATION.md) — TestRail UI options, API script env vars, runs and attachments migration.
+- [TESTMO_MIGRATION.md](./references/TESTMO_MIGRATION.md) — Testmo REST API migration (cases, runs, results, attachments), modeled on the TestRail script.
 - [XRAY_MIGRATION.md](./references/XRAY_MIGRATION.md) — XRay token extraction, env vars, folder-scoped import.
 - [CSV_MIGRATION.md](./references/CSV_MIGRATION.md) — converter scripts, direct UI imports, custom Testomat.io XLSX columns.
 - [CUSTOM_MIGRATION.md](./references/CUSTOM_MIGRATION.md) — custom converter or API v2 script for unsupported or broken TMS support.

package/skills/testomatio/test-management/migrate-to-testomatio/references/CSV_MIGRATION.md

@@ -1,6 +1,8 @@
 # CSV Migration (Testmo, QMetry, TestCaseLabs, Allure, Others)
 
-Two paths: converter script (normalizes export to Testomat.io CSV), or direct UI import.
+> CSV/XLSX migrates test cases only. It cannot migrate run results/history, attachments/screenshots, automation runs, or milestones. If the user needs any of these, stop and switch to the API migration path (TestRail: [TESTRAIL_MIGRATION.md](./TESTRAIL_MIGRATION.md), Testmo: [TESTMO_MIGRATION.md](./TESTMO_MIGRATION.md), other/unsupported: [CUSTOM_MIGRATION.md](./CUSTOM_MIGRATION.md)).
+
+Two paths: converter script (normalizes export to Testomat.io CSV), or direct UI import. Use only for cases-only scope with no attachments.
 
 Docs: https://docs.testomat.io/project/import-export/import/import-tests-from-csv-xlsx
 

package/skills/testomatio/test-management/migrate-to-testomatio/references/TESTMO_MIGRATION.md

@@ -0,0 +1,101 @@
+# Testmo Migration
+
+Three import methods. Pick by scope (cases-only vs full) and attachment/run need.
+
+- CSV file or converter script: test cases only, no runs/results, no attachments ([CSV_MIGRATION.md](./CSV_MIGRATION.md), repo https://github.com/testomatio/migrate-testmo).
+- Built-in UI tool (Testmo format option): test cases only, no attachments, small suites.
+- API migration script: full migration — cases with folders, runs with results, attachments. Modeled on https://github.com/testomatio/migrate-testrail.
+
+Docs: https://docs.testomat.io/project/import-export/import/import-tests-from-csv-xlsx
+Testmo API docs: https://support.testmo.com/hc/en-us/sections/37971074321293-API-Reference
+
+## UI Import (Cases Only)
+
+- Open project > Tests tab > (`...`) > Import from other TMS > Import > Import from CSV > dropdown `Testmo` > Choose file > Create.
+- Converter output (`*_Testomatio.csv`) always imports with format `Testomatio`.
+- Confirm scope first: if the user needs runs/results or attachments, skip UI import and use the API script below.
+
+## API Access
+
+- Base URL: `https://<your-name>.testmo.net/api/v1`.
+- Auth: `Authorization: Bearer <token>` header. Token is a user API key from Testmo profile settings (or a dedicated API user created by the admin).
+- Quick check:
+
+```bash
+curl -H "Authorization: Bearer $TESTMO_TOKEN" \
+  https://<your-name>.testmo.net/api/v1/user
+```
+
+- Key read endpoints for migration:
+  - `GET /api/v1/projects/{project_id}/folders` — folder tree (`id`, `parent_id`, `name`).
+  - `GET /api/v1/projects/{project_id}/cases?expands=tags,folders&per_page=100&page=N` — cases with custom fields (`custom_steps` HTML, `custom_priority`, tags). Paginate to `last_page`.
+  - `GET /api/v1/projects/{project_id}/templates` — template/field definitions, resolve `custom_*` keys before mapping.
+  - `GET /api/v1/projects/{project_id}/runs` — manual runs.
+  - `GET /api/v1/runs/{run_id}/results?get_latest_result=true&per_page=100` — latest result per test in a run (drop the flag for full history).
+  - `GET /api/v1/projects/{project_id}/cases/{case_id}/result-history` — per-case history alternative.
+  - `GET /api/v1/cases/{case_id}/attachments` — attachment list with download `path`.
+  - Automation runs (optional): `GET /api/v1/projects/{project_id}/automation/runs`, `GET /api/v1/automation/runs/{run_id}/tests`.
+- All list endpoints paginate (`per_page` max `100`); loop until `next_page` is null.
+
+## Migration Script (Based on migrate-testrail)
+
+No standalone `migrate-testmo` API script exists yet; scaffold it from https://github.com/testomatio/migrate-testrail (same structure: fetch source → map → push via Testomat.io API v2 → migrate runs).
+
+- Requires NodeJS 20+.
+- Scaffold outside the project repo:
+
+```bash
+git clone https://github.com/testomatio/migrate-testrail.git <temp-dir>/migrate-testmo-api
+cp .env.example .env
+npm i
+```
+
+- `.env` vars (adapted from the TestRail script):
+
+```env
+TESTMO_URL=https://<your-name>.testmo.net
+TESTMO_TOKEN=
+TESTMO_PROJECT_ID=
+# TESTMO_FOLDER_ID= # optional, single folder only
+TESTOMATIO_TOKEN=testomat_****
+TESTOMATIO_PROJECT=
+# TESTOMATIO_HOST=https://app.testomat.io # custom instance only
+# DRY_RUN=1 # dry run, no import
+```
+
+- `TESTOMATIO_PROJECT` is the URL slug: `https://app.testomat.io/projects/<slug>`.
+- `TESTOMATIO_TOKEN` is a General Token from https://app.testomat.io/account/access_tokens.
+- Replace the TestRail client in `migrate.js` with Testmo calls:
+  - Folders: build `/Folder` paths from `parent_id` chains (`GET .../folders`).
+  - Cases: page through `GET .../cases?expands=tags,folders`, convert `custom_steps` HTML (`text1` step, `text3` expected) to Markdown steps, map priority/tags/issues per [CSV_MIGRATION.md](./CSV_MIGRATION.md) column spec.
+  - Keep ID compatibility: zero-pad numeric IDs to 8 chars where a stable ID is needed.
+- Debug flags (same as TestRail script): `DEBUG="testomatio:testmo:*" npm start` (`:in` source data, `:out` posted data, `:migrate` processing).
+- Single case debug (run after full migration): `TESTMO_CASE_ID=12345 npm start`.
+
+## Test Runs with Results
+
+- Requires Project Reporting API key (project Settings > API section) as `TESTOMATIO_REPORT_TOKEN`.
+- Import all cases first, then migrate runs (same ordering as `npm run migrate-run-results` in the TestRail script).
+- Source: `GET /api/v1/projects/{project_id}/runs` then per run `GET /api/v1/runs/{run_id}/results?get_latest_result=true` (or full history without the flag).
+- Map Testmo statuses via `GET /api/v1/projects/{project_id}/statuses` (`is_passed` → passed, `is_failed` → failed, `is_untested` → untested, else skipped/retest as comment).
+- Tag created Testomat.io runs with `@id:<testmo_run_id>` in the run title so reruns skip already-imported runs.
+- Single run: `TESTMO_RUN_ID=<id> npm run migrate-run-results` (same convention as `TESTRAIL_RUN_ID`).
+
+## Attachments
+
+- Source: `GET /api/v1/cases/{case_id}/attachments`, download each file via its `path` with the Bearer token.
+- CSV import cannot carry attachments; re-upload downloaded files via Testomat.io API after the case exists (same pattern as the TestRail `migrate-attachments` step).
+- Dry-run first, then full run (mirroring the TestRail script):
+
+```bash
+npm run migrate-attachments:dry-run
+npm run migrate-attachments
+```
+
+## Recovery
+
+- 401/403 from Testmo: token missing, expired, or lacking project access — regenerate the API key or use a dedicated API user.
+- 422 on case create: `custom_*` field not in the template — check `GET .../templates` and drop or remap the field.
+- Empty cases list: wrong `TESTMO_PROJECT_ID` or user has no access to that project.
+- HTML in steps: `custom_steps` returns HTML (`<p>...</p>`) — strip/convert to Markdown during mapping.
+- CSV import fails: first row must hold column names; converted files import with format `Testomatio`, not `Testmo`.

package/dist/prompt/comment-thread.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"comment-thread.js","sourceRoot":"","sources":["../../prompt/comment-thread.ts"],"names":[],"mappings":"AAAA,OAAO,MAAM,MAAM,QAAQ,CAAC;AAE5B;;;;;;GAMG;AACH,MAAM,KAAK,GAAG;IACZ,MAAM,EAAE;QACN,GAAG,EAAE,CAAC,gBAAgB,CAAC;QACvB,QAAQ,EAAE,MAAM,CAAA;mRAC+P;KAChR;IAED,MAAM,EAAE;QACN,GAAG,EAAE,CAAC,WAAW,CAAC;QAClB,QAAQ,EAAE,MAAM,CAAA;wPACoO;KACrP;IAED,SAAS,EAAE;QACT,GAAG,EAAE,CAAC,wBAAwB,CAAC;QAC/B,QAAQ,EAAE,MAAM,CAAA;sQACkP;KACnQ;IAED,OAAO,EAAE;QACP,GAAG,EAAE,EAAE;QACP,QAAQ,EAAE,MAAM,CAAA;2QACuP;KACxQ;CAC6B,CAAC;AAEjC;;;GAGG;AACH,MAAM,UAAU,UAAU,CAAC,GAAgB;IACzC,KAAK,MAAM,CAAC,IAAI,EAAE,IAAI,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,EAAE,CAAC;QACjD,IAAI,IAAI,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,QAAQ,EAAE,EAAE,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC;YAAE,OAAO,IAAkB,CAAC;IAC5E,CAAC;IACD,IAAI,GAAG,CAAC,EAAE;QAAE,OAAO,SAAS,CAAC;IAC7B,OAAO,IAAI,CAAC;AACd,CAAC;AAED,2EAA2E;AAC3E,MAAM,UAAU,YAAY,CAAC,MAAc;IACzC,OAAO,wBAAwB,MAAM,EAAE,CAAC;AAC1C,CAAC;AAED,MAAM,UAAU,aAAa,CAAC,OAA6B;IACzD,OAAO,MAAM,CAAA;;;;QAIP,OAAO,CAAC,MAAM;;MAEhB,MAAM,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC;oBACR,CAAC;AACrB,CAAC;AAED;;;;GAIG;AACH,SAAS,KAAK,CAAC,OAA6B;IAC1C,IAAI,OAAO,CAAC,SAAS,EAAE,CAAC;QACtB,OAAO,MAAM,CAAA;;;6EAG4D,YAAY,CAAC,OAAO,CAAC,MAAM,CAAC;SAChG,MAAM,CAAC,OAAO,CAAC;;wHAEgG,CAAC;IACvH,CAAC;IAED,OAAO,MAAM,CAAA;;;;2CAI4B,YAAY,CAAC,OAAO,CAAC,MAAM,CAAC;OAChE,MAAM,CAAC,OAAO,CAAC;OACf,IAAI,CAAC,OAAO,CAAC;;;;IAIhB,MAAM,CAAC,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,QAAQ,CAAC,EAAE,CAAC;AAC3C,CAAC;AAED,gFAAgF;AAChF,+EAA+E;AAC/E,SAAS,MAAM,CAAC,OAA6B;IAC3C,MAAM,KAAK,GAAG,OAAO,CAAC,UAAU,CAAC,CAAC,CAAC,SAAS,OAAO,CAAC,UAAU,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;IACxE,MAAM,KAAK,GAAG;QACZ,oCAAoC,KAAK,kBAAkB;QAC3D,oFAAoF;QACpF,qCAAqC;KACtC,CAAC;IACF,IAAI,OAAO,CAAC,MAAM;QAAE,KAAK,CAAC,IAAI,CAAC,8BAA8B,OAAO,CAAC,MAAM,KAAK,CAAC,CAAC;IAClF,OAAO,KAAK,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AACzB,CAAC;AAED,SAAS,IAAI,CAAC,OAA6B;IACzC,IAAI,CAAC,OAAO,CAAC,UAAU;QAAE,OAAO,2BAA2B,CAAC;IAC5D,OAAO,kGAAkG,CAAC;AAC5G,CAAC;AAED,gFAAgF;AAChF,6EAA6E;AAC7E,SAAS,MAAM,CAAC,IAAY;IAC1B,OAAO,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC;AACzC,CAAC"}