feat(#6077): split GitLab poller into independent slash and event schedules

[fullsend-ai-coder]

Summary

Split the GitLab poller from a single auto-promoting schedule into two independent schedules with separate resource groups, fixing both the kill-on-overlap problem and the slash-command latency coupling. Also restores the --- YAML document separator after spec:inputs in both scaffold templates, fixing the zero-jobs pipeline failure on GitLab 18.11.6-ee caused by commit 04e0e929d.

Changes

• internal/cli/poll.go — Add --mode slash|events flag (also reads FULLSEND_POLL_MODE env var)
• internal/poll/poll.go — Replace shouldFullPoll auto-promote logic with explicit mode selection; remove FullPollInterval and defaultFullPollInterval
• internal/poll/events.go — Skip /fs-* notes in discoverAllEvents when mode is "events"
• internal/poll/types.go — Replace FullPollInterval time.Duration with Mode string in Options
• internal/cli/repos_gitlab.go — setupGitLabPipelineSchedules now creates two schedules with FULLSEND_POLL_MODE variables
• internal/forge/forge.go — Add Variables field to PipelineSchedule struct
• internal/forge/fake.go — Record schedule variables in FakeClient for test assertions
• fullsend-poll.yml — Restore spec:inputs + --- separator; dynamic resource group fullsend-poll-${FULLSEND_POLL_MODE}; per-mode process_mode; pass --mode to CLI
• fullsend-agent.yml — Restore --- separator after spec:inputs (bug fix)

Testing

• New tests for events-mode slash-command filtering (TestDiscoverAllEvents_EventsModeSkipsSlashCommands, TestDiscoverAllEvents_DefaultModeKeepsSlashCommands)
• Updated schedule setup tests to verify two schedules with correct crons, descriptions, and variables
• Mode-specific tests (TestRunSlashMode, TestRunEventsMode, TestRunDefaultModeIsEvents)
• All existing poll/forge tests pass; removed obsolete shouldFullPoll tests
• go vet clean on all affected packages

---

Closes #6077

Post-script verification

• Branch is not main/master (agent/6077-split-gitlab-poller)
• Secret scan passed (gitleaks — 277a2a81a1d69ffc682b61abad39957f8dc13f77..HEAD)
• PR body secret scan passed (gitleaks — no-git)

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:04 AM UTC · Completed 2:22 AM UTC

Commit: 37b6a53 · View workflow run →

[fullsend-ai-review]

Looks good to me

Previous run

Review

Findings

Low

• [input-validation-ordering] internal/scaffold/fullsend-repo-gitlab/.gitlab/ci/fullsend-poll.yml:15 — The resource_group field interpolates $FULLSEND_POLL_MODE at YAML evaluation time, before the case-statement validation in the script block (line 71). If a Maintainer sets FULLSEND_POLL_MODE to an unexpected value, it would create a spurious resource group name. Risk is well-mitigated: the variables: block default ensures a valid fallback (events), schedule-level variables take precedence, and the case statement aborts the job before any meaningful work.

Previous run (2)

Review

Findings

Low

• [input-validation-ordering] internal/scaffold/fullsend-repo-gitlab/.gitlab/ci/fullsend-poll.yml:15 — The resource_group field interpolates $FULLSEND_POLL_MODE at YAML evaluation time, before the case-statement validation in the script block (line 67). If a Maintainer sets FULLSEND_POLL_MODE to an unexpected value, it would create a spurious resource group name. Risk is well-mitigated: the variables: block default ensures a valid fallback (events), schedule-level variables take precedence, and the case statement aborts the job before any meaningful work.

• [undocumented-architectural-decision] internal/cli/repos_gitlab.go — The process_mode selection logic (oldest_first for events resource group, newest_first for slash) is partially documented in scaffold code comments but not in the ADR 0067 GitLab: split poller into independent slash-command and event-discovery schedules #6077 update block. The ADR notes per-mode resource groups but doesn't explain why each mode uses a specific process_mode.
  Remediation: Add detail to the ADR 0067 GitLab: split poller into independent slash-command and event-discovery schedules #6077 update block explaining the process_mode selection rationale (e.g., "slash polls use newest_first so the latest command takes precedence; event polls use oldest_first so long-running discovery completes").

• [naming-inconsistency] docs/guides/infrastructure/infrastructure-reference.md:255 — The watermark variables FULLSEND_LAST_POLL_AT_FAST and FULLSEND_LAST_POLL_AT_FULL are described as "legacy name" which could suggest deprecation. The variables are actively used; only the terminology mapping changed (fast→slash, full→events).
  Remediation: Replace "legacy name" with a clearer qualifier, e.g. "variable name predates the slash/events terminology split".

---

Labels: PR modifies Go code across the polling subsystem, install-time schedule setup, and forge interfaces.

Previous run (3)

Review

Findings

Low

• [comment-accuracy] internal/cli/repos_gitlab.go:296 — The function-level doc comment for healGitLabResourceGroups says "The toggle sequence (unordered → newest_first)" but the code now conditionally selects oldest_first for the fullsend-poll-events resource group. The comment describes the algorithm inaccurately.
  Remediation: Update the comment to reflect the mode-aware target, e.g. "The toggle sequence (unordered → target mode) forces GitLab to re-evaluate the lock state and release stale locks."

• [input-validation-ordering] internal/scaffold/fullsend-repo-gitlab/.gitlab/ci/fullsend-poll.yml:15 — The resource_group field interpolates $FULLSEND_POLL_MODE at YAML evaluation time, before the case-statement validation in the script block (line 71). If a Maintainer sets FULLSEND_POLL_MODE to an unexpected value, it would create a new resource group name. Risk is well-mitigated: rules clause restricts to schedule+protected-branch, only Maintainers can edit schedule variables, job-level default ensures fallback to events, and the script validates before any sensitive operations.

• [naming-consistency] internal/scaffold/fullsend-repo-gitlab/.gitlab/ci/fullsend-poll.yml:23 — The scaffold template hardcodes FULLSEND_POLL_MODE: "events" as a job-level variable alongside per-schedule variables. This is intentional defense-in-depth (ensures a sensible default for manual triggers and the resource_group interpolation) but creates a subtle layering question about where mode selection authority lives.

• [inconsistent-terminology] docs/guides/infrastructure/infrastructure-reference.md:255 — Variable descriptions for FULLSEND_LAST_POLL_AT_FAST and FULLSEND_LAST_POLL_AT_FULL still use the old "fast poll" and "full poll" terminology instead of the new "slash poll" and "event poll" terminology. The variable names remain unchanged for backward compatibility, so this is mild.
  Remediation: Update descriptions to use the new terminology.

Previous run (4)

Review

Findings

Low

• [error-handling-idiom] internal/cli/poll.go:64 — Error message --mode must be 'slash' or 'events' doesn't acknowledge the env var source. Users setting FULLSEND_POLL_MODE via environment may see a confusing reference to --mode.
  Remediation: Update error to acknowledge both sources, e.g. invalid poll mode %q: must be "slash" or "events".

• [stale-doc] docs/guides/infrastructure/infrastructure-reference.md:256 — FULLSEND_POLL_MODE is a new pipeline schedule variable introduced by this PR but is not documented in the infrastructure reference. Note: FULLSEND_LAST_POLL_AT_FULL is still actively used and should NOT be removed.
  Remediation: Consider adding a note about FULLSEND_POLL_MODE as a pipeline schedule variable.

Previous run (5)

Review

Findings

Low

• [logic-error] internal/scaffold/fullsend-repo-gitlab/.gitlab/ci/fullsend-poll.yml:12 — The resource_group uses bash parameter expansion syntax ${FULLSEND_POLL_MODE:-events}. GitLab's keyword-level variable expansion (applied before the runner shell) only supports $variable and ${variable} forms, not bash defaults like :-. When FULLSEND_POLL_MODE is unset, the fallback may not work as intended at the resource_group level. In practice this is low-risk because pipeline schedules always set FULLSEND_POLL_MODE explicitly (both schedules are created with the variable set during install), so the default is only relevant for manually triggered pipelines.
  Remediation: Add a job-level variables: block that sets FULLSEND_POLL_MODE: events as a default (job-level variables are expanded before resource_group), or use $FULLSEND_POLL_MODE without the default and rely on the script-level validation.

• [logic-inconsistency] internal/poll/poll.go:66 — When Mode is empty (backward compatibility), the else branch logs poll mode: events (full discovery). However, empty mode behaves differently from explicit "events" mode: it does NOT filter /fs-* slash commands from discovered notes (the filter in events.go checks p.opts.Mode == "events" explicitly). An operator seeing "poll mode: events" in logs would expect /fs-* notes to be filtered, but they are not.
  Remediation: Add a third log branch for empty mode, e.g. poll mode: events (full discovery, legacy — no /fs-* filtering).

Previous run (6)

Review

Findings

Medium

• [logic-inconsistency] internal/poll/types.go:16 — The Mode field comment says empty defaults to "events" (full discovery) and poll.go's Run() docstring says "": defaults to "events" for backward compatibility. However, when Mode is empty, discoverAllEvents does NOT filter out /fs-* slash commands — the filter condition checks p.opts.Mode == "events", not p.opts.Mode != "slash". Empty-mode behavior includes slash commands in event discovery, while explicit events mode filters them out. The test TestDiscoverAllEvents_DefaultModeKeepsSlashCommands confirms this is intentional (backward compatibility), but the comments claim equivalence that does not hold at runtime.
  Remediation: Update the Mode field comment in types.go and the Run() docstring in poll.go to clarify that empty mode uses the events watermark and discovery path but does not filter /fs-* notes (backward compatibility with pre-dual-schedule installations). Also update ADR 0067's GitLab: split poller into independent slash-command and event-discovery schedules #6077 update block which states "empty defaults to events" without qualification.

Low

• [outdated-architecture-reference] docs/ADRs/0067-gitlab-cron-polling-event-dispatch.md:384 — The "MR note limitation (fast-poll)" section describes MR notes being processed "during the full-poll cycle", referencing the pre-GitLab: split poller into independent slash-command and event-discovery schedules #6077 single-schedule auto-promotion model. The GitLab: consolidate fast/full poll into a single schedule #5959 update (now struck through) already lists this section as superseded, but the original body text is unannotated.
  Remediation: Add this section to the GitLab: split poller into independent slash-command and event-discovery schedules #6077 update note's list of superseded items, or add a brief inline annotation.

• [ambiguous-architecture-reference] docs/ADRs/0067-gitlab-cron-polling-event-dispatch.md:372 — The "Slash command latency" section references "Multi-frequency polling" which was superseded by GitLab: consolidate fast/full poll into a single schedule #5959 and now partially restored (with different cron patterns and resource group names) by GitLab: split poller into independent slash-command and event-discovery schedules #6077, without clarifying the current status of the reference.

Previous run (7)

Review

Findings

Low

• [scope-creep] internal/cli/repos_gitlab.go:253 — Rollback logic (delete slash schedule on event schedule creation failure) is not explicitly specified in issue GitLab: split poller into independent slash-command and event-discovery schedules #6077 but is a standard defensive pattern for multi-step resource creation. Well tested with both success and failure paths.

• [adr-annotation] docs/ADRs/0067-gitlab-cron-polling-event-dispatch.md:331 — Uses strikethrough to mark the GitLab: consolidate fast/full poll into a single schedule #5959 update as superseded. No established convention for inline update supersession in this repo, though strikethrough appears elsewhere (ADR 0027).

• [scope-creep] internal/forge/forge.go — Variables field added to PipelineSchedule is a minor scope expansion not in the issue's file list. Necessary supporting change for test verification of schedule-level variables.

• [scope-creep] internal/forge/fake.go — CreatePipelineScheduleErrSeq is new test infrastructure not mentioned in the issue. Supports the rollback error-path test.

Previous run (8)

Review

Findings

Medium

• [inconsistent-defaults] internal/scaffold/fullsend-repo-gitlab/.gitlab/ci/fullsend-poll.yml:17 — The resource_group key uses raw ${FULLSEND_POLL_MODE} without a default fallback, while all shell-level references (case validation at line 72, self-heal curl at line 90, --mode CLI flag at line 103) use ${FULLSEND_POLL_MODE:-events}. If a pipeline fires without FULLSEND_POLL_MODE set (legacy schedule from a pre-upgrade install), the job runs in resource group fullsend-poll- (empty suffix) while the self-heal curl targets fullsend-poll-events — different resource groups.
  Remediation: Change line 17 to resource_group: "fullsend-poll-${FULLSEND_POLL_MODE:-events}" to match all other references.

• [process-mode-mismatch] internal/cli/repos_gitlab.go:300 — healGitLabResourceGroups (not modified by this PR) unconditionally sets all fullsend-* resource groups to newest_first. With the new dual-schedule architecture, fullsend-poll-events should use oldest_first (as specified in the scaffold's self-heal at fullsend-poll.yml lines 85–87). On re-install, the heal function overrides the events resource group to newest_first. Impact is limited: the scaffold self-heal corrects this on the next poll job run.
  Remediation: Update healGitLabResourceGroups to use oldest_first for resource groups matching fullsend-poll-events, or make it mode-aware.

Low

• [test-coverage-gap] internal/poll/events_test.go — TestDiscoverAllEvents_EventsModeSkipsSlashCommands tests /fs-* filtering but does not test notes with leading whitespace before /fs-. The production code uses strings.TrimSpace before HasPrefix, so whitespace-prefixed slash commands are also filtered — a test confirming this edge case would strengthen coverage.

• [commit-convention] — PR title uses feat(#6077) but the change restructures internal polling architecture. The --mode flag is on a hidden command and schedules are configured by the installer, not users. Per COMMITS.md, refactor or fix may be more accurate — though feat is defensible given the genuinely new behavior (explicit mode selection, dual resource groups).

• [scope-creep] internal/forge/forge.go — Adding Variables field to PipelineSchedule is a minor scope expansion not in the issue's file list. Necessary supporting change for test verification of schedule-level variables.

• [scope-creep] internal/forge/fake.go — CreatePipelineScheduleErrSeq is new test infrastructure not mentioned in the issue. Supports the rollback test for the event schedule creation failure path.

• [naming-consistency] internal/poll/types.go:17 — Mode field accepts "events" (plural) while schedule description is "fullsend event poll" (singular). Internally consistent within each context — "events" describes the mode category, "event poll" is a human-readable schedule name.

• [missing-doc] docs/guides/infrastructure/infrastructure-reference.md:257 — GitLab variables section does not mention FULLSEND_POLL_MODE. This is a schedule-level pipeline variable set automatically by the installer, not a user-configured CI/CD project variable, so its absence from the CI/CD variables list is understandable. Could be useful in a troubleshooting context.

---

Labels: PR modifies GitLab polling subsystem and install-time schedule setup

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (9)

Review

Findings

High

• [no-rollback] internal/cli/repos_gitlab.go:242 — setupGitLabPipelineSchedules creates two schedules sequentially. If the slash schedule (first CreatePipelineSchedule call) succeeds but the events schedule (second call) fails, the function returns an error leaving the slash schedule orphaned. The orphaned schedule will run every 5 minutes triggering slash-only polls with no corresponding events schedule, leaving the system in a degraded state where label events and MR merges are not discovered.
  Remediation: Delete the successfully-created slash schedule if the second CreatePipelineSchedule call fails before returning the error, matching the defensive cleanup pattern already used at the top of the function.

• [stale-doc] docs/ADRs/0067-gitlab-cron-polling-event-dispatch.md:322 — The GitLab: consolidate fast/full poll into a single schedule #5959 update note (lines 322–337) states that FULLSEND_POLL_MODE was "eliminated" and the dual-schedule architecture was "replaced by a single */5 * * * * schedule with automatic full-poll promotion." This PR directly reverses that change by re-introducing FULLSEND_POLL_MODE, creating two independent schedules, and removing the auto-promote logic. The update note is now actively misleading. The surrounding multi-frequency polling section (lines 306–320) also needs reconciliation.
  Remediation: Add a new update note (e.g., > **Update (2026-08, #6077):**) documenting the revert to independent schedules with explicit FULLSEND_POLL_MODE=slash|events, the new cron patterns, per-mode resource groups, the --mode CLI flag, and the removal of auto-promote. Mark the GitLab: consolidate fast/full poll into a single schedule #5959 note as superseded.

Medium

• [default-mode-mismatch] internal/scaffold/fullsend-repo-gitlab/.gitlab/ci/fullsend-poll.yml:91 — The YAML template defaults FULLSEND_POLL_MODE to slash via --mode "${FULLSEND_POLL_MODE:-slash}", but the Go code (types.go) documents that an empty Mode defaults to events (full discovery). In normal operation the CI variable is always set by the schedule, so this only fires if someone manually triggers the pipeline without the variable. The slash default is arguably safer (narrower scope), but the divergence from Go-side documentation creates a maintenance hazard.

Low

• [injection] internal/scaffold/fullsend-repo-gitlab/.gitlab/ci/fullsend-poll.yml:74 — FULLSEND_POLL_MODE is interpolated into the curl URL path (resource_groups/fullsend-poll-${FULLSEND_POLL_MODE}) without shell-level validation. The Go CLI validates the mode to slash or events, but the curl command runs before the Go command in the script. Risk is mitigated by schedule source restriction and Maintainer access requirements, but a shell-level guard would provide defense in depth.

• [stale-reference] internal/cli/repos_gitlab_test.go — TestCleanupGitLabPipelineSchedules uses old schedule descriptions (fullsend fast poll, fullsend full poll) as test fixture data. The cleanup function uses strings.HasPrefix(s.Description, "fullsend") so the test still passes and exercises the correct behavior, but the fixture names should be updated to reflect the current naming.

• [variable-naming] internal/cli/repos_gitlab.go:241 — Minor naming asymmetry: variable eventsID uses plural but the schedule description is fullsend event poll (singular). Consider eventID for consistency, or keep as-is to match the mode name events.

• [stale-doc] docs/guides/getting-started/operations.md:84 — GitLab uninstall section says "Delete fullsend pipeline schedules." The plural wording is technically correct, but could be clearer now that there are two named schedules (fullsend slash poll and fullsend event poll).

• [commit-convention] — PR title uses feat(#6077):. Could alternatively be fix(#6077): since the primary motivation is fixing kill-on-overlap and latency coupling bugs from feat(#5959): consolidate GitLab poll into single auto-promoting schedule #6074. Either classification is defensible.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 2:32 AM UTC · Ended 2:39 AM UTC

Commit: b3f5e6e · View workflow run →

[github-actions]

Site preview

Preview: https://85e12572-site.fullsend-ai.workers.dev

Commit: fb6b9427d55647bbf22c9fb6817d79967e20fbfc

[codecov]

Codecov Report

❌ Patch coverage is 80.85106% with 9 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/forge/fake.go	25.00%	4 Missing and 2 partials ⚠️
internal/cli/repos_gitlab.go	89.47%	1 Missing and 1 partial ⚠️
internal/cli/poll.go	87.50%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:40 AM UTC · Completed 3:00 AM UTC

Commit: a5bb3a5 · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 3:09 AM UTC · Completed 3:26 AM UTC

Commit: 871483e · View workflow run →

Superseded by updated review

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 11:20 AM UTC · Completed 11:37 AM UTC

Commit: a3b6268 · View workflow run →

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 1:03 AM UTC · Completed 1:17 AM UTC

Commit: fb6b942 · View workflow run →

[fullsend-ai-retro]

Retro: PR #6078 — Split GitLab poller into independent slash and event schedules

Timeline

Time (UTC)	Event
Aug 11 01:33	ggallen opens #6077 with detailed spec (3 problems, exact file list, mode table)
Aug 11 01:34	Triage agent runs (#31449663825), classifies as high severity
Aug 11 01:43	ggallen invokes /fs-code
Aug 11 01:44–02:03	Code agent runs (#31450212057), creates PR in 19.5 min, 1 iteration, $7.33
Aug 11 02:04–03:26	First two review rounds: 5 findings (1 high, 1 medium, 3 low). ggallen pushes fixes. Agent approves, ready-for-merge applied.
Aug 11 11:19–13:26	ggallen pushes further refinements. 8 more review runs produce inline findings on GitLab variable expansion, log consistency, error messages, and doc terminology.
Aug 11 12:13	ggallen approves
Aug 11 14:01–Aug 12 01:01	15 merge queue attempts over 11 hours. 12 failures from flaky TestAdminInstallUninstall, 6 from functional test flakes. Attempt 12 hit GCP quota exhaustion (HTTP 429 on WIF provider).
Aug 12 01:01	Merged

What went well

• Code agent performance was strong. Completed in a single iteration (of 2 allowed), touching 16 files (+374/−189 lines) in 19.5 minutes for $7.33. The extremely well-specified issue (exact files, mode table, event routing matrix) contributed significantly.
• Review agent caught real platform-specific issues. Best findings: GitLab resource_group: doesn't support bash ${VAR:-default} syntax (fixed by moving default to job-level variables: block); empty mode logging misrepresented actual behavior; error message referenced --mode flag but not FULLSEND_POLL_MODE env var. These are subtle platform-semantics catches.
• Review precision was reasonable. 10 of 16 distinct findings were genuinely useful (62.5%). No clear false positives — the low-value findings (naming nitpicks, cosmetic test fixtures) identified real characteristics but weren't worth fixing.

Evidence for existing open issues

• e2e: TestAdminInstallUninstall flaky — triage dispatch not detected within 60s polling window #6005 (closed Aug 7) — TestAdminInstallUninstall flake has regressed. The exact same failure mode ("triage workflow should have been dispatched in .fullsend repo" with insufficient polling timeout) caused 12 of 14 merge queue ejections across this PR and at least 4 others (feat(#3697): add on_failure mode for comment.completion status notifications #5736, refactor(runtime): register opencode as a stub runtime #6035, perf(#6059): make LiveGCFClient poll delay injectable for tests #6062, perf(#6060): make CreateWithRetry sleep injectable for tests #6066). The fix from 5 days ago did not hold.
• Review agent should carry forward unresolved medium+ findings across commit iterations #4956, Re-post review findings when prior REQUEST_CHANGES was dismissed #2918 — High-severity finding lost in dismissed review. The review agent's only high-severity finding (no-rollback on dual schedule creation) was in the first dismissed review and never received an explicit response. These issues propose carrying forward unresolved medium+ findings and re-posting after dismissal.
• Review agent should deduplicate findings across re-review iterations on the same PR #2959, Review agent should deduplicate findings across iterations on the same PR #1013, Review agent: persistent finding cache for cross-iteration deduplication and dismissal enforcement #2816 — Finding re-raised 3 times with identical text. The input-validation-ordering finding appeared in 3 separate review rounds with nearly identical wording, creating noise for the human reviewer.
• Reduce review dispatch frequency during rapid fix-commit iterations #4069, Review agent posts diminishing-value findings after approval #3025, Review agent surfaces new low-severity findings across multiple approved passes #1367 — 10 review runs with diminishing returns. Later review rounds produced only low/cosmetic findings or re-raised previous ones. The agent's useful findings were concentrated in rounds 1–3.
• code agent: invoke review agent in a pre-PR self-review loop (max 3 iterations) #1088 — Pre-PR self-review would have reduced iterations. 5 of the code agent's initial issues could have been caught by a self-review loop before PR creation, potentially cutting review rounds in half.

Proposals filed

• E2E tests lack GCP resource quota protection under merge queue retry pressure (in fullsend-ai/fullsend)