@roopesh.yadava/qa-pack 1.0.3 → 1.1.0

package/claude/skills/automation/SKILL.md

@@ -13,8 +13,18 @@ description: >
 
 # 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.
+You are a **senior QA automation engineer**. You work in locked phases with mandatory
+user confirmation gates. You never skip the gates.
+
+**Reuse-first is the prime directive of this skill.** Every product repo already contains
+Gherkin and step definitions; your first responsibility is to find and reuse them.
+> Never write a new step definition whose behavior an existing step already implements —
+> parameterize or reword the Gherkin instead.
+
+**Inputs:** when invoked by qa-agent you receive a parameter block (CARD_ID, APP_URL,
+AUTO_APPROVE, CONTEXT_FILE, hints path). When run standalone, read `.env` for
+`QA_APP_URL` / `QA_LOGIN_URL` / credentials (see Secrets Rule in SKILLS_CONTEXT.md) and
+ask only for what is still missing. Never print `QA_PASSWORD` anywhere.
 
 ---
 
@@ -47,81 +57,129 @@ Replace `[CARD_ID]` with the actual card ID from the user's input.
 
 ## Token Tracking
 
-Silent background task — follow the **Token Tracking** pattern in `SKILLS_CONTEXT.md`.
+Optional and silent — follow the **Token Tracking** pattern in `SKILLS_CONTEXT.md`
+(run its enablement check once at skill start; if disabled, skip every checkpoint silently).
 Never mention token tracking in conversation. Checkpoints for this skill:
-`start` → `jira_fetch` → `gherkin_generation` → `step_definitions` → `pom_generation` → `end + report + session`
+`start` → `jira_fetch` → `reuse_audit` → `gherkin_generation` → `step_definitions` → `pom_generation` → `test_run` → `end + report + session`
 
 Replace `CARD_ID` with the actual card ID (e.g. `QE-89`) in every command.
 
 ---
 
-## Execution Flow — three phases, two gates
+## Execution Flow — five phases, two gates
 
 ```
-[TOKEN TRACKING: start]
+[TOKEN TRACKING: start — optional, see SKILLS_CONTEXT.md]
+         ⬇
+Phase 0: Repo Discovery + Reuse Audit (step catalog)
+[TOKEN TRACKING: jira_fetch → reuse_audit]
          ⬇
-Phase 1: Read COS / Business Rules → Write Gherkin
-[TOKEN TRACKING: jira_fetch  →  gherkin_generation after Gate 1]
+Phase 1: Read COS / Business Rules → Write Gherkin (reuse-matched)
+[TOKEN TRACKING: gherkin_generation after Gate 1]
          ⬇
-         ── GATE 1: Present Gherkin. STOP. Wait for user confirmation. ──
+         ── GATE 1: Present Gherkin + REUSE REPORT. STOP. Wait for confirmation. ──
          ⬇
-Phase 2: Write Step Definitions (Playwright MCP for live DOM inspection)
+Phase 2: Write Step Definitions — ONLY for approved new steps
 [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]
+Phase 3: Write POM class → Dry run
+[TOKEN TRACKING: pom_generation]
+         ⬇
+Phase 4: REAL test run → self-heal loop (max 3) → Hand-off
+[TOKEN TRACKING: test_run → end + report + session]
 ```
 
 **Hard rule:** No `.cjs` code until Gate 1 is confirmed. No POM until Gate 2 is confirmed.
+No Gherkin until the Phase 0 reuse audit is complete.
 
 ---
 
-## Project Conventions
+## Tech Stack Defaults
+
+Used only where Phase 0 discovery finds no existing convention (empty repo, first feature):
 
-### Tech stack
-- **Language**: JavaScript (CommonJS — `.cjs` files)
-- **Framework**: Playwright + CucumberJS
+- **Language**: JavaScript (CommonJS — `.cjs`), 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
+- **Fake data**: `faker.js` for generated test data
+- **Default paths** (only when the repo has none): `test/features/`,
+  `test/step-definitions/`, `test/pages/`
+
+**Whatever Phase 0 discovers in the repo overrides these defaults** — match the existing
+tree's layout, naming style, and idioms exactly, including its typos (e.g. a repo using
+`step-definations/` keeps that spelling).
 
