docs: rebrand Certifai → Prüfwerk (user-facing name) (#243)

docs/guide/demo-targets.md

@@ -1,6 +1,6 @@
 # Demo Targets
 
-Certifai ships a small, versioned set of **demo targets** — representative
+Prüfwerk ships a small, versioned set of **demo targets** — representative
 inputs that exercise every scan path repeatably. They double as the fixture
 set for the nightly regression and as a ready-made walkthrough for demos.
 

docs/guide/findings.md

@@ -116,7 +116,7 @@ When you mark a finding as a false positive, you are providing training signal t
 
 ## Human in the Loop
 
-Certifai uses AI to triage findings, but humans make the final decisions. Here is how the process works:
+Prüfwerk uses AI to triage findings, but humans make the final decisions. Here is how the process works:
 
 1. **AI triages** -- the LLM reviews each finding, assigns a severity, generates a confidence score, and writes a rationale explaining its assessment
 2. **You review** -- you read the AI's analysis alongside the code evidence and decide whether to act on it

docs/guide/getting-started.md

@@ -1,10 +1,10 @@
 # Getting Started
 
-Certifai is an AI-powered security compliance platform that scans your Git repositories for vulnerabilities, builds software bills of materials, performs dynamic application testing, and provides code intelligence through an interactive knowledge graph and AI chat.
+Prüfwerk is an AI-powered security compliance platform that scans your Git repositories for vulnerabilities, builds software bills of materials, performs dynamic application testing, and provides code intelligence through an interactive knowledge graph and AI chat.
 
 ## What You Get
 
-When you connect a repository, Certifai runs a comprehensive scan pipeline that covers:
+When you connect a repository, Prüfwerk runs a comprehensive scan pipeline that covers:
 
 - **Static Analysis (SAST)** -- finds code-level vulnerabilities like injection flaws, insecure crypto, and misconfigurations
 - **Software Bill of Materials (SBOM)** -- inventories every dependency, its version, and its license

docs/guide/issues.md

@@ -1,6 +1,6 @@
 # Issues & Tracking
 
-Certifai automatically creates issues in your existing issue trackers when new security findings are discovered. This integrates security into your development workflow without requiring teams to check a separate tool.
+Prüfwerk automatically creates issues in your existing issue trackers when new security findings are discovered. This integrates security into your development workflow without requiring teams to check a separate tool.
 
 ## How Issues Are Created
 
@@ -8,7 +8,7 @@ When a scan discovers new findings, the following happens automatically:
 
 1. Each new finding is checked against existing issues using its fingerprint
 2. If no matching issue exists, a new issue is created in the configured tracker
-3. The issue includes the finding title, severity, vulnerability details, file location, and a link back to the finding in Certifai
+3. The issue includes the finding title, severity, vulnerability details, file location, and a link back to the finding in Prüfwerk
 4. The finding is updated with a link to the external issue
 
 This means every actionable finding gets tracked in the same system your developers already use.
@@ -53,4 +53,4 @@ Issues are deduplicated using the same fingerprint hash that deduplicates findin
 
 ## Linked Issues in Finding Detail
 
-When viewing a [finding's detail page](/guide/findings#finding-detail), you will see a **Linked Issue** section if an issue was created for that finding. This provides a direct link to the external tracker issue, making it easy to jump between the security context in Certifai and the development workflow in your tracker.
+When viewing a [finding's detail page](/guide/findings#finding-detail), you will see a **Linked Issue** section if an issue was created for that finding. This provides a direct link to the external tracker issue, making it easy to jump between the security context in Prüfwerk and the development workflow in your tracker.

docs/guide/plc.md

@@ -1,10 +1,10 @@
 # PLC / SPS Projects (CODESYS)
 
-Certifai analyzes industrial control logic (IEC 61131-3) for PLC/SPS targets such
+Prüfwerk analyzes industrial control logic (IEC 61131-3) for PLC/SPS targets such
 as CODESYS projects. A single PLC/SPS target is treated as a **composite device**:
 the control application *and* the device it runs on.
 
-| What you provide | What Certifai does |
+| What you provide | What Prüfwerk does |
 | --- | --- |
 | PLC project (PLCopen XML / ST, or a `.projectarchive`) | **Control-logic SAST** — semantic security rules over ST **and** graphical FBD/LD |
 | A `.projectarchive` | **Control-app SBOM** — the referenced CODESYS libraries + the runtime version, matched against known CVEs |
@@ -28,7 +28,7 @@ Because of this, the device is built along **two independent tracks**, by
 different people, on different timelines, and shipped separately. It also
 inherits the **entire Linux / IT attack surface on top of** the OT / control
 one — which is exactly why a PLC/SPS target is treated as a **composite**:
-Certifai ingests one artifact per layer and scans each with the right pipeline.
+Prüfwerk ingests one artifact per layer and scans each with the right pipeline.
 
 ```mermaid
 flowchart TB
@@ -44,7 +44,7 @@ flowchart TB
     A3 --> DEV(["Running soft-PLC device<br/>SoC + Linux + runtime + control app<br/>Modbus · OPC UA · EtherNet/IP · WebVisu"])
     B3 --> DEV
 
-    subgraph CERT["What Certifai scans — one layer per artifact"]
+    subgraph CERT["What Prüfwerk scans — one layer per artifact"]
         direction LR
         S1["Firmware layer<br/>FirmwareStatic · SBOM · CVE"]
         S2["Control-logic layer<br/>PLC SAST — ST + FBD/LD"]
@@ -70,7 +70,7 @@ flowchart TB
 ::: tip Where Yocto fits
 Yocto is **Track A** — the *build system* for the device platform. It produces
 the Linux image and bakes in the CODESYS runtime, so it is the **firmware
-layer**, entirely separate from the control application. Hand it to Certifai as
+layer**, entirely separate from the control application. Hand it to Prüfwerk as
 its own **firmware image** artifact (scanned by the firmware pipeline, not the
 PLC pipeline). The device OS need not be Yocto — Raspbian/Debian/Buildroot, or
 even an RTOS / bare-metal, are all possible — but Yocto is the common,
@@ -79,7 +79,7 @@ product-grade industrial choice.
 
 ## Two ways to deliver the project
 
-You can either **upload** the project when onboarding, or point Certifai at a
+You can either **upload** the project when onboarding, or point Prüfwerk at a
 **git repository** (recommended — every scan is just a `git pull`, no re-upload).
 
 ### Option A — Upload
@@ -95,7 +95,7 @@ project** artifact and pick its format:
 
 ### Option B — Git repository (recommended)
 
-Attach a **Git repository** artifact to the PLC/SPS target. Certifai clones it and
+Attach a **Git repository** artifact to the PLC/SPS target. Prüfwerk clones it and
 runs the control-logic scan over the exported source in the repo.
 
 ## Best-case git repository layout
@@ -145,7 +145,7 @@ surface real CODESYS advisories as CVE alerts.
 
 ## Dynamic testing — ICS protocol probe
 
-Beyond the static analysis, Certifai can **probe the running device** over
+Beyond the static analysis, Prüfwerk can **probe the running device** over
 industrial protocols. Attach a **Live URL** artifact (the device host / WebVisu
 URL) to the PLC/SPS target and enable the **ICS Probe** scan.
 

docs/guide/repositories.md

@@ -1,6 +1,6 @@
 # Adding Repositories
 
-Repositories are the core resource in Certifai. Each tracked repository is scanned on a schedule, and its results are available across all features -- findings, SBOM, code graph, AI chat, and issue tracking.
+Repositories are the core resource in Prüfwerk. Each tracked repository is scanned on a schedule, and its results are available across all features -- findings, SBOM, code graph, AI chat, and issue tracking.
 
 ## Adding a Repository
 
@@ -20,11 +20,11 @@ The repository appears in the list immediately. It will not be scanned until you
 
 **Public repositories** can be cloned using an HTTPS URL with no additional setup.
 
-**Private repositories** require SSH access. When you add a repository with an SSH URL (e.g. `git@github.com:org/repo.git`), Certifai uses an SSH deploy key to authenticate.
+**Private repositories** require SSH access. When you add a repository with an SSH URL (e.g. `git@github.com:org/repo.git`), Prüfwerk uses an SSH deploy key to authenticate.
 
 ### Getting the SSH Public Key
 
-To grant Certifai access to a private repository:
+To grant Prüfwerk access to a private repository:
 
 1. Go to the **Repositories** page
 2. The platform's SSH public key is available for copying
@@ -34,7 +34,7 @@ To grant Certifai access to a private repository:
    - **Gitea**: Repository Settings > Deploy Keys > Add Deploy Key
 
 ::: tip
-Deploy keys are scoped to a single repository and are read-only by default. This is the recommended approach for granting Certifai access to private code.
+Deploy keys are scoped to a single repository and are read-only by default. This is the recommended approach for granting Prüfwerk access to private code.
 :::
 
 ## Configuring an Issue Tracker

docs/guide/sbom.md

@@ -6,7 +6,7 @@ The SBOM (Software Bill of Materials) feature provides a complete inventory of a
 
 A Software Bill of Materials is a list of every component (library, package, framework) that your software depends on, along with version numbers, licenses, and known vulnerabilities. SBOMs are increasingly required for compliance audits, customer security questionnaires, and supply chain transparency.
 
-Certifai generates SBOMs automatically during each scan using Syft for dependency extraction and OSV.dev + NVD for vulnerability matching.
+Prüfwerk generates SBOMs automatically during each scan using Syft for dependency extraction and OSV.dev + NVD for vulnerability matching.
 
 ## Packages Tab
 

docs/guide/scanning.md

@@ -1,10 +1,10 @@
 # Running Scans
 
-Scans are the primary workflow in Certifai. Each scan analyzes a repository for security vulnerabilities, dependency risks, and code structure.
+Scans are the primary workflow in Prüfwerk. Each scan analyzes a repository for security vulnerabilities, dependency risks, and code structure.
 
 ## What Happens During a Scan
 
-When a scan is triggered, Certifai runs through these phases in order:
+When a scan is triggered, Prüfwerk runs through these phases in order:
 
 1. **Clone** -- pulls the latest code from the Git remote (or clones it for the first time)
 2. **SAST** -- runs static analysis using Semgrep with rules covering OWASP, GDPR, OAuth, secrets, and general security patterns

docs/guide/webhooks.md

@@ -1,15 +1,15 @@
 # Webhooks & PR Reviews
 
-Webhooks let Certifai respond to events in your Git repositories automatically. When configured, pushes to your repository trigger scans, and pull requests receive automated security reviews.
+Webhooks let Prüfwerk respond to events in your Git repositories automatically. When configured, pushes to your repository trigger scans, and pull requests receive automated security reviews.
 
 ## What Webhooks Enable
 
 - **Automatic scans on push** -- every time code is pushed to your default branch, a scan is triggered automatically
-- **PR security reviews** -- when a pull request is opened or updated, Certifai scans the changes and posts a review comment summarizing any security findings in the diff
+- **PR security reviews** -- when a pull request is opened or updated, Prüfwerk scans the changes and posts a review comment summarizing any security findings in the diff
 
 ## Finding the Webhook URL and Secret
 
-Each repository in Certifai has its own webhook URL and secret:
+Each repository in Prüfwerk has its own webhook URL and secret:
 
 1. Go to **Repositories**
 2. Click **Edit** on the repository you want to configure
@@ -22,8 +22,8 @@ Each repository in Certifai has its own webhook URL and secret:
 
 1. Go to your repository in Gitea
 2. Navigate to **Settings > Webhooks > Add Webhook > Gitea**
-3. Set the **Target URL** to the webhook URL from Certifai
-4. Set the **Secret** to the webhook secret from Certifai
+3. Set the **Target URL** to the webhook URL from Prüfwerk
+4. Set the **Secret** to the webhook secret from Prüfwerk
 5. Under **Trigger On**, select:
    - **Push Events** -- for automatic scans on push
    - **Pull Request Events** -- for PR security reviews
@@ -34,9 +34,9 @@ Each repository in Certifai has its own webhook URL and secret:
 
 1. Go to your repository on GitHub
 2. Navigate to **Settings > Webhooks > Add webhook**
-3. Set the **Payload URL** to the webhook URL from Certifai
+3. Set the **Payload URL** to the webhook URL from Prüfwerk
 4. Set the **Content type** to `application/json`
-5. Set the **Secret** to the webhook secret from Certifai
+5. Set the **Secret** to the webhook secret from Prüfwerk
 6. Under **Which events would you like to trigger this webhook?**, select **Let me select individual events**, then check:
    - **Pushes** -- for automatic scans on push
    - **Pull requests** -- for PR security reviews
@@ -46,8 +46,8 @@ Each repository in Certifai has its own webhook URL and secret:
 
 1. Go to your project in GitLab
 2. Navigate to **Settings > Webhooks**
-3. Set the **URL** to the webhook URL from Certifai
-4. Set the **Secret token** to the webhook secret from Certifai
+3. Set the **URL** to the webhook URL from Prüfwerk
+4. Set the **Secret token** to the webhook secret from Prüfwerk
 5. Under **Trigger**, check:
    - **Push events** -- for automatic scans on push
    - **Merge request events** -- for PR security reviews
@@ -57,10 +57,10 @@ Each repository in Certifai has its own webhook URL and secret:
 
 When a pull request (or merge request) is opened or updated, the following happens:
 
-1. Your Git provider sends a webhook event to Certifai
-2. Certifai checks out the PR branch and runs a targeted scan on the changed files
+1. Your Git provider sends a webhook event to Prüfwerk
+2. Prüfwerk checks out the PR branch and runs a targeted scan on the changed files
 3. Findings specific to the changes in the PR are identified
-4. Certifai posts a review comment on the PR summarizing:
+4. Prüfwerk posts a review comment on the PR summarizing:
    - Number of new findings introduced by the changes
    - Severity breakdown
    - Details for each finding including file, line, and remediation guidance
@@ -83,5 +83,5 @@ Here is a summary of which events to enable for each feature:
 You can enable one or both depending on your workflow.
 
 ::: warning
-Make sure the webhook secret matches exactly between your Git provider and Certifai. Requests with an invalid signature are rejected.
+Make sure the webhook secret matches exactly between your Git provider and Prüfwerk. Requests with an invalid signature are rejected.
 :::