This commit is contained in:
ValueOn AG 2025-09-25 21:01:10 +02:00
parent cb8d337cf9
commit dec5f83260
10 changed files with 3255 additions and 1 deletions

1009
mandates/bwt/script.md Normal file

File diff suppressed because it is too large Load diff

30
mandates/pek/bostich.mtl Normal file
View file

@ -0,0 +1,30 @@
# Material-Definitionen für Bostich Locher
# Bostich.mtl
newmtl dark_blue
Ka 0.1 0.1 0.3
Kd 0.2 0.2 0.6
Ks 0.8 0.8 0.9
Ns 100.0
illum 2
newmtl light_gray
Ka 0.3 0.3 0.3
Kd 0.7 0.7 0.7
Ks 0.2 0.2 0.2
Ns 50.0
illum 2
newmtl white
Ka 0.8 0.8 0.8
Kd 0.9 0.9 0.9
Ks 0.1 0.1 0.1
Ns 30.0
illum 2
newmtl metal
Ka 0.2 0.2 0.2
Kd 0.6 0.6 0.6
Ks 0.9 0.9 0.9
Ns 200.0
illum 2

244
mandates/pek/bostich.obj Normal file
View file

@ -0,0 +1,244 @@
# Bostich 2-Loch Locher 3D Modell
# Abmessungen: 20cm x 10cm x 10cm
# Erstellt basierend auf Fotos
mtllib bostich.mtl
# Hauptkörper - Basis (dunkelblau)
# Vorne
v -10.0 -5.0 5.0
v 10.0 -5.0 5.0
v 10.0 5.0 5.0
v -10.0 5.0 5.0
# Hinten
v -10.0 -5.0 -5.0
v 10.0 -5.0 -5.0
v 10.0 5.0 -5.0
v -10.0 5.0 -5.0
# Obere Struktur (hellgrau/weiß)
# Vorne
v -8.0 -4.0 5.0
v 8.0 -4.0 5.0
v 8.0 4.0 5.0
v -8.0 4.0 5.0
# Hinten
v -8.0 -4.0 -3.0
v 8.0 -4.0 -3.0
v 8.0 4.0 -3.0
v -8.0 4.0 -3.0
# Hebel (dunkelblau)
# Vorne
v -6.0 -3.0 5.0
v 6.0 -3.0 5.0
v 6.0 3.0 5.0
v -6.0 3.0 5.0
# Hinten
v -6.0 -3.0 3.0
v 6.0 -3.0 3.0
v 6.0 3.0 3.0
v -6.0 3.0 3.0
# Papierführung (weiß)
# Basis
v -2.0 -5.0 5.0
v 2.0 -5.0 5.0
v 2.0 -5.0 8.0
v -2.0 -5.0 8.0
# Verlängerung
v -1.5 -5.0 8.0
v 1.5 -5.0 8.0
v 1.5 -5.0 12.0
v -1.5 -5.0 12.0
# Lochstanzen (Metall)
# Stanze 1 (links)
v -3.0 -0.5 5.0
v -2.0 -0.5 5.0
v -2.0 0.5 5.0
v -3.0 0.5 5.0
v -3.0 -0.5 -5.0
v -2.0 -0.5 -5.0
v -2.0 0.5 -5.0
v -3.0 0.5 -5.0
# Stanze 2 (rechts)
v 2.0 -0.5 5.0
v 3.0 -0.5 5.0
v 3.0 0.5 5.0
v 2.0 0.5 5.0
v 2.0 -0.5 -5.0
v 3.0 -0.5 -5.0
v 3.0 0.5 -5.0
v 2.0 0.5 -5.0
# Federn (Metall)
# Feder 1
v -2.5 -0.3 3.0
v -2.0 -0.3 3.0
v -2.0 0.3 3.0
v -2.5 0.3 3.0
v -2.5 -0.3 1.0
v -2.0 -0.3 1.0
v -2.0 0.3 1.0
v -2.5 0.3 1.0
# Feder 2
v 2.0 -0.3 3.0
v 2.5 -0.3 3.0
v 2.5 0.3 3.0
v 2.0 0.3 3.0
v 2.0 -0.3 1.0
v 2.5 -0.3 1.0
v 2.5 0.3 1.0
v 2.0 0.3 1.0
# Schrauben (Metall)
# Schraube 1
v 4.0 -2.0 4.0
v 4.5 -2.0 4.0
v 4.5 -1.5 4.0
v 4.0 -1.5 4.0
# Schraube 2
v 4.0 1.5 4.0
v 4.5 1.5 4.0
v 4.5 2.0 4.0
v 4.0 2.0 4.0
# Flächen definieren
# Hauptkörper - Basis (dunkelblau)
g base
usemtl dark_blue
# Vorderseite
f 1 2 3 4
# Rückseite
f 5 8 7 6
# Oben
f 1 5 6 2
f 2 6 7 3
f 3 7 8 4
f 4 8 5 1
# Unten
f 1 4 3 2
f 5 6 7 8
# Obere Struktur (hellgrau)
g upper_structure
usemtl light_gray
# Vorderseite
f 9 10 11 12
# Rückseite
f 13 16 15 14
# Oben
f 9 13 14 10
f 10 14 15 11
f 11 15 16 12
f 12 16 13 9
# Unten
f 9 12 11 10
f 13 14 15 16
# Hebel (dunkelblau)
g lever
usemtl dark_blue
# Vorderseite
f 17 18 19 20
# Rückseite
f 21 24 23 22
# Oben
f 17 21 22 18
f 18 22 23 19
f 19 23 24 20
f 20 24 21 17
# Unten
f 17 20 19 18
f 21 22 23 24
# Papierführung (weiß)
g paper_guide
usemtl white
# Basis
f 25 26 27 28
# Verlängerung
f 29 30 31 32
# Seiten
f 25 29 32 28
f 26 30 31 27
f 28 32 31 27
f 25 26 30 29
# Lochstanzen (Metall)
g punches
usemtl metal
# Stanze 1 - Zylinder
f 33 34 35 36
f 37 40 39 38
f 33 37 38 34
f 34 38 39 35
f 35 39 40 36
f 36 40 37 33
# Stanze 2 - Zylinder
f 41 42 43 44
f 45 48 47 46
f 41 45 46 42
f 42 46 47 43
f 43 47 48 44
f 44 48 45 41
# Federn (Metall)
g springs
usemtl metal
# Feder 1
f 49 50 51 52
f 53 56 55 54
f 49 53 54 50
f 50 54 55 51
f 51 55 56 52
f 52 56 53 49
# Feder 2
f 57 58 59 60
f 61 64 63 62
f 57 61 62 58
f 58 62 63 59
f 59 63 64 60
f 60 64 61 57
# Schrauben (Metall)
g screws
usemtl metal
# Schraube 1
f 65 66 67 68
# Schraube 2
f 69 70 71 72

