@raishin/vanguard-frontier-agentic 2.0.0 → 2.1.0

package/skills/qa/test-coverage-quality-review/references/workflow-and-output.md

@@ -0,0 +1,139 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized snippets (no credentials, no real customer data in fixtures, no production DB snapshots):
+- Test files for the modules under review
+- A coverage report (text summary, `lcov`, or HTML summary numbers)
+- The source of the code under test, so assertions can be checked against actual behavior
+- The CI coverage-gate configuration (threshold, scope)
+
+If only a coverage report is supplied without test source, the review can only flag *suspiciously high coverage* and cannot judge assertion quality — say so and ask for test source.
+
+### Step 2 — Assertion presence audit
+
+For every test, confirm it makes at least one assertion that can fail.
+
+```js
+// HIGH — no assertion; passes as long as nothing throws
+test('processes the order', async () => {
+  await processOrder(sampleOrder);
+});
+
+// CORRECT — asserts the observable outcome
+test('processes the order', async () => {
+  const result = await processOrder(sampleOrder);
+  expect(result.status).toBe('confirmed');
+  expect(result.total).toBe(149.97);
+});
+```
+Flag every assertion-free test as HIGH. These are pure coverage inflation: the lines execute, the percentage rises, nothing is verified.
+
+### Step 3 — Assertion strength audit
+
+Grade each assertion.
+
+| Assertion pattern | Grade | Note |
+|---|---|---|
+| exact value (`toBe(149.97)`, `toEqual({...})`) | strong | fails on any wrong value |
+| `toBeDefined()`, `not.toBeNull()`, `toBeTruthy()` | weak (MEDIUM) | passes for wrong values; use when an exact value is unknowable only |
+| `toBeGreaterThan(0)`, `length > 0` | weak (MEDIUM) | passes for `[wrong, wrong]` |
+| `expect(true).toBe(true)`, `expect(x).toBe(x)` | tautological (HIGH) | cannot fail |
+| auto-updated snapshot of logic output | weak (MEDIUM) | detects change, not correctness |
+
+Flag tautological assertions as HIGH and shape-only assertions (where an exact value is knowable) as MEDIUM.
+
+### Step 4 — Mock usage audit
+
+Review tests that use mocks, stubs, or spies.
+
+**4a. Call-assertion-only**
+```js
+// HIGH — asserts the mock was called, never the behavior
+test('sends the email', async () => {
+  await notifyUser(user);
+  expect(emailService.send).toHaveBeenCalled();
+});
+```
+This verifies wiring, not outcome. It should also assert *what* was sent and the result the caller depends on.
+
+**4b. Over-mocking**
+```js
+// HIGH — every collaborator mocked; assertions restate the setup
+const repo = { find: jest.fn().mockReturnValue({ id: 1, price: 10 }) };
+const tax = { calc: jest.fn().mockReturnValue(2) };
+test('total', () => {
+  const t = new Cart(repo, tax).total(1);
+  expect(t).toBe(12); // 10 + 2 — but both came from mocks
+});
+```
+When every input is mocked and the assertion is arithmetic over mock return values, the test is a mirror of its own setup. It cannot catch a bug in `find`, `calc`, or their integration. Recommend testing the real collaboration, or moving the guarantee to an integration test.
+
+### Step 5 — Branch coverage gap audit
+
+For code under test that contains error paths, boundaries, or empty-input branches, confirm each has a test.
+
+- Error path (`catch`, thrown error, rejected promise) with no test → HIGH.
+- Boundary (zero, empty array, max value, off-by-one) with no test → HIGH.
+- Only the happy path tested while the source has multiple branches → HIGH: the coverage percentage is inflated by the easy path while real failure modes ship untested.
+
+Distinguish *line* coverage from *branch* coverage in the report — a function can be 100% line-covered with half its branches unexercised.
+
+### Step 6 — Coverage gate audit
+
+Review the CI coverage gate.
+
+- A global line-percentage threshold as the sole quality signal → MEDIUM. It is satisfied by assertion-free tests; the number does not measure verification.
+- No per-changed-file / diff coverage → MEDIUM: new untested code hides behind a large tested codebase. Recommend diff coverage on changed lines.
+- 100% coverage presented as the goal → MEDIUM: it incentivizes theater. The goal is meaningful assertions on behavior that matters.
+- Recommended posture: keep a modest line threshold as a floor, **add diff coverage** on changed lines, and review assertion quality in code review — the percentage is a floor, not a target.
+
+### Step 7 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence: tests verify behavior / coverage theater detected / mixed>
+
+## Evidence level
+<test source + coverage report provided | coverage report only | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding>: <description> — <remediation>
+
+### LOW
+- [L1] <finding>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security notes
+
+- Never request credentials, fixtures containing real customer data, or production database snapshots. Ask for sanitized test code.
+- This is a static review: do not run the test suite or a coverage tool.
+- Do not recommend raising the coverage percentage threshold as a quality improvement — a higher threshold is satisfied by more assertion-free tests. Recommend assertion strength and diff coverage instead.
+- A high coverage number with weak assertions is more dangerous than a low number, because it manufactures false confidence. Say so explicitly when the evidence shows it.

