docs: add ADR 0043 for GitLab support via webhook bridge

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: ggallen

README.md

@@ -33,7 +33,8 @@ This is not a product spec. It's an evolving exploration of a hard problem space
   - [Performance Verification](docs/problems/performance-verification.md) — Catching agent-introduced performance regressions before they reach production
   - [Production Feedback](docs/problems/production-feedback.md) — How platform execution signals feed back into what agents work on and how they assess risk
   - [Testing the Agents](docs/problems/testing-agents.md) — CI for prompts: regression testing, eval frameworks, and behavioral verification for agent instructions
-  - [GitLab Implementation](docs/problems/gitlab-implementation.md) — Implementation details for GitLab support: webhook security, dispatch pipelines, forge interface evolution
+  - [GitLab Support](docs/problems/gitlab-support.md) — Webhook bridge architecture, token mint extension, credential model, and phased rollout plan for GitLab support
+  - [GitLab Implementation](docs/problems/gitlab-implementation.md) — *(Superseded by [GitLab Support](docs/problems/gitlab-support.md))* Original implementation details for the ADR-0028 approach
   - [Operational Observability](docs/problems/operational-observability.md) — How do the humans operating an autonomous software factory understand what it is doing, debug it when it goes wrong, and improve it over time?
   - [Adaptive Agent Selection](docs/problems/adaptive-agent-selection.md) — Learning which agent/team/workflow configurations work best for which problem classes, using evolutionary algorithms and Thompson Sampling
   - [Platform Nativeness](docs/problems/platform-nativeness.md) — When the platform you automate is also the one you build on: which problems are inherent vs. self-inflicted

docs/ADRs/0028-gitlab-support.md

@@ -1,6 +1,6 @@
 ---
 title: "28. GitLab Support Architecture"
-status: Deprecated
+status: Superseded
 relates_to:
   - agent-infrastructure
   - agent-architecture
@@ -17,7 +17,7 @@ Date: 2026-04-29
 
 ## Status
 
-Deprecated
+Superseded by [ADR 0043](0043-gitlab-support-via-webhook-bridge.md).
 
 ## Context
 

docs/ADRs/0031-reusable-workflows-for-action-installed-distribution.md

@@ -141,7 +141,7 @@ caller's perspective.
   inline, which partially mitigates this.
 - **GitHub-specific mechanism:** `workflow_call` and `secrets:` passthrough are
   GitHub Actions primitives with no direct equivalent in other CI systems.
-  Multi-forge support ([ADR 0028](0028-gitlab-support.md)) will need its own
+  Multi-forge support ([ADR 0043](0043-gitlab-support-via-webhook-bridge.md), supersedes ADR 0028) will need its own
   distribution mechanism (e.g., GitLab CI/CD Components or `include:`)
   independent of this ADR.
 - **Scaffold output changes:** `fullsend admin install` will emit thin callers

docs/ADRs/0036-agent-execution-sandbox.md

@@ -21,7 +21,7 @@ Accepted
 
 ## Context
 
-Fullsend agents execute within isolated sandboxes that enforce security boundaries: filesystem access control, network policy enforcement, and credential isolation (ADR-0017, ADR-0025). The current implementation uses OpenShell with per-agent L7 network policies and runs on GitHub Actions runners. With GitLab support proposed (ADR-0028), the execution architecture needs to work on both GitHub Actions and GitLab CI runners.
+Fullsend agents execute within isolated sandboxes that enforce security boundaries: filesystem access control, network policy enforcement, and credential isolation (ADR-0017, ADR-0025). The current implementation uses OpenShell with per-agent L7 network policies and runs on GitHub Actions runners. With GitLab support planned (ADR-0028, superseded by [ADR-0043](0043-gitlab-support-via-webhook-bridge.md)), the execution architecture needs to work on both GitHub Actions and GitLab CI runners.
 
 The sandbox architecture has multiple concerns that need to be resolved together:
 

docs/ADRs/0043-gitlab-support-via-webhook-bridge.md