Binary file not shown.

After

Width:  |  Height:  |  Size: 715 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 559 KiB

1489
mandates/pek/haus.dxf Normal file

File diff suppressed because it is too large Load diff

File diff suppressed because one or more lines are too long

View file

@ -0,0 +1,170 @@
### Gateway Architektur Überblick (aktuell in `gateway/`)
Diese Seite fasst die aktuelle Struktur des Gateways zusammen und stellt sie mit MermaidDiagrammen dar. Die Ebenen entsprechen deinem Schema: Connectors → Interfaces → Services → Workflows, ergänzt um Routes, Security/Middlewares, Shared und Datamodels.
---
### Layered Overview
```mermaid
flowchart LR
%% Entry
Client([Client / Frontend / Tests]) -->|HTTP| App[FastAPI app.py]
%% Routes
subgraph Routes[gateway/modules/routes]
RA[routeAdmin]
RAttr[routeAttributes]
RConn[routeDataConnections]
RFiles[routeDataFiles]
RMand[routeDataMandates]
RNeut[routeDataNeutralization]
RProm[routeDataPrompts]
RUsers[routeDataUsers]
RWF[routeWorkflows]
RChat[routeChatPlayground]
RSecL[routeSecurityLocal]
RSecM[routeSecurityMsft]
RSecG[routeSecurityGoogle]
RVoiceG[routeVoiceGoogle]
RVoiceS[routeVoiceStreaming]
RSecA[routeSecurityAdmin]
end
App --> RA & RAttr & RConn & RFiles & RMand & RNeut & RProm & RUsers & RWF & RChat & RSecL & RSecM & RSecG & RVoiceG & RVoiceS & RSecA
%% Middlewares / Security / Shared
subgraph Security[gateway/modules/security]
CSRF[csrf]
TRM[tokenRefreshMiddleware]
JWT[jwtService]
AUTH[auth]
TOK[tokenManager]
end
App -. middleware .-> CSRF & TRM
App -. uses .-> JWT & AUTH & TOK
subgraph Shared[gateway/modules/shared]
CFG[configuration]
LOG[auditLogger]
EVT[eventManagement]
TZ[timezoneUtils]
ATTR[attributeUtils]
end
App -. uses .-> CFG & LOG & EVT
%% Features (init triggers etc.)
subgraph Features[gateway/modules/features]
FInit[init]
FChat[chatPlayground]
FNeutral[neutralizePlayground]
FSync[syncDelta]
end
App --> FInit
RChat --> FChat
%% Service Center
subgraph ServiceCenter[gateway/modules/services/__init__.py]
SC[Services registry/factory\n(PublicService wrappers)]
end
%% Services
subgraph Services[gateway/modules/services]
SAi[serviceAi]
SDocE[serviceDocumentExtraction]
SDocG[serviceDocumentGeneration]
SNeut[serviceNeutralization]
SShare[serviceSharepoint]
STicket[serviceTicket]
SWeb[serviceWeb]
SWF[serviceWorkflow]
end
%% Interfaces
subgraph Interfaces[gateway/modules/interfaces]
IApp[interfaceAppObjects]
IComp[interfaceComponentObjects]
IChat[interfaceChatObjects]
IWeb[interfaceWebObjects]
IAi[interfaceAiObjects]
end
%% Connectors
subgraph Connectors[gateway/modules/connectors]
KOpenAI[connectorAiOpenai]
KAnth[connectorAiAnthropic]
KTavily[connectorWebTavily]
KJira[connectorTicketsJira]
KClickup[connectorTicketsClickup]
KGSpeech[connectorGoogleSpeech]
KPg[connectorDbPostgre]
KJson[connectorDbJson]
end
%% Datamodels
subgraph Datamodels[gateway/modules/datamodels]
DMUAM[datamodelUam]
DMChat[datamodelChat]
DMAi[datamodelAi]
DMWeb[datamodelWeb]
DMFiles[datamodelFiles]
DMVoice[datamodelVoice]
DMNeut[datamodelNeutralizer]
DMWork[datamodelWorkflow]
DMInit[__init__ (namespace)]
end
%% Workflows
subgraph Workflows[gateway/modules/workflows]
WM[workflowManager]
WMethods[methods/*]
WProc[processing/*]
end
%% Flows
Routes -->|calls| SC
SC --> SAi & SDocE & SDocG & SNeut & SShare & STicket & SWeb & SWF
SAi & SDocE & SDocG & SNeut & SShare & STicket & SWeb & SWF --> IApp & IComp & IChat & IWeb & IAi
IApp & IComp & IChat & IWeb & IAi --> KOpenAI & KAnth & KTavily & KJira & KClickup & KGSpeech & KPg & KJson
WMethods & WM --> SC
Services --> DMUAM & DMChat & DMAi & DMWeb & DMFiles & DMVoice & DMNeut & DMWork
```
---
### Request / Action Sequence
```mermaid
sequenceDiagram
participant C as Client
participant A as app.py (FastAPI)
participant R as Route (z.B. routeWorkflows)
participant SC as Services registry
participant S as Service (z.B. WorkflowService)
participant I as Interface (z.B. interfaceWebObjects)
participant K as Connector (z.B. connectorWebTavily)
participant EXT as External API
C->>A: HTTP Request
A->>R: Dispatch via APIRouter
R->>SC: get Services(user, workflow)
SC->>S: resolve service (PublicService proxy)
S->>I: normalized call (search/summarize/...)
I->>K: vendor-spezifischer Request
K->>EXT: API/SDK Call (Auth, Retries)
EXT-->>K: Response
K-->>I: Mapping → DTO
I-->>S: Normalized result
S-->>R: Business output
R-->>A: Response model
A-->>C: JSON
```
---
### Hinweise
- Die Services werden zentral in `modules/services/__init__.py` registriert und als `PublicService` nur mit öffentlichen Methoden exponiert.
- Interfaces kapseln VendorDetails; Services hängen von Interfaces, nicht direkt von Connectors.
- `modules/features/init.py` startet initiale Trigger beim AppStart.
- Security/Middlewares: CSRF + TokenRefresh sind global aktiviert; zusätzliche AuthN/AuthZ Utilities in `modules/security/*`.