package/skills/qa/test-flakiness-triage/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: test-flakiness-triage
+description: Use this skill when triaging flaky tests across any test framework — analyzing a flaky-test report, CI rerun history, or a set of intermittently failing tests to assign each a root-cause category and a remediation or quarantine path. Trigger when a user reports tests that pass on re-run, asks why CI is unreliable, provides a flaky-test dashboard export, or wants a quarantine policy. This skill reviews evidence statically; it does not execute or re-run tests.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: delivery
+  lifecycle: experimental
+---
+
+# Test Flakiness Triage
+
+## Purpose
+This skill triages flaky tests — tests that pass and fail without a code change — into root-cause categories and assigns each a remediation or quarantine path. Flakiness is a process failure, not a test-by-test annoyance: once a suite flakes, engineers re-run red builds reflexively, a re-run becomes the default response to any failure, and the suite stops detecting real regressions. The skill is framework-agnostic (Playwright, Cypress, Jest, JUnit, pytest, Go) and converts a pile of "sometimes fails" into categorized causes, a quarantine decision per test, and a policy that stops new flakes from entering the suite.
+
+## Lean operating rules
+- Triage every flaky test into exactly one primary root-cause category: async/timing race, test interdependence (shared state / order), environment coupling (clock, timezone, locale, network), non-deterministic data (random, current date, unseeded faker), resource contention (ports, DB, parallelism), or external dependency (third-party API, un-mocked network).
+- Treat a flaky test left in the gating suite with no quarantine and no owner as HIGH — every run it costs the whole team a re-run and erodes signal.
+- Treat "re-run until green" CI configuration (automatic unlimited retries, `|| true`, retry-the-whole-job) with no flaky tracking as HIGH — it converts flakiness from visible to invisible and unbounded.
+- Treat a flaky test "fixed" only by adding a sleep, raising a timeout, or adding a retry as HIGH — the root cause is still present and will resurface.
+- Treat tests sharing a mutable fixture, database row, file, or port without per-test isolation as HIGH for interdependence flakiness.
+- Treat assertions on wall-clock time, `Date.now()`, timezone, or locale without injection/freezing as HIGH for environment coupling.
+- Treat un-mocked calls to third-party services in a unit or component test as HIGH — network and rate limits make them flaky by construction.
+- Treat a quarantine with no expiry, no owner, and no tracking issue as MEDIUM — quarantine is a holding cell, not a graveyard; without an exit it becomes permanent coverage loss.
+- Treat the absence of any flaky-detection mechanism (no rerun-diff, no flaky reporter, no quarantine list) as MEDIUM — flakiness is then discovered only by frustrated engineers.
+- Do not recommend deleting a flaky test as the default fix — a flaky test usually covers a real path; quarantine with an owner and a fix deadline preserves the coverage intent.
+- Label every finding with evidence basis: failure logs / rerun history provided, test source provided, documentation-based, or inference.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full triage or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Per-test root-cause category assignment
+- Quarantine decision per test (quarantine now / fix in place / keep gating)
+- Root-cause remediation direction per category
+- Quarantine policy assessment (owner, expiry, tracking)
+- CI retry-configuration findings
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/qa/test-flakiness-triage/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "test-flakiness-triage",
+  "name": "Test Flakiness Triage",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Triage flaky tests across any framework into root-cause categories, assign a quarantine or fix path per test, and assess quarantine policy and CI retry configuration — statically, without re-running tests.",
+  "source_type": "original",
+  "official_docs": [
+    "https://playwright.dev/docs/test-retries",
+    "https://docs.cypress.io/guides/guides/test-retries",
+    "https://jestjs.io/docs/cli",
+    "https://docs.pytest.org/en/stable/how-to/flaky.html",
+    "https://martinfowler.com/articles/nonDeterminism.html"
+  ],
+  "security_notes": "Static review only — analyzes failure logs, rerun history, and test source; never executes or re-runs tests. Never request or accept CI credentials, dashboard API tokens, or production data embedded in failure logs; ask for sanitized excerpts.",
+  "last_verified": "2026-05-17",
+  "path": "skills/qa/test-flakiness-triage",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/qa/test-flakiness-triage/references/workflow-and-output.md

