Benjamin Admin a616b64273
CI / detect-changes (push) Successful in 10s
CI / guardrail-integrity (push) Has been skipped
CI / branch-name (push) Has been skipped
CI / sbom-scan (push) Has been skipped
CI / validate-canonical-controls (push) Successful in 14s
CI / loc-budget (push) Failing after 19s
CI / go-lint (push) Has been skipped
CI / python-lint (push) Has been skipped
CI / nodejs-lint (push) Has been skipped
CI / secret-scan (push) Has been skipped
CI / dep-audit (push) Has been skipped
CI / test-go (push) Successful in 47s
CI / nodejs-build (push) Successful in 2m46s
CI / iace-gt-coverage (push) Successful in 28s
CI / test-python-backend (push) Has been skipped
CI / test-python-document-crawler (push) Has been skipped
CI / test-python-dsms-gateway (push) Has been skipped
feat(iace): Customer-Standard-Reuse across customer's prior projects
[migration-approved]

Task #22. The IACE module is used by a single Maschinenhersteller, but
their plants land at many different end customers. When the safety expert
commissions the second or third plant at the same customer, whole classes
of mitigations (company-wide PPE rules, locked-out energy isolation,
customer-standard signage) are already in place there — but rediscovered
from scratch every project.

Migration 031: iace_projects.customer_name TEXT + partial index.
  The customer is stored as a plain text field rather than a normalised
  iace_customers table (option A from the design discussion). A proper
  customer-management screen can promote this to a FK later without
  data loss.

Backend store_customer_standards.go:
  - ListCustomerStandardSuggestions(projectID, includeVerified) collects
    mitigations from all non-archived prior projects sharing the same
    tenant_id AND case-insensitive customer_name. Aggregates by
    mitigation.name (since same-named measures from different prior
    projects collapse into one suggestion) and surfaces:
      • source_project_count + source_project_names
      • is_customer_standard / has_verified_instances flags
    includeVerified=false → strictly is_customer_standard=true
    includeVerified=true  → also status='verified'
  - ImportCustomerStandardSuggestion(projectID, name): for every prior
    (mitigation.name → hazard.name) pairing, finds matching hazards in
    the current project (by name) and ensures a customer-standard
    mitigation exists. New rows via CreateMitigation (idempotent through
    the UNIQUE(hazard_id, name) from migration 030); existing rows are
    flipped to is_relevant=true + is_customer_standard=true +
    status='verified' via UPDATE.

Routes:
  GET  /api/v1/iace/projects/:id/customer-standards?include_verified=
  POST /api/v1/iace/projects/:id/customer-standards/import   body {name}

Frontend:
  - New page /sdk/iace/[projectId]/customer-standards with:
      • empty-state hint pointing to Auftrag → Kundenname
      • per-suggestion checkbox + per-row Übernehmen button
      • bulk "N übernehmen" button
      • toggle "Auch verifizierte einbeziehen" widening the pool
      • per-suggestion source_project_count + status badges
  - Sidebar item "Kundenstandards" (building icon) placed between
    Verifikation and Nachweise.
  - Order-page now mirrors Auftraggeber.Firmenname into the top-level
    customer_name column on save, so the Reuse feature is fed
    automatically without a separate input field.

The same expert effect from migration 029's is_customer_standard flag —
"I already know it's covered, no evidence needed" — now becomes a
cross-project asset rather than a per-project annotation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-18 22:31:30 +02:00

breakpilot-compliance

DSGVO/AI-Act compliance platform — 10 services, Go · Python · TypeScript

CI Go Python Node.js TypeScript FastAPI DSGVO AI Act LOC guard Services


Overview

breakpilot-compliance is a multi-tenant DSGVO/EU AI Act compliance platform that provides an SDK for consent management, data subject requests (DSR), audit logging, iACE impact assessments, and document archival. It ships as 10 containerised services covering an admin dashboard, a developer portal, a Python/FastAPI backend, a Go AI compliance engine, TTS, and a decentralised document store on IPFS. Every service is deployed automatically via Gitea Actions → Orca on every push to main.


