synapse-hub 2.2.4 → 2.4.1

package/.agents/rules/performance_testing_rules.md

@@ -0,0 +1,74 @@
+# Performance & Load Testing Invariants (k6 · JMeter · Locust)
+
+> **Scope:** Applies whenever designing, executing, or analyzing performance, load, stress, spike, or soak test workloads.  
+> These invariants complement `AGENTS.md` and enforce enterprise safety, workload realism, and zero-hallucination analysis.
+
+---
+
+## 1. Safety Gate & Approval Invariants (Mandatory Pre-Flight)
+
+1. **Explicit Authorization:**
+   - Execute load tests **only** against pre-approved, dedicated environments (performance test environment or isolated sandbox).
+   - **Strictly forbidden:** Running load tests against production, shared staging, public demo sites, or third-party APIs without formal written sign-off.
+2. **Pre-Run Declaration:**
+   - Prior to any execution above Smoke test, the agent must declare the run profile and wait for explicit confirmation:
+     - Target host and environment owner
+     - Test archetype (Smoke, Average Load, Stress, Spike, Soak)
+     - Load profile (max VUs, target iterations/sec or requests/sec, duration, ramp-up/down phases)
+     - Data volume created and teardown strategy
+     - Kill-switch threshold (`abortOnFail`)
+3. **Progressive Stepped Escalation:**
+   - Always adhere to progressive ramp-up: **Smoke (1–5 VUs) → Baseline Average Load → Stress / Spike / Soak**.
+   - Never initiate Stress, Spike, Soak, or Breakpoint runs autonomously.
+4. **Hard Caps & Kill-Switch:**
+   - Every script must enforce hard upper bounds on rate and VUs, finite duration, and an automatic abort condition (`abortOnFail` when error rate breaches acceptable thresholds, e.g., > 10%).
+   - Unbounded loops or infinite duration scripts are strictly prohibited.
+5. **Third-Party Isolation:**
+   - Mock or stub third-party external dependencies (Payment Gateways, SMS providers, email senders, CAPTCHA, web analytics). Never send synthetic load to unisolated external partners.
+6. **Data Safety & Idempotent Cleanup:**
+   - Write traffic must use isolated, synthetic test data with recognizable prefixes (e.g., `PERF_AUTO_`, `PERF-`). Real customer credentials or PII must never be used.
+   - Every creation run must be paired with an automated teardown or ephemeral DB rollback.
+
+---
+
+## 2. Workload Modeling Invariants
+
+1. **Open vs. Closed Model:**
+   - **Open Model (Arrival Rate):** Use arrival-rate executors for public web traffic or SLA requirements stated in rate (e.g., `N req/sec`). Real users arrive independently of system slowdown.
+   - **Closed Model (Virtual Users):** Use VU-based executors only when modeling fixed concurrent sessions (e.g., internal enterprise portals).
+2. **Realistic Think Time:**
+   - Model user think time between journey steps using realistic distributions (e.g., Gaussian or uniform 1s–5s). Zero-think-time "hammer" testing is forbidden unless specifically requested for denial-of-service resilience audits.
+3. **Data Realism & Cache Skew Prevention:**
+   - Parameterize query parameters, identifiers, and payloads across realistic key spaces. Repeatedly querying identical records measures database cache hit rates rather than true backend capability.
+4. **Phase-Based Evaluation:**
+   - Structure tests into `Ramp-Up`, `Steady State`, and `Ramp-Down` phases.
+   - Compute SLA thresholds and verdicts **strictly against the Steady State**, never against warm-up or cool-down transients.
+
+---
+
+## 3. k6 Script Engineering Standards
+
+1. **Script Structure:**
+   - `options` (profile, stages, thresholds) → `setup()` (one-time auth and shared state) → default function (user journey with `check()` calls) → `teardown()` (cleanup).
+2. **Valid Threshold Syntax:**
+   - Use standard k6 threshold syntax: `metric{tag:value}: ['p(95)<500']`. Braces contain tag filters only.
+   - Latency thresholds must evaluate successful responses: `'http_req_duration{expected_response:true}': ['p(95)<500', 'p(99)<1000']`.
+   - Always pair `check()` with a `checks` threshold (e.g., `'checks': ['rate>0.99']`), as unasserted check failures do not alter k6 exit codes.
+3. **Generator Efficiency:**
+   - Set `discardResponseBodies: true` when response bodies are not required for subsequent extractions, minimizing memory overhead on the load generator.
+4. **Strict Credential Hygiene:**
+   - Pass tokens, usernames, and base URLs via environment variables (`__ENV.BASE_URL`). Never hardcode secrets in test plans or committed repository scripts.
+
+---
+
+## 4. Truth Anchor & Performance Autopsy Protocol
+
+1. **No Lowering Thresholds (Truth Anchor):**
+   - If an SLA threshold is breached, report the failure with root causes. **Never loosen thresholds, truncate steady states, or drop samples to manufacture a false pass.**
+2. **Structured Analysis Sequence:**
+   - Analyze results in strict sequence:
+     1. **Run Validity:** Confirm `dropped_iterations == 0` and generator CPU remained < 80%. If the generator was saturated, mark the run INVALID.
+     2. **Error Rate:** Categorize HTTP 4xx, 5xx, timeouts, connection resets.
+     3. **Latency Percentiles:** Report P50, P90, P95, P99, and Max. Never headline average latency.
+     4. **Throughput:** Compare target requests/sec vs. achieved requests/sec.
+     5. **Correlation:** Correlate breaches with backend APM traces (database slow queries, GC pauses, connection pool exhaustion) before attributing root causes.