@@ -45,6 +45,7 @@ Infrastructure platform choice and configuration are specified in the adopting o
 - Installer scaffold: the `WorkflowsLayer` deploys content from an embedded scaffold (`internal/scaffold/`), keeping deployable files as real files under version control rather than Go string constants.
 - Reusable workflows: agent workflows in `.fullsend` are thin callers (~40-70 lines) that delegate infrastructure logic to upstream reusable workflows (`fullsend-ai/fullsend/.github/workflows/reusable-*.yml`) via `workflow_call`. Infrastructure patches ship once upstream and propagate to all orgs without re-install ([ADR 0031](ADRs/0031-reusable-workflows-for-action-installed-distribution.md)).
 - Event-driven stage dispatch: eliminate `workflow_dispatch` + `gh workflow run` fan-out from `dispatch.yml` in favor of synchronous `workflow_call` so the dispatched run stays linked to the caller ([ADR 0041](ADRs/0041-synchronous-workflow-call-event-dispatch.md)).
+- GitLab support: a webhook bridge Cloud Function translates GitLab webhook events into pipeline triggers with hardcoded `ref=main`. Bridge authenticates to the token mint via OIDC/WIF. Project Access Tokens provide per-role credentials (replacing GitHub Apps). Defense-in-depth: protected CI/CD variables, per-project webhook secrets, payload validation ([ADR 0043](ADRs/0043-gitlab-support-via-webhook-bridge.md)).
 
 **Open questions:**
 
@@ -123,7 +124,7 @@ One concrete implementation option is [`oidcx`](https://github.com/oxidecomputer
 - ~~What identity model fits best — separate bot accounts per agent role, a single bot account with role metadata, GitHub App installations, or something else?~~ Decided in [ADR 0007](ADRs/0007-per-role-github-apps.md).
 - How are credentials rotated and revoked, and who has authority to do that?
 - Does the identity provider integrate with existing secrets management, or is it a new system?
-- How will per-role identity work on GitLab and Forgejo, which lack GitHub's app manifest flow?
+- ~~How will per-role identity work on GitLab and Forgejo, which lack GitHub's app manifest flow?~~ GitLab: decided in [ADR 0043](ADRs/0043-gitlab-support-via-webhook-bridge.md) — per-role Project Access Tokens with role-based permissions. Forgejo remains open.
 
 ## Agent Dispatch and Coordination Layer
 

docs/architecture.md

@@ -922,7 +922,7 @@ spec:
 - [ADR-0036: Agent Execution Sandbox Architecture](../ADRs/0036-agent-execution-sandbox.md)
 - [ADR-0017: Credential Isolation for Sandboxed Agents](../ADRs/0017-credential-isolation-for-sandboxed-agents.md)
 - [ADR-0025: Provider Credential Delivery](../ADRs/0025-provider-credential-delivery-for-sandboxed-agents.md)
-- [ADR-0028: GitLab Support Architecture](../ADRs/0028-gitlab-support.md)
+- [ADR-0028: GitLab Support Architecture](../ADRs/0028-gitlab-support.md) (superseded by [ADR-0043](../ADRs/0043-gitlab-support-via-webhook-bridge.md))
 - [agent-infrastructure.md](../problems/agent-infrastructure.md): Infrastructure layer exploration
 - [OpenShell Documentation](https://docs.nvidia.com/openshell/)
 - [Sigstore Cosign](https://docs.sigstore.dev/cosign/overview/)

docs/plans/agent-execution-environment.md

@@ -1,6 +1,8 @@
 # GitLab Support Implementation Details
 
-This document contains implementation details for GitLab support in fullsend. For the architectural decision and rationale, see [ADR-0028](../ADRs/0028-gitlab-support.md).
+> **Superseded.** This document was written for [ADR-0028](../ADRs/0028-gitlab-support.md), which has been superseded by [ADR-0043](../ADRs/0043-gitlab-support-via-webhook-bridge.md). See [gitlab-support.md](gitlab-support.md) for the current implementation plan.
+
+This document contains implementation details for the original GitLab support approach in fullsend. For the current architectural decision and rationale, see [ADR-0043](../ADRs/0043-gitlab-support-via-webhook-bridge.md).
 
 ## Table of Contents