@raishin/vanguard-frontier-agentic 2.0.0 → 2.1.0

package/skills/qa/playwright-e2e-execution-run/references/workflow-and-output.md

@@ -0,0 +1,133 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs (static mode)
+
+Without running anything, gather:
+- The Playwright project root (location of `playwright.config.ts/js` and the `tests/` directory).
+- The target base URL the operator wants to test against.
+- Whether browser binaries are already installed.
+- Confirmation of whether the operator is opting into runtime execution this session.
+
+If the operator has not explicitly opted into runtime execution, stay in static mode: report what would run and stop.
+
+### Step 2 — Target safety gate
+
+Before any execution, validate the target:
+- Reject a base URL that names or resolves to production — `prod`, `production`, a bare customer apex domain, or `www.` on the public site. Require a staging, preview, QA, or ephemeral environment.
+- Reject a base URL with embedded credentials (`https://user:pass@host`). Credentials belong in the environment, never the URL.
+- Echo back only the **host** for confirmation (`staging.example.internal`), never the full URL with query string or token.
+
+If the target cannot be confirmed as non-production, stay in static mode and state the refusal reason.
+
+### Step 3 — Resolve the command
+
+Construct the exact command from operator-supplied flags. Examples:
+
+```bash
+# Whole suite against a confirmed target
+PLAYWRIGHT_BASE_URL=https://staging.example.internal npx playwright test
+
+# A single project / shard
+npx playwright test --project=chromium --shard=1/4
+
+# A specific spec
+npx playwright test tests/checkout.spec.ts
+```
+
+State the resolved command verbatim and get a final go-ahead.
+
+### Step 4 — Ensure browsers (only if needed)
+
+If browser binaries are missing:
+
+```bash
+npx playwright install --with-deps
+```
+
+If egress to the Playwright browser CDN (`cdn.playwright.dev`, `playwright.download.prss.microsoft.com`) is blocked, do not report a test failure — the run never started. Degrade to `manual-review` with reason `browser-install-blocked`.
+
+### Step 5 — Execute (runtime mode only)
+
+Run the resolved `npx playwright test` command. Use a machine-readable reporter so results can be parsed deterministically:
+
+```bash
+npx playwright test --reporter=json
+```
+
+Capture: exit code, total/passed/failed/skipped counts, tests that passed only on retry (flaky), the slowest tests, and the paths to `playwright-report/` and any `test-results/**/trace.zip`.
+
+Do not re-run with raised timeouts or extra retries to force a green result. One run, reported as observed. A deliberate re-run for flakiness confirmation is allowed only if the operator asks, and both runs are reported.
+
+### Step 6 — Emit the attestation
+
+Produce a JSON attestation conforming to `schemas/attestation.schema.json`. Verdict rules:
+- `pass` — exit code 0, zero failed tests.
+- `fail` — one or more tests failed.
+- `manual-review` — the run could not complete (browser install blocked, config error, target unreachable, egress denied). Never auto-`pass` an incomplete run.
+
+### Step 7 — Produce the output
+
+Format the response using the Output section below, with the attestation JSON included.
+
+---
+
+## Output
+
+Return results in this structure:
+
+```
+## Mode
+<static | runtime> — <one-line reason>
+
+## Command
+<the exact command executed, or that would be executed in static mode>
+
+## Target
+host: <host only>   playwright: <version>   duration: <wall-clock>
+
+## Results
+total: <n>   passed: <n>   failed: <n>   flaky: <n>   skipped: <n>
+
+## Failures
+- <test title> — <file:line> — trace: <path/to/trace.zip>
+
+## Verdict
+<pass | fail | manual-review> — <reasons>
+
+## Attestation
+```json
+{
+  "schema": "schemas/attestation.schema.json",
+  "skill": "playwright-e2e-execution-run",
+  "target_host": "<host>",
+  "playwright_version": "<version>",
+  "command": "<command>",
+  "results": { "total": 0, "passed": 0, "failed": 0, "flaky": 0, "skipped": 0 },
+  "verdict": "<pass|fail|manual-review>",
+  "verdict_reasons": [],
+  "artifacts": { "report": "playwright-report/", "traces": [] },
+  "generated_at": "<ISO-8601>"
+}
+```
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring operator clarification>
+```
+
+---
+
+## Security notes
+
+- Default mode is static — the skill runs nothing until the operator explicitly opts into runtime execution in the current session.
+- Runtime execution is gated on an operator-confirmed non-production target. A production target is an immediate refusal, not a warning.
+- The Bash allowlist permits only `npx playwright test`, `npx playwright install`, and `npx playwright show-report`. Never run deploy, database migration, seed, registry, or `kubectl` commands under this skill.
+- Never accept credentials, bearer tokens, or a `storageState` file inline or in the base URL. Test credentials are supplied through the operator-controlled environment and are never collected, echoed, or written into the attestation.
+- E2E suites frequently create or modify data in the target application. That side effect is the operator's responsibility and is the reason a non-production target is mandatory — state this explicitly.
+- An incomplete run degrades to `manual-review`, never to `pass`. A blocked browser CDN, an unreachable target, or a config error must not be reported as a test `fail`, which would misattribute the cause.
+- Report failures as observed. Do not raise timeouts, add retries, or re-run selectively to manufacture a green verdict.

