Adds configuration docs, adds implemented checks docs, improves official badges

Signed-off-by: Sebastian Kawelke <sebastian.kawelke@l3montree.com>

src/pages/api-docs/v1/_meta.ts

 export default {
-    'sarif-per-repo-endpoint': { title: 'SARIF per Repo Endpoint' },
-    badges: { title: 'Badges' },
+    'sarif-per-repo-endpoint': { title: 'SARIF per Repo' },
+    badges: { title: 'Badge per Repo and BadgeId' },
 }

src/pages/api-docs/v1/badges.mdx

@@ -8,64 +8,60 @@ import { Tabs, Callout } from 'nextra/components'
 ## Get SVG Badge
 
 <Callout type="info">
-  `GET /api/v1/repositories/{repositoryUrl}/badges/{badgeId}.svg[?timestamp=<unix_timestamp>]`
+  `GET /api/v1/repositories/{repositoryUrl}/badges/{badgeID}`
 </Callout>
 
-This endpoint gets parameterized with the repository URL and the badge ID. The repository URL is the URL of the repository that should 
-be or was already scanned. The URL should be in the following format: `https://gitlab.opencode.de/zendis-repo-scanner`. 
-**The URL must be URL encoded.** (`https%3A%2F%2Fgitlab.opencode.de%2Fzendis-repo-scanner`)
-
-The badge ID is the title of the badge that should be returned. The badge ID can be one of the following:
-- `MAINTENANCE`
-- `SECURITY`
-- `REUSED`
-
-The timestamp parameter is optional. If it is provided, the endpoint will return the badge that is closest (but never in the future) to 
-the given timestamp. If it is not provided, the endpoint will return the latest badge as a SVG image `image/svg+xml`.
-
-This simplifies the integration of the badges into other elements like README files or websites.
-
-## Get Badge Explanation
-
-<Callout type="info">
-  `GET /api/v1/repositories/{repositoryUrl}/badges/{badgeId}[?timestamp=<unix_timestamp>]`
-</Callout>
+This endpoint returns the **SVG badge** for the given repository URL and badge ID.
 
 This endpoint gets parameterized with the repository URL and the badge ID. The repository URL is the URL of the repository that should 
-be or was already scanned.
+be or was already scanned. **The URL must be URL encoded** 
+(`https://gitlab.opencode.de/zendis-repo-scanner` → `https%3A%2F%2Fgitlab.opencode.de%2Fzendis-repo-scanner`).
+
+The badge ID is the title of the badge that should be returned. The available badges and therefore the badge IDs are defined in the
+[.badge-api.yaml](/concepts/configuration).
 
-The badge ID is the title of the badge that should be returned.
+### Example Request
 