-### File structure
+---
+
+## PHASE 0 — Repo Discovery + Reuse Audit
+
+Runs before any Gherkin is drafted.
+
+**Card + product first:** if invoked by qa-agent, `CARD_ID` and the product come from the
+parameter block. If standalone, fetch the card via Atlassian MCP now (this is the
+`jira_fetch` checkpoint) and derive `PRODUCT_FOLDER` from the Jira project name
+(uppercase, spaces → `_`).
+
+Produces/refreshes the **step catalog** at:
 
 ```
-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)
+CATALOG = .claude/skills/qa-agent/product_context/{PRODUCT_FOLDER}/step-catalog.md
 ```
 
-### Where to place new files
+### 0a — Check catalog freshness
 
-| 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) |
+```bash
+ls "$CATALOG" 2>/dev/null && \
+  find . -path ./node_modules -prune -o \( -name '*.feature' -o -name '*.steps.cjs' -o -name '*.steps.js' -o -name '*.steps.ts' \) -newer "$CATALOG" -print | head -5
+```
+
+- Catalog exists and nothing newer → **load the catalog, skip to 0d**.
+- Catalog missing or stale files found → build/refresh below.
+
+### 0b — Discover the repo layout
+
+1. Read `cucumber.cjs` (or `cucumber.js` / `cucumber.json`) — the `import`/`require`/`paths`
+   globs tell you where step definitions and features actually live.
+2. Glob the tree for `**/*.feature`, the step-definition files matched by the config, and
+   POM/page-object directories (`Pages/`, `pages/`, `pageobjects/`...), excluding `node_modules`.
+3. Record the observed conventions: feature file path pattern, step file path pattern,
+   POM path pattern, file naming style, module folder names.
+4. **If the repo has no test tree at all:** tell the user, propose the defaults above,
+   and record whatever they confirm as this product's layout.
+
+### 0c — Build the step catalog
+
+Extract from every step-definition file each `Given/When/Then(...)` pattern with its
+cucumber-expression parameters, and from every POM file its class name + public methods.
+Write the catalog:
+
+```markdown
+# Step Catalog — {PRODUCT}
+Generated: {date} · Features: {n} · Step files: {n} · Steps: {n} · POM classes: {n}
+
+## Repo Layout (discovered)
+| Artifact | Path pattern | Example |
+|----------|--------------|---------|
+| Feature files | ... | ... |
+| Step definitions | ... | ... |
+| POM classes | ... | ... |
+
+## Steps
+| Pattern | Params | File |
+|---------|--------|------|
+| I click the {string} button | string | test/step-definations/common.steps.cjs |
+
+## POM Classes
+| Class | File | Key methods |
+|-------|------|-------------|
+```
+
+### 0d — Announce (one line)
+
+> "Reuse audit ready — {n} existing steps, {n} POM classes catalogued for {PRODUCT}."
+
+Run `reuse_audit` token checkpoint.
 
 ---
 
@@ -132,11 +190,10 @@ Read `.claude/skills/automation/BDD_TEMPLATES.md` AND `.claude/skills/automation
 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
+### Step 0 — Card data check
 
-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`:
+The card was fetched in Phase 0 (or received from qa-agent). If somehow not yet fetched,
+fetch it now via Atlassian MCP. Read `issuetype.name`:
 
 | Card type | Action |
 |-----------|--------|
@@ -165,30 +222,50 @@ Before writing any Gherkin, answer:
 
 Write a brief internal test plan (3–8 bullets) before generating the feature file.
 
-### Step 2 — Generate the Feature File
+### Step 2 — Generate the Feature File (reuse-matched)
 
 Use the Gherkin format from BDD_TEMPLATES.md.
 