package/skills/qa/playwright-e2e-suite-review/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: playwright-e2e-suite-review
+description: Use this skill when reviewing a Playwright end-to-end test suite for flakiness, selector brittleness, isolation defects, and CI reliability. Trigger when a user provides Playwright spec files, a playwright.config.ts/js, a CI workflow that runs Playwright, or asks why their E2E suite is flaky, slow, or fails intermittently in CI but passes locally. This skill reviews test artifacts statically; it does not execute the suite or launch browsers.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: delivery
+  lifecycle: experimental
+---
+
+# Playwright E2E Suite Review
+
+## Purpose
+This skill reviews a Playwright end-to-end test suite for the defects that destroy CI trust at scale: flakiness, brittle selectors, broken test isolation, and unreliable CI configuration. A flaky E2E suite is worse than no suite — engineers learn to re-run failures instead of reading them, real regressions ship behind a green-after-retry checkmark, and the suite stops gating anything. The review catches hard waits, manual non-retrying assertions, implementation-coupled selectors, shared mutable state across tests, and retry/sharding misconfiguration before they erode confidence in the deploy pipeline.
+
+## Lean operating rules
+- Treat any use of `page.waitForTimeout()` / `waitForTimeout` in a spec (not a debugging branch) as HIGH — fixed sleeps are the single largest source of Playwright flakiness; they either race the app or pad every run.
+- Treat manual non-retrying assertions (`expect(await locator.isVisible()).toBe(true)`, `expect(await locator.textContent()).toBe(...)`) as HIGH — they snapshot a single instant and lose Playwright's auto-retry; use web-first assertions (`await expect(locator).toBeVisible()`).
+- Treat selectors bound to implementation detail — deep CSS chains, nth-child indexes, generated/hashed class names, raw XPath — as HIGH for brittleness; prefer role-, label-, text-, or `data-testid`-based locators.
+- Treat tests that depend on ordering or share mutable state (module-level variables mutated across `test()` blocks, a record created in test A read in test B) as HIGH — they break under parallelism, sharding, and `--shuffle`, and produce non-reproducible failures.
+- Treat `retries` set greater than 0 in CI with no flaky-test surfacing (no trace-on-retry, no flaky reporter, no quarantine) as HIGH — retries then silently mask real flakiness instead of buying time to fix it.
+- Treat `trace`/`screenshot`/`video` all disabled in the CI project as HIGH — a CI-only failure with no trace is undebuggable and forces blind re-runs.
+- Treat absolute waits on network (`waitForLoadState('networkidle')`) used as a general synchronization crutch as MEDIUM — it is fragile under analytics/polling; wait on the specific element or response instead.
+- Treat shared `storageState` / auth fixtures mutated by tests, or login performed inside every test instead of via a setup project, as MEDIUM — slow and a cross-test contamination risk.
+- Treat a single un-sharded CI job for a large suite, or `fullyParallel: false` without a stated reason, as MEDIUM — wall-clock time blocks every deploy.
+- Treat `expect` timeouts or global `timeout` raised well above default to make a suite "pass" as MEDIUM — masks a real slow path or race.
+- Do not recommend deleting or `.skip()`-ing a flaky test as the fix without a root-cause category and a quarantine/tracking path.
+- Label every finding with evidence basis: spec/config text provided, documentation-based, or inference from absent configuration.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Flakiness findings (hard waits, manual assertions, network-idle crutches)
+- Selector brittleness assessment (locator strategy per spec)
+- Test isolation findings (shared state, ordering dependence, auth contamination)
+- Retry and observability assessment (retries vs. trace/flaky surfacing)
+- CI configuration findings (sharding, parallelism, artifact capture, timeouts)
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/qa/playwright-e2e-suite-review/metadata.json