package/.agents/rules/systematic-debugging.md

@@ -31,7 +31,7 @@ This rule governs all AI Agents operating on the repository. It mandates strict
      ```bash
      python3 tools/verify_all.py
      ```
-   - All 8 Gates must return `PASS`. If any gate fails, the task is NOT complete.
+   - All 9 Gates must return `PASS`. If any gate fails, the task is NOT complete.
 2. **Targeted Re-Test:**
    - After modifying Page Classes, check impacted Test Cases with:
      ```bash
@@ -61,7 +61,7 @@ This rule governs all AI Agents operating on the repository. It mandates strict
 | **Dispatching Browser Actions (Live/CDP)** | `python3 tools/safety_firewall.py --dry-run` | Mandatory Pre-execution Hook: Block irreversible/destructive operations before browser dispatch. |
 | **Creating or updating Test Scripts** | `python3 tools/infer_linter.py` | Run AST scan for Fake-Pass (0 asserts) and empty catch blocks. |
 | **New/Modified Test Case Quality** | `python3 tools/micro_mutator.py --min-score 80` | AST Mutation Testing: Reject test suites with mutation score < 80%. |
-| **Before Git Commit or Completing Task** | `python3 tools/verify_all.py` | Validate all 8 Quality Gates DoD. |
+| **Before Git Commit or Completing Task** | `python3 tools/verify_all.py` | Validate all 9 Quality Gates DoD. |
 | **After modifying Page Classes** | `python3 tools/test_impact.py --git-diff` | Scope impacted test cases; avoid re-running entire test suites. |
 | **When Test FAILS in CLI/KRE** | `python3 tools/pinpoint_failure.py` | Parse JUnit XML to identify exact failing line and exception in 0.1s. |
 | **When CLI / Gradle logs are verbose** | `python3 tools/distill_log.py <log>` | Filter 95% noise; preserve only actionable stacktraces and pointers. |
@@ -81,10 +81,10 @@ This rule governs all AI Agents operating on the repository. It mandates strict
 
 ```markdown
 <reasoning_protocol>