View file

@ -0,0 +1,312 @@
### Gateway Development Framework: Connectors → Interfaces → Services → Workflows
This document explains the gateway's code logic and development framework to build market customer journey features. It focuses on how connectors, interfaces, and services compose a standardized services landscape that workflows and agent models can consume to perform tasks and actions.
---
### Purpose
- **Unify external tools**: Combine many thirdparty APIs and utilities behind a consistent interface.
- **Standardize service design**: Model capabilities as reusable services with clear contracts.
- **Enable workflow automation**: Let agent models orchestrate multistep tasks using the centralized services.
---
### HighLevel Architecture
1. **Connectors**: Adapters for specific external tools/platforms (auth, transport, retries, mapping).
2. **Interfaces**: Normalization layer exposing common contracts independent of any single vendor.
3. **Services**: Businesslevel capabilities built on interfaces, composed into featureready functions.
4. **Service Center**: Central registry/factory to discover, configure, and call services consistently.
5. **Workflows & Agents**: Orchestrations that call services to perform tasks/actions in a workflow engine.
Data/control flow: Client or workflow → Service Center → Service → Interface → Connector → External Tool
---
### Directory Overview (gateway)
- `gateway/modules/connectors/`: Vendorspecific adapters (HTTP clients, SDK wrappers, auth, mapping).
- `gateway/modules/interfaces/`: Stable contracts and DTOs decoupling services from vendors.
- `gateway/modules/services/`: Business capabilities built from interfaces (e.g., AI, search, files, messaging).
- `gateway/modules/workflows/`: Methods/engines that orchestrate tasks and call services; agent models live here.
- `gateway/modules/routes/`: HTTP endpoints exposing service and workflow capabilities.
- `gateway/modules/security/`: Key management, encryption, and role-based access across services.
- `gateway/modules/shared/`: Cross-cutting utilities (logging, config, error handling, typing).
---
### 1) Connectors: Many External Tools, One Adapter Shape
- **Role**: Provide the lowest-level integration with external systems (API clients, SDKs, auth, retries).
- **Responsibility**:
- Authentication and credential handling
- Transport (HTTP/WS), backoff/retry, circuit breaking
- Response normalization to a minimal internal shape
- **Output**: Vendorflavored data mapped to connector models, not directly used by workflows.
Key guidelines:
- Keep connectors vendorspecific and replaceable.
- No business logic; only integration concerns and basic mapping.
---
### 2) Interfaces: Stable Contracts Over Connectors
- **Role**: Define capabilityoriented contracts (e.g., `ChatModel`, `WebSearch`, `FileStore`) and map connector outputs into interface DTOs.
- **Responsibility**:
- Normalize differing vendors into consistent methods and data shapes
- Hide vendor peculiarities behind clear, typed DTOs
- Offer capability toggles and sensible defaults
- **Output**: Clean, stable methods used by services (e.g., `sendMessage`, `search`, `uploadFile`).
Key guidelines:
- Prefer capability names over vendor names.
- Keep interfaces small, cohesive, and testable with mocks.
---
### 3) Services: BusinessLevel Capabilities
- **Role**: Compose one or more interfaces to implement featureready operations (e.g., "answer question with web grounding").
- **Responsibility**:
- Apply business rules, guardrails, validation, transformations
- Orchestrate multiple interfaces/connectors when needed
- Emit domain events/metrics and enforce security policies
- **Output**: Highlevel operations that workflows can call atomically.
Key guidelines:
- Services depend on interfaces, not connectors.
- Keep input/output DTOs explicit and versioned when necessary.
---
### 4) Centralized Service Center
- **Role**: A registry/factory that instantiates and exposes services with consistent configuration and lifecycle.
- **Responsibility**:
- Discoverability: list/get services by capability key
- Configuration: environment, credentials, routing to specific vendors
- Crosscutting: logging, tracing, caching, ratelimits, RBAC checks
Usage pattern:
1. Workflow requests a capability (e.g., `ai.answerWithWebGrounding`).
2. Service Center resolves the concrete service instance configured for the tenant/env.
3. Workflow calls the service method with typed input; receives typed output.
---
### 5) Workflows & Agent Models
- **Role**: Coordinate tasks and actions by invoking services in sequence/branches/loops.
- **Responsibility**:
- Maintain execution state and step transitions
- Choose actions using agent models and policies
- Handle retries/compensation and record audit logs
Typical pattern:
1. Ingest user intent/context.
2. Plan next action (agent model) or follow a defined state machine.
3. Call one or more services via the Service Center.
4. Persist outputs, update state, decide next step.
---
### Standardized Interface Example (Conceptual)
```text
interface WebSearch {
search(query: string, topK: number): SearchResult[]
}
interface ChatModel {
sendMessage(messages: Message[], tools?: ToolDef[]): ModelResponse
}
```
Vendors like Tavily/Bing/SerpAPI implement `WebSearch` through their connectors; LLM providers implement `ChatModel`. Services compose these interfaces.
---
### Example Service Composition (Conceptual)
```text
Service: AnswerWithWebGrounding
Inputs: question, constraints
Steps:
1) WebSearch.search → urls/snippets
2) Fetch & summarize sources
3) ChatModel.sendMessage with citations → final answer
Outputs: answer, citations, provenance
```
---
### Adding a New Capability
1. **Connector**: Add vendor adapter in `connectors/` and map outputs to internal models.
2. **Interface**: Implement/extend capability contract in `interfaces/` using the new connector.
3. **Service**: Compose the interface in `services/` to expose a businessoriented method.
4. **Register**: Wire into the Service Center with config/env and RBAC.
5. **Expose**: If needed, add a route in `routes/` for external HTTP access.
6. **Use in Workflows**: Call the new service from methods/agents in `workflows/`.
---
### Security & Governance
- **RBAC**: Enforce rolebased access at the Service Center before invoking services.
- **Secrets**: Manage connector credentials centrally; avoid leaking to workflows.
- **Audit**: Record service calls and workflow steps for traceability.
- **Quotas**: Apply rate limits and budgets per tenant/service.
---
### Observability
- Structured logs at connector, interface, and service layers
- Tracing spans across layers and external calls
- Metrics per capability and vendor, with SLOs
---
### Minimal Request Lifecycle
1. Route receives request or workflow triggers an action.
2. Service Center resolves service instance and validates RBAC.
3. Service executes using interfaces; interfaces call connectors.
4. Results propagate back; logs/metrics recorded; workflow advances state.
---
### Benefits
- **Replace vendors without breaking services** (interfaces shield changes).
- **Accelerate feature delivery** (services are reusable building blocks).
- **Improve reliability and security** (centralized policies and observability).
- **Empower workflows/agents** to perform complex tasks with simple, typed calls.
---
### Quick Map to Code (for orientation)
- `gateway/modules/connectors/` → Vendor adapters (e.g., web search, storage, auth)
- `gateway/modules/interfaces/` → Capability contracts (e.g., `interfaceWebModel`, `interfaceAiModel`)
- `gateway/modules/services/` → Composed capabilities (e.g., `serviceAi`)
- `gateway/modules/workflows/` → Orchestrations/agents (e.g., `methods/methodWeb.py`)
This framework is the backbone for market customer journey features: build once as services, reuse everywhere in workflows.
---
### Visuals
#### Layered Architecture
```mermaid
flowchart TB
subgraph ClientOrWorkflow[Client / Workflow Engine]
C[Feature or Agent Task]
end
subgraph ServiceCenter[Service Center]
SC[Registry / Factory\nRBAC, Config, Observability]
end
subgraph Services[Services]
S1[AI Service]
S2[Web Service]
S3[File Service]
end
subgraph Interfaces[Interfaces]
I1[ChatModel]
I2[WebSearch]
I3[FileStore]
end
subgraph Connectors[Connectors]
K1[Tavily]
K2[Bing]
K3[S3]
K4[LLM Provider]
end
C --> SC --> S1 & S2 & S3
S1 --> I1
S2 --> I2
S3 --> I3
I1 --> K4
I2 --> K1 & K2
I3 --> K3
```
#### Request / Action Sequence
```mermaid
sequenceDiagram
participant Client as Client / Workflow
participant SC as Service Center
participant S as Service
participant I as Interface
participant K as Connector
participant EXT as External Tool
Client->>SC: Request capability (e.g., ai.answerWithWebGrounding)
SC->>SC: RBAC check, resolve config/vendor
SC->>S: Get service instance
S->>I: Call normalized method (e.g., search)
I->>K: Prepare vendor-specific request
K->>EXT: API/SDK call (auth, retries)
EXT-->>K: Response
K-->>I: Map to normalized DTO
I-->>S: Return normalized result
S-->>SC: Business output (validated, enriched)
SC-->>Client: Typed response, telemetry recorded
```
#### Service Center Components
```mermaid
graph LR
subgraph SC[Service Center]
REG[Registry]
CFG[Config / Env]
SEC[RBAC / Policies]
OBS[Logs / Traces / Metrics]
FAC[Factory]
end
REG --> FAC
CFG --> FAC
SEC --> FAC
OBS --> FAC
FAC -->|builds| Svc[(Service Instances)]
subgraph Layers[Below Services]
IF[Interfaces]
CON[Connectors]
end
Svc --> IF --> CON
```
#### Workflow State Machine (Conceptual)
```mermaid
stateDiagram-v2
[*] --> Plan
Plan: Decide next action (agent or rules)
Plan --> CallService: needs external capability
Plan --> Done: no more steps
CallService: Invoke via Service Center
CallService --> HandleResult
HandleResult: Persist, evaluate, log
HandleResult --> Plan: more work
HandleResult --> Done: goal achieved
Done --> [*]
```