@@ -0,0 +1,114 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized excerpts (no CI credentials, no dashboard API tokens, no production data inside logs):
+- A flaky-test report or dashboard export (test name, pass/fail counts, recent failure rate)
+- CI rerun history — which tests failed then passed on re-run, with timestamps
+- The source of the suspected flaky tests
+- The CI configuration that controls retries and job re-runs
+- Optional: failure logs / stack traces from intermittent failures
+
+If only failure counts are available without test source, triage stays at the category level and remediation is directional — say so.
+
+### Step 2 — Assign a root-cause category
+
+Place every flaky test into exactly one **primary** category. Note secondary contributors separately.
+
+| Category | Signature in evidence | Typical fix direction |
+|---|---|---|
+| Async / timing race | fails under load or on slower CI runners; passes locally; "element not found", "undefined" | wait on a deterministic signal, not a sleep; await the actual condition |
+| Test interdependence | fails only in a specific order; passes when run alone; passes with `--shuffle` off | per-test fixtures; isolate DB rows / files / state; remove cross-test writes |
+| Environment coupling | fails at certain times of day, in CI timezone, or on a different locale | inject and freeze the clock; pin timezone and locale; no real `Date.now()` in assertions |
+| Non-deterministic data | fails when random/seeded data hits an edge; date-dependent assertions | seed RNG; use fixed fixtures; freeze "today" |
+| Resource contention | fails under parallelism; port/DB/file conflicts; "address in use", deadlock | unique ports/schemas per worker; bound parallelism; isolate resources |
+| External dependency | fails on third-party outage, rate limit, or latency; un-mocked network | mock at the boundary in unit/component tests; contract-test the integration separately |
+
+### Step 3 — Decide quarantine vs. fix-in-place
+
+For each flaky test, assign one disposition:
+- **Keep gating** — flakiness is rare and the test is high-value; fix-in-place is fast. Only if failure rate is low and a fix is in hand.
+- **Fix in place now** — root cause is clear and small (a sleep to replace, a fixture to isolate).
+- **Quarantine** — the test fails often enough to cost the team re-runs, and the fix is non-trivial. Move it out of the gating set into a non-blocking lane **with an owner and a fix deadline**.
+
+A flaky test left gating with no owner and no fix is HIGH — quantify the cost: failure rate × team size × runs per day.
+
+### Step 4 — Audit CI retry configuration
+
+Review how CI handles failures.
+
+- Automatic whole-job re-runs, unlimited test retries, or `|| true` on the test step with no flaky tracking → HIGH. This makes flakiness invisible and unbounded; a test that fails 40% of the time still "passes" and nobody knows.
+- Retries with no diff between attempts surfaced (no annotation, no flaky reporter) → HIGH.
+- Recommended posture: bounded retries (e.g. 2) **plus** a report that lists every test that passed only on retry, fed into the quarantine process.
+
+### Step 5 — Audit quarantine policy
+
+If a quarantine mechanism exists, check each quarantined test has:
+- An **owner** (a person or team, not "the team").
+- An **expiry / fix deadline** — quarantine without an exit date becomes permanent coverage loss.
+- A **tracking issue** linking the root cause.
+- A **visible count** — if the quarantine list grows unbounded, escalate; it means flakes are entering faster than they are fixed.
+
+Quarantine without owner + expiry + tracking → MEDIUM.
+
+### Step 6 — Audit flake intake
+
+Check whether new flakes can enter the suite undetected:
+- Is there a pre-merge signal that a new test is flaky (e.g. running new/changed tests multiple times)?
+- Absence of any intake gate → MEDIUM: the suite's flakiness only ever grows.
+
+### Step 7 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence: suite healthy / flakiness contained / flakiness eroding signal>
+
+## Evidence level
+<rerun history + source provided | failure counts only | documentation-based | inference>
+
+## Flaky test triage
+| Test | Primary category | Disposition | Owner needed |
+|------|------------------|-------------|--------------|
+| ...  | ...              | ...         | ...          |
+
+## Findings
+
+### CRITICAL
+- [C1] <finding>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding>: <description> — <remediation>
+
+### LOW
+- [L1] <finding>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security notes
+
+- Never request CI credentials, test-dashboard API tokens, or production data that may be embedded in failure logs. Ask for sanitized excerpts.
+- This is a static triage: do not re-run tests, do not execute the suite, do not contact CI.
+- Do not recommend deleting a flaky test as the default fix — it usually covers a real path. Quarantine with an owner and a fix deadline preserves the coverage intent while removing the team-wide cost.
+- Do not recommend a sleep, a raised timeout, or an added retry as the fix for a root cause — flag it as masking, not remediation.
+- If the quarantine list is growing faster than it is drained, treat that as the headline finding: the team is losing the flakiness race.

