docs(adr): ADR 0063 — GitLab cron-polling event dispatch

README.md

@@ -35,7 +35,7 @@ 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 Implementation](docs/problems/gitlab-implementation.md) — Implementation details for GitLab support: cron-polling event dispatch, pipeline scheduling, forge interface evolution
   - [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

@@ -19,9 +19,11 @@ Date: 2026-04-29
 
 Deprecated — the harness-level forge-specific vs. forge-neutral split
 is now addressed by [ADR 0045](0045-forge-portable-harness-schema.md)
-(forge-portable harness schema). The broader GitLab support architecture
-(CI/CD pipeline mapping, PAT-based auth, webhook bridging) documented
-here remains reference material.
+(forge-portable harness schema). The webhook bridge approach described
+here is superseded by [ADR 0063](0063-gitlab-cron-polling-event-dispatch.md)
+(cron-polling event dispatch), which eliminates webhooks entirely. The
+broader GitLab support architecture (CI/CD pipeline mapping, PAT-based
+auth) documented here remains reference material.
 
 ## Context
 

docs/architecture.md

@@ -47,6 +47,7 @@ Infrastructure platform choice and configuration are specified in the adopting o
 - 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)).
 - Multi-repo management: a `fullsend repos` subcommand group with a declarative `repos.yaml` manifest for managing per-repo installations at scale — bulk install, status, sync, upgrade, and removal across repos and orgs ([ADR 0057](ADRs/0057-repos-management.md)).
 - Dispatch version-skew resolution: per-repo `reusable-dispatch.yml` inlines stage workflow jobs directly, eliminating `@v0` references to `reusable-{stage}.yml` ([ADR 0062](ADRs/0062-dispatch-version-skew.md)).
+- GitLab event dispatch: two-path model — native CI triggers (`merge_request_event`) for MR events, cron-based polling for issues/comments/labels. No external infrastructure (no webhook bridge). Bot PAT via OIDC/WIF from Secret Manager or protected CI/CD variable. Per-repo only ([ADR 0063](ADRs/0063-gitlab-cron-polling-event-dispatch.md)).
 
 **Open questions:**
 
