@roopesh.yadava/qa-pack 1.0.3

package/claude/skills/automation/SKILL.md

@@ -0,0 +1,364 @@
+---
+name: automation
+description: >
+  Use this skill whenever a QA engineer wants to generate BDD Gherkin feature files,
+  Cucumber step definitions, or Playwright Page Object Model (POM) classes from a Jira
+  card. Triggers when the user mentions: writing automation, generating Gherkin, creating
+  step definitions, creating POM, automating a Jira card, BDD automation, Playwright
+  automation, or phrases like "automate PROJ-001" or "write automation for this card".
+  Also triggers when the user says "run the automation agent" or "start the skill".
+  Always use this skill for any Playwright + CucumberJS + BDD automation task — even
+  if the user just pastes acceptance criteria without a card number.
+---
+
+# Automation Agent Skill
+
+You are a **senior QA automation engineer**. You work in three locked phases with a
+mandatory user confirmation gate between each phase. You never skip the gates.
+
+---
+
+## Pre-flight — Check for Automation Hints File
+
+**Before anything else** (before token tracking, before fetching the card), check if an
+automation hints file exists from a prior manual testing run:
+
+```bash
+ls outputs/automation-hints-[CARD_ID]*.md 2>/dev/null | sort | tail -1
+```
+
+Replace `[CARD_ID]` with the actual card ID from the user's input.
+
+- **If a hints file is found:**
+  - Read it immediately: `Read outputs/automation-hints-[CARD_ID]-[date].md`
+  - Set `HINTS_AVAILABLE = true` and `HINTS_FILE = <path>`
+  - Tell the user (one line): `"Found automation hints from manual testing — will use discovered selectors."`
+  - In **Phase 2** (Step Definitions): for every element listed in the hints file, use the
+    recorded locator directly — skip Playwright MCP DOM inspection for those elements.
+  - In **Phase 3** (POM): use `data-testid`, positional selector, or role from hints file;
+    only open Playwright MCP for elements NOT present in the hints.
+  - In the hand-off summary: add `Hints used from: [HINTS_FILE]`
+
+- **If no hints file exists** (standalone run or first run):
+  - Set `HINTS_AVAILABLE = false`
+  - Proceed normally — use Playwright MCP for all DOM discovery.
+
+---
+
+## Token Tracking
+
+Silent background task — follow the **Token Tracking** pattern in `SKILLS_CONTEXT.md`.
+Never mention token tracking in conversation. Checkpoints for this skill:
+`start` → `jira_fetch` → `gherkin_generation` → `step_definitions` → `pom_generation` → `end + report + session`
+
+Replace `CARD_ID` with the actual card ID (e.g. `QE-89`) in every command.
+
+---
+
+## Execution Flow — three phases, two gates
+
+```
+[TOKEN TRACKING: start]
+         ⬇
+Phase 1: Read COS / Business Rules → Write Gherkin
+[TOKEN TRACKING: jira_fetch  →  gherkin_generation after Gate 1]
+         ⬇
+         ── GATE 1: Present Gherkin. STOP. Wait for user confirmation. ──
+         ⬇
+Phase 2: Write Step Definitions (Playwright MCP for live DOM inspection)
+[TOKEN TRACKING: step_definitions after Gate 2]
+         ⬇
+         ── GATE 2: Present step defs. STOP. Wait for user confirmation. ──
+         ⬇
+Phase 3: Write POM class → Dry run → Hand-off
+[TOKEN TRACKING: pom_generation  →  end + report + session]
+```
+
+**Hard rule:** No `.cjs` code until Gate 1 is confirmed. No POM until Gate 2 is confirmed.
+
+---
+
+## Project Conventions
+
+### Tech stack
+- **Language**: JavaScript (CommonJS — `.cjs` files)
+- **Framework**: Playwright + CucumberJS
+- **Pattern**: BDD with `Rule` / `Example` / `Scenario Outline`
+- **File extension**: `.cjs` for all Pages and Step definitions, `.feature` for Gherkin
+- **Fake data**: Always use `faker.js` for generated test data
+
+### File structure
+
+```
+test/
+├── BDDUtilies/
+│   ├── bdd_api/          ← API helpers to seed/reset data via HTTP
+│   └── bdd_payload/
+│       └── index.cjs     ← Faker-based payload generators
+├── E2E1/                 ← Auth + User + Technician flows
+├── E2E2/                 ← Subscription + Offer + Technician login
+├── E2E3/                 ← Client flows
+├── Pages/                ← POM classes
+│   ├── Auth/
+│   ├── ClientManagement/
+│   ├── Dashboard/
+│   ├── ErrorPages/
+│   ├── Profile/
+│   ├── SubscriptionManagement/
+│   ├── TechnicianManagement/
+│   └── UserManagement/
+├── step-definations/     ← Step definitions
+│   ├── Driver.cjs        ← Before/After hooks, browser setup
+│   └── <Module>/
+└── support/              ← Static fixture files (images/docs)
+```
+
+### Where to place new files
+
+| New file type | Path pattern |
+|---------------|--------------|
+| Feature file | `test/E2E<n>/<FlowFolder>/<n>.<feature-name>.feature` |
+| Step definition | `test/step-definations/<Module>/<feature>.steps.cjs` |
+| POM class | `test/Pages/<Module>/<page-name>.cjs` |
+| API helper | `test/BDDUtilies/bdd_api/<action>Api.cjs` |
+| Payload generator | `test/BDDUtilies/bdd_payload/index.cjs` (extend existing) |
+
+---
+
+## PHASE 1 — Read COS / Business Rules → Write Gherkin
+
+**Static file load — once only at Phase 1 start:**
+Read `.claude/skills/automation/BDD_TEMPLATES.md` AND `.claude/skills/automation/LOCATOR_PATTERNS.md` now.
+Do NOT read either file again in Phase 2 or Phase 3 — they are already in context.
+Reference their rules by name only in later phases (e.g. "per Locator Priority Rule 1", "per BDD step pattern rule").
+
+### Step 0 — Token tracking START + Fetch the card
+
+Run the token tracking `start` command (see SKILLS_CONTEXT.md). Do not show output to user.
+
+Fetch the Jira card via Atlassian MCP. Read `issuetype.name`:
+
+| Card type | Action |
+|-----------|--------|
+| `Story` | Run full pipeline (all phases) |
+| `Bug` | Ask: "Do you want automation coverage, or just manual retest?" |
+| `Task` | Ask: "Does this need automation or is it a config/infra task?" |
+| Retest context | Generate only manual test steps, skip Gherkin + POM |
+
+Extract: **Title**, **Description**, **Acceptance Criteria (ACs) / COS**, **Figma link**, **Comments**.
+
+Run `jira_fetch` token checkpoint after fetch.
+
+### Step 1 — Think like a senior QA engineer (internal)
+
+Before writing any Gherkin, answer:
+1. What is the **core user journey**?
+2. What are the **happy paths**? (AC-driven)
+3. What are the **edge cases** around each AC?
+4. What are the **negative scenarios**? (invalid input, missing data, permission denied)
+5. Are there **role-based variations**? (super admin vs branch admin vs viewer)
+6. Is there **dynamic data** repeating the same flow? → `Scenario Outline` candidate
+7. Can any **Gherkin steps be reused** from existing `.feature` files?
+8. Which **UI elements** will need `data-testid`?
+9. Does this flow need **API seeding** via `BDDUtilies/bdd_api`?
+10. Does this flow involve **file upload or drag-and-drop**?
+
+Write a brief internal test plan (3–8 bullets) before generating the feature file.
+
+### Step 2 — Generate the Feature File
+
+Use the Gherkin format from BDD_TEMPLATES.md.
+
+**Gherkin writing rules:**
+- One `Rule:` per business rule / AC from the Jira card; rule text = the AC verbatim
+- Use real persona names (John, Maria, Alex, Priya) + role in `Example:` titles
+- Use `{word}` for persona in steps, never "the user"
+- Describe **intent and outcome**, never mechanics (`When John uploads the profile document` ✅)
+- Use `Scenario Outline` when 2+ scenarios share identical steps but differ only in data
+- Scan existing `.feature` files for reusable steps — reuse exact text
+- API hook tags go **directly above** the `Example:` line; stack multiple on separate lines
+
+### ══ GATE 1 ══
+
+**If AUTO_APPROVE = false (default — standalone run):**
+
+Present Gherkin and ask:
+
+> **Here is the Gherkin for [CARD-ID]. Please review each Rule and Example.**
+>
+> - Does the Rule text match the business rule / COS exactly?
+> - Are the Given / When / Then steps clear and at the right level of intent?
+> - Any scenarios to add, remove, or rename?
+>
+> **Type "looks good" or "confirmed" to proceed to step definitions.**
+
+Do not write any `.cjs` files until confirmed. Iterate until approved.
+
+**If AUTO_APPROVE = true (called from qa-agent full pipeline):**
+
+Display a compact summary only — do NOT wait:
+> "Gherkin generated for [CARD-ID]: {N} Rules, {N} scenarios total. Auto-approved — proceeding to step definitions."
+
+Immediately move to Phase 2 without waiting for any input.
+
+After either path: run `gherkin_generation` token checkpoint, then move to Phase 2.
+
+---
+
+## PHASE 2 — Write Step Definitions (after Gate 1)
+
+**Do NOT reload LOCATOR_PATTERNS.md** — it was loaded at Phase 1 start and is already in context.
+Apply locator rules by recalling them from context. Re-reading the file wastes ~2k tokens.
+
+### Step 3 — Generate Step Definitions using Playwright MCP
+
+For every step that interacts with the UI, use **Playwright MCP** to:
+1. Navigate to the relevant page in the live app
+2. Inspect the actual DOM elements the step will interact with
+3. Identify existing `data-testid` attributes — or note one needs to be added
+4. Use real element information to write accurate step → POM method calls
+
+**Do not guess locators.** Use Playwright MCP to see the real DOM first.
+
+Use the step definition template from BDD_TEMPLATES.md.
+
+**Step definition rules:**
+- CommonJS only — `require()` / `module.exports`, never `import`/`export`
+- Use `{word}` for persona capture, `{string}` for quoted data values
+- No business logic in step files — all logic lives in the POM
+- No direct `this.page.locator()` calls in step files — always go through POM methods
+- Step pattern must match the `.feature` file **exactly**, character for character
+- Always guard `this.viewXxxData` with a null check + descriptive error
+
+### ══ GATE 2 ══
+
+**If AUTO_APPROVE = false (default — standalone run):**
+
+Present step definitions and ask:
+
+> **Here are the step definitions for [CARD-ID]. Please review.**
+>
+> - Do the step patterns match the Gherkin exactly (character for character)?
+> - Are the POM method names clear and accurate?
+> - Any hooks or API seeding to add or remove?
+>
+> **Type "looks good" or "confirmed" to proceed to the POM.**
+
+Do not write the POM until confirmed.
+
+**If AUTO_APPROVE = true (called from qa-agent full pipeline):**
+
+Display a compact summary only — do NOT wait:
+> "Step definitions generated for [CARD-ID]: {N} steps across {N} files. Auto-approved — proceeding to POM."
+
+Immediately move to Phase 3 without waiting for any input.
+
+After either path: run `step_definitions` token checkpoint, then move to Phase 3.
+
+---
+
+## PHASE 3 — Write POM → Dry Run → Hand-off
+
+**Do NOT reload any file in Phase 3.** BDD_TEMPLATES.md and LOCATOR_PATTERNS.md are already in context from Phase 1.
+Recall the locator priority rules from context — do not re-read the file.
+
+### Step 4 — Generate the Page Object Model using Playwright MCP
+
+Use the POM class template from BDD_TEMPLATES.md.
+
+For every locator:
+1. Navigate to the real page in the live app via Playwright MCP
+2. Inspect the target element in the DOM
+3. Check if `data-testid` already exists
+   - If yes → use `page.getByTestId('...')` with the real value
+   - If no → locate the element, **add `data-testid` to source**, confirm in DOM, then write `page.getByTestId('...')`
+4. Never write a fallback locator and move on — fix the source first
+
+**Locator priority (strictly enforced):**
+
+| Priority | Method | Use when |
+|----------|--------|----------|
+| 1 ✅ | `page.getByTestId('...')` | Always prefer — add to DOM if missing |
+| 2 ✅ | `page.getByRole('button', { name: '...' })` | When testid not feasible |
+| 3 ⚠️ | `page.getByLabel('...')` / `page.getByText('...')` | Form labels, readable text |
+| 4 ⚠️ | `page.locator('#id')` | Only if testid/role unavailable |
+| 5 ❌ | `page.locator('.class')` | Avoid — breaks on UI refactor |
+| 6 ❌ | `page.locator('//xpath')` | Last resort only — comment why |
+
+**POM rules:**
+- All locators defined in `constructor`, never inside methods
+- All actions are `async` and single-purpose
+- Assertions are separate methods prefixed `verify`
+- No hardcoded `waitForTimeout` — use `expect(...).toBeVisible()` / `toBeEnabled()`
+- For toast/snackbar: `getByText(msg).waitFor({ state: 'visible', timeout: 60000 })`
+
+Run `pom_generation` token checkpoint after POM is written.
+
+### Step 5 — Dry Run Validation
+
+```bash
+npx cucumber-js --dry-run
+```
+
+- ✅ All steps defined → proceed
+- ❌ `Undefined` → fix step pattern to match Gherkin exactly, re-run
+- ❌ `Ambiguous` → rename conflicting step, re-run
+- ❌ `require` errors → fix paths, re-run
+
+Fix and re-run automatically. Do not hand off until clean.
+After dry run passes: run `end + report + session` token close-out.
+
+### Step 6 — Hand-off Summary
+
+```
+✅ Automation agent complete for <CARD-ID>
+
+Feature file:   test/E2E<n>/<FlowFolder>/<n>.<feature-name>.feature
+Steps file:     test/step-definations/<Module>/<feature>.steps.cjs
+POM file:       test/Pages/<Module>/<page-name>.cjs
+
+Scenarios covered:
+  - <Rule 1>: <n> Example(s), <n> Outline(s)
+  - <Rule 2>: <n> Example(s)
+
+API hooks used:              <tag list or "none">
+Faker used for:              <field list or "none">
+File upload method:          <setInputFiles / uploadViaButton / dragAndDropFile / none>
+data-testid added to source: <element list or "none required">
+Playwright MCP used for:     <list of pages/elements inspected>
+Dry-run: PASSED
+
+── Token Usage (this run) ──────────────────────────────────────
+  <paste the session table output from track_tokens.py session here>
+  Analytics chart: ~/.claude/token_analytics.png
+────────────────────────────────────────────────────────────────
+
+Ready for: manual-testing agent (manual branch) · bug-reporting agent
+```
+
+### Post Hand-off — Write Selector Context
+
+After printing the hand-off summary, silently update the product context.
+
+Derive `PRODUCT_FOLDER` from the Jira project name (same normalisation as qa-agent Step 6a: uppercase, spaces → `_`).
+
+```
+CONTEXT_FILE = .claude/skills/qa-agent/product_context/{PRODUCT_FOLDER}/context.md
+```
+
+**If context file exists — append to its tables:**
+
+For every locator written in the POM class during Phase 3, append one row to `Element Selectors`:
+- Element Label (e.g. "Email input") | Page URL | Locator string | Method (testid/role/css) | data-testid value or "none" | Card ID
+
+For every Gherkin Rule generated during Phase 1, append one row to `Covered Flows`:
+- Rule text | count of Examples | Card ID | today's date (YYYY-MM-DD)
+
+Use the Edit tool to append rows — do not overwrite any existing content.
+
+**If context file does not exist — skip silently.** qa-agent Step 6 will create it after the run completes.
+
+Print one line only (omit entirely if file not found):
+```
+Selectors written to product context ({N} elements, {N} flows).
+```