Architecture

Service Tech Port Container
admin-compliance Next.js 15 3007 bp-compliance-admin
backend-compliance Python / FastAPI 0.123 8002 bp-compliance-backend
ai-compliance-sdk Go 1.24 / Gin 8093 bp-compliance-ai-sdk
developer-portal Next.js 15 3006 bp-compliance-developer-portal
breakpilot-compliance-sdk TypeScript SDK (React/Vue/Angular/vanilla)
consent-sdk JS/TS Consent SDK
compliance-tts-service Python / Piper TTS 8095 bp-compliance-tts
document-crawler Python / FastAPI 8098 bp-compliance-document-crawler
dsms-gateway Python / FastAPI / IPFS 8082 bp-compliance-dsms-gateway
dsms-node IPFS Kubo v0.24.0 bp-compliance-dsms-node

All containers share the external breakpilot-network Docker network and depend on breakpilot-core (Valkey, Vault, RAG service, Nginx reverse proxy).


Quick Start

Prerequisites: Docker, Go 1.24+, Python 3.12+, Node.js 20+

git clone ssh://git@gitea.meghsakha.com:22222/Benjamin_Boenisch/breakpilot-compliance.git
cd breakpilot-compliance

# Copy and populate secrets (never commit .env)
cp .env.example .env

# Start all services
docker compose up -d

For the Orca/Hetzner production target (x86_64), use the override:

docker compose -f docker-compose.yml -f docker-compose.hetzner.yml up -d

Development Workflow

Use feature branches off main. Supported prefixes: feat/, feature/, hotfix/.

git checkout main && git pull origin main
git checkout -b feat/my-change
# ... make changes ...
git push origin feat/my-change
# Open a PR → squash merge to main

Push to main triggers:

  1. Gitea Actions — lint → test → validate (see CI Pipeline below)
  2. Orca — automatic build + deploy (~3 min total)

Monitor status: https://gitea.meghsakha.com/Benjamin_Boenisch/breakpilot-compliance/actions


CI Pipeline

Defined in .gitea/workflows/ci.yaml.

Job What it checks
loc-budget All source files ≤ 500 LOC; soft target 300
guardrail-integrity Commits touching guardrail files carry [guardrail-change]
go-lint golangci-lint on ai-compliance-sdk/
python-lint ruff + mypy on Python services
nodejs-lint tsc --noEmit + ESLint on Next.js services
test-go-ai-compliance go test ./... in ai-compliance-sdk/
test-python-backend-compliance pytest in backend-compliance/
test-python-document-crawler pytest in document-crawler/
test-python-dsms-gateway pytest test_main.py in dsms-gateway/
sbom-scan License + vulnerability scan via syft + grype
validate-canonical-controls OpenAPI contract baseline diff

File Budget

Limit Value How to check
Soft target 300 LOC bash scripts/check-loc.sh
Hard cap 500 LOC Same; also enforced by PreToolUse hook + git pre-commit + CI
Exceptions .claude/rules/loc-exceptions.txt Require written rationale + [guardrail-change] commit marker

The .claude/settings.json PreToolUse hook blocks Claude Code from writing or editing files that would exceed the hard cap. The git pre-commit hook re-checks. CI is the final gate.


URL
Admin dashboard https://admin-dev.breakpilot.ai
Developer portal https://developers-dev.breakpilot.ai
Backend API https://api-dev.breakpilot.ai
AI SDK API https://sdk-dev.breakpilot.ai
Gitea repo https://gitea.meghsakha.com/Benjamin_Boenisch/breakpilot-compliance
Gitea Actions https://gitea.meghsakha.com/Benjamin_Boenisch/breakpilot-compliance/actions
S
Description
No description provided
Readme 25 MiB
Languages
TypeScript 43.1%
Python 30.8%
Go 23.5%
Shell 1.2%
PLpgSQL 0.8%
Other 0.3%