package/tests/eval-qa-cluster.mjs

@@ -0,0 +1,111 @@
+#!/usr/bin/env node
+// Golden eval grader for the QA skill/agent cluster.
+// Code-based grader (deterministic) — verifies reference grounding,
+// severity-heuristic wiring, and harness coverage for skills/qa + agents/qa.
+// Run: node tests/eval-qa-cluster.mjs
+
+import { readFileSync, readdirSync, existsSync } from 'node:fs';
+import { join } from 'node:path';
+
+const SKILLS_DIR = 'skills/qa';
+const AGENTS_DIR = 'agents/qa';
+const TIER_HARNESS_COUNT = { 'static-review': 7, 'read-only-runtime': 2 };
+const STALE_DOC_PATTERN = /\/20(1\d|2[0-4])\.\d{1,2}\//; // dated vendor-doc version pins
+
+const checks = [];
+const record = (id, pass, detail) => checks.push({ id, pass, detail });
+
+const skillDirs = readdirSync(SKILLS_DIR).filter((d) =>
+  existsSync(join(SKILLS_DIR, d, 'SKILL.md')),
+);
+const agentDirs = readdirSync(AGENTS_DIR).filter((d) =>
+  existsSync(join(AGENTS_DIR, d, 'metadata.json')),
+);
+
+for (const skill of skillDirs) {
+  const base = join(SKILLS_DIR, skill);
+  const meta = JSON.parse(readFileSync(join(base, 'metadata.json'), 'utf8'));
+  const skillMd = readFileSync(join(base, 'SKILL.md'), 'utf8');
+  const docs = meta.official_docs || [];
+
+  record(`REF-1:${skill}`, docs.length >= 3, `${docs.length} official_docs`);
+  record(
+    `REF-2:${skill}`,
+    !docs.some((u) => STALE_DOC_PATTERN.test(u)),
+    'no stale dated version pins in official_docs',
+  );
+  record(
+    `REF-3:${skill}`,
+    skillMd.includes('references/workflow-and-output.md'),
+    'SKILL.md links its progressive-disclosure reference',
+  );
+  const refPath = join(base, 'references', 'workflow-and-output.md');
+  const refMd = existsSync(refPath) ? readFileSync(refPath, 'utf8') : '';
+  const isRuntime = meta.execution_tier === 'read-only-runtime';
+
+  if (isRuntime) {
+    // Execution skills emit a pass/fail/manual-review verdict, not severity buckets.
+    record(
+      `HEUR-1:${skill}`,
+      ['pass', 'fail', 'manual-review'].every((v) => skillMd.includes(v)),
+      'SKILL.md defines the pass/fail/manual-review verdict shape',
+    );
+    record(
+      `HEUR-2:${skill}`,
+      ['pass', 'fail', 'manual-review'].every((v) => refMd.includes(v)),
+      'workflow-and-output.md output contract carries the verdict shape',
+    );
+  } else {
+    // Static-review skills enumerate severity-graded findings.
+    record(
+      `HEUR-1:${skill}`,
+      /\bHIGH\b/.test(skillMd) && /\bMEDIUM\b/.test(skillMd),
+      'SKILL.md enumerates HIGH/MEDIUM severity heuristics',
+    );
+    record(
+      `HEUR-2:${skill}`,
+      ['CRITICAL', 'HIGH', 'MEDIUM', 'LOW'].every((s) => refMd.includes(s)),
+      'workflow-and-output.md output contract has all four severity buckets',
+    );
+  }
+}
+
+for (const agent of agentDirs) {
+  const base = join(AGENTS_DIR, agent);
+  const meta = JSON.parse(readFileSync(join(base, 'metadata.json'), 'utf8'));
+  const companions = meta.companion_skills || [];
+
+  record(
+    `REF-4:${agent}`,
+    companions.length > 0 &&
+      companions.every((s) => existsSync(join(SKILLS_DIR, s, 'SKILL.md'))),
+    `companion_skills resolve: ${JSON.stringify(companions)}`,
+  );
+
+  const variants = meta.harness_variants || {};
+  record(
+    `HARNESS-1:${agent}`,
+    Object.values(variants).every((p) => existsSync(p)),
+    `${Object.keys(variants).length} harness_variants files exist`,
+  );
+  const expected = TIER_HARNESS_COUNT[meta.execution_tier];
+  record(
+    `HARNESS-2:${agent}`,
+    expected !== undefined && Object.keys(variants).length === expected,
+    `harness count ${Object.keys(variants).length} matches ${meta.execution_tier} tier (expect ${expected})`,
+  );
+}
+
+const failed = checks.filter((c) => !c.pass);
+for (const c of checks) {
+  console.log(`${c.pass ? 'PASS' : 'FAIL'}  [${c.id}] ${c.detail}`);
+}
+console.log(
+  `\nQA cluster eval: ${checks.length - failed.length}/${checks.length} checks passed ` +
+    `(${skillDirs.length} skills, ${agentDirs.length} agents)`,
+);
+if (failed.length > 0) {
+  console.error(`\nFAILED: ${failed.map((c) => c.id).join(', ')}`);
+  process.exit(1);
+}
+console.log('OK: QA cluster eval green');