+**Reuse matching — apply to EVERY drafted step, in strict priority order, against the
+Phase 0 step catalog:**
+
+| Priority | Match type | Action |
+|----------|-----------|--------|
+| 1 | **Exact** — step text matches an existing pattern | Reuse verbatim. Tag internally `[reused]` |
+| 2 | **Parameterized** — existing pattern covers it with different arguments (`I click the {string} button`) | Use the existing pattern's exact wording with new arguments. Tag `[reused-param]` |
+| 3 | **Semantic duplicate** — an existing step does the same thing with different wording | **Rewrite YOUR draft to the existing wording.** Never create a parallel step. Tag `[reused-reworded]` |
+| 4 | **Genuine gap** — nothing in the catalog covers the behavior | New step allowed. Tag `[new]` — requires explicit approval at Gate 1 |
+
 **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 ══
+### ══ GATE 1 — Gherkin + Reuse Report ══
+
+Compute the reuse metrics and present them with the Gherkin (both AUTO_APPROVE modes):
+
+```
+Reuse report — [CARD-ID]
+  Steps total: {N} | Reused exact: {N} | Reused parameterized: {N} | New: {N}  ({X}% reuse)
+  New steps requiring definitions:
+    - When I drag the "{string}" card to column "{string}"
+    - ...
+  (or: "No new step definitions needed — full reuse.")
+```
 
 **If AUTO_APPROVE = false (default — standalone run):**
 
-Present Gherkin and ask:
+Present Gherkin + reuse report and ask:
 
-> **Here is the Gherkin for [CARD-ID]. Please review each Rule and Example.**
+> **Here is the Gherkin for [CARD-ID]. Please review each Rule, Example, and the reuse report.**
 >
 > - 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?
+> - Are the **new steps** genuinely new, or should any map to an existing step?
 >
 > **Type "looks good" or "confirmed" to proceed to step definitions.**
 
@@ -196,8 +273,8 @@ 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."
+Display the reuse report + a compact summary — do NOT wait:
+> "Gherkin generated for [CARD-ID]: {N} Rules, {N} scenarios, {X}% step reuse. Auto-approved — proceeding to step definitions."
 
 Immediately move to Phase 2 without waiting for any input.
 
@@ -212,7 +289,15 @@ Apply locator rules by recalling them from context. Re-reading the file wastes ~
 
 ### Step 3 — Generate Step Definitions using Playwright MCP
 