@@ -172,6 +173,7 @@ The existing design principle is that [the repo is the coordinator](problems/age
   evaluated by `fullsend dispatch` with pluggable input/output drivers
   operating on a `NormalizedEvent` struct
   ([ADR 0061](ADRs/0061-harness-cel-dispatch.md)).
+- GitLab dispatch uses cron-polled scheduled pipelines for issue/comment/label events and native `merge_request_event` for MR events. No webhook bridge required (see [ADR 0063](ADRs/0063-gitlab-cron-polling-event-dispatch.md)).
 
 **Open questions:**
 

docs/glossary.md

@@ -39,14 +39,14 @@ See [security-threat-model.md](problems/security-threat-model.md) and [architect
 
 ### Debouncing
 
-Collapsing rapid-fire events on the same issue or PR into a single agent invocation. Without debouncing, a burst of edits to an issue body could trigger multiple redundant triage runs. The [webhook + dispatch service](ADRs/0002-initial-fullsend-design.md#1-webhook--dispatch-service) is responsible for deduplicating flapping events before dispatching work to agents.
+Collapsing rapid-fire events on the same issue or PR into a single agent invocation. Without debouncing, a burst of edits to an issue body could trigger multiple redundant triage runs. The [webhook + dispatch service](ADRs/0002-initial-fullsend-design.md#1-webhook--dispatch-service) (and its GitLab equivalent, the cron poller) is responsible for deduplicating flapping events before dispatching work to agents. On GitHub this uses webhooks; on GitLab it uses cron-polled scheduled pipelines (see [ADR 0063](ADRs/0063-gitlab-cron-polling-event-dispatch.md)).
 See [architecture.md](architecture.md) (building block 1).
 
 ## E
 
 ### Entry Point
 
-The single deterministic component that receives GitHub events (webhooks) and decides which agent combination to run. Previously called **wrapper** — the rename was adopted to avoid confusion with the sandbox/wrapping layer (see [#101](https://github.com/fullsend-ai/fullsend/issues/101) for the terminology evolution). The entry point is non-AI: it is a conventional program (currently Go) that parses events, enforces ACLs on slash commands, validates label transitions, and dispatches to agent runtimes. It does not make LLM calls.
+The single deterministic component that receives forge events and decides which agent combination to run. On GitHub, events arrive via webhooks; on GitLab, via cron-polled scheduled pipelines (see [ADR 0063](ADRs/0063-gitlab-cron-polling-event-dispatch.md)). Previously called **wrapper** — the rename was adopted to avoid confusion with the sandbox/wrapping layer (see [#101](https://github.com/fullsend-ai/fullsend/issues/101) for the terminology evolution). The entry point is non-AI: it is a conventional program (currently Go) that parses events, enforces ACLs on slash commands, validates label transitions, and dispatches to agent runtimes. It does not make LLM calls.
 See [ADR 0002](ADRs/0002-initial-fullsend-design.md) building block 1 and [#101](https://github.com/fullsend-ai/fullsend/issues/101).
 
 ### Escalation
@@ -159,7 +159,7 @@ See [ADR 0002](ADRs/0002-initial-fullsend-design.md) building block 2.
 
 ### Trigger
 
-What initiates an agent run. Could be a GitHub event (issue filed, label applied, comment posted, PR opened, check completed), a [slash command](#slash-command), or a scheduled action. The term is used loosely in discussions — sometimes meaning the raw GitHub webhook event, sometimes meaning the processed signal that actually starts an agent after debouncing and validation. In fullsend's architecture, triggers flow through the [entry point](#entry-point), which normalizes and dispatches them.
+What initiates an agent run. Could be a forge event (issue filed, label applied, comment posted, PR/MR opened, check completed), a [slash command](#slash-command), or a scheduled action. The term is used loosely in discussions — sometimes meaning the raw forge event (GitHub webhook or GitLab cron-polled change), sometimes meaning the processed signal that actually starts an agent after debouncing and validation. In fullsend's architecture, triggers flow through the [entry point](#entry-point), which normalizes and dispatches them.
 See [architecture.md](architecture.md) (building block 1).
 
 ### Triage
@@ -182,7 +182,7 @@ See [security-threat-model.md](problems/security-threat-model.md) and [agent-arc
 
 ### Work Coordinator
 
-The mechanism that assigns work to agents and prevents conflicts. The existing design principle is that the **repo is the coordinator** — branch protection, CODEOWNERS, status checks, and GitHub events provide coordination without a central orchestrator. The work coordinator may be just the glue connecting GitHub webhooks to agent infrastructure, or it may need to be more (e.g., a claim/lock system to prevent two code agents from picking up the same issue).
+The mechanism that assigns work to agents and prevents conflicts. The existing design principle is that the **repo is the coordinator** — branch protection, CODEOWNERS, status checks, and forge events provide coordination without a central orchestrator. The work coordinator may be just the glue connecting forge events to agent infrastructure, or it may need to be more (e.g., a claim/lock system to prevent two code agents from picking up the same issue).
 See [architecture.md](architecture.md) and [#77](https://github.com/fullsend-ai/fullsend/issues/77).
 
 ## Z

docs/normative/normalized-event/v1/README.md

@@ -259,7 +259,7 @@ Example: **GitLab** ([gitlab-implementation.md](../../../problems/gitlab-impleme
 
 | Concern | Illustrative mapping (future) |
 |---------|-------------------------------|
-| Input driver | `gitlab-event` from GitLab webhook payload |
+| Input driver | `gitlab-event` from GitLab CI event payload (cron-polled or `merge_request_event`; see [ADR 0063](../../../ADRs/0063-gitlab-cron-polling-event-dispatch.md)) |
 | `source.system` | `gitlab` (new enum value) |
 | `repo` slug | Nested group path (`group/subgroup/project`) — requires wider `repo_path` pattern |
 | MR events | `merge_request_event` → `entity.kind: change_proposal` |