@@ -0,0 +1,23 @@
+{
+  "id": "playwright-e2e-suite-review",
+  "name": "Playwright E2E Suite Review",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review a Playwright end-to-end test suite for flakiness, selector brittleness, test isolation defects, retry masking, and CI reliability — statically, without executing the suite.",
+  "source_type": "original",
+  "official_docs": [
+    "https://playwright.dev/docs/best-practices",
+    "https://playwright.dev/docs/locators",
+    "https://playwright.dev/docs/test-assertions",
+    "https://playwright.dev/docs/test-retries",
+    "https://playwright.dev/docs/test-parallel",
+    "https://playwright.dev/docs/test-sharding",
+    "https://playwright.dev/docs/trace-viewer"
+  ],
+  "security_notes": "Static review only — reads test specs and config, never executes the suite, launches browsers, or contacts a target application. Never request or accept live application URLs with embedded credentials, auth tokens, real storageState files, or .env secrets; ask for sanitized snippets.",
+  "last_verified": "2026-05-17",
+  "path": "skills/qa/playwright-e2e-suite-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/qa/playwright-e2e-suite-review/references/workflow-and-output.md

@@ -0,0 +1,176 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized snippets (no live URLs with embedded credentials, no auth tokens, no real `storageState` JSON, no `.env` contents):
+- Playwright spec files (`*.spec.ts`, `*.spec.js`, `tests/**`)
+- `playwright.config.ts` / `playwright.config.js`
+- Page object / fixture files (`fixtures.ts`, `pages/**`)
+- The CI workflow step that runs Playwright (GitHub Actions, GitLab CI, etc.)
+- Optional: a recent CI failure log or flaky-test report
+
+If only a partial set is provided, note which inputs are absent and scope findings accordingly. A config without specs, or specs without a config, each leaves a blind spot — say so.
+
+### Step 2 — Flakiness audit
+
+Scan every spec for time-based and non-retrying synchronization.
+
+**2a. Hard waits**
+```ts
+// HIGH — fixed sleep races the application
+await page.waitForTimeout(2000);
+await page.click('#submit');
+```
+`waitForTimeout` is for debugging only. It either fires before the app is ready (flake) or pads every run (slow). Replace with an action or web-first assertion that auto-waits:
+```ts
+// CORRECT — auto-waits for the element to be actionable
+await page.getByRole('button', { name: 'Submit' }).click();
+```
+
+**2b. Manual non-retrying assertions**
+```ts
+// HIGH — snapshots one instant, no auto-retry
+expect(await page.getByText('welcome').isVisible()).toBe(true);
+```
+Web-first assertions retry until the condition holds or the timeout expires:
+```ts
+// CORRECT
+await expect(page.getByText('welcome')).toBeVisible();
+```
+Flag any `expect(await ...)` wrapping `isVisible()`, `textContent()`, `innerText()`, `count()`, `getAttribute()` as HIGH.
+
+**2c. Network-idle as a synchronization crutch**
+```ts
+// MEDIUM — fragile under analytics, polling, websockets
+await page.waitForLoadState('networkidle');
+```
+`networkidle` is discouraged for general synchronization. Wait on the specific signal instead:
+```ts
+await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
+// or
+await page.waitForResponse(r => r.url().includes('/api/orders') && r.ok());
+```
+
+### Step 3 — Selector brittleness audit
+
+Review the locator strategy in every spec and page object.
+
+| Locator pattern | Verdict | Why |
+|---|---|---|
+| `getByRole`, `getByLabel`, `getByText`, `getByTestId` | preferred | resilient to refactor; user- or contract-facing |
+| `data-testid` CSS (`[data-testid="x"]`) | acceptable | stable contract, but `getByTestId` is clearer |
+| deep CSS chain (`div > div:nth-child(3) .btn`) | HIGH | breaks on any layout change |
+| hashed/generated class (`.css-1a2b3c`, `.MuiBox-root`) | HIGH | regenerated on every build |
+| raw XPath (`//div[2]/span`) | HIGH | brittle, hard to read |
+| `nth()` / index-based selection on dynamic lists | MEDIUM | breaks when list order or length changes |
+
+Flag each HIGH locator with the spec file and the recommended role/label/test-id replacement.
+
+### Step 4 — Test isolation audit
+
+Verify each test is independent and order-free.
+
+Check for:
+- Module-level mutable variables written by one `test()` and read by another → HIGH
+- A test that creates a record (user, order) consumed by a later test → HIGH (breaks under sharding and `--shuffle`)
+- `test.describe.serial()` used to paper over a shared-state dependency rather than for a genuine sequential flow → HIGH
+- `beforeAll` performing mutable setup that tests then modify without reset → MEDIUM
+- Shared `storageState` file written to by tests → MEDIUM (cross-test auth contamination)
+
+```ts
+// HIGH — test B depends on test A's side effect
+let createdOrderId;
+test('creates order', async () => { createdOrderId = await createOrder(); });
+test('views order', async () => { await page.goto(`/orders/${createdOrderId}`); });
+
+// CORRECT — each test owns its data via a fixture
+test('views order', async ({ orderFixture }) => {
+  await page.goto(`/orders/${orderFixture.id}`);
+});
+```
+
+### Step 5 — Retry and observability audit
+
+Review `retries`, `trace`, `screenshot`, `video` in `playwright.config`.
+
+- `retries > 0` in CI with no flaky surfacing (no `trace: 'on-first-retry'`, no flaky reporter, no quarantine list) → HIGH. Retries are a buffer to *fix* flakes, not to *hide* them. A test that only passes on retry must be visible and tracked.
+- `trace`, `screenshot`, and `video` all `'off'` for the CI project → HIGH. A CI-only failure with zero artifacts is undebuggable; engineers re-run blindly.
+- Recommended CI baseline:
+```ts
+export default defineConfig({
+  retries: process.env.CI ? 2 : 0,
+  use: {
+    trace: 'on-first-retry',
+    screenshot: 'only-on-failure',
+    video: 'retain-on-failure',
+  },
+  reporter: [['html'], ['github']],
+});
+```
+
+### Step 6 — CI configuration audit
+
+Review parallelism, sharding, and timeouts.
+
+- `fullyParallel: false` without a stated reason → MEDIUM (serial execution blocks deploys).
+- A large suite running in a single CI job with no `--shard` matrix → MEDIUM. Recommend a shard matrix:
+```yaml
+strategy:
+  matrix:
+    shard: [1/4, 2/4, 3/4, 4/4]
+steps:
+  - run: npx playwright test --shard=${{ matrix.shard }}
+```
+- Global `timeout` or `expect.timeout` raised far above default to force a pass → MEDIUM. The raised timeout masks a real slow path or race; flag the underlying cause.
+- `workers` pinned to 1 in CI without justification → MEDIUM.
+- No `--forbid-only` (or equivalent) in CI → MEDIUM: a stray `test.only` silently skips the rest of the suite.
+
+### Step 7 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence: pass / needs work / critical issues found>
+
+## Evidence level
+<spec and config provided | partial artifacts | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security notes
+
+- Never request or accept live application URLs with embedded credentials, bearer tokens, real `storageState.json`, or `.env` contents. Ask for sanitized snippets.
+- This is a static review: do not run `npx playwright test`, launch browsers, or contact the application under test.
+- Do not recommend `.skip()` or deleting a flaky test as the fix — every flaky test needs a root-cause category (race, hard wait, shared state, brittle selector) and a quarantine/tracking path so it is fixed, not buried.
+- Do not recommend raising timeouts or adding retries to make a suite "go green" — both mask defects the review exists to surface.

package/skills/qa/plc-control-logic-safety-review/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: plc-control-logic-safety-review
+description: Use this skill when reviewing exported PLC program logic (Ladder Diagram, Structured Text, Function Block Diagram, or Sequential Function Chart) for safety and reliability defects. Trigger when a user provides exported IEC 61131-3 program source, an I/O list, a safety requirements spec, a SIL assessment, or asks whether their PLC logic has a safe state, a correct E-stop implementation, unresolved latches, forced I/O, or interlock bypass risks. This is OT/ICS — defects injure people or destroy equipment. The skill performs static review only; it never connects to a live PLC, never writes to a controller, and never advises modifying running logic or bypassing a safety function.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: resilience
+  lifecycle: experimental
+---
+
+# PLC Control Logic Safety Review
+
+## Purpose
+This skill statically reviews exported IEC 61131-3 PLC program logic for safety and reliability defects before that logic reaches a live controller. In operational technology (OT) and industrial control systems (ICS), a logic defect that would be a bug in enterprise software can injure people, destroy equipment, or trigger a process shutdown with downstream consequences measured in hours of downtime or lives at risk. The review covers E-stop and safety function implementation, output fail-safe behavior, latch integrity, memory-write races, forced I/O left in production exports, interlock bypass governance, timer determinism, watchdog coverage, and input-validation gaps. It never touches a live controller, never modifies logic, and never advises weakening a safety function.
+
+## Lean operating rules
+- E-stop or safety function implemented in standard-PLC software logic instead of a hardwired, fail-safe safety relay or a safety-rated PLC/SIL-rated controller — CRITICAL (violates IEC 60204-1 / IEC 61508; a scan fault, firmware bug, or communications loss can defeat a software-only E-stop).
+- An output coil that can be energized but has no reachable path to de-energize on fault, communications loss, or PLC STOP/mode change — CRITICAL (remote I/O modules may hold last state on network dropout; a stuck energized output can sustain hazardous motion or heat).
+- A latch (SET coil, SR block, retentive coil) with no reachable RESET anywhere in the program, or a RESET gated behind a condition that can never evaluate TRUE — HIGH (output permanently energized; no operator recovery path without forcing).
+- The same output bit, memory flag, or output coil address written by more than one rung, task, or Program Organization Unit (POU) within a single scan cycle — HIGH (last-write-wins race; behavior is non-deterministic and scan-order dependent).
+- Forced I/O values or commissioning force-tables present in the exported program file — HIGH (commissioning state or debug override shipped to production; control loop sees forced value, not the live field sensor).
+- An interlock bypass or maintenance-override bit with no time limit enforced in logic and no supervisor key-switch, credential gate, or logged acknowledgment — HIGH (silent, indefinite defeat of a safety interlock; not compliant with IEC 62443-3-3 SR 2.12 and typical SIF management procedures).
+- Timer or counter logic whose numerical correctness depends on scan-cycle duration rather than an explicit, hardware-referenced real-time base (e.g., incrementing a counter in every scan and comparing to a literal count instead of using a TON/TOF with a PT in milliseconds) — HIGH (breaks when scan time changes under load, program additions, or firmware upgrade).
+- No watchdog output and no defined fail-safe default output state documented or implemented for communications loss with remote I/O or a supervisory system (SCADA/DCS) — HIGH (silent loss of supervision; outputs may hold indefinitely in an unsafe energized state).
+- Division, array indexing, or type conversion applied to a process value or network-received value that has not been validated for range — MEDIUM (integer divide-by-zero or out-of-bounds array access causes a scan fault and PLC halt in most runtimes, transitioning to a potentially undefined output state).
+- Rung, network, or task execution priority that creates a correctness dependency undocumented in comments or a technical note — MEDIUM (maintainers and future modifications may break the assumed order silently).
+- Do not recommend disabling, bypassing, or weakening any safety interlock, E-stop circuit, or SIF — refuse the request and explain the IEC 61508 and IEC 60204-1 basis for the refusal.
+- Label every finding with its evidence basis: exported logic provided, I/O list provided, documentation-based, or inference from absent configuration.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Safety function and E-stop implementation findings (hardwired vs. software; SIL-rated controller vs. standard PLC)
+- Output fail-safe and de-energization path analysis
+- Latch/SET-RESET integrity findings
+- Memory-write race findings (multiple writers to same address)
+- Forced I/O and commissioning override findings
+- Interlock bypass governance findings
+- Timer and watchdog determinism findings
+- Input validation findings (division, array, type conversion on unvalidated values)
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/qa/plc-control-logic-safety-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "plc-control-logic-safety-review",
+  "name": "PLC Control Logic Safety Review",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Statically review exported IEC 61131-3 PLC program logic (LD, ST, FBD, SFC) for safety and reliability defects — E-stop implementation, output fail-safe paths, latch integrity, memory-write races, forced I/O, interlock bypass governance, timer determinism, and watchdog coverage — without connecting to a live controller.",
+  "source_type": "original",
+  "official_docs": [
+    "https://plcopen.org/iec-61131-3",
+    "https://webstore.iec.ch/publication/4552",
+    "https://webstore.iec.ch/publication/22273",
+    "https://webstore.iec.ch/publication/26037",
+    "https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_structure_application_objects.html"
+  ],
+  "security_notes": "Static review only — reads exported program logic, never connects to a live PLC, never writes to a controller, and never advises modifying running logic or bypassing a safety function. Never request or accept live controller IP addresses, plant network credentials, historian credentials, or any identifier that maps to a production asset. Ask for sanitized, anonymized exports only.",
+  "last_verified": "2026-05-17",
+  "path": "skills/qa/plc-control-logic-safety-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}