What runs inside.
One review workflow, explicit ownership boundaries.
Service map
Deployment and trust boundaries
Routes and Mermaid source
- Team → Backoffice: HTTPS.
- Backoffice → Identity: Authorize.
- Identity → OIDC / Keycloak: OIDC.
- MCP clients → ContextForge: MCP.
- ContextForge → Read receiver: Scoped read.
- Read receiver → Identity: Current access.
- Identity → Private services: Tenant scope.
- ContextForge → ContextForge PG: Own database.
- Private services → Service PostgreSQL: Own databases.
flowchart LR
team["Team / Browser"]
bff["Backoffice / Protected ingress"]
identity["Identity / Tenant and roles"]
oidc["OIDC / Keycloak / Corporate identity"]
agents["MCP clients / Scoped tools"]
cf["ContextForge / Gateway and consent"]
receiver["Read receiver / Recheck access"]
roles["Private services / Control / Worker / Context"]
cfpg["ContextForge PG / Separate owner"]
pg["Service PostgreSQL / Separate DBs and roles"]
team -->|HTTPS| bff
bff -->|Authorize| identity
identity -->|OIDC| oidc
agents -->|MCP| cf
cf -->|Scoped read| receiver
receiver -->|Current access| identity
identity -->|Tenant scope| roles
cf -->|Own database| cfpg
roles -->|Own databases| pgWhere selected review data goes
Routes and Mermaid source
- Your GitLab → Connector: Allowed reads.
- Connector → Context: Pinned revision.
- Context → Worker / PR-Agent: Selected context.
- Worker / PR-Agent → Approved model: Approved material.
- Worker / PR-Agent → Control: Draft findings.
- Control → Connector: Gated actions.
- Control → Service PostgreSQL: Durable history.
flowchart LR
gitlab["Your GitLab / MR / source / CI"]
connector["Connector / GitLab credentials"]
context["Context / Selected source"]
worker["Worker / PR-Agent / Review context"]
model["Approved model / API or official CLI"]
control["Control / Queue and reports"]
pg["Service PostgreSQL / History and ownership"]
gitlab -->|Allowed reads| connector
connector -->|Pinned revision| context
context -->|Selected context| worker
worker -->|Approved material| model
worker -->|Draft findings| control
control -->|Gated actions| connector
control -->|Durable history| pgFrom a change to a team decision
Routes and Mermaid source
- Changed MR → Prepare context: Select.
- Prepare context → Draft findings: Review.
- Draft findings → Team fixes code: Consider.
- Team fixes code → Fresh review: Re-review.
- Fresh review → CI and criteria: Compare evidence.
- CI and criteria → Team decision: Decide separately.
flowchart LR
change["Changed MR / Current SHA"]
prepare["Prepare context / Diff / task / rules"]
draft["Draft findings / Evidence and fix"]
fix["Team fixes code / New SHA"]
recheck["Fresh review / Current source"]
ci["CI and criteria / Separate evidence"]
decision["Team decision / Policy and permission"]
change -->|Select| prepare
prepare -->|Review| draft
draft -->|Consider| fix
fix -->|Re-review| recheck
recheck -->|Compare evidence| ci
ci -->|Decide separately| decisionWho owns what
| Service | Responsibility |
|---|---|
| Identity | Users, tenants, roles, OIDC and authorization. |
| Control | Queue, current SHA, policies, decision history and publication control. |
| Connector | The sole GitLab read/write path, including CI. |
| Worker / PR-Agent | Selected model invocation and draft findings. No independent publisher. |
| Context | Selected source and task context within the authorized scope. |
| ContextForge | Shared MCP gateway. Its own authorization and separate access revocation. |
Data ownership stays explicit
PostgreSQL is required. Services own their databases, credentials and versioned migrations; ContextForge has a separate ordinary owner. Tenant scope comes from trusted authorization, not a request field. Model credentials belong to a specific organization and profile. A shared MCP gateway does not give an agent global permissions.
Network boundaries
Expose only the protected backoffice ingress and approved MCP endpoints. Service APIs remain private. Permit outbound connections only to approved GitLab, OIDC and model destinations. Docker bridges provide connectivity, not a complete egress policy. Firewall rules, corporate CA trust and server-name verification are deployment tasks.