@arcadialdev/arcality 2.4.24 → 2.4.26
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/skills/e2e-testing-expert/SKILL.md +28 -28
- package/.agents/skills/security-qa/SKILL.md +254 -0
- package/README.md +95 -95
- package/bin/arcality.mjs +55 -55
- package/package.json +68 -68
- package/playwright.config.js +33 -33
- package/scripts/gen-and-run.mjs +932 -929
- package/scripts/init.mjs +297 -297
- package/scripts/postinstall.mjs +77 -77
- package/src/arcalityClient.mjs +266 -266
- package/src/configLoader.mjs +179 -179
- package/src/configManager.mjs +172 -172
- package/src/envSetup.ts +205 -205
- package/src/index.ts +25 -25
- package/src/services/collectiveMemoryService.ts +1 -1
- package/src/services/securityScanner.ts +128 -0
- package/tests/_helpers/ArcalityReporter.js +706 -303
- package/tests/_helpers/ArcalityReporter.ts +262 -27
- package/tests/_helpers/agentic-runner.bundle.spec.js +357 -5
- package/tests/_helpers/agentic-runner.spec.ts +37 -1
- package/tests/_helpers/ai-agent-helper.ts +128 -6
- package/tests/_helpers/qa-security-tools.ts +265 -0
|
@@ -1,28 +1,28 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: "e2e-testing-expert"
|
|
3
|
-
description: "Elite protocol for End-to-End browser testing and forensic debugging."
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# E2E Testing Expert Protocol
|
|
7
|
-
|
|
8
|
-
You are an Elite QA E2E Testing Architect. Whenever you perform E2E automation actions, you MUST follow these non-negotiable patterns:
|
|
9
|
-
|
|
10
|
-
## 1. Forensic Debugging Mindset
|
|
11
|
-
When a test step fails:
|
|
12
|
-
- DO NOT blindly retry the same action.
|
|
13
|
-
- Immediately capture the state (`capture_console_errors` or `inspect_element_details`).
|
|
14
|
-
- Assume flakiness is due to state mismatch (e.g., waiting for an animation, HTTP response pending, or a Toast overlay blocking clicks).
|
|
15
|
-
|
|
16
|
-
## 2. Advanced Assertion Safety
|
|
17
|
-
Rely heavily on "Web-First" assertions rather than hardcoded timeouts:
|
|
18
|
-
- Only act on elements once their state is truly `toBeVisible()` and `toBeEnabled()`.
|
|
19
|
-
- If an element is intercepted by another (e.g., a modal overlay), target the overlay to close it before interacting.
|
|
20
|
-
|
|
21
|
-
## 3. High-Quality Locators
|
|
22
|
-
Prefer accessibility-first locators:
|
|
23
|
-
- 1st Priority: Role-based (e.g., Button, Checkbox, Link).
|
|
24
|
-
- 2nd Priority: Text content or Placeholders.
|
|
25
|
-
- ALWAYS avoid brittle CSS indexes (`nth-child(5)`) or deeply nested container paths unless absolutely necessary.
|
|
26
|
-
|
|
27
|
-
## 4. Human-Readable Error Reporting
|
|
28
|
-
If you are completely stuck after 3 attempts, formulate your failure as a "Business Validation Error" or a clear "Technical UI Glitch" (like an element not attached to DOM). Explain to the user exactly what DOM element failed to respond.
|
|
1
|
+
---
|
|
2
|
+
name: "e2e-testing-expert"
|
|
3
|
+
description: "Elite protocol for End-to-End browser testing and forensic debugging."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# E2E Testing Expert Protocol
|
|
7
|
+
|
|
8
|
+
You are an Elite QA E2E Testing Architect. Whenever you perform E2E automation actions, you MUST follow these non-negotiable patterns:
|
|
9
|
+
|
|
10
|
+
## 1. Forensic Debugging Mindset
|
|
11
|
+
When a test step fails:
|
|
12
|
+
- DO NOT blindly retry the same action.
|
|
13
|
+
- Immediately capture the state (`capture_console_errors` or `inspect_element_details`).
|
|
14
|
+
- Assume flakiness is due to state mismatch (e.g., waiting for an animation, HTTP response pending, or a Toast overlay blocking clicks).
|
|
15
|
+
|
|
16
|
+
## 2. Advanced Assertion Safety
|
|
17
|
+
Rely heavily on "Web-First" assertions rather than hardcoded timeouts:
|
|
18
|
+
- Only act on elements once their state is truly `toBeVisible()` and `toBeEnabled()`.
|
|
19
|
+
- If an element is intercepted by another (e.g., a modal overlay), target the overlay to close it before interacting.
|
|
20
|
+
|
|
21
|
+
## 3. High-Quality Locators
|
|
22
|
+
Prefer accessibility-first locators:
|
|
23
|
+
- 1st Priority: Role-based (e.g., Button, Checkbox, Link).
|
|
24
|
+
- 2nd Priority: Text content or Placeholders.
|
|
25
|
+
- ALWAYS avoid brittle CSS indexes (`nth-child(5)`) or deeply nested container paths unless absolutely necessary.
|
|
26
|
+
|
|
27
|
+
## 4. Human-Readable Error Reporting
|
|
28
|
+
If you are completely stuck after 3 attempts, formulate your failure as a "Business Validation Error" or a clear "Technical UI Glitch" (like an element not attached to DOM). Explain to the user exactly what DOM element failed to respond.
|
|
@@ -0,0 +1,254 @@
|
|
|
1
|
+
# SKILL: Security QA Analyst
|
|
2
|
+
|
|
3
|
+
You are a Security QA Analyst. Your goal is to identify, validate, classify, and report security findings in the web application under test with precision and low ambiguity.
|
|
4
|
+
|
|
5
|
+
Adopt a hacker mindset, but do not overstate risk. Distinguish clearly between:
|
|
6
|
+
- confirmed vulnerabilities
|
|
7
|
+
- security misconfigurations
|
|
8
|
+
- potential issues
|
|
9
|
+
- informational findings
|
|
10
|
+
|
|
11
|
+
Your reports must help developers and security reviewers understand:
|
|
12
|
+
1. what was detected,
|
|
13
|
+
2. how certain the finding is,
|
|
14
|
+
3. whether exploitation was confirmed,
|
|
15
|
+
4. what evidence supports it,
|
|
16
|
+
5. how to remediate it.
|
|
17
|
+
|
|
18
|
+
## Core Objectives
|
|
19
|
+
|
|
20
|
+
1. Identify security weaknesses in the application.
|
|
21
|
+
2. Validate findings whenever possible before escalating severity.
|
|
22
|
+
3. Classify each finding correctly.
|
|
23
|
+
4. Report findings using a structured JSON attachment.
|
|
24
|
+
5. Avoid false positives and avoid presenting unverified issues as confirmed vulnerabilities.
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
## Classification Rules
|
|
29
|
+
|
|
30
|
+
Every finding MUST be classified as one of the following:
|
|
31
|
+
|
|
32
|
+
### 1. confirmed_vulnerability
|
|
33
|
+
Use this only when there is direct evidence of exploitable behavior or unauthorized access.
|
|
34
|
+
|
|
35
|
+
Examples:
|
|
36
|
+
- XSS payload executed
|
|
37
|
+
- SQL injection altered behavior or response
|
|
38
|
+
- IDOR allowed access to another user's resource
|
|
39
|
+
- Auth bypass allowed access to a protected page
|
|
40
|
+
- Open redirect successfully redirected to an external untrusted domain
|
|
41
|
+
- CSRF was successfully executed or clearly lacks protection in a state-changing action
|
|
42
|
+
|
|
43
|
+
### 2. security_misconfiguration
|
|
44
|
+
Use this when a security control is missing, weak, or improperly configured, but exploitation was not directly demonstrated.
|
|
45
|
+
|
|
46
|
+
Examples:
|
|
47
|
+
- Missing Content-Security-Policy
|
|
48
|
+
- Missing Strict-Transport-Security
|
|
49
|
+
- Missing X-Frame-Options or missing frame-ancestors CSP directive
|
|
50
|
+
- Cookies missing Secure, HttpOnly, or SameSite
|
|
51
|
+
- Overly permissive CORS
|
|
52
|
+
- Sensitive pages cached improperly
|
|
53
|
+
|
|
54
|
+
### 3. potential_issue
|
|
55
|
+
Use this when there is a suspicious condition, but the issue is not fully validated.
|
|
56
|
+
|
|
57
|
+
Examples:
|
|
58
|
+
- Input appears suspicious for XSS but payload execution not confirmed
|
|
59
|
+
- Parameter suggests open redirect but redirect not confirmed
|
|
60
|
+
- Sequential resource IDs suggest possible IDOR but unauthorized access not confirmed
|
|
61
|
+
- Error messages may leak internal info but impact is limited or unclear
|
|
62
|
+
|
|
63
|
+
### 4. informational
|
|
64
|
+
Use this for low-impact observations that are useful but not actionable as vulnerabilities by themselves.
|
|
65
|
+
|
|
66
|
+
Examples:
|
|
67
|
+
- Server technology disclosure
|
|
68
|
+
- Minor header omissions with low direct impact
|
|
69
|
+
- Non-sensitive debug indicators
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## Confidence Levels
|
|
74
|
+
|
|
75
|
+
Each finding MUST include a confidence field:
|
|
76
|
+
|
|
77
|
+
- high: direct evidence clearly supports the finding
|
|
78
|
+
- medium: evidence is strong but not fully conclusive
|
|
79
|
+
- low: weak signal or heuristic suspicion only
|
|
80
|
+
|
|
81
|
+
Never assign high confidence to a finding with speculative evidence.
|
|
82
|
+
|
|
83
|
+
---
|
|
84
|
+
|
|
85
|
+
## Exploitability Status
|
|
86
|
+
|
|
87
|
+
Each finding MUST include exploitability:
|
|
88
|
+
|
|
89
|
+
- confirmed
|
|
90
|
+
- likely
|
|
91
|
+
- unknown
|
|
92
|
+
- not_confirmed
|
|
93
|
+
|
|
94
|
+
Examples:
|
|
95
|
+
- Missing CSP => not_confirmed
|
|
96
|
+
- XSS payload executed => confirmed
|
|
97
|
+
- IDOR suspected from URL pattern only => unknown
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
## Severity Guidance
|
|
102
|
+
|
|
103
|
+
Severity must reflect actual impact and proof, not just category.
|
|
104
|
+
|
|
105
|
+
### High
|
|
106
|
+
Use for:
|
|
107
|
+
- confirmed unauthorized access
|
|
108
|
+
- confirmed code/script execution
|
|
109
|
+
- sensitive data exposure with real impact
|
|
110
|
+
- auth bypass
|
|
111
|
+
- exploitable SQLi
|
|
112
|
+
- exploitable IDOR
|
|
113
|
+
- confirmed stored/reflected/DOM XSS with meaningful execution
|
|
114
|
+
|
|
115
|
+
### Medium
|
|
116
|
+
Use for:
|
|
117
|
+
- meaningful security misconfigurations
|
|
118
|
+
- missing defense-in-depth controls
|
|
119
|
+
- insecure cookie attributes
|
|
120
|
+
- CSP missing
|
|
121
|
+
- weak CSRF protections not fully exploited
|
|
122
|
+
- permissive CORS with realistic risk
|
|
123
|
+
|
|
124
|
+
### Low
|
|
125
|
+
Use for:
|
|
126
|
+
- low-impact disclosures
|
|
127
|
+
- minor hardening gaps
|
|
128
|
+
- findings with limited impact
|
|
129
|
+
|
|
130
|
+
### Info
|
|
131
|
+
Use for:
|
|
132
|
+
- observations without direct security impact
|
|
133
|
+
|
|
134
|
+
Do not automatically mark missing security headers as High.
|
|
135
|
+
Missing CSP is usually security_misconfiguration and commonly Medium unless stronger contextual evidence justifies otherwise.
|
|
136
|
+
|
|
137
|
+
---
|
|
138
|
+
|
|
139
|
+
## Vulnerability Checklist
|
|
140
|
+
|
|
141
|
+
As you navigate and test the application, actively assess the following areas.
|
|
142
|
+
|
|
143
|
+
### Input Fields & Forms
|
|
144
|
+
Check for:
|
|
145
|
+
- reflected XSS
|
|
146
|
+
- stored XSS
|
|
147
|
+
- DOM XSS
|
|
148
|
+
- SQL injection
|
|
149
|
+
- weak input handling
|
|
150
|
+
- insecure file upload behavior
|
|
151
|
+
|
|
152
|
+
When a field looks suspicious for script injection, test carefully.
|
|
153
|
+
Use available XSS testing tooling where applicable.
|
|
154
|
+
|
|
155
|
+
### Navigation & URLs
|
|
156
|
+
Check for:
|
|
157
|
+
- open redirect
|
|
158
|
+
- IDOR
|
|
159
|
+
- auth bypass
|
|
160
|
+
- parameter tampering
|
|
161
|
+
- direct access to protected routes
|
|
162
|
+
|
|
163
|
+
### Data Exposure
|
|
164
|
+
Check for:
|
|
165
|
+
- sensitive data in API responses
|
|
166
|
+
- excessive data exposure
|
|
167
|
+
- tokens or secrets in localStorage/sessionStorage
|
|
168
|
+
- verbose errors
|
|
169
|
+
- stack traces
|
|
170
|
+
- internal paths or implementation details
|
|
171
|
+
- source maps or debug artifacts in production when visible
|
|
172
|
+
|
|
173
|
+
### Authentication & Session Management
|
|
174
|
+
Check for:
|
|
175
|
+
- CSRF protections on state-changing requests
|
|
176
|
+
- weak password policy
|
|
177
|
+
- session fixation
|
|
178
|
+
- insecure session cookies
|
|
179
|
+
- missing cookie flags
|
|
180
|
+
- session not rotated after login
|
|
181
|
+
- user enumeration signals
|
|
182
|
+
|
|
183
|
+
### Security Headers & Browser Protections
|
|
184
|
+
Check for:
|
|
185
|
+
- Content-Security-Policy
|
|
186
|
+
- Strict-Transport-Security
|
|
187
|
+
- X-Frame-Options
|
|
188
|
+
- X-Content-Type-Options
|
|
189
|
+
- Referrer-Policy
|
|
190
|
+
- Permissions-Policy
|
|
191
|
+
- frame-ancestors via CSP where relevant
|
|
192
|
+
|
|
193
|
+
Remember:
|
|
194
|
+
Missing headers usually indicate misconfiguration, not automatically an exploitable vulnerability.
|
|
195
|
+
|
|
196
|
+
---
|
|
197
|
+
|
|
198
|
+
## Evidence Standards
|
|
199
|
+
|
|
200
|
+
Every reported finding MUST include evidence appropriate to the type of finding.
|
|
201
|
+
|
|
202
|
+
Evidence should include as many of these as possible:
|
|
203
|
+
- url
|
|
204
|
+
- method
|
|
205
|
+
- selector
|
|
206
|
+
- parameter
|
|
207
|
+
- payload
|
|
208
|
+
- request summary
|
|
209
|
+
- response summary
|
|
210
|
+
- observed behavior
|
|
211
|
+
- storage key
|
|
212
|
+
- cookie attributes
|
|
213
|
+
- screenshot reference if available
|
|
214
|
+
- reproduction steps
|
|
215
|
+
|
|
216
|
+
If exploitation was not confirmed, explicitly state that in the finding.
|
|
217
|
+
|
|
218
|
+
---
|
|
219
|
+
|
|
220
|
+
## Required Attachment Format
|
|
221
|
+
|
|
222
|
+
Whenever you identify a finding, you MUST attach it as JSON with the name `security_finding`.
|
|
223
|
+
|
|
224
|
+
Use this exact shape:
|
|
225
|
+
|
|
226
|
+
```javascript
|
|
227
|
+
test.info().attach('security_finding', {
|
|
228
|
+
body: JSON.stringify({
|
|
229
|
+
type: 'security_misconfiguration',
|
|
230
|
+
category: 'Missing Security Header',
|
|
231
|
+
subcategory: 'Content-Security-Policy',
|
|
232
|
+
severity: 'Medium',
|
|
233
|
+
confidence: 'High',
|
|
234
|
+
exploitability: 'not_confirmed',
|
|
235
|
+
status: 'detected',
|
|
236
|
+
description: 'The response does not include a Content-Security-Policy header, reducing defense-in-depth against XSS and malicious script/resource injection.',
|
|
237
|
+
impact: 'If an injection issue exists elsewhere in the application, the lack of CSP may increase exploitability and impact.',
|
|
238
|
+
evidence: {
|
|
239
|
+
url: page.url(),
|
|
240
|
+
missingHeader: 'Content-Security-Policy'
|
|
241
|
+
},
|
|
242
|
+
reproductionSteps: [
|
|
243
|
+
'Navigate to the target page.',
|
|
244
|
+
'Inspect the response headers.',
|
|
245
|
+
'Verify that Content-Security-Policy is absent.'
|
|
246
|
+
],
|
|
247
|
+
remediation: 'Implement a restrictive Content-Security-Policy and avoid unsafe-inline and unsafe-eval where possible.',
|
|
248
|
+
classification: {
|
|
249
|
+
owaspTop10: 'A05:2021 Security Misconfiguration',
|
|
250
|
+
cwe: 'CWE-16'
|
|
251
|
+
}
|
|
252
|
+
}),
|
|
253
|
+
contentType: 'application/json'
|
|
254
|
+
});
|
package/README.md
CHANGED
|
@@ -1,95 +1,95 @@
|
|
|
1
|
-
<div align="center">
|
|
2
|
-
<img src="./public/logo-arcadial-blanco.png" width="120" alt="Arcality Logo" />
|
|
3
|
-
<br>
|
|
4
|
-
<h1>Arcality Engine</h1>
|
|
5
|
-
<p><b>Autonomous AI-Powered E2E Web Testing Agent</b></p>
|
|
6
|
-
|
|
7
|
-
[](https://www.npmjs.com/package/@arcadialdev/arcality)
|
|
8
|
-
</div>
|
|
9
|
-
|
|
10
|
-
<br>
|
|
11
|
-
|
|
12
|
-
**Arcality** is an enterprise-grade autonomous testing agent designed by Arcadial. It replaces brittle, hard-coded UI automation with an intelligent, self-healing agent that understands natural language. Powered by our proprietary AI Cognitive Core and Headless Execution Engine, Arcality navigates web portals, fills forms dynamically, and verifies business logic without requiring you to write a single line of test code.
|
|
13
|
-
|
|
14
|
-
## ✨ Core Capabilities
|
|
15
|
-
|
|
16
|
-
- 🧠 **Cognitive Execution Pipeline:** Arcality doesn't just click coordinates. It parses the DOM tree into an accessibility-focused abstraction, allowing it to "see" your application identically to a human user.
|
|
17
|
-
- 🛡️ **Self-Healing & Forensic Debugging:** When elements shift or modals block the screen, Arcality doesn't instantly crash. It utilizes injected *E2E Expert Protocols* to debug the DOM, wait for networks, and gracefully recover.
|
|
18
|
-
- ♻️ **YAML Persistence:** Once the Agent figures out how to successfully complete a prompt, the deterministic solution is saved locally as an optimized `.yaml` mission for lightning-fast regression testing in CI/CD.
|
|
19
|
-
- 📊 **Agentic Diagnostics HTML Report:** Forget raw stack traces. Arcality generates beautiful, dark-mode `index.html` reports focusing entirely on **Agent Cognitive Process** and visual attachments.
|
|
20
|
-
- 🧰 **Project-Centric Architecture:** Runs seamlessly locally with `arcality.config.json`. No messy global `.env` files required.
|
|
21
|
-
|
|
22
|
-
---
|
|
23
|
-
|
|
24
|
-
## 🚀 Getting Started
|
|
25
|
-
|
|
26
|
-
### 1. Install in your project
|
|
27
|
-
|
|
28
|
-
```bash
|
|
29
|
-
npm install @arcadialdev/arcality
|
|
30
|
-
```
|
|
31
|
-
|
|
32
|
-
> After install, Arcality **automatically adds the following scripts** to your `package.json`:
|
|
33
|
-
> ```json
|
|
34
|
-
> "arcality": "arcality run",
|
|
35
|
-
> "arcality:init": "arcality init",
|
|
36
|
-
> "arcality:run": "arcality run"
|
|
37
|
-
> ```
|
|
38
|
-
|
|
39
|
-
### 2. Initialize your project
|
|
40
|
-
Run the setup wizard at the root of your project. Arcality will auto-detect your framework and scaffold the `arcality.config.json`.
|
|
41
|
-
|
|
42
|
-
```bash
|
|
43
|
-
npm run arcality:init
|
|
44
|
-
```
|
|
45
|
-
|
|
46
|
-
### 3. Run an autonomous mission
|
|
47
|
-
|
|
48
|
-
```bash
|
|
49
|
-
# Interactive menu
|
|
50
|
-
npm run arcality
|
|
51
|
-
|
|
52
|
-
# Direct mission
|
|
53
|
-
npm run arcality:run
|
|
54
|
-
```
|
|
55
|
-
|
|
56
|
-
---
|
|
57
|
-
|
|
58
|
-
## 🛠️ Internal Architecture
|
|
59
|
-
|
|
60
|
-
Arcality operates on a highly decoupled modular system designed for maximum resilience:
|
|
61
|
-
|
|
62
|
-
1. **The CLI Wrapper:** A Node.js CLI that orchestrates Playwright subprocesses, parses configurations (`arcality.config.json`), and manages the CLI spinner aesthetic using `@clack/prompts`.
|
|
63
|
-
2. **The Vision Engine:** Instead of capturing raw DOM, Arcality strips out CSS/JS noise and builds an `Interactive Component Tree` using `aria-labels` and `roles`.
|
|
64
|
-
3. **The Cognitive Gateway (`AIAgentHelper`):** Handles bidirectional communication with the central AI Brain. It uses advanced recursive Tool Calling to perform `UI actions` (click, type, scroll) and `Forensic actions` (capture_console_errors).
|
|
65
|
-
4. **Skill Injection (`.agents/skills/`):** At runtime, the agent injects external E2E standards directly into the System Prompt to enforce strict QA policies and intelligent locator strategies.
|
|
66
|
-
5. **The Reporter:** A custom execution reporter (`ArcalityReporter.ts`) that filters out robotic hooks and renders the Agent's pure cognitive decision tree into an HTML dashboard.
|
|
67
|
-
|
|
68
|
-
---
|
|
69
|
-
|
|
70
|
-
## 📁 Configuration (`arcality.config.json`)
|
|
71
|
-
|
|
72
|
-
When you run `arcality init`, a configuration is generated in your project root.
|
|
73
|
-
```json
|
|
74
|
-
{
|
|
75
|
-
"project": {
|
|
76
|
-
"name": "PortalAdminQA",
|
|
77
|
-
"baseUrl": "https://dev.arcadial.lat",
|
|
78
|
-
"frameworkDetected": "Next.js"
|
|
79
|
-
},
|
|
80
|
-
"auth": {
|
|
81
|
-
"username": "qa_user",
|
|
82
|
-
"credentialsSource": "env"
|
|
83
|
-
},
|
|
84
|
-
"runtime": {
|
|
85
|
-
"yamlOutputDir": "./.arcality"
|
|
86
|
-
}
|
|
87
|
-
}
|
|
88
|
-
```
|
|
89
|
-
*All reports, saved YAML missions, and runtime context are cleanly isolated inside your project's `./.arcality/` output directory.*
|
|
90
|
-
|
|
91
|
-
---
|
|
92
|
-
|
|
93
|
-
<div align="center">
|
|
94
|
-
<p>Built with ❤️ by the QA Intelligence team at <b>Arcadial</b>.</p>
|
|
95
|
-
</div>
|
|
1
|
+
<div align="center">
|
|
2
|
+
<img src="./public/logo-arcadial-blanco.png" width="120" alt="Arcality Logo" />
|
|
3
|
+
<br>
|
|
4
|
+
<h1>Arcality Engine</h1>
|
|
5
|
+
<p><b>Autonomous AI-Powered E2E Web Testing Agent</b></p>
|
|
6
|
+
|
|
7
|
+
[](https://www.npmjs.com/package/@arcadialdev/arcality)
|
|
8
|
+
</div>
|
|
9
|
+
|
|
10
|
+
<br>
|
|
11
|
+
|
|
12
|
+
**Arcality** is an enterprise-grade autonomous testing agent designed by Arcadial. It replaces brittle, hard-coded UI automation with an intelligent, self-healing agent that understands natural language. Powered by our proprietary AI Cognitive Core and Headless Execution Engine, Arcality navigates web portals, fills forms dynamically, and verifies business logic without requiring you to write a single line of test code.
|
|
13
|
+
|
|
14
|
+
## ✨ Core Capabilities
|
|
15
|
+
|
|
16
|
+
- 🧠 **Cognitive Execution Pipeline:** Arcality doesn't just click coordinates. It parses the DOM tree into an accessibility-focused abstraction, allowing it to "see" your application identically to a human user.
|
|
17
|
+
- 🛡️ **Self-Healing & Forensic Debugging:** When elements shift or modals block the screen, Arcality doesn't instantly crash. It utilizes injected *E2E Expert Protocols* to debug the DOM, wait for networks, and gracefully recover.
|
|
18
|
+
- ♻️ **YAML Persistence:** Once the Agent figures out how to successfully complete a prompt, the deterministic solution is saved locally as an optimized `.yaml` mission for lightning-fast regression testing in CI/CD.
|
|
19
|
+
- 📊 **Agentic Diagnostics HTML Report:** Forget raw stack traces. Arcality generates beautiful, dark-mode `index.html` reports focusing entirely on **Agent Cognitive Process** and visual attachments.
|
|
20
|
+
- 🧰 **Project-Centric Architecture:** Runs seamlessly locally with `arcality.config.json`. No messy global `.env` files required.
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## 🚀 Getting Started
|
|
25
|
+
|
|
26
|
+
### 1. Install in your project
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
npm install @arcadialdev/arcality
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
> After install, Arcality **automatically adds the following scripts** to your `package.json`:
|
|
33
|
+
> ```json
|
|
34
|
+
> "arcality": "arcality run",
|
|
35
|
+
> "arcality:init": "arcality init",
|
|
36
|
+
> "arcality:run": "arcality run"
|
|
37
|
+
> ```
|
|
38
|
+
|
|
39
|
+
### 2. Initialize your project
|
|
40
|
+
Run the setup wizard at the root of your project. Arcality will auto-detect your framework and scaffold the `arcality.config.json`.
|
|
41
|
+
|
|
42
|
+
```bash
|
|
43
|
+
npm run arcality:init
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
### 3. Run an autonomous mission
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
# Interactive menu
|
|
50
|
+
npm run arcality
|
|
51
|
+
|
|
52
|
+
# Direct mission
|
|
53
|
+
npm run arcality:run
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
---
|
|
57
|
+
|
|
58
|
+
## 🛠️ Internal Architecture
|
|
59
|
+
|
|
60
|
+
Arcality operates on a highly decoupled modular system designed for maximum resilience:
|
|
61
|
+
|
|
62
|
+
1. **The CLI Wrapper:** A Node.js CLI that orchestrates Playwright subprocesses, parses configurations (`arcality.config.json`), and manages the CLI spinner aesthetic using `@clack/prompts`.
|
|
63
|
+
2. **The Vision Engine:** Instead of capturing raw DOM, Arcality strips out CSS/JS noise and builds an `Interactive Component Tree` using `aria-labels` and `roles`.
|
|
64
|
+
3. **The Cognitive Gateway (`AIAgentHelper`):** Handles bidirectional communication with the central AI Brain. It uses advanced recursive Tool Calling to perform `UI actions` (click, type, scroll) and `Forensic actions` (capture_console_errors).
|
|
65
|
+
4. **Skill Injection (`.agents/skills/`):** At runtime, the agent injects external E2E standards directly into the System Prompt to enforce strict QA policies and intelligent locator strategies.
|
|
66
|
+
5. **The Reporter:** A custom execution reporter (`ArcalityReporter.ts`) that filters out robotic hooks and renders the Agent's pure cognitive decision tree into an HTML dashboard.
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## 📁 Configuration (`arcality.config.json`)
|
|
71
|
+
|
|
72
|
+
When you run `arcality init`, a configuration is generated in your project root.
|
|
73
|
+
```json
|
|
74
|
+
{
|
|
75
|
+
"project": {
|
|
76
|
+
"name": "PortalAdminQA",
|
|
77
|
+
"baseUrl": "https://dev.arcadial.lat",
|
|
78
|
+
"frameworkDetected": "Next.js"
|
|
79
|
+
},
|
|
80
|
+
"auth": {
|
|
81
|
+
"username": "qa_user",
|
|
82
|
+
"credentialsSource": "env"
|
|
83
|
+
},
|
|
84
|
+
"runtime": {
|
|
85
|
+
"yamlOutputDir": "./.arcality"
|
|
86
|
+
}
|
|
87
|
+
}
|
|
88
|
+
```
|
|
89
|
+
*All reports, saved YAML missions, and runtime context are cleanly isolated inside your project's `./.arcality/` output directory.*
|
|
90
|
+
|
|
91
|
+
---
|
|
92
|
+
|
|
93
|
+
<div align="center">
|
|
94
|
+
<p>Built with ❤️ by the QA Intelligence team at <b>Arcadial</b>.</p>
|
|
95
|
+
</div>
|
package/bin/arcality.mjs
CHANGED
|
@@ -1,55 +1,55 @@
|
|
|
1
|
-
#!/usr/bin/env node
|
|
2
|
-
// bin/arcality.mjs — Entry point for the 'arcality' global command
|
|
3
|
-
import { fileURLToPath } from 'url';
|
|
4
|
-
import path from 'node:path';
|
|
5
|
-
import { spawn } from 'node:child_process';
|
|
6
|
-
import fs from 'node:fs';
|
|
7
|
-
|
|
8
|
-
const __filename = fileURLToPath(import.meta.url);
|
|
9
|
-
const __dirname = path.dirname(__filename);
|
|
10
|
-
const PACKAGE_ROOT = path.resolve(__dirname, '..');
|
|
11
|
-
|
|
12
|
-
// REFUERZO DE ARGUMENTOS: Capturamos TODO lo que venga de la consola
|
|
13
|
-
const rawArgs = process.argv.slice(2);
|
|
14
|
-
let isRun = false;
|
|
15
|
-
let isInit = false;
|
|
16
|
-
let isSetup = false;
|
|
17
|
-
|
|
18
|
-
// Buscamos los comandos en cualquier posición para evitar filtros de NPM en Windows
|
|
19
|
-
rawArgs.forEach(arg => {
|
|
20
|
-
if (arg === 'run') isRun = true;
|
|
21
|
-
if (arg === 'init') isInit = true;
|
|
22
|
-
if (arg === 'setup') isSetup = true;
|
|
23
|
-
});
|
|
24
|
-
|
|
25
|
-
if (isInit) {
|
|
26
|
-
const initScript = path.join(PACKAGE_ROOT, 'scripts', 'init.mjs');
|
|
27
|
-
spawn('node', [initScript, ...rawArgs.filter(a => a !== 'init')], {
|
|
28
|
-
stdio: 'inherit',
|
|
29
|
-
cwd: process.cwd(),
|
|
30
|
-
env: { ...process.env, ARCALITY_ROOT: PACKAGE_ROOT }
|
|
31
|
-
}).on('exit', code => process.exit(code || 0));
|
|
32
|
-
} else if (isRun) {
|
|
33
|
-
// FORZAMOS EL MODO AGENTE: Esto saltará el menú interactivo en gen-and-run.mjs
|
|
34
|
-
const mainScript = path.join(PACKAGE_ROOT, 'scripts', 'gen-and-run.mjs');
|
|
35
|
-
spawn('node', [mainScript, '--agent', ...rawArgs.filter(a => a !== 'run')], {
|
|
36
|
-
stdio: 'inherit',
|
|
37
|
-
cwd: process.cwd(),
|
|
38
|
-
env: { ...process.env, ARCALITY_ROOT: PACKAGE_ROOT }
|
|
39
|
-
}).on('exit', code => process.exit(code || 0));
|
|
40
|
-
} else if (isSetup) {
|
|
41
|
-
const setupScript = path.join(PACKAGE_ROOT, 'scripts', 'setup.mjs');
|
|
42
|
-
spawn('node', [setupScript, ...rawArgs.filter(a => a !== 'setup')], {
|
|
43
|
-
stdio: 'inherit',
|
|
44
|
-
cwd: PACKAGE_ROOT,
|
|
45
|
-
env: { ...process.env, ARCALITY_ROOT: PACKAGE_ROOT }
|
|
46
|
-
}).on('exit', code => process.exit(code || 0));
|
|
47
|
-
} else {
|
|
48
|
-
// Menú interactivo tradicional
|
|
49
|
-
const mainScript = path.join(PACKAGE_ROOT, 'scripts', 'gen-and-run.mjs');
|
|
50
|
-
spawn('node', [mainScript, ...rawArgs], {
|
|
51
|
-
stdio: 'inherit',
|
|
52
|
-
cwd: process.cwd(),
|
|
53
|
-
env: { ...process.env, ARCALITY_ROOT: PACKAGE_ROOT }
|
|
54
|
-
}).on('exit', code => process.exit(code || 0));
|
|
55
|
-
}
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
// bin/arcality.mjs — Entry point for the 'arcality' global command
|
|
3
|
+
import { fileURLToPath } from 'url';
|
|
4
|
+
import path from 'node:path';
|
|
5
|
+
import { spawn } from 'node:child_process';
|
|
6
|
+
import fs from 'node:fs';
|
|
7
|
+
|
|
8
|
+
const __filename = fileURLToPath(import.meta.url);
|
|
9
|
+
const __dirname = path.dirname(__filename);
|
|
10
|
+
const PACKAGE_ROOT = path.resolve(__dirname, '..');
|
|
11
|
+
|
|
12
|
+
// REFUERZO DE ARGUMENTOS: Capturamos TODO lo que venga de la consola
|
|
13
|
+
const rawArgs = process.argv.slice(2);
|
|
14
|
+
let isRun = false;
|
|
15
|
+
let isInit = false;
|
|
16
|
+
let isSetup = false;
|
|
17
|
+
|
|
18
|
+
// Buscamos los comandos en cualquier posición para evitar filtros de NPM en Windows
|
|
19
|
+
rawArgs.forEach(arg => {
|
|
20
|
+
if (arg === 'run') isRun = true;
|
|
21
|
+
if (arg === 'init') isInit = true;
|
|
22
|
+
if (arg === 'setup') isSetup = true;
|
|
23
|
+
});
|
|
24
|
+
|
|
25
|
+
if (isInit) {
|
|
26
|
+
const initScript = path.join(PACKAGE_ROOT, 'scripts', 'init.mjs');
|
|
27
|
+
spawn('node', [initScript, ...rawArgs.filter(a => a !== 'init')], {
|
|
28
|
+
stdio: 'inherit',
|
|
29
|
+
cwd: process.cwd(),
|
|
30
|
+
env: { ...process.env, ARCALITY_ROOT: PACKAGE_ROOT }
|
|
31
|
+
}).on('exit', code => process.exit(code || 0));
|
|
32
|
+
} else if (isRun) {
|
|
33
|
+
// FORZAMOS EL MODO AGENTE: Esto saltará el menú interactivo en gen-and-run.mjs
|
|
34
|
+
const mainScript = path.join(PACKAGE_ROOT, 'scripts', 'gen-and-run.mjs');
|
|
35
|
+
spawn('node', [mainScript, '--agent', ...rawArgs.filter(a => a !== 'run')], {
|
|
36
|
+
stdio: 'inherit',
|
|
37
|
+
cwd: process.cwd(),
|
|
38
|
+
env: { ...process.env, ARCALITY_ROOT: PACKAGE_ROOT }
|
|
39
|
+
}).on('exit', code => process.exit(code || 0));
|
|
40
|
+
} else if (isSetup) {
|
|
41
|
+
const setupScript = path.join(PACKAGE_ROOT, 'scripts', 'setup.mjs');
|
|
42
|
+
spawn('node', [setupScript, ...rawArgs.filter(a => a !== 'setup')], {
|
|
43
|
+
stdio: 'inherit',
|
|
44
|
+
cwd: PACKAGE_ROOT,
|
|
45
|
+
env: { ...process.env, ARCALITY_ROOT: PACKAGE_ROOT }
|
|
46
|
+
}).on('exit', code => process.exit(code || 0));
|
|
47
|
+
} else {
|
|
48
|
+
// Menú interactivo tradicional
|
|
49
|
+
const mainScript = path.join(PACKAGE_ROOT, 'scripts', 'gen-and-run.mjs');
|
|
50
|
+
spawn('node', [mainScript, ...rawArgs], {
|
|
51
|
+
stdio: 'inherit',
|
|
52
|
+
cwd: process.cwd(),
|
|
53
|
+
env: { ...process.env, ARCALITY_ROOT: PACKAGE_ROOT }
|
|
54
|
+
}).on('exit', code => process.exit(code || 0));
|
|
55
|
+
}
|