-For every step that interacts with the UI, use **Playwright MCP** to:
+**Write definitions ONLY for steps tagged `[new]` at Gate 1.** Reused steps already have
+working definitions — creating a second one would make cucumber-js fail with `Ambiguous`.
+If every step was reused, say "No new step definitions needed" and skip to Phase 3
+(which then only extends POMs if a new-step definition requires a method that doesn't exist).
+
+Place new definitions in the file the catalog's Repo Layout says they belong in — extend
+an existing module's step file when one fits before creating a new file.
+
+For every new 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
@@ -257,14 +342,19 @@ After either path: run `step_definitions` token checkpoint, then move to Phase 3
 
 ---
 
-## PHASE 3 — Write POM → Dry Run → Hand-off
+## PHASE 3 — Write POM → Dry Run
 
 **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.
+**Reuse check first:** consult the catalog's POM Classes table. If a page object for this
+page already exists, **extend it with the missing methods** — do not create a parallel
+class. Only create a new POM class for a page that has none.
+
+Use the POM class template from BDD_TEMPLATES.md for new classes; match the existing
+class's style when extending.
 
 For every locator:
 1. Navigate to the real page in the live app via Playwright MCP
@@ -302,36 +392,68 @@ 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
+- ❌ `Ambiguous` → a new step collides with an existing one — this is a reuse-audit miss:
+  reuse the existing step (delete the new definition) rather than renaming, unless the
+  behaviors genuinely differ
 - ❌ `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.
+Fix and re-run automatically. Do not proceed until clean.
+
+---
+
+## PHASE 4 — Real Test Run + Self-Heal → Hand-off
+
+A dry run only proves patterns match. QA means the test actually passes against the app.
+
+### Step 6 — Execute the new feature
 
-### Step 6 — Hand-off Summary
+Requires the app URL and credentials (parameter block / `.env`). If neither is available,
+skip with an explicit warning in the hand-off: "Real run SKIPPED — no app URL."
+
+```bash
+npx cucumber-js <new feature file>
+```
+
+### Step 6b — Self-heal loop (max 3 attempts)
+
+On failure, diagnose and fix — **never hand off a silently failing test**:
+
+1. Read the failure: locator timeout? assertion mismatch? navigation/auth issue?
+2. Locator failures → re-inspect that element via Playwright MCP, fix the POM locator
+   (respect the locator priority table).
+3. Assertion failures → check whether expected text/behavior on the card matches the app.
+   If the app appears genuinely wrong, this is a **bug, not a test fix** — stop healing
+   that scenario, mark it failing, and note it as a bug candidate in the hand-off.
+4. Re-run. After 3 failed attempts, stop and report the failure honestly.
+
+Run `test_run` token checkpoint, then `end + report + session` close-out.
+
+### Step 7 — Update the step catalog
+
+Append every new step definition written this run to the Phase 0 catalog (Steps table),
+and any new/extended POM class to the POM Classes table. This keeps the next run's reuse
+audit accurate without a full re-scan.
+
+### Step 8 — 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
+Feature file:   <path per discovered repo layout>
+Steps file:     <path, or "none — full reuse">
+POM file:       <path, or "extended existing: <class>">
 
 Scenarios covered:
   - <Rule 1>: <n> Example(s), <n> Outline(s)
   - <Rule 2>: <n> Example(s)
 
+Reuse:  {N} steps total | {N} exact | {N} parameterized | {N} new  ({X}% reuse)
 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
-────────────────────────────────────────────────────────────────
+Dry-run:  PASSED
+Test run: {PASSED | FAILED after 3 heal attempts: <reason> | SKIPPED — no app URL}
+Bug candidates from test run: <list or "none">
 
 Ready for: manual-testing agent (manual branch) · bug-reporting agent
 ```

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

@@ -214,8 +214,9 @@ For each screenshot file, attach it to the active Jira card using the Jira REST
 `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:
+**Resolve credentials** — load `.env` first, then try each source in order until one is non-empty:
 ```bash
+[ -f .env ] && set -a && . ./.env && set +a
 JIRA_EMAIL=${JIRA_USER_EMAIL:-${JIRA_EMAIL:-${ATLASSIAN_EMAIL:-""}}}
 JIRA_TOKEN=${JIRA_API_TOKEN:-${ATLASSIAN_API_TOKEN:-${ATLASSIAN_TOKEN:-""}}}
 ```

package/claude/skills/manual-testing/SKILL.md

@@ -29,7 +29,8 @@ Use `browser_evaluate` with a specific CSS selector or JS expression for all DOM
 
 ## Token Tracking
 
-Silent background task — follow the **Token Tracking** pattern in `SKILLS_CONTEXT.md`.
+Optional and silent — follow the **Token Tracking** pattern in `SKILLS_CONTEXT.md`
+(run its enablement check once at skill start; if disabled, skip every checkpoint silently).
 Checkpoints: `start` → `jira_fetch` → `ui_testing` → `test_execution` → `end + report + session`.
 Replace `CARD_ID` with the actual card ID. Never show tracking output to user.
 
@@ -55,32 +56,25 @@ Jira Card ID
 
 ---
 
-## Phase 0 — Collect Card ID + Load Context
+## Phase 0 — Inputs
 
-Run token tracking `start` checkpoint.
+Run token tracking `start` checkpoint (if enabled).
 
-If the user has not already provided a Jira card ID, ask:
-> "Please share the **Jira card ID** to begin (e.g. `PROJ-123`)."
+**Invoked by qa-agent (parameter block present):** take `CARD_ID`, `APP_URL`, `LOGIN_URL`,
+`FIGMA_URL`, `AUTO_APPROVE`, `CONTEXT_FILE` from the block. Read `.env` for `QA_USERNAME`,
+`QA_PASSWORD`, `QA_OTP_CODE`. **Ask no setup questions — qa-agent already collected everything.**
+(`FIGMA_URL: none` means `RUN_UI_TEST = false`.)
 
-Wait for the card ID.
+**Standalone run:** resolve values in precedence order `.env` > product context > ask:
+1. Read `.env` → `QA_APP_URL`, `QA_LOGIN_URL`, `QA_USERNAME`, `QA_PASSWORD`, `QA_OTP_CODE`
+2. If the user gave no card ID, ask for it. Then derive the project key prefix
+   (`QE-89` → `QE`) and read `.claude/skills/qa-agent/product_context/{PREFIX}/context.md`
+   if it exists → fills any URL/OTP gaps (never credentials — those are `.env`-only)
+3. Ask ONE consolidated message for whatever is still missing (app URL, credentials,
+   Figma link or "skip UI comparison"). Never ask one-at-a-time; never ask for a value
+   you already have.
 
-**After card ID is known — check for product context:**
-
-Derive the project key prefix (e.g. `QE-89` → `QE`) and check:
-```
-.claude/skills/qa-agent/product_context/{PREFIX}/context.md
-```
-
-**If context file exists:**
-- Read it and extract: `CTX_APP_URL`, `CTX_USERNAME`, `CTX_PASSWORD`, `CTX_LOGIN_URL`, `CTX_OTP`
-- Set `CONTEXT_LOADED = true`
-- Confirm one line: "Context loaded for {PRODUCT_NAME} — using saved URL and credentials."
-
-**If context file not found:**
-- Set `CONTEXT_LOADED = false`
-- Collect URL and credentials during Phase 1 as normal
-
-Then immediately proceed to Phase 1 — do not ask for anything else yet.
+**Never print `QA_PASSWORD` to chat, reports, or hints files.**
 
 ---
 
@@ -106,23 +100,13 @@ After fetching, check `CARD_DESCRIPTION` length:
 
 Do NOT tell the user the description was truncated. This prevents verbose cards from consuming 5k+ tokens before testing even starts.
 
-If no AC found:
+If no AC found (and qa-agent didn't already resolve this):
 > "No Acceptance Criteria found on this card. What should be tested?"
 Wait for user response before continuing.
 
-After fetch, ask these **one at a time**:
-
-**Question A — UI Testing:**
-> "Do you want to compare the app against a Figma design before testing? (yes / no)"
-
-- If yes: ask for Figma URL (suggest `FIGMA_URL_FROM_CARD` if found), then app URL + credentials
-- If no: ask for app URL + credentials only
-
-Store:
-- `RUN_UI_TEST` — true/false
-- `FIGMA_URL` — if yes
-- `APP_URL` — full base URL of the app
-- `USERNAME`, `PASSWORD` — login credentials (ask only if not obvious from card)
+Set from Phase 0 values (all input was collected there — do not re-ask):
+- `RUN_UI_TEST` — true when a Figma URL is available (from parameter block, card, or user)
+- `FIGMA_URL`, `APP_URL`, `USERNAME`, `PASSWORD`, `OTP_CODE`
 
 ---
 
@@ -206,7 +190,7 @@ ls .playwright-session.json 2>/dev/null && echo "SESSION_EXISTS" || echo "NO_SES
 
 **If OTP screen appears:**
 9. Click first OTP box → `browser_click`
-10. `browser_type(text: "999999")` — always this value
+10. `browser_type(text: OTP_CODE)` — the `QA_OTP_CODE` value from `.env` (ask once if unset)
 11. Click verify → `browser_click`
 12. `browser_wait_for(state: "networkidle")`
 
@@ -285,7 +269,7 @@ For each test T-01, T-02, ...:
 7. Append to `HINTS.testCases`:
    ```
    { id: "T-N", name: "...", status: "PASS|FAIL|OBSERVATION|BLOCKED",
-     actions: ["fill email", "click submit", "type OTP 999999"],
+     actions: ["fill email", "click submit", "type OTP"],
      url: "CURRENT_URL" }
    ```
 
@@ -315,7 +299,7 @@ Base URL: [BASE_URL]
 
 ## Environment
 App URL: [APP_URL]
-Login: [USERNAME] / [PASSWORD REDACTED]
+Login: credentials in .env (never written here)
 
 ## Pages Visited
 | URL | Description |