docs(ui): add UI user guide section with screenshots and runner catalog

SUMMARY.md

@@ -30,6 +30,36 @@
   * [Profiles](in-depth/concepts/profiles.md)
 * [Deployment](in-depth/deployment.md)
 
+## UI guide
+
+* [Overview](ui/README.md)
+* Quickstart
+  * [First run in 5 minutes](ui/quickstart.md)
+  * [Sign in & first login](ui/sign-in.md)
+  * [Global interface](ui/global-interface.md)
+  * [Dashboard](ui/dashboard.md)
+  * [Workspaces](ui/workspaces.md)
+  * [Targets](ui/targets.md)
+  * [Runners](ui/runners.md)
+  * [Findings](ui/findings.md)
+  * [Reports](ui/reports.md)
+* Attacks
+  * [Attack capabilities](ui/attack-capabilities.md)
+  * [Available scans](ui/available-scans.md)
+  * [Available workflows](ui/available-workflows.md)
+  * [Meta options](ui/meta-options.md)
+  * [Attack patterns](ui/attack-patterns.md)
+* Concepts
+  * [Platform overview](ui/platform-overview.md)
+  * [Glossary](ui/glossary.md)
+* Power features
+  * [AI suggestions](ui/ai-suggestions.md)
+  * [Chores & owner features](ui/chores.md)
+* Account & API
+  * [Profile, organization, billing](ui/profile-billing.md)
+  * [API tokens](ui/api-tokens.md)
+* [Quick reference](ui/quick-reference.md)
+
 ## For developers
 
 * [Development setup](for-developers/development-setup.md)

ui/README.md

@@ -0,0 +1,15 @@
+# UI guide
+
+This section is the end-user reference for the **Secator web interface** — for analysts, pentesters and team admins who use the platform through the browser rather than the CLI.
+
+It is organized in five parts:
+
+| Part | What it covers |
+|---|---|
+| **Quickstart** | Log in, run your first scan, find your way around the UI. |
+| **Attacks** | What the platform can do, the catalog of every scan and workflow with their full task tree. |
+| **Concepts** | The glossary of platform-specific terms and a high-level architectural overview. |
+| **Power features** | AI suggestions, scheduling, owner-only controls. |
+| **Account & API** | Profile, organization, billing, API tokens. |
+
+If you are looking for the **CLI** documentation (`secator x`, `secator w`, `secator s`, library usage, writing custom tasks/workflows), see the rest of this site under *Getting started* and *In-depth*.

ui/ai-suggestions.md

@@ -0,0 +1,42 @@
+# AI suggestions
+
+Suggestions are *actionable hints* generated automatically from the findings already collected in a workspace. They show up in the workspace's **Suggestions** tab and (optionally) appear on the Dashboard via the **View suggestions** button.
+
+### Where they come from
+
+Once **AI suggestions** is enabled (Workspace settings → *General* tab), a background job analyses each new wave of findings — open ports, exposed certificates, subdomains, web technologies, leaked emails — and proposes follow-up actions. There is no manual prompt to write; suggestions are pushed asynchronously as data accrues.
+
+### What a suggestion looks like
+
+Each suggestion is an expandable card with:
+
+- **A title and an icon** — at a glance, the kind of action proposed (run a scan, run a workflow, run a single tool, add a target).
+- **A natural-language `message`** — *why* the system proposed this. Examples: *"Ports 22, 80, 443 detected on `host-3.acme.com` — running an `sshaudit` task could surface weak ciphers"*, or *"`api.acme.com` was discovered via subdomain enumeration but is not yet a target — adding it lets you scan its endpoints"*.
+- **`help` lines** — short reminders or warnings about the proposed action (run hours impact, scope, expected duration).
+- **A `cost_evaluation`** — an estimate of how many run hours / how much wall-time the action will consume so you can decide before clicking.
+- **A list of related runs** — if you have already executed similar runners on this target, they are linked here so you can compare results.
+
+### Suggestion types
+
+| Type | What clicking it does |
+|---|---|
+| **Runner** (scan / workflow / task) | Opens the *Run* form pre-filled with the suggested runner, target, and options. You can review and tweak before launching. |
+| **Add target** | Opens the *Target* form pre-filled with the asset the system thinks should be in scope. Useful right after a subdomain or DNS recon run. |
+
+### Actions on a suggestion
+
+- **Run now** — Launches the proposed runner immediately. Once executed, the suggestion is marked *done* and decorated with the run's status.
+- **Add target** — Opens the target sheet, with workspace and asset pre-filled.
+- **Dismiss** — Removes the suggestion from the active list. Useful when the suggestion does not apply to your engagement.
+
+> [!note]
+> Suggestions are workspace-scoped. Disabling AI suggestions in *Workspace settings → General* stops new suggestions from being generated; existing ones stay until dismissed or executed.
+
+### Tuning what suggestions you get
+
+- **Workspace scope** (allowlist / denylist) — Suggestions only consider in-scope assets.
+- **Display settings** (Workspace settings → *Display* tab) — Hiding finding types you don't care about prevents suggestions of that flavour.
+- **Notifications** — You can subscribe to a notification when a new suggestion appears (Workspace settings → *Notifications* tab).
+
+> [!tip]
+> Use suggestions as a *checklist*, not a roadmap. Always review the proposed options and the cost estimate before clicking *Run now*.