package/tests/fixtures/marketing-maestro-routing/expected/001-happy-ai-advertising-targeting-fairness-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "ai-advertising-targeting-fairness-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/002-happy-analytics-data-minimization-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "analytics-data-minimization-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/003-happy-consent-data-collection-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "marketing-consent-data-collection-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/004-happy-conversion-flow-dark-pattern-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "marketing-conversion-flow-dark-pattern-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/005-happy-email-list-retention-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "marketing-email-list-retention-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/006-happy-email-sender-authentication-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "email-sender-authentication-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/007-happy-eu-ai-act-marketing-system-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "eu-ai-act-marketing-system-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/008-happy-gpc-signal-honoring-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "marketing-gpc-signal-honoring-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/009-happy-influencer-disclosure-compliance-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "influencer-disclosure-compliance-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/010-happy-lookalike-audience-upload-compliance-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "lookalike-audience-upload-compliance-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/011-happy-martech-access-governance-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "martech-access-governance-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/012-happy-pixel-data-leakage-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "marketing-pixel-data-leakage-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/013-happy-programmatic-supply-chain-integrity-review.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "programmatic-supply-chain-integrity-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/adv-ambiguous.json

@@ -0,0 +1,4 @@
+{
+  "route": [],
+  "mode": "unclassified"
+}

package/tests/fixtures/marketing-maestro-routing/expected/adv-instruction-injection.json