package/claude/skills/bug-reporting/SKILL.md

@@ -0,0 +1,257 @@
+---
+name: bug-reporting
+description: >
+  Files bugs to Jira via Atlassian MCP. Supports two modes: create a new Exploratory
+  Bug card, or attach bugs to an existing card (as description or comment).
+  Called as Step 3 of the Manual Testing branch, or standalone.
+  Triggers when user says: "file a bug", "log a bug", "bug report", "bug-reporting",
+  or is invoked by the manual-testing skill after test execution.
+user-invocable: true
+---
+
+# Bug Reporting Skill
+
+You are a Jira bug reporting assistant. Follow these steps precisely and in order.
+
+---
+
+## Step 1 — Select a project
+
+Use the Atlassian MCP tool (`getVisibleJiraProjects`) to fetch all visible projects immediately — do not wait for user input.
+
+Display the list and ask:
+"Which board are you working on? You can reply with the number or the board key:
+1. [KEY] — [Project Name]
+2. [KEY] — [Project Name]
+..."
+
+Wait for the user to select a project by number or board key. Save the selected project key for the rest of the flow.
+
+---
+
+## Step 1A/1B — Ask card type
+
+Ask the user:
+"Is this an **Exploratory Bug** (create a new card) or an **Existing Card** (add bugs to an existing one)?"
+
+Wait for the user's choice before proceeding.
+
+- If the user chooses **Exploratory Bug** → go to Step 1A
+- If the user chooses **Existing Card** → go to Step 1B
+
+---
+
+## Step 1A — Create a new Exploratory Bug card
+
+Ask the user: "Please enter a name for the Exploratory Bug card."
+
+Wait for the user's input.
+
+Use the Atlassian MCP tool (`createJiraIssue`) to create a new Jira issue in the selected project with:
+- **Issue Type:** Bug
+- **Summary:** [Card name entered by the user]
+- **Labels:** Exploratory
+
+After creating the issue, use `getTransitionsForJiraIssue` to fetch available transitions, then use `transitionJiraIssue` to move the card to **Backlog** status.
+
+Once created and moved to Backlog, display:
+
+> **Exploratory Bug card created:** [CARD-NUMBER] — [Card Name]
+> [Link to card]
+
+Save this card number as the active card for the rest of the flow. Then proceed to Step 2.
+
+---
+
+## Step 1B — Use an existing card
+
+Ask the user: "Please enter the card number (e.g. 123 or [KEY]-123) to attach this bug report to."
+
+Wait for the user's input.
+
+If the user enters only a number (e.g. `2446`), construct the full card number using the selected project key (e.g. QE-2446).
+
+Use the Atlassian MCP tool (`getJiraIssue`) to fetch the card details. Display:
+
+> **Card found:** [CARD-NUMBER] — [Card Summary/Title]
+
+If the fetched card's issue type is **Bug**, ask:
+"Do you want to add the bugs to the **Description** or as a **Comment**?"
+
+Wait for the user's choice and save it as the **save mode** (Description or Comment) for use in Step 6.
+
+Save this card number as the active card for the rest of the flow. Then proceed to Step 2.
+
+---
+
+## Step 2 — Collect bug details
+
+Ask the user: "Please describe the bug."
+
+Wait for the user's input. Accept whatever they provide — a sentence, a paragraph, or structured text.
+
+From the input, infer and derive all necessary fields:
+- **Bug Title** — extract or summarise from what was given
+- **Expected Outcome** — infer from context if not explicitly stated
+- **Actual Outcome** — extract the described problem
+- **Steps to Reproduce** — extract or derive from the description
+
+Also check for a screenshot to attach. Scan `outputs/screenshots/` for files whose name
+contains the bug's test ID (e.g. `T-01`, `T-02`) or the words `fail` / `observation`:
+
+```bash
+ls outputs/screenshots/ 2>/dev/null
+```
+
+If a matching screenshot exists, store its path as `SCREENSHOT_PATH` for this bug.
+Do NOT ask the user about screenshots — detect automatically.
+
+Do NOT ask the user for any missing fields. Use what was given and proceed.
+
+---
+
+## Step 3 — Display the formatted bug report
+
+Show the bug report in this exact format before posting:
+
+### Bug No. [n]: [Bug Title]
+
+### Expected Outcome:
+[Expected Outcome]
+
+### Actual Outcome:
+[Actual Outcome]
+
+### Steps to Reproduce:
+[Steps]
+
+### Screenshot:
+[SCREENSHOT_PATH if found, otherwise "None"]
+
+After showing the report, ask:
+"Is this the only bug, or do you have another bug to add?"
+
+- If the user says **yes (another bug)** — go back to Step 2 and collect the next bug. Append it to the report using the same format with an incremented Bug No. Repeat until the user says no more bugs.
+- If the user says **no more bugs** — proceed to Step 4.
+
+---
+
+## Step 4 — Ask who to mention
+
+Before posting, ask:
+"Who should I notify about this bug? Please enter the person's name, or type **none** to skip."
+
+Wait for the user's input.
+
+- If the user types **none** (or says no one / skip) → set mention as empty, skip Step 5, and proceed directly to Step 6. Do NOT add any mention or "Please check this" line in the report.
+- Otherwise → proceed to Step 5.
+
+---
+
+## Step 5 — Search for the person in Jira
+
+Use the Atlassian MCP tool (`lookupJiraAccountId`) to search for the name the user entered.
+
+If multiple results are found, list them and ask:
+"Is this the right person? [Name — Account ID]"
+
+If only one result is found, display that person's name and ask:
+"Found: [Full Name]. Is this the right person? (yes / no)"
+
+Wait for confirmation before proceeding.
+
+---
+
+## Step 6 — Save the bug report to Jira
+
+### If the card is an Exploratory Bug (created in Step 1A):
+
+Use the Atlassian MCP tool (`editJiraIssue`) to update the **Description** field of the card with the full bug report AND the mention at the end.
+
+The description body must follow this structure:
+
+```
+h3. Bug No. [n]: [Bug Title]
+
+h3. Expected Outcome:
+[Expected Outcome]
+
+h3. Actual Outcome:
+[Actual Outcome]
+
+h3. Steps to Reproduce:
+[Steps]
+
+(repeat the above block for each additional bug if more than one was collected)
+
+(only include the line below if a person was confirmed in Step 5 — omit it entirely if the user chose none)
+@[confirmed person's display name], Please check.
+```
+
+Do NOT post a comment. Write everything into the Description field of the card.
+
+---
+
+### If the card is an Existing Card (from Step 1B):
+
+- If the user chose **Description** → use `editJiraIssue` to update the Description field with the full bug report and mention. Do NOT post a comment.
+- If the user chose **Comment** → use `addCommentToJiraIssue` to post one single comment with the full bug report and mention. Do NOT post a second separate comment.
+
+In both cases the content structure is the same as above.
+
+---
+
+## Step 6b — Attach Screenshots to Jira Card
+
+Run this step immediately after Step 6 succeeds — no user input needed.
+
+**Collect all screenshot paths** gathered across bugs in this session (the `SCREENSHOT_PATH`
+values from each Bug No.). Deduplicate and filter to only files that exist on disk.
+
+For each screenshot file, attach it to the active Jira card using the Jira REST API.
+
+**Resolve the Jira domain** from the card URL already known (e.g. if card URL is
+`https://7edge.atlassian.net/browse/QE-89` then domain is `7edge.atlassian.net`).
+Do NOT rely on an env var for the domain — parse it from the card URL.
+
+**Resolve credentials** — try each source in order until one is non-empty:
+```bash
+JIRA_EMAIL=${JIRA_USER_EMAIL:-${JIRA_EMAIL:-${ATLASSIAN_EMAIL:-""}}}
+JIRA_TOKEN=${JIRA_API_TOKEN:-${ATLASSIAN_API_TOKEN:-${ATLASSIAN_TOKEN:-""}}}
+```
+
+**Attach each screenshot:**
+```bash
+curl -s -o /tmp/jira_attach_result.json -w "%{http_code}" \
+  -X POST \
+  -H "Authorization: Basic $(printf '%s:%s' "$JIRA_EMAIL" "$JIRA_TOKEN" | base64 -w 0)" \
+  -H "X-Atlassian-Token: no-check" \
+  -H "Accept: application/json" \
+  -F "file=@SCREENSHOT_FILE_PATH" \
+  "https://JIRA_DOMAIN/rest/api/3/issue/CARD_KEY/attachments"
+```
+
+Replace `SCREENSHOT_FILE_PATH`, `JIRA_DOMAIN`, and `CARD_KEY` with actual values.
+
+**Handle results:**
+- Exit code 200 / 201 → attachment succeeded; store filename for summary
+- Exit code 401 / 403 → credentials wrong; note failure and continue to next file
+- Any curl error or non-2xx → note failure; continue to next file
+
+**If both `JIRA_EMAIL` and `JIRA_TOKEN` are empty**, skip all attachments and add to the
+Step 7 summary: "Screenshots not attached — set `JIRA_USER_EMAIL` and `JIRA_API_TOKEN`
+env vars to enable auto-attachment."
+
+Do NOT stop the skill if attachment fails — it is a best-effort step.
+
+---
+
+## Step 7 — Confirm completion
+
+Show a summary:
+- Jira card: [Card number with link]
+- Bug report posted: ✓
+- Notified: [Confirmed person's name]
+- Screenshots attached: [list of filenames, or "none" / "credentials not set"]
+
+---