ui/api-tokens.md

@@ -0,0 +1,15 @@
+# API tokens
+
+![API tokens page](../.gitbook/assets/ui-screenshots/19-app-tokens.png)
+
+Programmatic access to the Secator API is gated by tokens you manage from the **API Tokens** page in the user menu. You can:
+
+- **List tokens** with their name, scopes, creation date, expiration, and status (active, expired, revoked).
+- **Create token** — Set a name, choose scopes (read / write / admin and finer-grained), and pick an expiration (preset durations of 7d, 30d, 90d, 1 year, or a custom date). The token value is shown **once** at creation — copy it immediately.
+
+> [!caution]
+> The token value cannot be recovered after the creation dialog is dismissed. If you lose it, you must revoke and recreate the token. Treat it like a password — keep it out of git, CI logs, and shared docs.
+
+- **Edit** name and scopes of existing tokens.
+- **Delete** (revoke) a token with confirmation.
+- **Filter** the list by status.

ui/attack-capabilities.md

@@ -0,0 +1,94 @@
+# Attack capabilities
+
+The platform's offensive and defensive capabilities are organised here by **intrusion layer** — from zero-touch passive intelligence (Layer 1) to live exploitation (Layer 5). This is the same way a serious engagement scope is written: *"OK for layers 1-3, written authorization required beyond"*.
+
+When you discuss scope with a client, refer to a layer rather than naming individual tools — every layer maps to a curated set of profiles, workflows and tasks below.
+
+> [!note]
+> Higher layers always include the capabilities of the layers beneath them when they need to (e.g. a Layer 4 vuln scan first runs Layer 2 probes to discover the surface). The layer boundaries are about **what new traffic the platform sends to the target**, not about which tools "could" run.
+
+### Layer 1 — Passive intelligence
+
+Zero requests sent to the target. All data comes from third-party datasets (Wayback, Common Crawl, certificate transparency, breach corpora, public source code, social platforms).
+
+Safe to run during scoping, on out-of-scope assets, or when stealth is mandatory. Use the `passive` profile to lock the platform into this layer.
+
+| Capability | Tools |
+|---|---|
+| Subdomain enumeration | `subfinder`, `xurlfind3r` |
+| URL harvesting | `gau`, `xurlfind3r`, `urlfinder` |
+| WHOIS / domain info | `jswhois`, `whois` |
+| ASN / IP intelligence | `getasn` |
+| Known-CVE lookup | `searchsploit`, `search_vulns` |
+| Email breach lookup | `h8mail` |
+| Username correlation | `maigret` |
+| Public secret hunting | `gitleaks` (on public git repos) |
+
+### Layer 2 — Active probing
+
+Sends TCP / HTTP / DNS / ICMP probes to the target but **no offensive payload**. Just enough traffic to map the surface and fingerprint services.
+
+Equivalent to standard pre-engagement recon. Most clients accept this as soon as the IP / domain is in scope.
+
+| Capability | Tools |
+|---|---|
+| DNS resolution | `dnsx` |
+| Port scanning | `nmap`, `naabu` |
+| HTTP probing | `httpx` |
+| Network discovery (LAN) | `arpscan`, `arp`, `fping`, `mapcidr`, `netdetect` |
+| TLS posture | `testssl` |
+| SSH hardening | `sshaudit` |
+| WAF fingerprinting | `wafw00f` |
+
+### Layer 3 — Crawling & content discovery
+
+Walks the application like a user or a search-engine spider, plus directory / parameter brute-force on the discovered surface. Consumes target bandwidth but does not yet send injection payloads.
+
+Use when the scope is *web app testing* without explicit authorization for vuln scanning.
+
+| Capability | Tools |
+|---|---|
+| Active crawling | `katana`, `gospider`, `cariddi` |
+| Directory / file brute-force | `feroxbuster`, `dirsearch`, `ffuf` |
+| HTTP parameter discovery | `arjun`, `x8` |
+| In-response secret hunting | `trufflehog` |
+| Pattern matching for vuln candidates | `gf` (SQLi / SSRF / LFI / RCE / IDOR / debug paths) |
+
+### Layer 4 — Vulnerability scanning
+
+Sends template- or signature-based payloads to verify whether known issues exist. Findings carry CVE / CVSS / severity data and may include reproducible request/response evidence (records).
+
+Requires written authorization. Choose `aggressive` for speed, `polite` for production targets.
+
+| Capability | Tools |
+|---|---|
+| Generic vulnerability scanner | `nuclei` (10 000+ templates: CVEs, misconfigs, exposed panels) |
+| Multipurpose recon-to-vuln pipeline | `bbot` |
+| Container / filesystem CVE scanning | `trivy`, `grype` |
+| WordPress audit | `wpscan`, `wpprobe` |
+| Reflected / stored / DOM XSS | `dalfox` |
+| Subdomain-takeover detection | `subdomain_recon` workflow (chains `subfinder → dnsx → httpx → nuclei` takeover templates) |
+
+### Layer 5 — Exploitation
+
+Live exploit attempts against confirmed vulnerabilities. **Do not run** unless you have explicit authorization in writing and a controlled rollback plan.
+
+| Capability | Tools |
+|---|---|
+| 40x bypass attempts | `bup` (30+ techniques: header injection, path tricks, method override) |
+| Known-CVE exploitation modules | `msfconsole` (Metasploit) |
+
+> [!caution]
+> Layer 5 produces real changes on the target — application state, audit logs, sometimes data. Always run inside a lab/staging environment before pointing at production. Verify the workspace's [scope](glossary.md#g-scope) before launching.
+
+The full content of each scan and each workflow follows directly below.
+
+
+
+---
+
+See the full content of every scan and workflow in:
+
+- [Available scans](available-scans.md)
+- [Available workflows](available-workflows.md)
+