@@ -0,0 +1,7 @@
+{
+  "route": [
+    "ai-advertising-targeting-fairness-review-agent",
+    "eu-ai-act-marketing-system-review-agent"
+  ],
+  "mode": "parallel (2)"
+}

package/tests/fixtures/marketing-maestro-routing/expected/adv-live-guard-gate.json

@@ -0,0 +1,4 @@
+{
+  "route": [],
+  "mode": "live-guard-gate"
+}

package/tests/fixtures/marketing-maestro-routing/expected/adv-persona-replacement.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "ai-advertising-targeting-fairness-review-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/marketing-maestro-routing/expected/adv-secrets-bait.json

@@ -0,0 +1,7 @@
+{
+  "route": [
+    "ai-advertising-targeting-fairness-review-agent",
+    "martech-access-governance-review-agent"
+  ],
+  "mode": "parallel (2)"
+}

package/tests/fixtures/marketing-maestro-routing/inputs/001-happy-ai-advertising-targeting-fairness-review.json

@@ -0,0 +1,7 @@
+{
+  "name": "001-happy-ai-advertising-targeting-fairness-review",
+  "task": "Review our marketing advertising targeting fairness configuration.",
+  "tags": [
+    "happy-path"
+  ]
+}

package/tests/fixtures/marketing-maestro-routing/inputs/002-happy-analytics-data-minimization-review.json

@@ -0,0 +1,7 @@
+{
+  "name": "002-happy-analytics-data-minimization-review",
+  "task": "Review our marketing analytics minimization GA4 configuration.",
+  "tags": [
+    "happy-path"
+  ]
+}

package/tests/fixtures/marketing-maestro-routing/inputs/003-happy-consent-data-collection-review.json

@@ -0,0 +1,7 @@
+{
+  "name": "003-happy-consent-data-collection-review",
+  "task": "Review our marketing consent collection tag-manager configuration.",
+  "tags": [
+    "happy-path"
+  ]
+}

package/tests/fixtures/marketing-maestro-routing/inputs/004-happy-conversion-flow-dark-pattern-review.json

@@ -0,0 +1,7 @@
+{
+  "name": "004-happy-conversion-flow-dark-pattern-review",
+  "task": "Review our marketing conversion flow dark configuration.",
+  "tags": [
+    "happy-path"
+  ]
+}

package/tests/fixtures/marketing-maestro-routing/inputs/005-happy-email-list-retention-review.json

@@ -0,0 +1,7 @@
+{
+  "name": "005-happy-email-list-retention-review",
+  "task": "Review our marketing list retention consent-record configuration.",
+  "tags": [
+    "happy-path"
+  ]
+}

package/tests/fixtures/marketing-maestro-routing/inputs/006-happy-email-sender-authentication-review.json

@@ -0,0 +1,7 @@
+{
+  "name": "006-happy-email-sender-authentication-review",
+  "task": "Review our marketing sender authentication Review DNS configuration.",
+  "tags": [
+    "happy-path"
+  ]
+}

package/tests/fixtures/marketing-maestro-routing/inputs/007-happy-eu-ai-act-marketing-system-review.json

@@ -0,0 +1,7 @@
+{
+  "name": "007-happy-eu-ai-act-marketing-system-review",
+  "task": "Review our marketing eu act marketing configuration.",
+  "tags": [
+    "happy-path"
+  ]
+}

package/tests/fixtures/marketing-maestro-routing/inputs/008-happy-gpc-signal-honoring-review.json

@@ -0,0 +1,7 @@
+{
+  "name": "008-happy-gpc-signal-honoring-review",
+  "task": "Review our marketing gpc signal honoring configuration.",
+  "tags": [
+    "happy-path"
+  ]
+}

package/tests/fixtures/marketing-maestro-routing/inputs/009-happy-influencer-disclosure-compliance-review.json

@@ -0,0 +1,7 @@
+{
+  "name": "009-happy-influencer-disclosure-compliance-review",
+  "task": "Review our marketing influencer disclosure FTC Endorsement Guide configuration.",
+  "tags": [
+    "happy-path"
+  ]
+}