-The endpoint will return the badge evaluation as JSON. The timestamp parameter is optional. If it is provided, the endpoint will return the 
-badge that is closest (but never in the future) to the given timestamp. If it is not provided, the endpoint will return the latest badge 
-evaluation. It is a subset of the whole SARIF response.
+<Tabs items={['GO', 'JavaScript', 'curl']}>
+    <Tabs.Tab>
+        ```go filename="main.go" copy
+        package main
 
-### Example Response
+        import (
+            "fmt"
+            "io"
+            "net/http"
+        )
 
-```json
-{
-  "badgeUrl": "https://img.shields.io/badge/maintenance-silver-lightgrey.svg",
-  "badgeId": "MAINTENANCE",
-  "badgeStatus": "silver",
-  "badgeInformationUri": "https://gitlab.opencode.de/zendis-repo-scanner/badges/maintenance.json",
-  "badgeExplanation": {
-    "criteria": [
-      {
-        "description": "The average issue reaction time qualifies as silver (4 days, between 1 and 7 days).",
-        "ruleId": "ISSUE_REACTION_TIME",
-        "value": 4,
-        "status": "silver",
-      },
-      {
-        "description": "The bus factor qualifies as gold (3 contributors or more).",
-        "ruleId": "BUS_FACTOR",
-        "value": 3,
-        "status": "gold",
-      },
-    ],
-    "conclusion": "Based on the evaluation of the above criteria, this project is classified as Silver level maintenance."
+        func main() {
+            url := "https://scanner.zend.is/api/v1/repositories/https%3A%2F%2Fgitlab.opencode.de%2Fzendis-repo-scanner/badges/MAINTAINED"
+            resp, err := http.Get(url)
+            if err != nil {
+                fmt.Println("Error:", err)
+                return
             }
+            defer resp.Body.Close()
+
+            body, _ := io.ReadAll(resp.Body)
+            fmt.Println(string(body))
         }
         ```
+    </Tabs.Tab>
+    <Tabs.Tab>
+        ```js filename="main.js" copy
+        const fetch = require('node-fetch');
 
-The currently provided badgeUrls serve only as an example. They will be dynamically generated in the future.
\ No newline at end of file
+        const url = 'https://scanner.zend.is/api/v1/repositories/https%3A%2F%2Fgitlab.opencode.de%2Fzendis-repo-scanner/badges/MAINTAINED';
+
+        fetch(url)
+        .then(response => response.json())
+        .then(data => console.log(data))
+        .catch(error => console.error('Error:', error));
+        ```
+    </Tabs.Tab>
+    <Tabs.Tab>
+        ```bash filename="cli" copy
+        curl -X GET "https://scanner.zend.is/api/v1/repositories/https%3A%2F%2Fgitlab.opencode.de%2Fzendis-repo-scanner/badges/MAINTAINED"
+        ```
+    </Tabs.Tab>
+</Tabs>

src/pages/concepts/_meta.ts

 export default {
     index: { title: 'Overview' },
-    'active-maintained-badge': { title: 'Active Maintained Badge' },
-    'security-badge': { title: 'Security Badge' },
-    'reuse-badge': { title: 'Reuse Badge' },
+    configuration: { title: 'Configuration' },
+    'official-badges': { title: 'Official Badges' },
+    'implemented-checks': { title: 'Implemented Checks' },
 }

src/pages/concepts/configuration/_meta.ts

+export default {
+    index: { title: 'Configuration File' },
+    'manual-checks': { title: 'Manual Checks' },
+}

src/pages/concepts/configuration/index.mdx

+import { Callout } from 'nextra/components'
+
+# Configuration
+
+<Callout type="info">
+  You can find the configuration file of the official instance [here →](https://gitlab.opencode.de/open-code/badgebackend/badge-api/-/blob/main/.badge-api.yaml)
+</Callout>
+
+The `.badge-api.yaml` configuration file defines a list of badges, their levels and their criteria. The file is structured as follows:
+
+```yaml filename=".badge-api.yaml" copy
+badges:
+  - id: your-badge-name 
+    description: "Description of this badge"
+    # ORDERED list of levels of your badge (e.g. bronze, silver, gold)
+    levels:
+    - name: level-1-name
+      svgUrl: https://gitlab.opencode.de/.../raw/main/assets/badge-xy-level-1.svg
+      # Optional - if true, the checks of this level are not necessary for the next higher level, default is false
+      notNecessaryForNextHigherLevels: true
+      description: "Description of the level"
+      # List of checks for this level, these can be one of the implemented types (see /implemented-checks) or of type MANUAL
+      checks:
+      - type: PACKAGES
+        description: "Describe the check in context of your badge and level"
+        # sense of these options depends on the check
+        threshold:
+          timeRangeInMonths: 6
+          min: 1
+          max: 3
+      - type: MANUAL 
+        description: "Description of the manual check"
+        # For more details see /concepts/configuration/manual-checks
+        # URL to the JSON file that contains a list of granted projects or a regex pattern for granted projects 
+        decisionJsonUrl: "https://gitlab.opencode.de/.../raw/main/badges/manual-check.json"
+```

src/pages/concepts/configuration/manual-checks.mdx

+# Manual checks
+
+Manual checks are a special type of check that is not automatically evaluated by the badge API. 
+Instead, the result of the check is provided by a JSON file that is hosted on a server reachable by the Badge API Instance. 
+The JSON file contains a list of granted projects or a regex pattern for granted projects.
+
+You can provide a GitLab personal access token via the environment variable `GITLAB_TOKEN` to access a private repository 
+where the JSON file is stored.
+
+```json filename="manual-check.json" copy
+{
+    "granted": [],
+    "grantedRegex": [
+        "^https://gitlab\\.opencode\\.de.*"
+    ]
+}
+```
+
+The file is referenced in the `.badge-api.yaml` configuration file of the badge. 
+See more details about the [configuration file](/concepts/configuration).
\ No newline at end of file

src/pages/concepts/implemented-checks/_meta.ts

+export default {
+    index: { title: 'Overview' },
+}

src/pages/concepts/implemented-checks/ci-pipeline.mdx

+import { Callout } from 'nextra/components'
+
+# CI Pipeline
+
+<Callout type="default">
+  Check type: `CI_PIPELINE`
+</Callout>
+
+This check queries the GitLab API and counts the number of CI pipeline runs (whether successfull or failed)
+in the time range.
+The check passes if the number of commits is greater than or equal to the minimum threshold.
+
+The number of successfull CI pipeline runs is provided as info in the evidence of the API Response.
+
+```yaml filename=".badge-api.yaml" copy
+- type: CI_PIPELINE
+  description: "Describe the check in context of your badge and level"
+  threshold:
+    timeRangeInMonths: 6
+    min: 1
+```
+
+### Background
+
+Measuring the number of CI pipeline runs can help gauge the stability and reliability of a project's 
+development process. A high number of successful pipeline runs indicates a well-maintained and 
+stable codebase, with regular testing and validation.
+
+- Continuous Integration Health: Frequent CI pipeline runs indicates that the project is undergoing regular 
+automated testing, catching errors early, and ensuring the quality of the software.
+
+- Development Efficiency: A smooth CI pipeline also reflects the development team's efficiency in 
+integrating and testing new changes, improving the project's overall workflow and reducing the likelihood of issues in production.
\ No newline at end of file

src/pages/concepts/implemented-checks/commits.mdx

+import { Callout } from 'nextra/components'
+
+# Commits
+
+<Callout type="default">
+  Check type: `COMMITS`
+</Callout>
+
+This check queries the GitLab API and counts the number of commits in a given time range. 
+The check passes if the number of commits is greater than or equal to the minimum threshold.
+
+```yaml filename=".badge-api.yaml" copy
+- type: COMMITS
+  description: "Describe the check in context of your badge and level"
+  threshold:
+    timeRangeInMonths: 6
+    min: 5
+```
+
+### Background
+
+Counting commits within a time range can be part of measuring a project's activity and maintenance. 
+Frequent commits indicate active development, bug fixes, and ongoing improvements. A high commit 
+count can reflect engaged contributors and project evolution, while fewer commits may signal stagnation.
\ No newline at end of file

src/pages/concepts/implemented-checks/index.mdx

+# Overview of Implemented Checks
+
+The following checks are implemented and can be used to generate badges:
+
+- [`CI_PIPELINE` ↗](/concepts/implemented-checks/ci-pipeline)
+- [`COMMITS` ↗](/concepts/implemented-checks/commits)
+- [`ISSUE_REACTION_TIME` ↗](/concepts/implemented-checks/issue-reaction-time)
+- [`PACKAGES` ↗](/concepts/implemented-checks/packages)
+- [`RELEASES` ↗](/concepts/implemented-checks/releases)
\ No newline at end of file

src/pages/concepts/implemented-checks/issue-reaction-time.mdx

+import { Callout } from 'nextra/components'
+
+# Issue Reaction Time
+
+<Callout type="default">
+  Check type: `ISSUE_REACTION_TIME`
+</Callout>
+
+This check queries the GitLab API for the minimum time it takes for a project member to react to an issue in the given time range.
+The check passes if the number of commits is greater than or equal to the minimum threshold.
+
+```yaml filename=".badge-api.yaml" copy
+- type: ISSUE_REACTION_TIME
+  description: "Describe the check in context of your badge and level"
+  threshold:
+    timeRangeInMonths: 3
+    max: 7
+```
+
+The issue response time is the time between the creation of an issue in a project and the first valid response.
+
+A **project member** is a user matching one of the following criteria:
+
+- A member of the project (as returned by the project member API of GitLab)
+- A user who has created at least 5% (magic number) of all issues and/or commits in the project
+
+**The conditions apply simultaneously and not independently of each other:**
+
+- If a project does not have any issues, the check will pass.
+- Issues created by project members are not considered.
+- Every (automatic) action in the stream of an issue, except comments such as “Mentioned in MR” or “labeled” or “Assigned to” etc. are evaluated as a valid issue reaction.
+- A comment is considered a valid response if the comment is submitted by a project member.
+- A comment is not considered a valid response if a non-project member responds to the ticket of a non-project member.
+
+### Background
+
+Measuring issue reaction time is a valuable metric for assessing a project's maintenance and responsiveness. 
+A quick reaction time indicates that project maintainers are actively monitoring and addressing issues, which 
+reflects good project health and responsiveness.
+
+- Indicator of Active Maintenance: Fast issue responses signal that the project is being actively maintained, 
+with attention to bugs, feature requests, or other user concerns. Slow reactions might suggest neglect, 
+which could impact the user experience or drive away contributors.
+
+- Community Engagement: Quick reactions from project members also demonstrate an engaged and supportive community.
+It shows that maintainers or contributors are available to help, fostering a more collaborative and productive environment.
+
+- User Confidence: Projects with shorter issue reaction times inspire greater confidence in users, as they know 
+their concerns will be addressed promptly, making the project more appealing for adoption and contribution.
+
+In summary, tracking issue reaction time helps gauge the level of active maintenance, community involvement, 
+and responsiveness, which are crucial for the long-term success and sustainability of a project.
\ No newline at end of file

src/pages/concepts/implemented-checks/packages.mdx

+import { Callout } from 'nextra/components'
+
+# Packages
+
+<Callout type="default">
+  Check type: `PACKAGES`
+</Callout>
+
+The check passes if the project has a packaging system in place and used it the give times during the given time range.
+It checks the container registry, the package registry and the releases. It expects either a release to 
+have assets or packages inside those two registries.
+
+
+```yaml filename=".badge-api.yaml" copy
+- type: PACKAGES
+  description: "Describe the check in context of your badge and level"
+  threshold:
+    timeRangeInMonths: 6
+    max: 1
+```
+
+### Background
+
+Packaging is a way to distribute software. It is important to have a packaging system in place to make it 
+easier for users to install and use the software. Packaging systems can help automate the process of 
+installing software, manage dependencies, and ensure that the software is installed correctly.
+Regularly updating these registries signals active maintenance, showing that the project is well-supported
+and evolving. Versioning helps users track updates and access stable releases, while consistent
+packaging enhances compatibility and consistency across environments. Overall, using packaging systems
+improves software accessibility, signals good project health, and fosters reliability and reuse.
\ No newline at end of file

src/pages/concepts/implemented-checks/releases.mdx

+import { Callout } from 'nextra/components'
+
+# Releases
+
+<Callout type="default">
+  Check type: `RELEASES`
+</Callout>
+
+This check queries the GitLab API and counts the number of tags/releases in the time range.
+The check passes if the number of tags/releases is greater than or equal to the minimum threshold.
+
+```yaml filename=".badge-api.yaml" copy
+- type: RELEASES
+  description: "Describe the check in context of your badge and level"
+  threshold:
+    timeRangeInMonths: 6
+    max: 1
+```
+
+### Background
+
+The use of tags and releases in a project can be an indicator of its maintenance, stability, and ease of reuse. 
+Tags and releases allow developers to mark specific points in a project's history, often representing stable versions, 
+important updates, or significant milestones.
+
+- Maintenance Indicator: Regular releases and tags show that a project is actively maintained. If releases are 
+consistently made, it indicates that the project is receiving attention and updates from its maintainers. 
+Conversely, a lack of releases over a prolonged period might suggest that the project is abandoned or in a stagnant state.
+
+- Versioning and Stability: Tags often correspond to stable points in the project's development. 
+They help define and communicate specific versions of the software, making it easier to track 
+changes over time. Users or other developers relying on your project can be confident in the 
+version they're using, knowing it's a defined, stable release.
+
+- Ease of Reuse: Projects with regular, well-documented releases are easier to reuse in other projects. 
+When developers can clearly see what versions of a project are available, it's much simpler to pick the right 
+one for their needs. Furthermore, proper tagging allows users to access more recent or earlier versions of the project, 
+if needed, without the risk of breaking changes or similar issues.
+
+In essence, keeping tags and releases up-to-date and within a sensible threshold makes your project 
+more attractive for contributors, users, and those looking to integrate it into their own work. 
+It builds trust, improves usability, and ensures your project remains relevant over time.

src/pages/concepts/official-badges/_meta.ts

+export default {
+    'active-maintained-badge': { title: 'Active Maintained Badge' },
+    'security-badge': { title: 'Security Badge' },
+    'reuse-badge': { title: 'Reuse Badge' },
+}

src/pages/concepts/active-maintained-badge.mdx → src/pages/concepts/official-badges/active-maintained-badge.mdx

 ---
 sidebar_position: 2
 ---
+import { Callout } from 'nextra/components'
 
 # Active Maintained Badge
 
+<Callout type="info">
+**Status: In development**
+</Callout>
+
+
 <div className="flex justify-center"><img src="/assets/badges/badges-maintained.svg" className=""/></div>
 
 The active maintained badge is a badge that indicates the maintenance status of a repository.
 The badge is based on the following criteria:
 
 ### Bronze
-- Number of commits: 30 or more in timeframe
-- Bug-Report process in place: __Yes__/No
-- Issue reaction time: 14Days or less in timeframe
+- Number of commits: A minimum of 5 commits within the last 6 months
 
 ### Silver
 - All criteria from bronze
-- Number of releases: 1 or more in timeframe
+- Issue reaction time: There are reactions on issues within 7 days in a timeframe of the last 3 months
 
 ### Gold
 - All criteria from silver
-- Bus factor: 3 or more in timeframe
-- Elephant factor: 2 or more in timeframe
\ No newline at end of file
+- Releases: There was at least one release or tag created within the last 6 months
+- Elephant Factor: TBD
+- Bus Factor: TBD
\ No newline at end of file

src/pages/concepts/reuse-badge.mdx → src/pages/concepts/official-badges/reuse-badge.mdx

 ---
 sidebar_position: 4
 ---
+import { Callout } from 'nextra/components'
 
 # Reuse Badge
 
+<Callout type="info">
+**Status: In development**
+</Callout>
+
 <div className="flex justify-center"><img src="/assets/badges/badges-reuse.svg" className=""/></div>
 
 The reuse badge is a badge that indicates the reuse status of a repository. 
 The badge is based on the following criteria:
 
-### Ready for reuse
+### Ready for reuse (bronze)
 
-- Bug-Report process in place:
-- Issue reaction time: 14 days or less in timeframe
-- Ensure build:
-- Packaging:
+- Packages: There was at least one package/ container published in the projects package/ container registry within the last 6 months
+- CI-Pipelines: There has been at least one CI-Pipeline within the last 6 months
 
-### Actievly reused
+### Actively reused
 
-- Proof of reuse submitted: 1 or more
+- Proof of reuse submitted: TBD

src/pages/concepts/security-badge.mdx → src/pages/concepts/official-badges/security-badge.mdx

 ---
 sidebar_position: 3
 ---
+import { Callout } from 'nextra/components'
 
 # Security Badge
 
+<Callout type="warning">
+**Status: In development**
+</Callout>
+
 <div className="flex justify-center"><img src="/assets/badges/badges-security.svg" className=""/></div>
 
 The active maintained badge is a badge that indicates the security status of a repository.
@@ -11,17 +16,17 @@ The badge is based on the following criteria:
 
 ### Bronze
 - Bug-Report process in place:
-- Issue reaction time:
-- Branch protection:
-- Vulnarability checks - CVE Age:
-- Vulnarability checks - Remidiation time:
+- Issue reaction time: TBD
+- Branch protection: TBD
+- Vulnerability checks - CVE Age: TBD
+- Vulnerability checks - Remediation time: TBD
 
 ### Silver
 - All criteria from bronze
-- Security Policy (SECURITY.md):
-- No release with known vulnarabilities:a
+- Security Policy (SECURITY.md): TBD
+- No release with known vulnerabilities: TBD
 
 ### Gold
 - All criteria from silver
-- Signed Releases:
-- Code-Review process in place:
\ No newline at end of file
+- Signed Releases: TBD
+- Code-Review process in place: TBD
\ No newline at end of file

theme.config.tsx

@@ -54,7 +54,7 @@ const config: DocsThemeConfig = {
         </span>
     ),
     sidebar: {
-        defaultMenuCollapseLevel: 1,
+        defaultMenuCollapseLevel: 2,
     },
     project: {
         link: 'https://gitlab.opencode.de/open-code/badgebackend/badge-api',
@@ -99,7 +99,7 @@ const config: DocsThemeConfig = {
                     <a
                         className="text-blue-500 hover:text-blue-300"
                         title="Impressum"
-                        href="#"
+                        href="https://opencode.de/de/impressum"
                         target="_blank"
                         rel="noopener noreferrer"
                     >
@@ -108,7 +108,7 @@ const config: DocsThemeConfig = {
                     <a
                         className="text-blue-500 hover:text-blue-300"
                         title="Datenschutz"
-                        href="#"
+                        href="https://opencode.de/de/datenschutz"
                         target="_blank"
                         rel="noopener noreferrer"
                     >