-Step 1 - Boundary & Invariant Extraction: Xác định các bất biến (invariants) của hệ thống. Cái gì bắt buộc không bao giờ được phép xảy ra?
-Step 2 - Falsification Hypotheses (Phản đề Popper): Đưa ra 3 kịch bản lập trình viên có thể làm hàm chạy sai mà test thông thường vẫn pass (False Negatives).
-Step 3 - Self-Debate: Tự giải thích tại sao assertion chuẩn bị viết sẽ bắt chết cả 3 kịch bản phá hoại ở Step 2.
-Step 4 - Emit Code / Universal IR: Chỉ sinh code khi đã hoàn thành 3 bước trên.
+Step 1 - Boundary & Invariant Extraction: Define system invariants. What must strictly NEVER happen under any circumstances?
+Step 2 - Falsification Hypotheses (Popper's Falsification): Propose 3 realistic scenarios where a developer could break functionality while conventional tests still pass (False Negatives).
+Step 3 - Self-Debate: Explain why the proposed assertion will catch and fail all 3 destructive scenarios in Step 2.
+Step 4 - Emit Code / Universal IR: Only synthesize code once the 3 steps above are completed.
 </reasoning_protocol>
 ```
 

package/.agents/skills/agent-orchestration-multi-agent-optimize/SKILL.md

@@ -1,239 +1,88 @@
 ---
 name: agent-orchestration-multi-agent-optimize
-description: "Profile, benchmark, and orchestrate multi-agent test workloads and token throughput."
+description: "Profile, benchmark, and orchestrate multi-agent test workloads and token throughput. Use when orchestrating multi-agent swarms, partitioning workloads, or optimizing agent roles."
 ---
 
-# Multi-Agent Optimization Toolkit
+# Multi-Agent Optimization & Orchestration Skill
 
-## Use this skill when
+> **Target:** Optimize multi-agent test workloads, reduce context overhead, streamline agent handoffs, and monitor token consumption across autonomous test swarms.
 
-- Improving multi-agent coordination, throughput, or latency
-- Profiling agent workflows to identify bottlenecks
-- Designing orchestration strategies for complex workflows
-- Optimizing cost, context usage, or tool efficiency
-
-## Do not use this skill when
-
-- You only need to tune a single agent prompt
-- There are no measurable metrics or evaluation data
-- The task is unrelated to multi-agent orchestration
-
-## Instructions
-
-1. Establish baseline metrics and target performance goals.
-2. Profile agent workloads and identify coordination bottlenecks.
-3. Apply orchestration changes and cost controls incrementally.
-4. Validate improvements with repeatable tests and rollbacks.
-
-## Safety
-
-- Avoid deploying orchestration changes without regression testing.
-- Roll out changes gradually to prevent system-wide regressions.
-
-## Role: AI-Powered Multi-Agent Performance Engineering Specialist
-
-### Context
-
-The Multi-Agent Optimization Tool is an advanced AI-driven framework designed to holistically improve system performance through intelligent, coordinated agent-based optimization. Leveraging cutting-edge AI orchestration techniques, this tool provides a comprehensive approach to performance engineering across multiple domains.
-
-### Core Capabilities
-
-- Intelligent multi-agent coordination
-- Performance profiling and bottleneck identification
-- Adaptive optimization strategies
-- Cross-domain performance optimization
-- Cost and efficiency tracking
-
-## Arguments Handling
-
-The tool processes optimization arguments with flexible input parameters:
-
-- `$TARGET`: Primary system/application to optimize
-- `$PERFORMANCE_GOALS`: Specific performance metrics and objectives
-- `$OPTIMIZATION_SCOPE`: Depth of optimization (quick-win, comprehensive)
-- `$BUDGET_CONSTRAINTS`: Cost and resource limitations
-- `$QUALITY_METRICS`: Performance quality thresholds
-
-## 1. Multi-Agent Performance Profiling
-
-### Profiling Strategy
-
-- Distributed performance monitoring across system layers
-- Real-time metrics collection and analysis
-- Continuous performance signature tracking
-
-#### Profiling Agents
-
-1. **Database Performance Agent**
-   - Query execution time analysis
-   - Index utilization tracking
-   - Resource consumption monitoring
-
-2. **Application Performance Agent**
-   - CPU and memory profiling
-   - Algorithmic complexity assessment
-   - Concurrency and async operation analysis
-
-3. **Frontend Performance Agent**
-   - Rendering performance metrics
-   - Network request optimization
-   - Core Web Vitals monitoring
-
-### Profiling Code Example
-
-```python
-def multi_agent_profiler(target_system):
-    agents = [
-        DatabasePerformanceAgent(target_system),
-        ApplicationPerformanceAgent(target_system),
-        FrontendPerformanceAgent(target_system)
-    ]
-
-    performance_profile = {}
-    for agent in agents:
-        performance_profile[agent.__class__.__name__] = agent.profile()
-
-    return aggregate_performance_metrics(performance_profile)
-```
-
-## 2. Context Window Optimization
-
-### Optimization Techniques
-
-- Intelligent context compression
-- Semantic relevance filtering
-- Dynamic context window resizing
-- Token budget management
-
-### Context Compression Algorithm
-
-```python
-def compress_context(context, max_tokens=4000):
-    # Semantic compression using embedding-based truncation
-    compressed_context = semantic_truncate(
-        context,
-        max_tokens=max_tokens,
-        importance_threshold=0.7
-    )
-    return compressed_context
-```
-
-## 3. Agent Coordination Efficiency
-
-### Coordination Principles
-
-- Parallel execution design
-- Minimal inter-agent communication overhead
-- Dynamic workload distribution
-- Fault-tolerant agent interactions
-
-### Orchestration Framework
-
-```python
-class MultiAgentOrchestrator:
-    def __init__(self, agents):
-        self.agents = agents
-        self.execution_queue = PriorityQueue()
-        self.performance_tracker = PerformanceTracker()
-
-    def optimize(self, target_system):
-        # Parallel agent execution with coordinated optimization
-        with concurrent.futures.ThreadPoolExecutor() as executor:
-            futures = {
-                executor.submit(agent.optimize, target_system): agent
-                for agent in self.agents
-            }
-
-            for future in concurrent.futures.as_completed(futures):
-                agent = futures[future]
-                result = future.result()
-                self.performance_tracker.log(agent, result)
-```
+---
 
-## 4. Parallel Execution Optimization
+## 1. When to Use
 
-### Key Strategies
+- Managing multi-agent coordination, test suite sharding, and throughput.
+- Profiling sub-agent task decomposition to eliminate redundant execution.
+- Implementing dynamic model tiering (fast models for search, deep models for healing).
+- Budgeting context tokens across collaborative agent swarms.
 
-- Asynchronous agent processing
-- Workload partitioning
-- Dynamic resource allocation
-- Minimal blocking operations
+---
 
-## 5. Cost Optimization Strategies
+## 2. Core Orchestration Principles
 
-### LLM Cost Management
+1. **Single Front-Door Protocol:**
+   - All inbound tasks route through `orchestrator` to prevent split-brain execution.
+2. **Context Isolation (`Workspace: 'share'`):**
+   - Subagents run in isolated workspaces to avoid git index collisions and context pollution.
+3. **Observation Distillation:**
+   - Subagents return only 3-5 line summaries and pointers to logs on disk, never dumping thousands of stdout lines into the parent context.
+4. **Dynamic Model Routing:**
+   - Use lighter models (`flash`, `flash_lite`) for element exploration and log filtering.
+   - Use deeper models (`inherit`, `pro`) for root-cause synthesis and AST mutation testing.
 
-- Token usage tracking
-- Adaptive model selection
-- Caching and result reuse
-- Efficient prompt engineering
+---
 
-### Cost Tracking Example
+## 3. Workload Sharding & Matrix Execution
 
 ```python
-class CostOptimizer:
-    def __init__(self):
-        self.token_budget = 100000  # Monthly budget
-        self.token_usage = 0
-        self.model_costs = {  # USD per 1K input tokens
-            'gpt-5': 0.03,
-            'claude-sonnet-4-6': 0.003,
-            'claude-haiku-4-5': 0.001
-        }
-
-    def select_optimal_model(self, complexity):
-        # Dynamic model selection based on task complexity and budget
-        pass
+# Multi-agent workload partition example
+def shard_test_workload(suite_files: list, max_agents: int = 4) -> list:
+    """Partitions test cases across parallel subagents to minimize total execution wall-clock time."""
+    shards = [[] for _ in range(max_agents)]
+    for idx, test_file in enumerate(suite_files):
+        shards[idx % max_agents].append(test_file)
+    return [s for s in shards if s]
 ```
 
-## 6. Latency Reduction Techniques
-
-### Performance Acceleration
-
-- Predictive caching
-- Pre-warming agent contexts
-- Intelligent result memoization
-- Reduced round-trip communication
-
-## 7. Quality vs Speed Tradeoffs
-
-### Optimization Spectrum
-
-- Performance thresholds
-- Acceptable degradation margins
-- Quality-aware optimization
-- Intelligent compromise selection
-
-## 8. Monitoring and Continuous Improvement
-
-### Observability Framework
-
-- Real-time performance dashboards
-- Automated optimization feedback loops
-- Machine learning-driven improvement
-- Adaptive optimization strategies
-
-## Reference Workflows
+---
 
-### Workflow 1: E-Commerce Platform Optimization
+## 4. Token & Latency Governance
 
-1. Initial performance profiling
-2. Agent-based optimization
-3. Cost and performance tracking
-4. Continuous improvement cycle
+| Optimization Layer | Baseline (Naive) | Optimized (Synapse Swarm) | Savings |
+| :--- | :--- | :--- | :--- |
+| **CLI Log Output** | Dump 3,000 lines | `tools/distill_log.py` (< 50 tokens) | **95%** |
+| **Codebase Reading** | Read whole classes | `tools/repo_map.txt` (< 600 tokens) | **90%** |
+| **Failure Resolution**| Multiple prompt loops | SQLite cache lookup (< 0.1s) | **> 90%** |
+| **DOM Inspection** | Raw HTML DOM | Compact AOM (< 500 tokens) | **90%** |
 
-### Workflow 2: Enterprise API Performance Enhancement
+---
 
-1. Comprehensive system analysis
-2. Multi-layered agent optimization
-3. Iterative performance refinement
-4. Cost-efficient scaling strategy
+## 5. Verification & Safety Guidelines
 
-## Key Considerations
+- Always establish baseline metrics before applying workflow changes.
+- Ensure subagent dynamic test data uses unique runtime IDs (`AUTO_<timestamp>_<agentId>`).
+- Enforce automated teardown for all creation actions dispatched by subagents.
 
-- Always measure before and after optimization
-- Maintain system stability during optimization
-- Balance performance gains with resource consumption
-- Implement gradual, reversible changes
+---
 
-Target Optimization: $ARGUMENTS
+## 6. Hierarchical Process & Manager Delegation
+
+> *Borrowed and adapted from the crewAI hierarchical process model (MIT license, crewAIInc/crewAI).*
+
+The hub's default is a flat swarm with the `orchestrator` as single front-door
+(Section 2). For tasks too large for one dispatch round, escalate to a
+**hierarchical process**:
+
+1. **Manager delegation** — the orchestrator becomes a manager: it decomposes
+   the goal, assigns one bounded sub-task per specialist (`live-explorer`,
+   `pom-crafter`, `test-runner`, `failure-analyst`), and validates each result
+   before assigning the next. Workers never talk sideways; all coordination
+   flows through the manager.
+2. **Bounded delegation depth** — max 2 levels (orchestrator → specialist →
+   sub-task). Deeper recursion hides cost and breaks the token budget.
+3. **Validation gates between hops** — a manager accepts a sub-task result
+   only when it passes its stage gate (e.g. Stage 1 Data Contract JSON is
+   schema-valid); rejected results are retried once, then escalated.
+4. **Escalate structure, not authority** — the hierarchy speeds coordination;
+   Truth Anchor, safety firewall and quality gates apply identically at every
+   level. Delegation never bypasses a gate.

package/.agents/skills/agent-orchestration-multi-agent-optimize/examples/swarm_workload_config.json

@@ -0,0 +1,12 @@
+{
+  "swarm": "LeadQAOrchestrator",
+  "subagents": [
+    "live-explorer",
+    "pom-crafter",
+    "test-runner",
+    "failure-analyst",
+    "quality-gatekeeper"
+  ],
+  "tokenBudgetPerAgent": 1200,
+  "concurrency": 3
+}

package/.agents/skills/antigravity-test-sentinel/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: antigravity-test-sentinel
-description: "Enforce verification-first discipline: blocks task completion until tests and quality gates pass."
+description: "Enforce verification-first discipline: blocks task completion until tests and quality gates pass. Use when enforcing Definition-of-Done quality gates before completing a code or test task."
 ---
 
 # Antigravity Test Sentinel — Verification-First Gatekeeper
@@ -41,7 +41,7 @@ flowchart TD
 1. **Step 1: Execute Runner Command:**
    - Run the targeted test case or test suite via headless CLI runner or verification gate:
      ```bash
-     python3 tools/verify_all.py
+     synapse verify
      ```
 2. **Step 2: Inspect Exit Code:**
    - If the process terminates with exit code != 0, the task is **LOCKED**.
@@ -50,7 +50,7 @@ flowchart TD
    - The Agent must parse the exact error exception and stack trace from the failure output.
    - Apply targeted in-place healing and re-execute.
 4. **Step 4: Definition of Done Verification:**
-   - Run `python3 tools/verify_all.py` to confirm all 6 quality gates pass.
+   - Run `synapse verify` to confirm all 6 quality gates pass.
 
 ---
 

package/.agents/skills/antigravity-test-sentinel/examples/dod_gate_policy.json

@@ -0,0 +1,11 @@
+{
+  "policyName": "Enterprise-DoD-Gate-0-to-8",
+  "enforceGates": [
+    "Gate-0-Integrity",
+    "Gate-1-UTF8-NoBOM",
+    "Gate-3-CleanPOM",
+    "Gate-7-InferLinter",
+    "Gate-8-MicroMutator"
+  ],
+  "minMutationScore": 80.0
+}

package/.agents/skills/api-network-mocking-interception/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: api-network-mocking-interception
-description: "Intercept HTTP/GraphQL traffic, stub routes, and simulate chaos network failures."
+description: "Intercept HTTP/GraphQL traffic, stub routes, and simulate chaos network failures. Use when stubbing, mocking, or intercepting network calls during UI or API tests."
 ---
 
 # API Network Mocking, Interception & Resilience Skill

package/.agents/skills/api-network-mocking-interception/examples/network_route_stub.json

@@ -0,0 +1,9 @@
+{
+  "route": "**/api/v1/checkout",
+  "method": "POST",
+  "status": 200,
+  "response": {
+    "orderId": "ORD-AUTO-998822",
+    "status": "CONFIRMED"
+  }
+}

package/.agents/skills/api-spec-to-e2e-matrix/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: api-spec-to-e2e-matrix
-description: "Generate automated positive, boundary, and negative test matrices from OpenAPI specifications."
+description: "Generate automated positive, boundary, and negative test matrices from OpenAPI specifications. Use when converting an OpenAPI/Swagger spec into an end-to-end test matrix."
 ---
 
-# API Spec to E2E Matrix — Contract-Based Test Generator
+# API Spec to E2E Matrix — Contract-Based Test Generator
 
 This skill converts OpenAPI / Swagger specifications, JSON Schemas, or REST endpoint contracts into a structured, executable End-to-End (E2E) testing matrix covering happy path, boundary values, and negative error scenarios.
 
@@ -14,9 +14,9 @@ This skill converts OpenAPI / Swagger specifications, JSON Schemas, or REST endp
 ```mermaid
 flowchart TD
     Spec["OpenAPI / Swagger / JSON Schema"] --> Parse["Extract Endpoint Contracts"]
-    Parse --> Pos["1. Positive Happy Path<br/>• Valid payload<br/>• HTTP 200/201<br/>• Response schema match"]
-    Parse --> Bound["2. Boundary Value Analysis<br/>• Min/Max string length<br/>• Zero, negative numbers<br/>• Unicode & special chars"]
-    Parse --> Neg["3. Negative & Fault Scenarios<br/>• Missing required fields (400)<br/>• Invalid auth token (401/403)<br/>• Malformed payload (422)"]
+    Parse --> Pos["1. Positive Happy Path<br/>• Valid payload<br/>• HTTP 200/201<br/>• Response schema match"]
+    Parse --> Bound["2. Boundary Value Analysis<br/>• Min/Max string length<br/>• Zero, negative numbers<br/>• Unicode & special chars"]
+    Parse --> Neg["3. Negative & Fault Scenarios<br/>• Missing required fields (400)<br/>• Invalid auth token (401/403)<br/>• Malformed payload (422)"]
 
     Pos & Bound & Neg --> Suite["Executable Test Suite"]
 ```
@@ -44,7 +44,7 @@ Every negative test case must assert two distinct layers:
    - Verify HTTP Status Code is appropriately 400, 401, 403, 404, or 422.
    - Verify error payload contains expected error codes and localization messages.
 2. **UI / Toast Notification Layer Assertion:**
-   - Verify that the web UI displays the appropriate red toast notification (e.g. *"Dữ liệu không hợp lệ"* or *"Mã đã tồn tại"*).
+   - Verify that the web UI displays the appropriate red toast notification (e.g. *"Dữ liệu không hợp lệ"* or *"Mã đã tồn tại"*).
    - Verify that the form remains open and input fields preserve user state without losing entered data.
 
 ---
@@ -62,13 +62,13 @@ Agent can automatically invoke `tools/generate_api_matrix.py` and `tools/export_
 
 ```bash
 # 1. Generate Markdown matrix
-python tools/generate_api_matrix.py --spec path/to/openapi.json --format md -o docs/api_matrix.md
+python3 tools/generate_api_matrix.py --spec path/to/openapi.json --format md -o docs/api_matrix.md
 
 # 2. Generate JSON matrix for programmatic ingestion
-python tools/generate_api_matrix.py --spec path/to/openapi.json --format json -o tools/api_matrix.json
+python3 tools/generate_api_matrix.py --spec path/to/openapi.json --format json -o tools/api_matrix.json
 
 # 3. Export directly to Postman Collection v2.1.0 with AJV JSON Schema & DDT
-python tools/export_postman_collection.py --spec path/to/openapi.json -o postman_collection.json --env-output postman_env.json --ddt-output test_data.csv
+synapse export-postman --spec path/to/openapi.json -o postman_collection.json --env-output postman_env.json --ddt-output test_data.csv
 
 # 4. Zero-Input Autonomous Synthesis (No input file provided!)
 agent-qa export-postman --domain banking -o banking_col.json --env-output env.json --ddt-output ddt.csv

package/.agents/skills/api-spec-to-e2e-matrix/examples/sample_openapi.json

@@ -0,0 +1,19 @@
+{
+  "openapi": "3.0.0",
+  "info": {
+    "title": "Payment API",
+    "version": "1.0.0"
+  },
+  "paths": {
+    "/payments": {
+      "post": {
+        "summary": "Create payment",
+        "responses": {
+          "201": {
+            "description": "Created"
+          }
+        }
+      }
+    }
+  }
+}