ui/attack-patterns.md

@@ -0,0 +1,78 @@
+# Attack patterns
+
+This is the *cookbook* of the platform — concrete, intent-driven recipes. Each pattern says *what you want to do*, *what to click*, and *where to look at the result*. Pick the closest pattern to your engagement, then tune the options to your scope.
+
+### Bug bounty — out-of-scope guard
+
+**Goal:** confirm a candidate asset is in scope before any active probe.
+
+1. Workspace settings → *Scope* tab → enter the program's allowlist patterns (and denylist for explicit out-of-scope domains).
+2. Run **`subdomain_recon`** workflow with profile **`passive`** on the program's apex domain.
+3. Open the *Findings → Subdomain* tab. Subdomains that fall outside the allowlist are tagged `scope-mismatch` and shown in red.
+4. Resolve / drop the out-of-scope ones before adding them as targets.
+
+> [!tip]
+> Combine with the *Suggestions* tab: the platform proposes adding only allowlist-compatible subdomains as new targets.
+
+### Authenticated web app scan
+
+**Goal:** scan an app behind a login.
+
+1. Get a valid session token / API key from the app.
+2. Open the *Run* form for the **`url_crawl`** workflow on your target URL.
+3. In *Options*, set **Headers** to: `Authorization: Bearer <token>`. For cookie-based auth use `Cookie: session=...`.
+4. Optionally set **Method** + **Data** if the app expects POST navigation (rare).
+5. Chain with **`url_vuln`** in the same workspace — both will reuse the workspace targets and you'll get `nuclei` + `dalfox` running with the same auth context.
+
+> [!warning]
+> Pick the **`polite`** profile for production apps to avoid filling the audit log with rate-limited 429s.
+
+### WordPress CVE audit
+
+**Goal:** find known CVEs on a WordPress install.
+
+1. Run the **`wordpress`** workflow with profile **`aggressive`** if scope allows, otherwise **`polite`**.
+2. Open *Findings → Vulnerability*. Filter by **Severity** ≥ High.
+3. Each vulnerability with an `id` (CVE) shows a **Source** badge (`wpscan`, `wpprobe`, `nuclei`).
+4. The **Exploit** tab right next to it lists `searchsploit` matches: ready-to-use PoCs for the same CVE.
+
+### Find leaked secrets in a target's JS
+
+**Goal:** identify hardcoded API keys / tokens shipped in front-end JS.
+
+1. Run **`url_crawl`** with the **`hunt_secrets`** profile on the target.
+2. Wait for the run to complete. Switch to *Findings → Tag*.
+3. Filter by tag value: `aws_key`, `api_key`, `jwt`, `private_key`, `slack_webhook`, `gcp_credentials`.
+4. Click any finding → the *Record* link shows the exact JS file and line where the secret was found.
+
+### Internal CIDR mapping
+
+**Goal:** map a /24 internal network during an on-site engagement.
+
+1. Add the CIDR (e.g. `10.0.0.0/24`) as a target in the workspace.
+2. Run **`cidr_recon`** workflow with profile **`active`**.
+3. Open the workspace's *Overview* tab → **Infrastructure Graph** to see the live host topology.
+4. Switch to *Findings → Port* to see the open services per host, then chain `nmap` (deep) tasks on interesting hosts.
+
+> [!note]
+> Layer 2 traffic (ARP, ICMP) requires the worker to be on the same network — typically a worker deployed inside the client's environment.
+
+### 40x bypass on a forbidden endpoint
+
+**Goal:** see if a `403 Forbidden` page can be reached through bypass techniques.
+
+1. From *Tasks → Run a task*, pick **`bup`**.
+2. Set the target URL to the forbidden endpoint (e.g. `https://target/admin`).
+3. Leave the default 30+ techniques enabled.
+4. The runner shows a per-technique table: bypass technique → response status → response size. Anything other than the original 403 is worth investigating manually.
+
+### Unknown-tech triage
+
+**Goal:** you have a black-box target and don't know yet which workflow fits.
+
+1. Add the target.
+2. Run the **`url`** scan with profile **`passive`** + **`http_headless`**.
+3. Open *Findings → URL* and look at the **Tech** column. The detected stack (PHP, Drupal, Spring, …) tells you which dedicated workflow to run next: `wordpress` for WP, `url_vuln` + `dalfox` for generic webapp, `code_scan` if a public repo was discovered, etc.
+
+> [!tip]
+> The *Suggestions* tab usually proposes the right next workflow automatically based on the detected technologies. Save these clicks by enabling AI suggestions in workspace settings.